multi-view consistency checking of bon software description diagrams
Post on 22-Jan-2016
40 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related