OCL Tools Supervised by Prof. Daniel Amyot

1. Submitted to Professor Daniel Amyot in partial fulfillment of the requirements for the course CSI 5112 OCL ToolsSupervised by Prof. Daniel Amyot May Khalil Nadia Spido

2. Outline • Project context and goals • Methodology • Candidate tools • Previously analyzed Dresden • OCLE • Octopus • Evaluation criteria • Experiments • Summary and recommendation

3. Project Context Development of Academic Control System • Maple University • Software Development Research Group • Support from private company • Interest in OCL: • exploration • establishment in software development

4. Project Goals • Moving towards MDA approach, where the models play a central role in presenting abstractions of real-world systems • therefore, we focus on the use of high precision OCL-based UML models, to help: • designers make up a coherent model of the problem domain, • developers making use of the implementation of an OCL specification, which will reduce the development, testing and maintenance effort • Support to free software and open source development

5. Methodology • Module “Courses Registration” chosen

6. Methodology - Courses Registration simple design

7. Methodology – Sample Constraints • A course can not be a direct pre-requisite of itself • The attribute name for courses must be unique • In order to register in a course in a different level from the student's level, a student must have an explicit authorization context Student inv diffLevel: regs->select(regcourse_offered.course.level <> self.level)->forAll((auths ->select(authcourse_offered.course.id = regcourse_offered.course.id))->notEmpty) • A student can not be registered for a course if he or she has already passed that course

8. Methodology - Evaluation • Similar experiments applied to both tools • Assign evaluation marks : • for low level criteria (L) the weight is 1 • for high level criteria (H) the weight is 2

9. Previously analyzed tool Dresden OCL Toolkit • Initially good candidate tool • Did not work: 1) Standalone version does not load models 2) Eclipse Plugin needs generation and didcompile, no stable version • Documentation is poor

10. Candidate Tools • OCL Environment • OCL Tool for Precise UML Specifications

11. OCLE • Started in the 90’s • LCI team from BABEŞ-BOLYAI UNIVERSITY - CLUJ-NAPOCA, ROMANIA • UML CASE Tool for both static and dynamic OCL Checking

12. Octopus • Started in the 90’s • Jos Warmer and Anneke Kleppe - authors of famous UML and OCL books • OCL Tool for static check OCL expressions

13. Evaluation Criteria • Integration • Number of integration with case tools and type of Integration (H) • Validation and Verification • Syntactical analysis (H) • Typechecking (H) • Logical consistency checking (L) • Dynamic behavior validation (L) • Parsing (L) • Transformation • Uml Class Diagrams to Java Code (H) • Documentation • Provided examples and Efficiency, completeness , and clarity of documentation (H)

14. GRL

15. 1.Integration • Currently each modeling tool uses its own dialect of the UML interchange format XMI. It is therefore very difficult to create an XMI import functionality that works correctly for each UML model • Octopus is an Eclipse plug-in • Both tools exchange UML models with ArgoUML • OCLE USE • Octopus  Poseidon

16. Octopus Tool

17. OCLE Tool

18. 2. Validation and Verification • OCLE Demo • Octopus Demo

19. 1-Syntactical analysis - Octopus

20. 1-Syntactical analysis - OCLE

21. 2-Typechecking - Octopus As OCL constraints always make reference to an underlying class model, an OCL typechecker has to have access to the underlying UML model information.

22. 2-Typechecking - OCLE

23. 3-Logical consistency - Octopus As was expected non of the tools respond to the contradiction of OCL Constraints

24. 3-Logical consistency - OCLE

25. 4-Dynamic Checking - Octopus • The tool imported the object class diagram successfully BUT: • the OCL constraints were not evaluated against the corresponding instance model (object diagram)

26. 4-Dynamic Checking - OCLE

27. 5-Parsing Octopus • context Course • inv CUniqueN: Course::allInstances()->isUnique(name)

28. 5-Parsing - OCLE

29. 3. Transformation • correspondence and traceability • presentation of generalization relations • handling of associations directions • representation of collections • getters, setters or any additional methods • Compilation • Code generation for OCL constraints

30. Uml Class Diagrams to Java Code -Octopus

31. Uml Class Diagrams to Java Code -OCLE

32. Summary and recommendation • The evaluation was applied to the candidate tools aiming at the use of OCL as a facilitator resource for modeling and developing the academic system. • OCLE has the dynamic checking, Octopus is an Eclipse plug-in. So it is recommended to benefit from both tools for better checking OCL and building the code.

33. References • Dresden OCL Toolkit:http://dresden-ocl.sourceforge.net/ • OCLE – Object Constraint Language Environment: http://lci.cs.ubbcluj.ro/ocle/index.htm • http://www.klasse.nl/octopus/index.html • BAAR, T., et al. Tool Support for OCL and Related Formalisms – Needs and Trends, 2005 • GOGOLLA, M., et al. Tool Support for Validating UML and OCL Models through Automatic Snapshot Generation, 2003 • HUSSMANN, H., et al. Modular architecture for a toolset supporting OCL, 2002 • CLARK, T. AND WARMER, J. Object Modeling with the OCL, 2002, pp. 59-68 • DZIDEK, W. et al. Lessons Learned from Developing a Dynamic OCL Constraint Enforcement Tool for Java, 2005 • JOS WARMER, ANNEKE KLEPPE. The Object Constraint Language ISBN 0-201-37940

34. Thank you Questions ?