270 likes | 473 Views
Multi-view Consistency Checking of BON Software Description Diagrams. Presented By: Yan Gao July 19 , 2004. Outline. Introduction. Conclusion & Future work. BON & BON metamodel. Constraints for multi-view consistency checking. The BCCT tool. New Design Method: CDD. Introduction.
E N D
Multi-view Consistency Checking of BON Software Description Diagrams Presented By: Yan Gao July 19, 2004
Outline • Introduction • Conclusion & Future work • BON & BON metamodel • Constraints for multi-view consistency checking • The BCCT tool • New Design Method: CDD
Single-view Consistency B X C Introduction Model Consistency A
Multi-view Consistency Contractual Consistency Syntactic Consistency Introduction Model Consistency Single-view Consistency
Approaches to multi-view consistency • Mainly Informal e.g. [Glintz 2000] • Minimize overlap • Systematically cross-reference corresponding information • Formal • Paige and Ostroff • Includes syntactic and contractual consistency • Based on a metamodel • ROOM4[2002] UKTEST [2003]
Approaches to multi-view consistency • [Krishnan 2000] extends ROOM4 to UML and OCL • Our work • Based on ROOM4 & UKTEST • Modify the metamodel • Develop prototype tool • First tool to formally check multi-view consistency with contracts
BON & BON Metamodel Model Language Notation Metamodel
BON ROOT_CLASS (root) CUSTOMER (customer) 1 ROOT_CLASS c1 CUSTOMER 3 2,4 account customer 2.2 a1 ACCOUNT (account) t DEPOSIT_TRANSACTION (deposit_transaction) TRANSACTION ACCOUNT 2.1 3.1 transaction:List[..] TRANSACTION (transaction) DEPOSIT_TRANSACTION Dynamic Diagram (DD) Static Diagram (SD)
SyntacticConsistency Constraints for multi-view consistency checking • consistency(v1,v2) • messages-invokable • 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 m B (b) A (a) A … f1 is do … b.f2 … end … B … f2 is do … end … b f1 f2 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 B Contractual-consistency B (b) m1, m2 A (a) • 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.postimpliesr2.pre. • Generate code automatically and run TestDriver • Consistent if TestDriver runs without contract violations.
Messages-invokable Specified depth algorithm
Algorithms for multi-view consistency checking • Algorithm 4-1 • Algorithm 4-2 • Algorithm 5-4 • (Specified Depth) The BON Consistency Checking Tool • Algorithm 4-3 • (generate code)
The BCCT Tool • A BON Diagram Editor. • A BON Diagram Parser. • A Consistency Checker. • A Code Generator.
Consistency Driven Development • Construct some small part of the model; • 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);
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