<< Site map >> << History file >>
Ecoop 2002 is organized in cooperation with:

You are the visitor number

from 4th October 2001.

Authors

Dan CHIOREAN, Adrian CÂRCU, Mihai PASCA, Cristian BOTIZA, Horia CHIOREAN, Sorin MOLDOVAN, Ilinca CIUPA
"Babes-Bolyai" University - Computer Science Research Laboratory
chiorean@cs.ubbcluj.ro, lci@lci.cs.ubbcluj.ro

Abstract

The main objective of the checking process
Obtaining correct UML models.
This implies:

• Reduced time & costs with system development
• Better system quality

UML model correctness = completeness + correctness (against UML Specification)

• Precondition - a correct and complete set of WFR

State of the art
Today, checking of UML models is done using:

• Checking operations implemented in UML CASE Tools
• Scripts
• Other Add-Ins tools (like Rose Checker)

Drawbacks of the above techniques:

• Only a part of the WFR are implemented
• The equivalence between the WFR and their implementation has to be proved
• Each CASE tool has its own Repository interface and script language
• A part of the WFR cannot be implemented due to the lack of information

OCL Evaluator
Technique used:

• Check UML Models by means of WFR
• The UML models are expressed in XMI 1.1 format
• The user has full access to the metamodel information by means of UML AO
  • Consequently the user can extend the checks at different profile levels (including checks specific to the target language)
  • All the rules expressed at the metamodel (M2) level. The constraints can be fully evaluated. Apart from the UML model, no additional information is necessary. The rules are stored in a text file, conforming to the OCL standard.
  • The OCL support is fully compliant with the OCL 1.4 Specification.
  • The BCR specified by the user at the M1 level can also be evaluated provided that all the required information is available.

The results obtained
Using NEPTUNE OCL Evaluator, most of the UML 1.4 WFR were evaluated.

• Apart from the errors discovered in case of similar projects (see http://www.db.informatik.uni-bremen.de/projects/USE) a lot of conceptual errors have been identified in the AO and WFR Specification

The main conclusions are:

• The WFR have to be clearly explained in natural language and if needed, exemplified using pieces of models. Providing examples of correct models and of modes breaking the WFR gives the user the possibility to better understand the meaning and importance of each rule.
• The UML WFR do not have to forbid legal constructions in object oriented programming languages.
• The UML metamodel has pure object oriented architecture. Given that the AO and the WFR specify the UML metamodel classes behavior, their specification has to satisfy the rules specific to OOP and to the design and programming by contract domains. (The naming rules, the redefinition rules, the rules adopted for solving the ambiguities in multiple inheritance
  etc.)
• The AO and the WFR specifications have many solutions. It is very important to find the simplest and clearest one.
• We are now trying to identify all the errors in the AO and the WFR and propose solutions for them

References:
[Moors2000] Michael Moors - Consistency Checking - Rose Architect - Spring Issue, April 2000 - http ://www.therationaledge.com/rosearchitect/mag/index.html
[Richters 2000] Mark Richters, Martin Gogolla - Validating UML Models and OCL Constraints - "Proc.\ 3rd International Conference on the Unified Modeling Language (UML)", - Springer-Verlag 2000
[Chiorean01] Dan Chiorean - Using OCL beyond specification - Lecture Notes in Informatics 7 - "Practical UML-Based Rigorous Development Methods - Countering or Integrating the eXtremists, pag. 57-69
[UML 1.4] UML 1.4 Final Specification - January 2002 - http://uml.sh.com
[Warmer1999] Warmer J, Kleppe A. - "The Object Constraint Language" - Addison Wesley 1999
[DresdenOCL] http://dresdedn-ocl.sourceforge.net/index.html

Most of this research work has been done in the framework of NEPTUNE IST 1999-20017 Research European Project

Additional Information

http://lci.cs.ubbcluj.ro