Multi-view Consistency Checking of

BON Software Description Diagrams

Presented By:

Yan Gao

July 19, 2004

Outline

• Conclusion & Future work

• Introduction

• BON & BON metamodel

• Constraints for multi-view consistency checking

• The BCCT tool

• New Design Method: CDD

Introduction

Office

13 sq. m.

Missing window

Plan View

Elevation View

Introduction

Model Consistency

Single-view Consistency

A

B

C

X

Introduction

Model Consistency

Multi-view Consistency

Syntactic Consistency Contractual Consistency

Single-view Consistency

Approaches to multi-view consistency

• Formal

• Mainly Informal e.g. [Glintz 2000]

• Minimize overlap

• Systematically cross-reference corresponding information

• Includes syntactic and contractual consistency

• Based on a metamodel

• ROOM4[2002] UKTEST [2003]

• Paige and Ostroff

Approaches to multi-view consistency

• Our work

• Based on ROOM4 & UKTEST

• Modify the metamodel

• Develop prototype tool

• First tool to formally check multi-view consistency with contracts

• [Krishnan 2000] extends ROOM4 to UML and OCL

BON & BON Metamodel

Model Language

Notation Metamodel

BON

ROOT_CLASS CUSTOMER

TRANSACTION ACCOUNT

DEPOSIT_TRANSACTION

c1

a1

account

customert

transaction:List[..]

ROOT_CLASS(root)

CUSTOMER(customer)

ACCOUNT(account)

DEPOSIT_TRANSACTION(deposit_transaction)

TRANSACTION(transaction)

1

2,4

3

2.1

2.2

3.1

Static Diagram (SD) Dynamic Diagram (DD)

Scenario: deposit1 create customer c12 create account a1 with c12.1 create transaction list transactions2.2 set customer’s account to a13 create a deposit transaction t for account a1 of $1003.1 add transaction t to transactions4 check balance

BON Metamodel

MODEL VIEW

VIEWS

STATIC_DIAGRAM DYNAMIC_DIAGRAM

ABSTRACTIONS RELATIONSHIPS

abs:SET[..] rel:SET[..]

OTHERS

vs:SET[..] CODE

– messages-invokable

Constraints for multi-view consistency checking

Syntactic Consistency

• consistency(v1,v2)

– object-class

– message-feature

– contractual-consistency

Object-Class

A B a b

Each object in the Dynamic Diagram (e.g. a) has a corresponding class in the Static Diagram (e.g. A)

Message-Feature

A(a)

B(b)

Each message, such as m in the DD, has to be invoked by a routine f1 in the source class A in the SD which makes a call to feature f2 in the target class B.

A…f1 isdo … b.f2 …end…

B…f2 isdo …end…

mf1 f2b

Contractual-consistency

A B A(a)

B(b)

• Check that there is at least one execution of the message sequence m1; m2 in the DD that can be executed without the contracts in the SD being violated, e.g. r1.post implies r2.pre.

• Generate code automatically and run TestDriver• Consistent if TestDriver runs without contract

violations.

m1, m2

Messages-invokable

A

r isdo

b.a.b.a.b.c.f end

C

f

B

b

ac

A(a)

C(c)

1 Scenario1: a sends message m to c

Specified depth algorithm

Algorithms for multi-view consistency checking

Algorithm 4-1

Algorithm 4-2

Algorithm 4-3

(generate code)

Algorithm 5-4

(Specified Depth) The BON Consistency

Checking Tool

The BCCT Tool

• A BON Diagram Editor.

• A BON Diagram Parser.

• A Consistency

Checker. • A Code

Generator.

The BCCT tool

The BCCT Tool

The BCCT Tool

The BCCT Tool

The BCCT Tool

Consistency Driven Development

• Refactor the model to get the consistency check to pass, and re-run the checks.

• Run the consistency checks (which will usually fail as the model is incomplete or inconsistent);

• Construct some small part of the model;

Conclusion

• Formalized the notion consistency(v1,v2)

• Developed algorithms to check consistency

• Incorporated these algorithms into BCCT – A graphical editor

– Check Syntactic consistency automatically

– Translate the model to executable Eiffel Code• A new design method: CDD

Future Work

• Automatic generation of testdrivers

• Specified Depth Algorithm

• BCCT tool