1. Multi-view Consistency Checking of BON Software Description Diagrams
Good afternoon, everybody. Thank you for coming my oral examination. Today my topic is “Multi-view Consistency Checking of BON Software Description Diagrams” based on my thesis
Presented By:
Yan Gao
July 19, 2004

2. Outline Introduction BON & BON metamodel
Constraints for multi-view consistency checking
The BCCT tool
In this presentation, firstly, I will introduce why do we need consistency checking in modern software engineering, the category of model consistency and which part the thesis will focus on. Then, I will describe the modelling language we used in the thesis – BON and its metamodel briefly. The metamodel of a model language is used to express the well-formedness constraints that all legitimate models written in the notation must obey. I will introduce the constraints we used in the thesis to guarantee multi-view consistency. In the thesis, we mapped those contraints into algorithms and implemented them in a consistency checking tool – The BCCT tool, The BON Consistency Checking Tool. At last, I will discuss the contribution of the thesis and possible future work.
New Design Method: CDD
Conclusion & Future work

3. Introduction Try if can animate it
Imagine that you are building your dream home. You hire an architect to draw up the blueprints . In the elevation view you specify a window facing west with a beautiful sea view. In the plan view the architect omits the window. These two views are now inconsistent with each other. If the builder uses the plan view to construct the floors, walls, windows and doors, then the window may actually be omitted in the actual construction. Fixing it at a later date may also prove much costlier than getting it right the first time.
The same problem exists in Modern Software developing. Software Engineers have suggested Modelling will clearly aid us in developing better quality code.
The UML standard (v1.3) states: “Every complex system is best approached through a small set of nearly independent views of a model; no single view is sufficient.” Those views maybe inconsistency themselves or with each other.

4. Single-view Consistency
Introduction
Model Consistency A
Single-view Consistency X B C
The first category of model consistency is single-view consistency.
Single-view consistency describes the constraints that must exits in a single view to make that view legal – such as no name clashes,no inheritance cycles.
If a class B inherit from class A and class C inherits form class B, then class A can not inherit from class C.

5. Introduction Model Consistency Single-view Consistency
Multi-view Consistency
Single-view Consistency
Multi-view consistency deals with if two different views consistent or not. In the thesis, we divided it into syntactic and contractual consistency. I will introduce them a little later.
Syntactic Consistency
Contractual Consistency

6. Approaches to multi-view consistency
Mainly Informal e.g. [Glintz 2000]
Minimize overlap
Systematically cross-reference corresponding information
Formal
Paige and Ostroff
Multi-view consistency deals with if two different views consistent or not. In the thesis, we divided it into syntactic and contractual consistency. I will introduce them a little later.
Includes syntactic and contractual consistency
Based on a metamodel
ROOM4[2002] UKTEST [2003]

7. Approaches to multi-view consistency
[Krishnan 2000] extends ROOM4 to UML and OCL
Our work
Based on ROOM4 & UKTEST
Modify the metamodel
Multi-view consistency deals with if two different views consistent or not. In the thesis, we divided it into syntactic and contractual consistency. I will introduce them a little later.
Develop prototype tool
First tool to formally check multi-view consistency with contracts

8. BON & BON Metamodel Model Language Notation Metamodel
In this thesis, we use BON- Business Object Notation to present our work on consistency checking. Like other modelling language, it consists of two parts: a notation used to write models; and a metamodel which expresses the well-formedness constraints that all legitimate models written in the notation must obey. Without a precise metamodel it is difficult to explain the notation and build tools that support the notation.

9. (deposit_transaction)
BON
ROOT_CLASS
(root)
CUSTOMER
(customer) 1
ROOT_CLASS c1
CUSTOMER 3
2,4
account
customer a1
2.2 t
ACCOUNT
(account)
DEPOSIT_TRANSACTION
(deposit_transaction)
TRANSACTION
ACCOUNT
2.1
3.1
transaction:List[..]
TRANSACTION
(transaction)
BON supports two kinds of diagrams:
Static diagrams describe the structure of a system, i.e. the components and the relationships between these components
Dynamic diagrams document how the system will behave over time. A dynamic diagram consists of a set of communicating objects
DEPOSIT_TRANSACTION
Static Diagram (SD)
Dynamic Diagram (DD)

10. BON Metamodel
The metamodel is at the heart of view consistency checking techniques for BON. We refactored the metamodel presented in the previous literature to make it easier to carry out consistency checking. In this architecture, class MODEL contains a set of VIEW.Invariant clauses in MODEL are used to capture constraints for multiple view consistency checking and invariant clauses in VIEW are used to capture constraints for single-view consistency.

11. Constraints for multi-view consistency checking
consistency(v1,v2)
object-class
Syntactic Consistency
message-feature
messages-invokable
Object-class: Each object appearing in the BDD must have a corresponding class in the BSD.
Message-feature: Each message in the BDD diagram corresponds to a call of a feature in the target class, and a routine in the source class of the message makes such a call.
Message-invokable:the target feature of each message should be exported to the source class and the source class should can invoke this feature.
Contractual-consistency:it ensures that the precondition of each message in the dynamic diagram is true before the message is sent. A precondition is enabled by any prior routine calls in the dynamic diagram.
contractual-consistency

12. Object-Class a A B b
Each object in the Dynamic Diagram (e.g. a) has a corresponding class in the Static Diagram (e.g. A)

13. Message-Feature A …
f1 is do
b.f2
end B …
f2 is do
end A
(a) m B
(b) 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.

14. Contractual-consistencyB
(b)
m1, m2 A
(a) A 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.

15. Specified depth algorithm
Messages-invokable
Specified depth algorithm

16. Algorithms for multi-view consistency checking
(Specified Depth)
The BON Consistency Checking Tool
Algorithm 4-3
(generate code)

17. The BCCT Tool A BON Diagram Editor. A BON Diagram Parser.
A Consistency Checker.
The BCTT tool is not ready for industrial strength usage. Rather it is a prototype tool that allowed us to explore tool support for multi-view consistency checking and Consistency Driven Design. The tool was implemented in C# using .NET and a diagramming component for .NET called GoDiagram. Even though the tool is a prototype, its design and implementation presented many challenges as it had to support the various graphical features of BON as well as the extended BON metamodel defined in Chapter 4. The tool includes the following components:
A BON Diagram Editor. Before consistency can be checked, an editor is needed to draw the static diagrams and dynamic diagrams.
A BON Diagram Parser. This tool parses BON Diagrams to extract the information needed to check consistency. The tool stores BON Diagrams for a project in XML files (persistence).
A Consistency Checker. The tool checks the various consistency constraints using the algorithms in Chapter 4 and Chapter 5.
A Code Generator. The tool translates the model to executable code which facilitates the writing of tests cases using ETester (a unit testing feature which is also used for contract testing).
A Code Generator.

18. The BCCT tool

19. The BCCT Tool Tolerant versus Strict consistency checking
Use the BCCT editor, we add an association relationship between C and D, this problem will be solved. But if we invoke tools->message-feature, then the tool supplies another error report and we need fix again.

20. The BCCT Tool

21. The BCCT Tool

22. The BCCT Tool

23. Consistency Driven Development
Construct some small part of the model;
Run the consistency checks (which will usually fail as the model is incomplete or inconsistent);
Refactor the model to get the consistency check to pass, and re-run the checks.
The tool can be used to interactively and repeatedly construct models, automatically test for consistency and refactor the models as required. This leads to a design method that we call Consistency Driven Development (CDD).

24. 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
The main contribution of this thesis was to develop the BCCT tool (the first to our knowledge) that checks multi-view consistency between structural class diagrams and behavioural collaboration diagrams. Such a tool also opens up the possibility of using consistency to drive development as described in the previous chapter (Consistency Driven Development). The following steps were needed to make the tool a reality:
·        We formalized the notion consistency(v1,v2) of two views v1 (a static view with contracts) and v2 (a dynamic view) of a model. This definition of consistency includes notions of syntactic and contractual consistency.
·        We developed algorithms to check syntactic consistency, and incorporated these algorithms into BCCT.
·        The tool has a graphical editor which is used to construct graphical models, and specify features, contracts down to detailed body code.
·        The syntactic consistency checks are run automatically and provide details of where failures occur.
·        The model can be automatically translated to executable Eiffel code, and a testdriver is used to check contractual consistency.
Why do we need formalize the consistency(v1,v2)?????
A new design method: CDD

25. Future Work Automatic generation of testdrivers
Specified Depth Algorithm
BCCT tool
Currently, we manually create a test driver to check contractual consistency after code generated. With further study, a test driver should be generated automatically.
the algorithm actually generates all possible calls from the target feature to a specified depth, but this full capability is not used in the tool. The tool currently checks if the call actually specified in the feature body is in the generated list.
However, the algorithm could also be used to provide the designer with a list of possible calls in the list, allowing the designer to select which call to use.
The current BCCT tool is only a prototype to explore consistency checking. As such it only implements part of BON (e.g. support for expanded classes and aggregations). To be a really usefully tool, it needs more work so as to support the full range of BON modelling constructs.

26. Thanks