How-To-Use the OSLO Tool (V1)
Author: Christian Hein Date: 11.11.05 Version: 1.0 http://oslo-project.berlios.de
1. Introduction
This is the first version of the How-To-Use tutorial of the first version of the OSLO Tool. The aim of this tutorial is to show a simple way to handle with OCL. For this purpose the OSLO Tool was written by us. We have to mention that the OSLO Tool is not OSLO. It only uses the OCL library of OSLO. Remember, OSLO stands for Open Source Library for OCL. Additionally, we have also to mention that the OSLO Tool only supports OCL-checking against UML2 models, but the OCL Library is not limited by the UML2 metamodel. It is possible to use any other kind of metamodels which are based on EMF.
2. Download and Installation
2.1. Preconditions The OSLO Tool is a java based tool. Therefore you have to install a Java Virtual Machine on your computer to execute the OSLO Tool. We have already tested it with the JDK 1.4.2 and JDK1.5.0. You can download this stuff at this webpage: http://java.sun.com/
2.2. Download We hope that the up-to-date version of the OSLO Tool can be found always on our FTPserver at BerliOS. The current version of the OSLO Tool is 1.0. You can download it under this address: ftp://ftp.berlios.de/pub/oslo-project/OSLO-GUI/OSLO-GUI-1.0.zip The zip-file contains all needed libraries and some UML2 models. The structure of this zip file should looks like this:
The file OSLOTool.jar is an executable jar file. Hence you can start the OSLO Tool by a double click on this file. Of course if you have a Microsoft Windows machines. If not the Command Line is another possibility. For this use: java –jar OSLOTool.jar If it’s all correct you should see the GUI of the OSLO Tool. In version 1.0 it should looks like this screenshot:
3. Use of the OSLO Tool
3.1. Load a UML2 Model First of all you have to load a UML2 Model. An OCL Constraint is checked against this loaded model. To load a model use the Menu Item File->Load UML2 Model. Some example models are in the resource folder. After loading you should see the name of the model in the top of the GUI. Additionally the OSLO Tool makes an entry in the LogView text field.
3.2. Evaluate an OCL Expression The OCL Expression must be written in the OCLConstraint text field. The syntax of such an expression has always this strutucre: context [Type] inv: [OCL Invariant] In order to clarify this thing more simply, we take an example model from the resource folder. The TestCase1 UML2 Model is a simple model, which contains only one package with three classes, but it is a good one to show how to formulate an OCL expression corresponding
to the OSLO library. Assuming that, we would work in a company, which prescribes guidelines for modelling and one guideline means that a package should contains no more than 3 elements. The constraint for that guideline would look like the following expression: context Package inv: ownedMember->size()<4 The expression will be evaluated after pressing the evaluate button. The result will be displayed in the result text field. The expected result of our guideline constraint for the TestCase1 model should be TRUE. To get the result FALSE we can change the expression into this: context Package inv: ownedMember->size()<3 The meaning of this constraint is that a package should contain no more than 2 elements. But the package in the TestCase1 model contains 3 classes. Hence the result has to be FALSE.
4. How to formulate OCL expressions
4.1. Instance, Model, Metamodel, MetaMetamodel and OCL If you take a look at the OCL specification you will find the OCL description in connection with UML, but constraints are not linked at UML models only. OCL is useful with any other kind of MOF or ECORE model instances. That is the way, which the OSLO project goes. To understand the difference between these things we want to start with a typical standard OCL tutorial, this is similar to tutorials which you can find in the internet. The Company (an often used example model☺)
The figure above shows a simple UML2 model of a company. The company consists of departments. Employees work in groups and a group belongs to a department. A few of the employees are managers of the company, this fact is represented by the manage association. Within the company some rules exist which cannot be formulate with UML. In order to express such constraints, OCL can be used within the model.
A possible rule for the company could be that the company has at least one manager. If the company has more than three departments, the company must have more than one manager. The following OCL expression represents this rule: context Company inv: if department->size()>3 then manager->size()>1 else manager->size()>0 endif Another rule could be that every name of a department starts with a capital letter. The OCL expression for that could looks like this: context Department inv: Set{'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O ','P','Q','R','S','T','U','V','W','X','Y','Z'} ->includes(name.substring(1,1)) From the view of an UML-model architect these constraints refer to an UML-model and condition the corresponding instance models of this model. From the view of OSLO these constraints of the company model are formulated at metamodel level without any knowledge about UML2. The reason for that view lies on the metamodel independency of OSLO. We hope that the following figures clarify this circumstance: Modelling elements to define “Modelling Languages” (meta models) Modelling elements to Constraints on this level describe “Application define restrictions on the Models” usage of the meta model elements e.g. UML classes etc. (design guidelines) e.g. “Each class name must start with a capital letter.”
Models of the elements Constraints on this level of the Application Area define restrictions on the and their relations use of the model elements e.g. “Each company must have at least one manager and two managers if there are more then three departments.” The “real” instances of No constraint on this the application area level since no further being modelled instantiation takes place.
The figures show in each case the different layer of models and metamodels. The UMLmodels Company and Library are instances of the Pseudo UML Metamodel. The Philosopher CCM Model is also an instance of the Pseudo CCM Metamodel. Both metamodels are instances of a MOF or an ECORE metametamodel. And finally the System is an instance of an UML or CCM Model. The constraints which are mentioned above are conceptual between the layers UML Model and System. A possible further constraint for a Philosopher would be at the same level. The constraints at this level can only formulated with concepts which are defined by the UML or CCM Models. Accordingly to the company model the concept space consists of all instances of UML classes, UML attributes (Company, Employee, Department, Group …), as well as all association, but no information and concepts from the UML2 metamodel. But it is also possible that a model designer want to use such concept from the corresponding metamodel. Guidelines for software design are suitable examples. Such a guideline could be that a model package does not contain more than 10 classes or that a modeller should not use association classes. These guidelines condition all UML models and of course the system too, but how to formulate this at UML Model level? The answer to it is actually simple. At UML Model level it would not work. We have to formulate such constraint at metamodel level to get the needed concept space. To illustrate this, we take a cut-out of the UML metamodel (Packages Diagram):
The diagram shows how to use packages in case of UML. First of all a Package is a PackageableElement and can own such PackageableElements. An already mentioned design guideline for models could be that a package does not contain more than 10 classes. The corresponding OCL constraint would be: context Package inv: ownedMember ->select(x|x.oclIsTypeOf(Class))->size()<11 This guideline constraint is formulated at metamodel level and can condition every UML Model which is designed by a modeller. For this purpose it uses the concept space from the UML metamodel. OSLO works exactly at this metamodel level. Remember the constraint with the meaning that the company must have more than one manager. From the view of OSLO this constraint must be also formulated at metamodel level and hence the company model is an instance of ECORE or MOF metametamodel. The company model is at the same layer like the UML or CCM metamodel.
4.2. OCL expressions at metamodel level The following section clarifies the semantic between concept space and condition space of OCL constraints. Let’s look back to the constraint of our company example. The constraints are formulated at the level of the UML model and hence they use the concept space which is defined by the company model. Furthermore we know that these constraints condition the instances of the UML model, in this case the system. The following figure illustrates this:
Remember we can also formulate OCL expression at metamodel level, the only one difference between these cases is that the concept space is taken from the metamodel and the conditions refer to the UML model. It can be said generalized that an OCL constraint needs a concept space of a model around to condition the instances of the model. The following figure summarizes this semantic:
The OSLO library makes always use of the concept space which is defined by the metamodel. This can be an UML2 metamodel, a CCM metamodel or any other kind of metamodels. If you
want to formulate and to evaluate constraints at model level with OSLO you have to understand it as a metamodel.