Forecast

1. Automated Contract Driven Development with UML’s OCLJames W. Dzidek, Ph.D. Candidatedzidek@simula.nohttp://www.simula.no

2. Forecast • Will advocate the use of Analysis & Design by Contract to obtain software of higher quality faster.

3. Outline • Motivation & Definitions • Contract Driven Development (CDD) • Introduction to OCL • Examples • ocl2j: A prototype

4. Advantages of CDD • Better designs are achieved. • The reliability is improved. • The documentation is better. • Debugging is easier. • Support for reuse is better. • Control over inheritance.

5. OO Systems & Testing • OO systems are harder to test at an system-level and integration testing, (not unit-level testing) due to encapsulation and information hiding (masking of errors). • Inheritance is not necessarily detrimental to error masking; however, when combined with information hiding, it may become lethal. • A testing technique is necessary helps with this masking, i.e., that reveals defects before software release.

6. Assertions • Assertions are functions that evaluate to True when a program state appears to be satisfactory, and False otherwise. • E.g. A certain integer has a positive value: assert(x>=0) • They are a means of boosting testing’s value where masking errors are most likely. • Complementary to other software testing techniques. • “An assertion can never decrease the propagation condition, but can only improve or make no change to it, which is important for thwarting the negative impact of information hiding.” J. Voas

7. Contracts – Definitions 1/2 • Analogous to contracts as used in human affairs. • Contracts are a more sophisticated version of assertions. • Goals: Specify operations so that caller/client and callee/server operations share the same assumptions. • A contract specifies constraints that the caller must meet before using the class as well as the constraints that are ensured by the callee when used.

8. Contracts – Definitions 2/2 • Two types of constraints involved in contracts: Operation Preconditions and Postconditions. • Contracts should be specified, for known operations, at the Analysis stage – starting with system level operations in boundary classes. • Deals with software-to-software communication, not software-to-human or software-to-outside-world.

9. Usage of Contracts • Analysis/Design: Understand and document clearly operations’ intent and purpose. • Coding: Guide programmer to an appropriate implementation (i.e. method). • System robustness: Check invariants and pre-conditions at run time before the execution of operations, possibly raise exceptions and display error messages. Post-conditions can also be checked after the completion of operations. • Testing: Verify that the method does what was originally intended. • Almost never used on deployed systems.

10. Operation Pre- and Postconditions • Precondition: What must be true before executing an operation. • Postcondition: Assuming the pre-condition is true, what should be true about the system state and the changes that occurred after the execution of the operation. • These conditions have to be written as logical (Boolean) expressions. • Thus, system operations are treated as black boxes. Nothing is said about operations’ intermediate states and algorithmic details. • If the pre- and postconditions are satisfied, then the class invariant must be preserved. • Stereotypes of UML constraints: <<precondition>>, <<postcondition>>.

11. DbC: Rights & Obligations Contractor :: put (element: T, key: STRING) -- insert element x with given key

12. Precondition Example /** * @pre x > 0 */ publicfloat sqrt(float x) { ... }

13. Class Invariant • Consistency constraints characterizing the semantics of a class. • Condition that must always be met by all instances of a class. • Described using that an expression that evaluates to true if the invariant is met. • Invariants must be true before and after the execution of a public operation in the context class and after the execution of a constructor. • A violated invariant suggests an illegal system state. • Stereotype of UML constraints: <<invariant>>.

14. Invariant Example /** * @inv: 0 <= count and count <= capacity */ publicclass Stack { int capacity; int count; ... }

15. Six Principles for Writing Contracts • Separate queries from commands. • Separate basic queries from derived queries. • Write a postcondition for each derived query that specifies what result can be returned. • Write a postcondition for each command that specifies the value of every basic query. • Decide on a suitable precondition for every query and command. • Write invariants to define unchanging properties of objects.

16. The Object Constraint Language 1/2 • Formal, mathematical language. • Inspired by the work on formal methods. • Part of UML since version 1.1. • Motivation: UML diagrams are not precise enough for a precise and unambiguous specification. • Not a programming language but a typed, declarative language: expressions can have no side-effects. • Uses: invariants, pre/post conditions, guards, etc… • OCL contains all set operators and logic connectives.

17. The Object Constraint Language 2/2 • Constraints on UML model elements: conditions that must be true about some aspect of the system. • Precise constraints make the analysis more precise and rigorous: Communication without misunderstanding. • Complement the UML graphical notation by associating properties with model elements (e.g., methods, classes, transitions). • Help verification and validation of models. • The focus here is on a specific use of constraints: Contracts and Invariants.

18. OCL Example Company Person * age : Integer person All the employees of the company must be over 16 years of age. context Company inv: self.person->forAll(age > 16)

19. Contracts and Inheritance 1/2 • Subclassing vs. subtyping. • Liskov Substitution Principle (LSP):A subtype must require no more and promise no less than its supertype. • Benefits of generalization arise from the substitutability principle: Subclass object can be used in place of a superclass object in any part of the code where the superclass object is accessed.

20. Contracts and Inheritance 2/2 • However, and unfortunately, the inheritance mechanism may be used in a way that defeats the benefits of the substitutability principle. • Contracts can check to see if the subtype is properly implemented! • The precondition is weakened and the postcondition is strengthened.

21. LSP Example

22. Example: Power & Simplicity of OCL A Person P working for company C can only be part of Project B as long as company C participates in Project B. context Person inv: company->includesAll(projects)

23. Recent Findings 1/4 • Investigating the Use of Analysis Contracts to Improve the Testability of Object Oriented Code. • Can instrumented contracts be used as a substitute to hard-coded test oracles in the test drivers? • Can instrumented contracts be used to significantly lower the effort of locating faults after the detection of a failure?

24. Recent Findings 2/4 • In roughly 80 percent of the cases, contracts were good enough substitutes to hard-coded oracles in test drivers. • The contracts don’t have to be highly precise to be very useful. • Diagnosability improved nearly an order of magnitude between mutant programs without contract assertions and the ones with contract assertions, regardless of the level of precision.

25. Recent Findings 3/4 • A Controlled Experiment on the Impact of the Object Constraint Language in UML-based Development. • Experiment with 4th year software/computer engineering students who received a very thorough training in UML and OCL. • Studied the impact of using OCL on three variables capturing the capability to: • Detect defects in a UML models while inspecting them. • Answer questions about the underlying logic of the system. • Perform an impact analysis of changes using the UML model.

26. Recent Findings 4/4 • Results show that OCL has a positive impact on the three abovementioned variables. • Effect can be very large (e.g., up to a 122% increase for maintenance). • OCL had the potential to significantly improve people’s ability to inspect and modify UML models, but that this required significant training and experience. • It is unlikely that people will benefit from using OCL in UML models unless they have proper training.

27. ocl2j • Currently there’s very little support for OCL in commercial tools. • My master’s thesis: Using AOP toInstrument OCL Contracts in Java. • Only a prototype, but it showed a lot of potential. • Support for almost the entire OCL language was implemented. • Potential for optimizations was shown (e.g. the forAll operation).

28. Program Bytecode Ocl2jAspect UML Model with OCL Constraints ocl2j Approach Overview Stage 1: Contract Code Generation ocl2j Tool

29. Program Bytecode Ocl2jAspect UML Model with OCL Constraints Instrumented Bytecode ocl2j Approach Overview Stage 1: Contract Code Generation ocl2j Tool Stage 2: Program Instrumentation Aspect Weaver

30. Summary By using contracts… • Better designs are achieved. • The reliability is improved. • The documentation is better. • Debugging is easier. • Support for reuse is better. • Control over inheritance. • Contracts are not a luxury, but a necessity!

31. References • Design by Contract by Example by Richard Mitchell, Jim McKim • The Object Constraint Language: Getting Your Models Ready for MDA, Second Edition by Jos Warmer, Anneke Kleppe • Object-Oriented Software Construction (2e) by Bertrand Meyer • Interviews with Bertrand Meyer on CDD: • http://www.artima.com/intv/serious.html • http://www.artima.com/intv/contracts.html • http://www.artima.com/intv/contest.html • Research articles on UML & OCL: http://www.sce.carleton.ca/faculty/briand/pubs.html • More specific references are found in the notes of the slides.