A Pratical Application of the Object Constraint Language OCL

Transcription

1 A Pratical Application of the Object Constraint Language OCL Kjetil Måge Agder University College Abstract. The Unified Modeling Language, UML, has for several years been the leading standard for modeling of software systems. OCL is the expression language for UML and lets you describe system structure by invariants and system behavior by pre and post conditions. There are tools that can be used to validate and verify aspects of formal OCL specifications. This paper aims to describe some of the tools available, and to demonstrate how one of these tools, the Dresden OCL Toolkit, can be used to validate and verify a simple model. 1 Introduction The Object Constraint Language, OCL, was first developed as business modeling language by IBM, and introduced as a part of UML 1.1 in UML uses a variety of diagrams for describing both static and dynamic aspects of a system. However, in many cases, a graphical model like a class diagram, is not enough for a precise and unambiguous specification. Additional constraints concerning the objects in the model need to be described. Such constraints have often been described in natural language, which has often led to ambiguities. OCL is a textual specification language, used to formally specify constraints on models in a more precise and concise way than it is possible to do with diagrams only, but without complexity of traditional formal languages. OCL uses a notation similar to object oriented programming languages like C++ and Java, and is a pure expression language. OCL expressions do not have side effects, they cannot alter the state of the system (but they can specify state changes). OCL can be used for a number of different purposes[7]: 1. To specify invariants on classes and types in the class model 2. To specify type invariant for stereotypes 3. To describe pre- and post conditions on operations and methods 4. To describe guards 5. As a navigation language 6. To specify constraints on operations By using OCL, one can specify the static structure and the behavior of the system. Invariants are conditions that must be fulfilled at all times, and describe the static structure of the system. Constraints on behavior can be constructed using pre and post conditions, constraints that must be fulfilled before or after the execution of an operation. The model provides the context for the constraints.

2 1.1 Limitations of OCL OCL has certain shortcomings, some of which is addressed in the OCL 2.0 proposal. OCL s lack of metamodel makes it impossible to formally define the integration with the UML metamodel. Also, the distinction between concrete syntax and semantics is blurred. OCL lacks expressibility in several areas, and there are reports of ambiguities and inconcistence. Several extensions to OCL have been proposed. These include temporal operators, redundant invariants and time-based constraints, and behavioral constraints on occurrences of events, signals, and operation calls. 2 Functionality of OCL Tools The many tools offering UML support provide features like drawing of UML diagrams, code generation and reverse engineering, but very few implement any OCL support. Whether the lack of tool support is the result of low interest or low interest is caused by the lack of tool is discussable, but the practical improvements of OCL in a software project has still to be proven. Another possible reason for the lack of OCL tools, could be that it is still not completely clear what kind of functionality such tools would provide. The following section discusses different functionality [2] that could be provided by OCL tools. 2.1 Syntax Check The simplest kind of OCL support one would expect to find, is syntax checking, simply verifying that the expression is correct according to the grammer defined in the OCL specification, without any concern to the underlying model. The main purpose of the type check is to discover typing errors and other syntactical errors. 2.2 Semantic Check Even if a syntactical check proves successfull, the OCL expression could still be incorrect because of semantical errors. A semantic analysis checks that the OCL expressions conforms with the underlying model. Sematic analysis can be divided into two parts, type check and consistency check. Type Check. OCL defines a set of basic types. Type checking ensures that the types in the OCL statements conform with the model. Type checking in an OCL tool would be performed much like in any programming language. Consistency Check. Because OCL i a logical language, it is possible to define contradictory OCL expressions. A consistency check will aim to detect such inconsistencies in a model. But there are certain open questions regarding consistency of a model. There is no clear definition of what concistency means, and it could even be undecidable.

3 2.3 Dynamic Validation There are two main approaches to perform such validation: Model Animation One way of dynamicly validating and verifying a model, is animating or creating a prototype of the model in a simulation tool. Such a tool would be effective for creating snapshots of the system and examine invariants in these different system states. Code Generation By generating code from OCL expressions, assertion tests providing automatic checking of invariants and pre/post conditions could be integrated into application code and executed at runtime. 2.4 Test Automation OCL statements could be used by an automated test tool to check test results against the specification, and it may be possible to derive test cases from the specification written in OCL. 2.5 Code Verification and Synthesis In a more ambitious kind of tool, OCL may also form a basis for code verication and synthesis. 2.6 Integration with CASE Tools Some of the OCL tools availible are stand-alone applications that defines its owen proprietary formats for model information. Since most models are developed in CASE tools such as Rational Rose or ArgoUML, it would be more practical to either integrate the tool as a plugin to a CASE tool, or providing import of XMI, the OMG standard for exchanging data and metadata. 3 OCL Tools Even though UML has been the industry-standard language for software modeling and design for several years, few of the UML tools available offer any OCL support. Bu there is an increasing number of tools available and under development, many of them originating from research projects. 3.1 IBM OCL Parser v0.3 The first OCL tool available, was probably IBM s OCL Parser [8], written in Java using the JavaCC parser generator. The intention with this parser was to encourage the use of OCL with UML modelers rather than providing a powerful tool. The functionality of the parser contains syntax checking and partial type checking. It requires model and OCL expression on a special file format, which makes the use of it cumbersome.

4 3.2 OCL 1.4 syntax checker Klasse Objecten [9] is a dutch company highly involved in the development of the UML 2.0 submission. They provide the OCL 1.4 syntax checker that performs a syntax check only, using the OCL 1.4 definition. 3.3 Dresden OCL Toolkit The Dresden OCL Toolkit [10] is a modular toolkit for OCL developed at the Dresden University of Technology, and which purpose is to generate code out of OCL expressions. The compiler consists of four modules: a parser, semantic analysis, normalization and a code generator. The semantic analysis provides type checking and a simple consistency check. Normalization is applied to reduce the code generator complexity. The injector tool generates Java code from OCL expressions, which provides evaluation of OCL expressions at runtime. The downloadable version includes full source code of the parser. 3.4 ArgoUML ArgoUML [11] is an open-source CASE-tool that uses the OCL compiler from Dresden, and provides full OCL syntax and type checking. 3.5 Poseidon 1.4 Gentleware s Poseidon 1.4 [12] is a UML CASE tool evolved from ArgoUML. Poseidon offers specification of OCL constaints with syntax and semtics checking. A beta version of the OCL-to-Java plugin, based on the Dresden OCL Toolkit, is currently available for free download. Plugin support is not available in the free community edition. 3.6 Boldsoft ModelRun Boldsoft s ModelRun [13] is a tool that enables creation of instant prototypes of the model. Model files from Rational Rose and Bold for Delphi are supported. It is possible to examine the model properties in an Explorer like treeview, and instanced of the classes can be created. When objects have been created, relations can be realized by drag-and-drop. The OCL Workbench lets you execute OCL queries. Boldsoft also delivers the application development frameworks Bold for Delphi and Bold for C++, which allow direct execution of OCL expressions. 3.7 LCI OCL Evaluator The Computer Science Research Laboratory at the Babes-Bolyai University in Romania has developed and OCL evaluator [14] with full OCL 1.4 support. UML model exchange is done using XML, XMI 1.0 or 1.1 standards.

5 3.8 Cybernetic OCL Compiler 1.5 Cybernetic is a Swiss-based software company that has developed an OCL compiler [15]. A beta version with frontends for SELECT Enterprise and Rational Rose is available for download on their website. Current version (prototype 1.5) provides syntactic check and type check of the OCL expressions. Prototype 2 is under development, and will provide logical consistency check as well as generate the appropriate constraint checking code. 3.9 OCL for Java library At Canterbury University David Akehurst has developed a OCL for Java library [16] that enables runtime evaluation of OCL. It uses a Java reflection and runtime class creation to construct objects representing OCL expressions that can be evaluated at runtime USE A UML-based Specification Environment At the University of Bremen, the USE system [17] has been developed. USE is a system for specification of information systems. USE enables animation of the model to validate the specification against non-formal requirements expressed in OCL statements. System states (snapshots) can be created and manipulated during an animation. USE defines its own textual spesification for a model and its constraints (import of XMI is a proposed extension) Elixir Technologies Elixir Technologies [19] claims OCL support in their CASE tool Elixir Case and their Java development enviroment Elixir IDE 2.4. Elixir Case provides an OCL constraint text field, but no further funcionality. For Elixir IDE a plugin is provided by icontract, a Java preprocessor using an expression language modeled after a subset of OCL, providing runtime evalutation of assertions at specific checkpoints during the system s execution MagicDraw 5.5 MagicDraw [18] is a commericial UML modeling and CASE tool, and offers automatic OCL syntax validation and highlighting. 4 Using Dresden OCL Toolkit 4.1 Example Model To demostrate how the Dresden OCL Toolkit can be used to validate and verify a model, a simple model can be creates using ArgoUML (Figure 1). The model

6 Fig. 1. Simple Example Model contains three classes, Company, Person and Project, supplied with OCL constraints. An example of such a constraint, is that to fire a person, that person has to be an employee of the company: context Company::fire(Person) pre: employee->includes(pers) When generating Java code from the model in ArgoUML, the OCL expression are included as JavaDoc comments. These are used by the OCL injector tool to create Java code from OCL statements. The code generated by ArgoUML need some modification, besides adding method bodies, before it can compiled and run. Although the Dresden OCL Toolkit claims to be fully integrated with ArgoUML, the OCL injector doesn t always recognise the OCL constraints generated by ArgoUML, often caused by an empty line in the beginning of the JavaDoc comments. Also, the context of pre and post conditions are often wrong, they tend to be placed in the beginning of the source file, not with their belonging operations. A simple test program creates objects that violates the OCL constraints. When the test program is compiled and executed, nothing happends. The OCL constraints are only comments and are ignored by the compiler, thus have no effect on the execution of the program. The following command runs the injector tool to modify the source code: java -classpath. -jar dresden-ocl-injector.jar -r ocltest -m ocltest.java The injector generates constraint checking Java code, based on the OCL statements in the JavaDoc comments. The code added by the injector, creates objects representing invariants, and wrappes functions, adding evaluation of invariants

7 and pre/post conditions, but leaving the original method bodies unmodified. If we then recompile and run the test program, error messages indicating broken constraints will appear. javac -classpath dresden-ocl-injector.jar;. ocltest\test.java java -cp dresden-ocl-injector.jar;. ocltest.test violated ocl invariant nameuppercase on object violated ocl invariant agegreaterthan0 on object violated ocl precondition nothired on object operation fire(p : Person). violated ocl precondition alreadyhired on object ocltest.company@1befab0 operation hire(p :Person). violated ocl invariant budgetlimit on object ocltest.project@c21495.} The modified code can be cleaned from the source files by running the injector with the -c parameter. 4.2 Limitiations Parallellism is a potential problem for this approach of constraint checking. If a state change for the system occurs during the validation of a constraint, one can not guarantee that the constraint is evaluated correctly, since other processes/threads can modify the objects included in the evaluation before the checking is complete. 5 Conclusion The code genration tool from Dresden, provides an easy to use and powerful method of OCL constraint checking that requires little effort from developers. There are however arguments that calls for a different approach [3]. The code generation method requires that the the model, or at least parts of it, is implemented before the validation can be done. If the model can be validated before the coding starts, design errors can be detected early in the development process, possibly reducing the extent of design errors. Tools like Boldsoft s ModelRun and the USE tool from the University of Bremen, employs such a method by animating a model. The UML 2.0 submission addresses some of the weaknesses of OCL, and will hopefully encourage the release of new OCL tools, but whether OCL will gain the same status as UML in the software development community is yet to see. References 1. Finger, Frank: Design and Implementation of a Modular OCL Compiler. Dresden University of Technology, Department of Computer Science

8 2. Hussmann, Heinrich, Demuth, Birgit and Finger, Frank: Modular Architecture for a Toolset Supporting OCL. Dresden University of Technology, Department of Computer Science. 3. Richters, Mark and Gogolla, Martin: Validating UML Models and UML Constraints. University of Bremen Richters, Mark and Gogolla, Martin: OCL: Syntax, Semantic and Tools. University of Bremen. Springer Richters, Mark: A Precise Approach to Validating UML Models and OCL Constraints. University of Bremen. 6. Baar, Thomas: Experiences with the UML/OCL-Approach to Precise Software Modeling: A Report from Practice. Institut für Logik, Komplexität und Deduktionssysteme, Universität Karlsruhe. 7. OMG Unified Modeling Language Specification, Chapter 6: Object Constraint Language Specification OMG IBM OCL Parser Klasse Objecten Dresden OCL Toolkit, Dresden University of Technology ArgoUML Poseidon 1.4, Gentleware ModelRun, Boldsoft LCI OCL Evaluator Cybernetic OCL Compiler 1.5. Cybernetic Intelligence GmbH OCL for Java library (version 10-July-02). David Akehurst, Canterbury University USE A UML-based Specification Environment, University of Bremen MagicDraw Elixir Technologies