1

ISWIM For Testing

–A Model Driven

Approach

Tony Clark

tony.clark@tvu.ac.uk

http://itcentre.tvu.ac.uk/~clark

2

Overview

•A Requirement for Constraints:

–Telecomms

–Aerospace

–Business Migration

–Information Systems, SOA

•ISWIM Constraint Representation

•ISWIM for testing

•Conclusion

3

Modelling with Constraints

4

Telecomms

5

Netw

ork

Models

Check configurations based

on properties of devices and

network components.

6

Aerospace

Message Bus

Integrated Modular Avionics (IMA)

7

IMA Models

Check configurations

of IMA components

that must satisfy

requirements of

navigation modes.

8

Payload Configurations

9

Business Processes

©Xactium

Ltd

. 2007

10

Restructuring A Company

Restructure

Company

Produce

Plans

Implement

Plans

Produce

BizRep

Develop

Plans

Produce

Restructuring

Plan

Produce

Operating

Plan

Ditch

Unprofitable

Customers

Reorganize

products

Check sequences of company

snapshots –do they satisfy the

business goals?

©Ltd

. 2007

11

Web Services and SOA

©Xactium

Ltd

. 2007

12

Information Systems

13

ISWIM Constraint Representation

14

Constraints

•W

hat not to

be: O

CL, Java.

•Vis

ual la

nguage (w

hy?), w

ith e

xam

ple

s:

–Sim

ple

sta

te.

–Variable

s.

–And/O

r/N

ot

–Q

uantification

–Pre

dic

ate

s.

15

Snapshots

•O

bje

cts

, slo

ts a

nd lin

ks.

•C

onte

xt m

ust be g

iven:

–Para

mete

rs

–R

oot obje

ct

–Self in s

tate

machin

e.

–O

bserv

ations in g

oals

.

•C

onju

nction o

f conte

nts

.

•N

egation.

16

Snapshots as Constraints

not c.business_report.terminal and

c.restructuring_plan.addresses = c.business_report

17

Sharing via Identifiers

(separation of concerns)

18

Negation

…but not ...

19

Unknowns Tied Together

…same as …

20

Links Over Collections

21

Universal Quantification

22

Existential Quantification

23

Snapshot Checking Machine

24

Syntax Model

©Xactium

Ltd

. 2007

25

An Execution Machine

26

Machine Transitions

27

Auxiliary Machine Defs

28

An Im

ple

menta

tion –

ISW

IM for M

odel D

riven T

esting

29

Testing Architecture

Program

Testing

Engine

Interface

(XML)

Test

Cases

(XML)

Test

Reports

(XM

L)

Program

Display

Test

Reports

(HTML)

Display

Test Cases

(HTML)

Model

(XMF-Mosaic)

Test cas

es includ

e:

•Static Sce

narios

•Dyn

amic Sce

narios

•Inv

ariants

•Pr

e/P

ost Con

ditions

•State

Mac

hines

C

B

A

DE

F

G

H

I

A sales system keeps info on customers, accounts and their orders.

Customer ids (CID) are unique, but custotheir mer information may be distributed.

30

31

Model Browser

A model is constructed that shows the

structure and behaviour of the

application.

The model could be extracted from

an implementation or could be

constructed by hand or could be

constructed from another modelling

tool.

The example shows the classes

extracted from a Java application.

32

Test Specification

Each class may have:

•Static scenarios defining typical

configurations of instances. These may

be positive and negative examples.

•Invariants defining conditions that

must hold true at all times.

Each operation may have specifications

defining:

•Precondition defining an expectation of

the method.

•Postcondition defining a corresponding

guarantee if the precondition is satisfied.

33

Static Scenarios

A static scenario defines a collection of

objects that conforms to the model.

The tool will support the construction of

the scenarios by completing slots and

links where possible.

Types of values can be checked by the

tool.

The scenario represents an

implementation independent definition of

application data.

It might represent a correct, or an illegal,

configuration.

The scenario can be exported in XML and

recreated as implementation data.

SomeContacts

34

Example Invariant

For any sales system,

With a contacts database,

For each known person p,

It is not the case,

That the customer id value is

EMPTY.

NoEmptyCID

35

Another Invariant

For any sales system,

With a contacts

database,

For each known

person p1,

With an id x,

It is not the case that,

There is a known

person p2,

With the id x,

Where p1 and p2 are

different people.

AllCIDsUnique

36

addContact(String id,String info)

Pre-condition

Post-condition

37

placeOrder(String id,int items)

post-condition

©Xactium

Ltd

. 2007

38

Export as XML

publicclassSalesSystem {

ContactsDB contactsDB= newContactsDB();

OrderSystem orderSystem= newOrderSystem();

publicvoidaddContact(String CID,String info) {

JTest test = JTest.startCall("test/SalesSystem","addContact",this,CID,info);

if(legal(CID)) contactsDB.addContact(CID,info);

test.endCall(null);

} publicvoidplaceOrder(String CID,intamount) {

JTest test = JTest.startCall("test/SalesSystem","placeOrder",this,CID,amount);

orderSystem.placeOrder(CID,amount);

test.endCall(null);

}}

39

Modify Source (or use class loader)

40

A Test Harness

public

staticvoidmain(String[] args) {

SalesSystem sales =

(SalesSystem)JTest.build("test/SalesSystem", "SomeContacts");

JTest.startRecording("C:/testResults.xml");

JTest.checkInv("test/SalesSystem", sales);

sales.addContact("PERSON1","Fred is a sales manager.");

System.out.println();

sales.placeOrder("PERSON1",10);

JTest.stopRecording();

}

©Xactium

Ltd

. 2007

41

Test Results

42

Conclusion

•Constraints occur everywhere in modelling

•Constraints can be expressed as snapshots

(ISWIM).

•Constraints can be executed in various

ways to suit the solution.

•ISWIM-constraints can be implemented as

a tool for model driven testing.