uml consistency checking - computer science · 2001-11-30 · uml consistency checking ii preface...

UML consistency checking

SIF8094

Torger Kielland Jon Arvid Børretzen

Institutt for datateknikk og informasjonsvitenskap


i

AAbbssttrraacctt In large UML documents inconsistencies can occur more or less frequently, something that can prove to be costly in software development projects. In light of this we are looking into the need for, the specifications of and implementation of a consistency checker for UML diagrams/documents. In a summer job project in the summer of 2001 we have already made a simple consistency checker, and we are looking to expand on that, possibly with a rule based consistency checker in this project.


ii

PPrreeffaaccee This paper is the result of our project about “UML consistency checking”, a part of the course SIF8094 taken in the fall of 2001 at the department of computer and information science at the Norwegian University of Science and Technology. We would like to thank our project supervisor Reidar Conradi, and co -advisor Jon Skandsen at Genera for all help and guidance during this project. Trondheim 30.11.01

_____________________ Torger Kielland

_____________________ Jon Arvid Børretzen


iii

IInnddeexx

1. Introduction..............................................................................................................1

1.1 Purpose .............................................................................................................1

1.2 Context ..............................................................................................................1

1.3 Intended audience .............................................................................................2

2. Survey of ‘the state -of-the-art’ and related work ......................................................3

2.1 Existing tools ......................................................................................................3

2.2 Model representation .........................................................................................3

2.2.1 XMI - XML Metadata Interchange................................................................4

2.3 Existing work on model consistency ..................................................................5

2.3.1 The Genova consistency checker ...............................................................5

2.3.2 xlinkit ...........................................................................................................7

2.3.3 USE .............................................................................................................7

2.3.4 Other research ..........................................................................................11

3. Context ..................................................................................................................12

3.1 Background......................................................................................................12

3.1.1 Consistency...............................................................................................12

3.1.2 Formalization of consistency checking ......................................................12

3.1.3 Genera ......................................................................................................12

3.2 Motivation - WHY is this useful and WHAT can be gained? ............................13

3.2.1 Benefits of a rule based system ................................................................14

3.3 The concept of semantic web ..........................................................................14

4. Research ...............................................................................................................16

4.1 Defect types .....................................................................................................16

4.2 Object-oriented reading techniques .................................................................17

4.2.1 Horizontal vs. vertical reading ...................................................................19

4.2.2 Discussion of the Object Oriented Reading Techniques (OORTs) ............20

4.3 Alternatives for an improved consistency checker ...........................................21

4.3.1 What can be checked? ..............................................................................22

4.3.2 Taxonomy of inconsistencies, errors and flaws .........................................23

4.3.3 Choice of consistency checker expansion .................................................24

4.3.4 Analysis of consistency checker application results ..................................25

5. Technology Alternatives ........................................................................................26


iv

5.1 The “engine” of the consistency checker. ........................................................26

5.1.1 Forward chaining or data driven ................................................................26

5.1.2 Backward chaining or goal driven..............................................................26

5.2 Inference engines ............................................................................................27

5.2.1 Java...........................................................................................................27

5.2.2 Prolog ........................................................................................................28

5.3 Parsing the XMI document ...............................................................................28

5.3.1 SAX ...........................................................................................................29

5.3.2 DOM..........................................................................................................29

5.3.3 SGML parser for Prolog .......................................................................30

5.4 The rules ..........................................................................................................31

5.4.1 First order predicate logic ..........................................................................31

5.4.2 Prolog ........................................................................................................32

5.4.3 OCL ...........................................................................................................32

5.4.4 Xlinkit.........................................................................................................34

5.4.5 Other rule formats .....................................................................................34

6. Technology desicions ............................................................................................35

6.1 Development of a rule based consistency checker ..........................................35

6.1.1 Technology alternatives ............................................................................35

6.1.2 The rule interface towards us ers ...............................................................37

6.1.3 Presentation of consistency checker results ..............................................38

6.2 A prolog based consistency checking tool .......................................................38

7. Results ..................................................................................................................40

7.1 Applying the Genova consistency checker on UML models ............................40

7.1.1 Description of the models ..........................................................................40

7.1.2 Results from the Genova consistency checker on two real UML projects .41

7.2 Implementation of a rule based consistency checker.......................................44

7.2.1 Getting the facts ........................................................................................44

7.2.2 Applying a check on the model ..................................................................44

7.2.3 Example of execution ................................................................................45

8. Evaluation of results ..............................................................................................48

9. Conclusion.............................................................................................................49

Glossary ....................................................................................................................50

References ................................................................................................................51


v

Appendices................................................................................................................54

Appendix A. Some consistency rules sorted by type. ............................................54

Errors: ................................................................................................................54

Warnings: ...........................................................................................................57

Appendix B. Rules from xlinkit.com’s UML checker ..............................................58

Appendix C. Example of xlinkit ...............................................................................65

Appendix D. Results from the Genova consistency checker ..................................69

Appendix E. The prolog implementation ................................................................73

Appendix F. User Guide to Genova consistency checker ......................................75

Appendix G. Results from the prolog consistency checker ....................................80


vi

LLiisstt ooff ff iigguurreess

Figure 1 – Starting the Genova consistency checker ..................................................6

Figure 2 – The Genova consistency checker ..............................................................6

Figure 3 – A result reference in xlinkit .........................................................................7

Figure 4 – USE example UML diagram .......................................................................8

Figure 5 – USE model description ...............................................................................9

Figure 6 – USE OCL constraints ...............................................................................10

Figure 7 – Defect types .............................................................................................16

Figure 8 - OORT inputs and goals .............................................................................19

Figure 9 – Simple classification of UML model deficiencies ......................................23

Figure 10 – Information and process flow..................................................................39

Figure 11 – The test2 model ......................................................................................46


vii

LLiisstt ooff ttaabblleess

Table 1 – Horizontal and vertical defects ...................................................................20

Table 2 – UML diagrams and artefacts ......................................................................22

Table 3 – Available diagram types in XMI from Rational Rose/Unisys ......................23

Table 4 – Model representation alternatives..............................................................35

Table 5 – Implementation language alternatives .......................................................36

Table 6 – Model descriptions.....................................................................................40


1

11.. IInnttrroodduucctt iioonn

1.1 Purpose This paper aims to bring some light onto the situation concerning consistency checking of UML today. Firstly it will introduce the work already existing on a specific consistency checker made by this paper’s authors and what this application is able to do. Secondly, it will present some of the existing work done by others in the same field. Further it will go into the needs for consistency checking, and present possible ways of implementing a more general and useful application. A presentation of rules, what they are, and how they should work will also be made. A discussion of the possible applicable technologies in the development of a consistency checker and the conclusions of this will also be a integral part of the paper.

1.2 Context In the software community there is an increasing interest for early development, which in a high degree includes modelling. This results in a better understanding of the application that is to be de veloped, and in many respects saves costs by avoiding development of applications with the wrong specifications. But models will not do a project any good if they are not good models. One contribution in keeping the quality of models high is to make sure t hey are consistent. (Model consistency will be defined later in the paper.) In the summer of 2001 Torger Kielland and Jon Arvid Børretzen had a summer job for Genera, a company that specialises in model based software engineering. Therefore, for them the UML model that usually is seen as an early part of the process in a software project is a very important part of a software development project, and is used throughout the whole development phase. Experience shows that since models become quite large when dealing with major industrial projects, the models can become somewhat difficult to follow. If many persons work on a model, or even if one person has too large models to work on, inconsistencies can easily occur. In our summer job, one of our assignments was to develop a consistency checker that could find certain inconsistencies that Genera knew they had or could have in their models. Some examples of this could be that there were duplicate role names on the associations going out from a class, or if car dinalities on the associations were set. The result was the implementation of a consistency checker that later was refined and added to Genera’s tool Genova.


2

The focus on this paper is UML consistency checking, although the paper is also relevant in relation to the general concept of document consistency checking.

1.3 Intended audience This paper is aimed at software developers using the UML modelling language and users of UML tools, as well as researchers interested in UML and UML development. Developers who want to lower the number of faults in a software product and reduce the effort in finding these faults should find the concept of model consistency checking intriguing. Readers should at least be familiar with XML, its use and notation, as well as UML. For the implementation part of the paper, Prolog is used, and knowledge of this language is an advantage when reading these chapters. In addition, consistency checking is also relevant to the up and coming field of “The Semantic Web”, and with the r eader approaching this paper with a wider way of thinking, it can also be related to this subject.


3

22.. SSuurrvveeyy ooff ‘‘ tthhee ssttaattee--ooff--tthhee--aarrtt ’’ aanndd rreellaatteedd wwoorrkk

2.1 Existing tools The possibility of some simpler consistency checking of UML models already exist as functions in some UML modelling tools, such as Rational Rose, Telelogic Tau, No Magic’s Magicdraw and StP (Software through Pictures). In addition, the tools themselves are implemented with behaviour that embeds certain rules and restrictions in the functionality that help keep the models consistent. One example is the fact that one cannot have two classes with the same name in one package, or indeed one model. The reason for choosing UML as the modelling language to be discussed here is that it is the most widely used modelling language in the software development community. In addition it is probably the most accepted standard in this community, and is also continuously being worked on by the OMG organization. Another basis for this paper is the exist ing Genova consistency checker made by us. We will present how it works, and use it on different existing models to examine and demonstrate what kind of errors/inconsistencies we are able to find with it. The results will be presented and commented. Also, the consistency rules that exist in this tool are presented in the appendices. Moreover, several other research projects exist concerning consistency checking of UML. Some are very specific and detailed, while others are more general and theoretical. A selection of such projects will be introduced later in the paper.

2.2 Model representation In order to check a model for consistency, the model must exist in a format that can be examined. Most UML modelling tools have their own proprietary format for sto ring the models, although models can be exported to Rational Rose’s mdl -format from other tools than Rose itself as well. A more general format exists in the form of OMG’s XMI, and more and more of the UML tools on the market are incorporating functions for exporting the models as XMI files. Although the Rose mdl-files are in a readable textual form, XML parsers and processing tools already exist. This means that development of a consistency checker does not have to start from scratch, as one already has t ools to process the data.


4

In chapter 7.1.1 Description of the models , we will present some example models which will be used for different purposes in the project.

2.2.1 XMI - XML Metadata Interchange XMI is a standard defined by OMG, the Object Management Group. Some industry leaders in the field of object oriented software development, including IBM and Unisys, have proposed a new open industry standard that combines the benefits of the web-based XML standard for defining, validating, and sharing document formats on the web with the benefits of the object -oriented Unified Modelling Language (UML), another specification of the Object Management Group (OMG). XML is the well-known open standard of the World Wide Web C onsortium (W3C) designed as a data format for structured document interchange on the web. XMI’s objective is to allow for the exchange of objects from the OMG's Object Analysis and Design Facility. These objects are more commonly known as UML (Unified Modelling Language) and MOF (Meta Objects Facility). Before XMI there was no agreed-upon industry standard for doing this, thus leading to a wide variety of proprietary formats, each specific to a specific vendor tool. Also, XMI is intended to be a "stream" format since it is based on XML. That is, it can either be stored in a traditional file system or streamed across the Internet from a database or repository. XMI UML is defined through the XMI UML DTD. That is a definition that says how a XMI UML document is to be structured. The XMI standard presently exists in two versions, 1.0 and 1.1. The XMI 1.1 specification shows that XMI can be used for models as well as instances, and the OMG is now in a final phase of adopting XMI 1.1, work that aims to make XMI a nd the generated XML DTDs and Documents more readable. XMI 1.1 also has support for XML namespaces, which were adopted after XMI 1.0 became an OMG standard. In this paper, when referring to XMI, we mean XMI version 1.1 unless stated otherwise. Notes on the Unisys XMI exporter tool To get the UML models in Rational Rose in XMI format, we had to download and install a special add-in for Rational Rose, namely the Unisys Rose XML Tools. When exporting some models, the exporter tool can report warnings or errors when the model is not as expected. For instance, class attributes and operation parameters that lack type are set to have the type “undefined”. Another more serious example is that some diagrams will be skipped in the exporting process due to the fa ct that unspecified objects in some diagrams prevent a conversion to XMI. When exporting the Lisa1 model, the result was 27 model errors and 149 warnings. In the Lisa5 model, there were 461 errors and 87 warnings. It should be mentioned


5

that especially in Lisa5 the vast majority of the errors were due to references to packages that did not exist in our model. The exporter tool reported 0 errors and 48 warnings on the eCourse model. The Loan Arranger had 0 errors and 15 warnings, while Parking Garage had 0 errors and 0 warnings reported by the exporter. The first thing to do in these cases is to correct the errors so as to be able to export a correct model. Secondly one should look into the warnings to see if they are of a serious nature, before moving on w ith the consistency checking. Another thing to note is that the exporter tool has several options, among them the version of XMI to be used, how the model are to be saved (single file, package per file or class per file) and warning report level for the e xporter. One can also opt to export a XMI representation of the diagrams, as well as the model information into the XMI file. This is for model transfer purposes, and is not relevant in consistency checking. The files including diagram information were fro m 20 to 27 % larger. (See Table 6)

2.3 Existing work on model consistency

2.3.1 The Genova consistency checker The Genova consistency checker was made especially for Rational Rose. The Norwegian company Genera has made a tool call ed Genova as an extension of Rose to provide much more support in the developing process. This product acquires a model from Rose via the REI (Rose Extensibility Interface) to continue working with it. If the data received from Rose is not logically consis tent it can affect the following work. As a consequence of this Genera saw the need to develop a consistency checker to control that the model in Rose would not create problems in the Genova tool. A paper of the problems encountered was prepare by Stian Ro lfsen at Genera and given to us at arrival for our summer work (2001). We chose to develop the consistency checker in Rational Rose’s own specially tailored version of the Basic language, RoseScript. This script language gave us access to the REI model (e ssentially a meta model of a Rose model) through short commands like this:

Set AllClasses = RoseApp.CurrentModel.GetAllClasses () The line of code above would take all the classes in the REI model and put them in the set ‘AllClasses’. We could then very easily take individual classes out of the set and with a similar command get all the attributes in it. This gave us the opportunity to start the development very fast. We separately made small Subs of every test in the specification we had been given and tested them individually. A common user interface was then made to give the opportunity to choose the checks you wished to run, choose which part of the model you wanted to run them on and how the output was going to be presented. There was also


6

functionality added were you could make sets of test you wished to run frequently and save them under a common name. At last the program was added as an ‘Add -In’ in Rational Rose. It could then be started from the ‘Genova DB’ menu like shown in Figure 1.

Figure 1 – Starting the Genova consistency checker

The consistency checker program user interface looked like Figure 2.

Figure 2 – The Genova consistency ch ecker

The user guide for the Genova consistency checker is included in Appendix F.


7

2.3.2 xlinkit Furthermore, others have already made some work on consistency checking of UML models, through a wider consistency checking tool for distributed documents called xlinkit. Their rule format is presented later, and their rule base is also presented in the appendices. There are two ways of using their UML consistency checker, either by downloading the xlinkit source code, and compiling it, or by using their UM L consistency checking service on the world wide web (which is what we have done). One of the problems with using xlinkit is that when submitting an URL with a XMI UML document, the response is somewhat awkward to understand. The result is a link to the r ule that applies to the actual inconsistency, and URLs referring to where in our XMI document the inconsistency occurs. An example of this is:

http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Association[1]/Foundation.Core.Association.connection[1]/ Foundation.Core.AssociationEnd[2]

Figure 3 – A result reference in xlinkit Here we see that one is forced to trace manually into the XMI document oneself to find where the occurrence is. The numbers in the brackets point to which instance of the object iside another object is inconsistent, for example “…Foundation.Core.Association.connection[1]/Foundation.Core.AssociationEnd[2]” means that the inconsistency occurs in the second instance of Foundation.Core.AssociationEnd inside the current Foundation.Core.Association.connection. Since xlinkit seemingly does not explicitly state what the inconsistency is, or where it is to be found, w e feel that this is not a very mature tool that would need quite a bit of improvement to be really useful. In the appendices an example of xlinkit results are shown. Xlinkit operates on XMI version 1.0, and can therefore be said to be a bit outdated already.

2.3.3 USE At the university of Bremen, a system for specification of information systems have been researched and developed. USE, as it is called, is based on a subset of the UML. A USE specification is a textual description of a model using featu res and artefacts found in UML class diagrams. Expressions written in the Object Constraint Language (OCL) are used to specify additional integrity constraints on the model.


8

The USE specification language is based on UML and OCL. The USE developers claim that because of the semi-formal definition of OCL there are some language constructs whose interpretation is ambiguous or unclear. They therefore attempt to provide a solution by making a more formalized form of OCL. As they say; “This is ongoing work and it is likely that there will be changes in USE.” [USE] The biggest drawback with USE, as we see it, is its proprietary format for representing a model. In the documentation it says “a possible extension to USE would be the import of an XMI file created by a CASE tool like Argo UML or Rational Rose” [USE] . For USE to be helpful for us, we would have to implement a conversion tool from XMI to the USE representation and back to XMI again. There are two big disadvantages to such a solution. Firstly, the conce pt of going away from XMI for processing is not a good one, as it should be possible to process the XMI file directly. Second, we do not think USE has all the functionality of XMI UML, since it is based on a subset of UML. Therefore it is not ideal for han dling full scale XMI UML files. It seems that USE has been designed with main regard to checking ordinary models on an instance level, but should also be able to work on metamodels. Here are examples of how the textual description of a UML diagram would look, and some OCL to define some constraints. In the following syntax example of the USE system, the example’s appurtenant UML diagram is shown in Figure 4.

Figure 4 – USE example UML diagram

The first part of the specification shown in Figure 5 below describes the structural information of the class diagram.

��

��


9

�� "!�!$#% &� � �'�� "()(+*-, .�/�(0��!�� 21�354+6-7 ��8�� 69�&1":)��40��8��6��;��

�� "!�!$<=��6>4+ ?��4 "()(+*-, .�/�(0��!�� 21�354+6-7 ��8� � � ��4@7 ��$1'354>6A7 ��8B"C�D 8��4E1�:)��4>��8��6

��;��

�� "!�!$F%6G�IH0� � 4 "()(+*-, .�/�(0��!�� 21�354+6-7 ��8B"C�D 8��4E1�:)��4>��8��6

��;��

�� 7 ��4J7 ��

�!�!��, �(@, ��;LKM��6ANO�":P�$.��(PQR�"�S;#% T� � ��UWVYX<=�S��6+4> ?��4GU+Z'[9[ VAX

��;��

�!�!��, �(@, ��;LKM��6ANO��\?��.'��(PQR�"��;#% T� � ��UWVYXF%6G��H9� � 4GUWVAX

��;��

�!�!��, �(@, ��;?��S��4>6G� � ��.��"(]Q^�"�S;<=�S��6+4> ?��4GU+ZOXF%6G��H9� � 4GUWVAX

��;��

Figure 5 – USE model description


10

In the second part of the specification shown in Figure 6, we define the constraints in OCL. Each constraint is defined as an invariant in context of a class.

�E� \LR_ � ��4>6G��7 ��49�

��;�!�(>*J �, ;�(9!

��;�(9�'`�(%<=��6+4+ a�S��4�� 4Jb��2� C B ��6S�'c�� &� � �'��"�RdR��6-N�7 �'8e7 �f� D �S��6+4> ?��4� C ��4�� B ��8�6G��4>��6S��6��g C � � 49�$4Jb��e� C B ��6��'cE��6+�IH>� � 40�� S��4>6G� � � � DeB �f4@b�� D ��'��6+4> ?��4, ;�h&iL��6+�S#% &� � �'�'�"��jkb��F%6+��H9� � 49��1�� c@[W�� T� � �'�'�"� �Al ��7 m�� l�n �� c-[0�'6G�IH0� � 4 �Al ��7 m��

��;�(9�'`�(%#% &� � ��"�� T� � �'�'�"��L8��4��eb"7 8Sb'��6�� 6>�odfb��S�o4@b��odR��6-Np�� ?��6G�2�'6+��H9� � 49�, ;�h&iL��6+�SF%6G�IH>� � 40�"q�7 8�b'��6J3r� � ��69��1#5 &� � �'��[ � � � :)��49�S� � �� Al c9��69s � � t �EZ�u��vxw�%Z'[)�'6G��H9� � 4 �Al �"7 m�� l ��vS[0�'6G�IH9� � 4 �Al �"7 m��, �Ty"� , ��!f�EZ'[ �� 6>� l �"vS[W�� 6>��z

��;�(9�'`�(%F%6+��H0� � 4�� 4Jb�� B�C�D 8��4��c��e�'6G��H9� � 4� C ��4S�'��4"�'{ � �� D 4Jb�� B�C�D 8��4��'c"4@b�� 4>6G� � � 7 ��8 D ��6+4G ?��4, ;�h&| C�D 8��40K}7 4Gb�7 �"<=��6+4> ��S��4G| C�D 8"��4J1�� c@[ B�C'D 8��4S~ n �� c-[ D ��6G4+ ?��4-[ B"C�D 8��4

�� T� � �'�'�"��RdR��6AN�7 ��8$��L�e�'6G��H9� � 4� C ��4�� ad^��6ANL7 �o4Jb�� S��4>6G� � � 7 ��8 D �S��6>4+ ��4, ;�hT#% �� '�'�"��":P�'��S��4+6+� � � 7 ��8S<=�S��6+4> ?��4J1�� c@[ D ��6+4> ��S��4J[W�� &� � �'�'�"� �Al 7 � �� C�D ��s � � t �� c-[ �� &� � �'��z

Figure 6 – USE OCL constraints This example illustrates the aspect of constraints on an instance level. In addition it should certainly be possible to use USE on a schema level as well, as it uses OCL as its format for expressing the consistencies and c onstraints.


11

USE certainly is an interesting concept, and very related to the project. Unfortunately, it only supports a subset of UML, and in addition uses its own model representation format. Therefore it could introduce added complexity in translating t he model format, whilst not being as powerful as hoped because of the UML subset -property.

2.3.4 Other research The paper “Consistency Checks for UML” by Padmanabhan Krishnan approaches the subject by defining UML diagrams as state predicates and using a theorem prover called PVS (Prototype Verification System) to verify consistency between various diagrams. PVS is a verification system, where a specification language is integrated with support tools and a theorem prover. It intends to capture the state -of-the-art in mechanized formal methods and to be adequately robust so that it can be used for significant applications. PVS is a research prototype, this means that it evolves and improves as new capabilities are developed and applied. [Krishnan, 2000] This system provides mechanized support for formal specification and verification. PVS is apparently mainly intended for the formalization of requirements and design -level specifications, and for the analysis of intricate and difficult problems. It has been mainly applied to algorithms and architectures for fault -tolerant flight control systems, and in working with problems in hardware and real -time system design. This method of having the UML diagrams represented as state predicates (facts) and using a theorem prover resembles that of using the prolog inference machine as a tool. This is presented more thoroughly later in the paper.


12

33.. CCoonntteexxtt

3.1 Background This section presents some background on what consistency checking is about, and tries to introduce some of the reasoning behind the choices we will make later.

3.1.1 Consistency Model consistency has been defined as “No set of requirements are in conflict with another set.” [Lindland et. al., 1994] If one includes parameters as requirements, a problem here is that since UML is not a very formal modelling language, it is hard to prove if anything conflicts. The problems addressed with this kind of consistency checker are of different types. Omissions, erroneous values/names/types or plain inconsist encies between different objects of a diagram are examples of what we will be looking at. Since UML consists of many diagram types, there is a need in not only having consistency in one diagram, but also across several types of diagram.

3.1.2 Formalizat ion of consistency checking In object-oriented modelling, a graphical model, like a class model, is not enough for a precise and unambiguous specification. There is a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will always result in ambiguities. To write unambiguous constraints, so-called formal languages have been developed. For a long time, lack of formalization has been felt in the object -oriented software modelling area. Even though the basic elements of the diagram specifications used are very powerful and obvious, and it is easy to understand the way they fit together, several modelling details, such as uniqueness, referential and associ ational restraints, limitations and other constraints are expressed ambiguously, or in some cases cannot be described at all by the existing graphical notations. Because of abstraction issues we often leave out details when doing object -oriented modelling, but we still need consistency and precision in the models. [Abreu, 2001]

3.1.3 Genera The consistency checker that was made for Genera is not a very general tool for use on UML models, since most of the consistency checks in that tool are applied to


13

properties that are very specific for their tool Genova. Examples of this are that several checks are related to certain stereotypes and relationships between stereotypes in the UML models that Genova use, which are not used generally in UML modelling. Other checks are related to the fact that some classes and variables are to be set as primary keys and/or persistent in database mappings, which again is very specific to the Genova tool working on the UML model. The application Genova is tightly integrated wit h Rational Rose through COM and other techniques. The repositories of Rational Rose and Genova are seen as one logical repository, and the properties described in one of the tools can be traced into the other tool. The toolset supports the object oriented modelling standard UML and an iterative, incremental development process. The tools are especially strong in GUI development (dialog modelling) and database handling, but they also provide valuable extensions and add-ins to standard tools like Rational Ros e in the area of code generation.

3.2 Motivation - WHY is this useful and WHAT can be gained? The reason for working with model consistency and improving model consistency is clearly to improve the quality of the engineered software and to improve the effectiveness of the work put into a project. The most important motivation for an automated consistency checker is probably the economic aspect, since improved quality and effectiveness both are factors that ultimately influence the cost of a software development project. Potential benefits from automated model checking include:

• Increasing chance of detecting subtle errors: Very promising, is the potential for early detection of subtle and potentially costly errors (defects) that are not identified even in extensive testing. Often these errors are not recognized until the software is in the field.

• Ability of effectively handling complexity: automated work can address system

complexity that is difficult for humans to verify even through extensive individual review of the problem.

• Likely detection of errors early: Since it can be used for analysis of models

from early on in the development process without significant extra cost, automated checking offers the potential to detect more errors early in the design process before they propagate more widely into the design or ultimately into the code.


14

• Simpler identifying of basic errors: The large complexity and size of software systems obstructs verification by significantly increasing the amount of mundane checking that is needed (e.g., that there is consistent naming and use, that all the terms are defined, etc.) These editing -like activities can be effectively and efficiently accomplished through automated checking.

• More flexibility for partial and targ eted analysis: By implementing a suited front

end to a consistency checker, the checking approach can be applied to the whole of or part of the system. This enables its efficient use in upgrades of complex systems where the analysis can be targeted to only the upgraded parts of the system or to critical areas of system.

3.2.1 Benefits of a rule based system The advantages of an inference-based rule-based system are that it can store and process hundreds or thousands of rules and that it can be updated, without recompiling, by simply adding or modifying rules in its rule base. [Harmon, 2000] We do not propose to make hundreds or thousands of rules, but using a rule based point of view, one can make new rules as one sees a need for consistency in a new area of the model.

3.3 The concept of semantic web "The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. " [Berners -Lee et. al., 2001] The so-called Semantic Web promises to bring structure to the meaningful content of Web pages, creating an environment where software agents roaming from page to page can readily carry out sophisticated tasks for users. The Semantic Web is not a new and separate We b but an extension of the current one, in which information is given well -defined meaning, better enabling computers and people to work in cooperation. The first steps in weaving the Semantic Web into the structure of the existing Web are already under way . In the future, these developments can introduce significant new functionality as machines become much better able to process and "understand" the data that they merely display at present. In order to make this a possibility, the content of the semantic web must be consistent, in much the same way a executable computer program made in any programming language should be a consistent unit in order for it to execute properly. Therefore a way to ensure the consistency of the content of the web language, be it HTML, XML or something else would be useful. But since XML is seen as one of the basic technologies for the semantic web, this is seen as the primary object of interest.


15

As this paper is titled “UML Consistency” it concentrates on the consistency of UML models, but since the representation of the models is XML (XMI), the concept of a consistency checker should be relevant for all types of XML documents as well.


16

44.. RReesseeaarrcchh This chapter will present in more detail what the field of consistency checking is missing. Questions we hope to answer in this paper include:

• Which types of model deficiencies exist, and which of these could be detected by a model checking tool?

• What kind of rules can/should be available? • What are the needs in ensuring model consi stency? • What are the possible alternatives when checking a UML model? • How can an automated consistency checker be implemented?

Something to take note of is that UML is in fact a somewhat informal description, and is not ideal for complete and extremely precise error/fault detection and analysis. As a consequence, it will mainly be the syntactical side we will be addressing in the paper, as the semantic aspect of UML models is hard to formalize.

4.1 Defect types Figure 7 is taken from [Travassos et. al., 2000] and tries to illustrate where potential defects in a UML model can come from. As we can see it is clearly not only inconsistencies that can occur in a model.

Software (Design) artifacts

Other domain

Requirements

Domain knowledge

Incorrect fact

Omission

Inconsistency

Extraneous

Ambiguity

Figure 7 – Defect types


17

In the figure the model itself is represented as the box in the middle, named as the Software Design Artefacts. The types of defects are omissions, incorrect facts, inconsistencies, ambiguities and extraneous information. Some of these de fects demand the application of systematic reading techniques to be in order to be identified. However, human-performed reading of design models can probably not be executed perfectly, especially very large models with many diagrams and artefacts. The mos t tedious tasks, like searching out typing errors or certain omissions are also the ones that require the least amount of thought to carry out. At the same time they are likely to be easy to miss when inspecting manually. Therefore such checks are both possible and well suited to automate.

4.2 Object -oriented reading techniques Figure 8 is an extract from [Travassos et. al., 2000] about seven object-oriented reading techniques, the inputs and goals for each technique is stated.


18

OORT-1: Sequence Diagram x Class Diagram Inputs: 1. A class diagram, possibly in several packages. 2. Sequence diagrams. Goal: To verify that the class diagram for the system describes classes and their relationships in such a way that the behaviours speci fied in the sequence diagrams are correctly captured. OORT-2: State Diagram x Class Description Inputs : 1. A set of class descriptions. 2. A set of state diagrams for the system objects. Goal: To verify that the classes are defined, so that they can captur e the functionality specified by the state diagram. OORT-3 Sequence Diagram x State Diagram Inputs : 1. A set of sequence diagrams. 2. A set of state diagrams for several objects. Goal: To verify that every state transition for an object can be achieved by the messages sent and received by that object. OORT-4: Class Diagram x Class Description Inputs : 1. A class diagram (CDia), possibly in several packages. 2. A set of class descriptions (CDe). Goal: To verify that the detailed descriptions of classes contai n all the information necessary according to the class diagram, and that the descriptions of classes make semantic sense. OORT-5: Class Description x Requirement Description Inputs : 1. A set of requirement descriptions (RD), mainly functional. 2. A set of class descriptions (CDe). Goal: To verify that the concepts and services that are described by the functional requirements are captured by the class descriptions. OORT-6: Sequence Diagram x Use Case Diagram Inputs :


19

1. A use case diagram (UC) for a part of the system, with its services. 2. One or more sequence diagrams (SqD) for relevant system objects and services. 3. A set of associated class descriptions (CDe). Goal: To verify that sequence diagrams describe an appropriate combination of objects and messages that capture the functionality from the use case. OORT-7: State Diagram x (Requirement Description / Use Case) Inputs : 1. The set of all state diagrams (StD). 2. The set of all requirement descriptions (RD). 3. The set of use case diagrams (UC). Goal: To verify that the state diagrams describe appropriate states of objects and events that trigger state changes as described by the requirements and use cases.

Figure 8 - OORT inputs and goals Some of these reading techniques are ob viously more suited for automatic checking than others. Tasks that involve assessments of a more subjective nature, like design principles are not easy to automate. Some of these reading techniques get their input from descriptions, which are textual, and therefore not suited to automatic checking.

4.2.1 Horizontal vs. vertical reading Also, in [Travassos et. al., 2000] the concept of horizontal vs. vertical reading/checking of models is brought up. Horizontal reading involves checking the internal consistency of the design, in order to make sure that all the artefacts in the design represents a consistent system. This includes both static and dynamic views, illustrated by class diagrams and sequence diagrams respectively. Vertical reading aims to ensure traceability between requirements and design. This can be done by comparing documents from different phases in the design cycle. This means that the level of detail and abstraction are different, and here the task is to ensure that the design artefacts represent the same system as the requirements (as use -cases and prose descriptions of requirements). It is clear that horizontal checking will be most meaningful to automate, since the vertical checking often involves comparison of textual information with di agrams, and also since vertical checking also will involve checking of different abstraction levels, which in one sense can seem to be inconsistencies, but in reality are not. The different defect types presented earlier can be put into the two categories like shown in Table 1. One category is the ones that are discovered by vertical reading, the other is the ones that are discovered by horizontal reading. As we can see inconsistencies are the defect type that is the most relevant in trying to automate, so a consistency checker tool should be a plausible and worthwhile application to develop and use.


20

Vertical reading Horizontal reading Incorrect facts Inconsistencies Omissions Ambiguities* Extraneous

Table 1 – Horizontal and vertical defects Note that the ambiguity defect type can also be a defect in a vertical sense. It is quite ambiguous!

4.2.2 Discussion of the Object Oriented Reading Techniques (OORTs) The following section tries to clarify the OORTs further and discusses what could be automated in each of them, or states that automation is not suitable.

• OORT-1: Sequence Diagram x Class Diagram In this OORT the aim is to ensure that the class diagrams describes classes and inter-class relationships so that the behaviours shown in the sequence diagrams are possible. In this case things to check could be that the classes shown in the sequence diagram exist, that the operations used in the sequence diagram exist in the right classes and that ope rations that show relations between classes also has a representation in form of an association in the class diagram.

• OORT-2: State Diagram x Class Description This is based on descriptions, and is therefore not suited to automated checking.

• OORT-3: Sequence Diagram x State Diagram This is a quite straightforward OORT, as it concentrates on actions described in the model. The goal is to verify that the state transitions for an object can be performed by the messages the object sends and receives.

• OORT-4: Class Diagram x Class Description Again, this OORT is based upon a textual description, and is not suited.

• OORT-5: Class Description x Requirement Description As this OORT is supposed to match two descriptions, it is not applicable.

• OORT-6: Sequence Diagram x Use Case Diagram This OORT verifies that sequence diagrams describe an appropriate combination of objects and messages that present the functionality from the use case. This is a vertical check, but could be possible to automate, although in a simpl e manner.

• OORT-7: State Diagram x (Requirement Description / Use Case) Here the goal is to make sure that the state diagrams describe appropriate states of objects, as well as events that can trigger state changes in accordance with the


21

requirement description and use cases. Matching of states and state changes with the requirement description will not be possible, but if modelling is done properly, matching with elements from the use case diagrams could be possible. To summarize, checks belonging to OOR T-1 and OORT-3 should be straightforward to check, and in certain cases OORT -6 and OORT-7 should be possible to check for some of the artefacts belonging to use cases. A topic the OORTs do not include is the reading/checking within one diagram, i.e. it could seem like the OORTs take for granted that the diagrams are consistent within themselves. Certainly there should not bee a need for special techniques for examining the consistency of a diagram, but an important task for a consistency checker tool would be to make sure a diagram at least does not conflict with itself.

4.3 Alternatives for an improved consistency checker There are several alternatives one can consider when contemplating an improved consistency checker. Manual checking, hard coded rule checking (as in the Genova consistency checker), or a general checker that can be fed with rules as needed. Manual checking This would be the most basic way of checking for consistency in diagrams, and this method is certainly used frequently and by man y developers. The problem is that it is costly, as this method takes a lot of time. An advantage is that the ones doing the checks can see any semantic inconsistencies as well as the syntactical ones. Until the semantic elements in a model can be formalize d, this is the only way of finding certain defect types that cannot be stated in the form of rules. Hard coded rules In the case of the Genova consistency checker, the rules are incorporated in the source code as different applications of comparisons insi de loops and recursive structures. If one wishes to add more checks, one will have to make a new subroutine for that check, and this routine would have to be made from scratch. Also the user interface would have to be altered to accommodate the new check. Semi -hard coded rules It would be possible to make the Genova tool more general, as in making the comparisons and loops on a more general level. This would still mean that addition of new rules would have to be done by programming them, although one would not have to make them from scratch if one could use functions already coded in some way. Application -independent rules Apparently, the optimal solution, as seen from a functionality viewpoint, would be to produce a solution where the rules are not embedd ed in the application at all. This


22

way new rules could readily be defined. If the model syntax expands, for UML represented by new stereotypes, or a more revolutionary development of the modelling language, new rules for new syntactic elements could also b e added without toil.

4.3.1 What can be checked? The current consistency checker is not a very general one. Not all of the tests it can perform are relevant to a general UML model development. Many of the existing tests are linked to Genera’s special s tereotypes for the Genova tool. An expansion of the number of general checks must be done, and defined as rules in a certain rule language. The diagrams that are possible to check are those that can be exported to XMI from Rational Rose or any other UML modelling tool. The Unisys Rose XML Tool is very thorough and supports most of the candidate diagrams. Some UML artefacts and diagrams are summarized in Table 2. Dynamic view Static view

• use cases • activities • interaction

o sequences o collaborations

• state machines

• classes

o relationships � generalizations � compositions � associations � dependencies � realizations o extensibility � constraints � stereotypes

• descriptions • packages • deployment

Table 2 – UML diagrams and artefact s

The diagrams that are available in XMI made from exporting UML to UML as XMI in Rational Rose are shown in Table 3.


23

Diagram types

• Use case diagrams • Class diagrams • Component diagrams • Deployment diagrams • Collaboration diagrams • State chart/state machine

diagrams • Activity diagrams • Sequence diagrams

Table 3 – Available diagram types in XMI from Rational Rose/Unisys The types shown in Table 3 include most of, and certainly the most i mportant parts of Table 2.

4.3.2 Taxonomy of inconsistencies, errors and flaws A classification scheme of things that can be wrong in a UML diagram could be useful. This is because not all faults will have the same implications if not identified. Some will be more serious or difficult to find and fix than others. The types of shortcomings in a model can be divided into several groups. The following is a classification of deficiencies, along with a short description or explanation of the deficiency in question.

• Syntactical errors: attributes should be named in a certain manner • Completeness/omissions: missing type information for an attribute, or other

missing information • Inconsistency internally in a UML view, for instance in a clas s diagram • Inconsistency across UML diagrams, for instance objects in a sequence

diagram in relation to belonging class diagrams • Qualitative flaws: Coupling too strong or weak, related to UML packages, or

perhaps on a design pattern level • Design pattern violation: If a design is to be made according to a pattern, and

clear errors according to the pattern are made

Figure 9 – Simple classification of UML model deficiencies As stated earlier, the faults applicable to an automated mo del checker of our calibre would be ones connected to the syntactical side of a model. That would include the top four items in Figure 9.


24

In the same way, the seriousness of the shortcoming can also be categorised. Some of the flaws will be out-and-out errors, in that they should never be allowed to appear in a diagram. Others could be of a nature that in some cases are not errors as such, as in the case of missing cardinality specification, which could be interpreted as representing a “0..*”-type cardinality. Such decisions are really up to the developers in question, and is probably more related to what the developers are used to or what the project’s standard states than what is right and wrong to do. In [Travassos et. al., 20 00] the severity of defect types are exemplified as:

• Major • Significant • Minor

In addition, one could partition warnings in the categories

• Significant • Minor • Negligible

A third categorisation possibility is about how difficult it is to find the defect. Som e will be trivial, and therefore well suited to automatic checking, whilst others are more diffuse and depend more on a broader model understanding as well as a semantic insight than on pure recognition.

4.3.3 Choice of consistency checker expansion There obviously exist several options when planning to implement an improved consistency checker. Should it be a totally new implementation, or a modification of the existing solution? The following are the options we have seen as most relevant in this proje ct:

1. Expanding the Rose Script solution 2. Implement checker by XML parsing an XMI document, using rules made in for

example prolog 3. Implement checker by XML parsing an XMI document, using some more

common development language and rules in something of the kin d of xlinkit or OCL

Expanding the Genova consistency checker One possibility in the quest for a more general consistency checker could be that of improving the existing consistency checker. The most obvious possibility of making it more efficient and general by implementing it in a way where it would not traverse the whole model for each consistency check that is performed.


25

A major point that weighs against this type of solution is that the Genova checker’s environment is inside Rational Rose, and works on the internal model workspace of Rational Rose through the REI interface, so it is not connected to XMI in any way. That means that no matter what expansion is made on this application, it will never be independent of Rational Rose. New implementation using Prolog With the use of prolog we would have an inference engine to do all the matching of rule instances, with the developers having to make a bridge from the parsed XML to the rule application. New implementation using other development language This would let us decide quite freely on the rule language to be used, and would let us program in a well known language like Java or C++. The downside would be that we would perhaps have to make the rule matching ‘engine’ from scratch, as the solutions we found elsewhere did not seem very suitable.

4.3.4 Analysis of consistency checker application results What kind of analysis tools can be made in conjunction with a consistency checker? How can such results be of use? Clearly, some kind of diagnostics tool could be made in a consistency checker. In addition to reporting the inconsistencies and faults that are found, a summary of the number of found faults could be output from the tool. If the consistency checker had knowledge of the “quality” of the f ault, it could classify the errors into groups according to what kind of faults they were and how serious they would be. In this way one could easily see if the general state of the UML model was seriously inconsistent, or just a little flawed.


26

55.. TTeecchhnnoollooggyy AAll tteerrnnaatt iivveess In this section we will present the different technology elements we have considered in the planning of the development of the consistency checker. First a little introduction to the planned inner working of the application, then more det ailed about implementation language, model parsers and possible rule choices.

5.1 The “engine” of the consistency checker. In the Genova consistency checker, the engine is really just a collection of loops and comparisons of variables that may or may no t trigger an output. Thus it goes through the model several times checking one property at a time. This in it self is not a very efficient solution, and could certainly be improved. By making a more general consistency checker, one would still have to go through the model in loops, but maybe handling several properties at a time. One possibility that appealed to us is that of using an inference engine, which is a software tool that emulates the human quality of being able to arrive at a conclusion by reasoning. We generally recognize two types of inferencing: Forward chaining and backward chaining.

5.1.1 Forward chaining or data driven This applies to reactions to a change. For instance, you turn on the lights in your house when you see that it is gettin g too dark in the room to read. The theory is that the new information causes us to examine some specific rule that we can locate directly without having to review or execute any of the other rules that are irrelevant at the moment. Forward Chaining applies the rules to the currently known facts to deduce new facts. Without some guidance as to the rules that are to be chosen it leads to very inefficient implementations.

5.1.2 Backward chaining or goal driven This applies to the situations where we are trying to explain the cause of what we observe. For instance, you may notice that the light in your house went out and you can then look out the window to see first if the problem is in the whole area, and if it is not, then you will check the fuse box in your house. Goal driven inference applies to situations where you are making a diagnostics. It presumes that we are aware of a given situation but we do not know what caused it.


27

Therefore we have to ask questions and/or perform some tests to determine the cause. Backward Chaining is the inference method used by the prolog engine. Backward chaining is thus easy to code in prolog. Inference proceeds by choosing a goal to be proved and looking for rules that will establish the goal.

5.2 Inference engines There are four control components of an inference engine: • Matching - Current rule is compared to given patterns • Selection - Most appropriate rule is chosen • Fire - Implementation of the best rule • Action - Execution of resulting action A consistency checker could be implemented as an expert system, usin g combination of rules and probabilities to choose among rules to be chosen, but in this case a simple case of checking if a rule is satisfied or not will do. The main object is therefore to see if the current situation (the model) satisfies a given rule. The matching, firing and action parts of the inference engine would still be in use. If an inference engine were to be used in an implementation, the question would be which kind of inference engine to use, and why. The following are the possibilities we have considered.

5.2.1 Java Several inference engines for Java has been looked into, some including a prolog inference engine as java classes, others are based on other types of inference engines. Java Internet Prolog JIP - Java Internet Prolog is a p rolog interpreter for Java made by Ugo Chirico. It has been developed using JDK1.1 and uses the prolog Edimburgh syntax. As such it is compatible with some of the other well -known prolog engines (such as LPA, Quintus, SWI) and can be run by any browsers su pporting JDK1.1. JIP advertises with an easy-to-use API by which one can use the prolog engine in any java applet/application. Using this API one can use the prolog engine in java classes and calling the needed prolog code in the same way one would call a java method and vice versa one can invoke java classes in the prolog code as the predicates are called. In addition, the JIP architecture allows extension of the set of built -in predicates in the same way as java classes are written. Custom features, such as custom dialogs or custom algorithms can be implemented.


28

Problems with this are that it is not a widely recognised standard or application, and is not very well supported. Also some of the reasonably standard prolog predicates were not implemented, which is quite an inconvenience. Jess Jess (Java Expert System Shell) is a rule engine and scripting environment written entirely in Java by Ernest Friedman-Hill at Sandia National Laboratories. Jess was originally based on the CLIPS expert system shell, but has grown into a comp lete, distinct Java-influenced environment of its own. Using Jess, it is possible to build Java applets and applications that have the capacity to "reason" using knowledge supplied in the form of declarative rules. [Jess] The fact that this system presen ts itself as, and seems to work more like a expert system than a pure inference machine did not make it seem very suitable to us, and therefore discarded it early in the process.

5.2.2 Prolog By using the prolog language, the inference engine is include d in the language. Programming of multiple loops as is done in the Genova consistency checker would not be as mundane, since prolog can make traversing structures more effective with its concise and powerful syntax. Prolog is a declarative language, as op posed to traditional languages as C and Java, which are procedural languages. By stating the facts and rules that relate objects in the problem domain to each other, you construct your Prolog program. Its meaning is the set of logical consequences of these program statements, and this is computed by the inference engine at run -time. The Prolog programmer only needs to supply a description of the problem and the ground rules for solving it. From there, the Prolog system is left to determine how to find a solution � The concept of the inference engine is presented above in this chapter.

5.3 Parsing the XMI document SAX and DOM are two ways of processing XML files that were both designed to allow programmers to access their information without having to write a parser themselves. Most available XML parsing packages include these two types of parsing. Examples of XML parser packages are IBM’s Alphaworks XML Parser (for Java and C++), The Apache XML Project’s Xerces (for Java, C++ and Perl),


29

Microsofts XML Parser and Sun’s The JavaTM XML Pack. In addition there exists a multitude of parser implementation without the big brand name backing.

5.3.1 SAX SAX (Simple API for XML) is an event based form of processing XML documents. Different to most other processing models SAX will not build an internal tree representation of the XML data, instead it will fire off a series of events as it reads the document from beginning to end. These events are sent to event handlers, w hich provide access to the document contents. SAX is a serial-access mechanism for accessing XML documents. This is the protocol that most servlets and network -oriented programs will want to use to transmit and receive XML documents, because it's the fas test and least memory-intensive mechanism that is currently available for dealing with XML documents. Developers who are writing a user -oriented application that displays an XML document and possibly modifies it will want to use the DOM mechanism described next.

5.3.2 DOM The Document Object Model (DOM) makes the information stored in XML documents accessible as a hierarchical object model. DOM creates a tree of nodes (based on the structure and information in the XML document) and one can access the information by interacting with this tree of nodes. Each node contains one of the components from an XML structure. The two most common types of nodes are element nodes and text nodes. Using DOM functions lets you create nodes, remove nodes, change their contents, and traverse the node hierarchy. The textual information in the XML document gets turned into a collection of these tree nodes. Regardless of the kind of information in the XML document (whether it is tabular data, or a list of items, or just a doc ument), DOM creates a tree of nodes when you create a Document object given the XML document. In this way DOM forces use of a tree model (just like a Swing TreeModel) to access the information in the XML document. This works out quite well because XML itse lf is hierarchical in nature. This is why DOM can put all the information in a tree (even if the information is actually tabular or a simple list). DOM implementations provide an abstract API for the construction, access, and manipulation of XML (and HTML ) documents. A binding of the DOM to a particular programming language provides a concrete API. Microsoft, Sun and other vendors provide APIs which let us use the DOM to query and manipulate XML documents in memory.


30

5.3.3 SGML parser for Prolog SWI-Prolog makes it possible to import and parse SGML -files with the sgml2pl package which is available from SWI -Prolog’s webpages. As XML is a subset of SGML, it is also possible to work on XML with SWI -prolog. The following is a little example of how SWI -Prolog handles XML. SWI Prolog mainly uses the term element(ElementType, AttributeList, Children) to keep the XML information. That means that the element( ) -predicate is the heart of the xml-representation. A little XML file like <example date="2001.11.06"> <p> <em> Hello </em> , world! </p> </example> would be returned as the value element(example, [date='2001.11.06'],[ element(p, [], [ element(em, [], ['Hello']), ', world!'])]) It is to be said that the XMI has some properties that make the use of the SGML -parser a little more complicated. A translation of special characters is made, so that <, >, /, “ and others show up as other characters, or not at all after bei ng parsed. The reason for this is to comply with Prolog rules of atoms. For instance, an attribute that is found in an XML document as xmi.version=”1.1” is translated to ‘xmi.version’=’1.1’ . The problem with this is that the latter expression is seen as a kind of operation, where ‘xmi.version’ is set equal to ‘1.1’. Thus it does not interpret the whole thing as a text string, as we could have wished for. For this reason, we had to go around this problem and do the implementation in a different way than firs t planned.


31

5.4 The rules One can put consistency rules into several categories according to the model discrepancy it is supposed to handle. In one dimension there is the type of rule, whether it applies to finding general errors (like having the same ro le names on different associations going out of a class), warnings about object oriented discrepancies or if its is supposed to take care of special faults (like the rules for self -made stereotypes). In the other dimension there is the severity of the error/warning/fault, from minor to major to supermajor. This was presented more carefully in chapter 4.3.2. The rule format should not be a totally proprietary one, as this would mean that making new rules would be difficult for people not involved in develo ping the rule format. A well-known way of representing rules is preferable, as this means that understanding and making rules would be a manageable task. Different possible formats already exist, with some being more flexible, some being more powerful and of course some being easier. The ones we present here are ways of representing rules that already exist, as choosing to use one of these lightens our burden in the making and adaptation of a rule format considerably.

5.4.1 First order predicate logic Expressing rules in predicate logic can be done with several degrees of formality. Informal predicate logic is most suited to present the rule in a human understandable way, and is not suited to computation. Further, first order predicate logic has both sem i-formal and formal descriptions for use in automated computation. There exists a logic language Q implemented in ML. An example of the use of predicate logic, even if it is not used in implementation, is in defining rules, since this is a very precise ex pression format. The following is an example that will be used to illustrate the other rule representation formats. A constraint that can be applied for associations in the UML Foundation/Core package, “The AssociationEnds (role names) must have a unique name within the association” can be expressed abstractly as

∀a(∀x ∈ a(∀y ∈ a(name(x) = name(y) → x = y))) where a will be assigned to the associations and x and y refer to the association ends inside the association. This can be stated in another less formal way: “The role names in an association must not be the same”. This rule could now be evaluated


32

against a set of documents in order to establish their consistency status with respect to the rule.

5.4.2 Prolog If implemented in Prolog, the rules w ill be made so that the execution of the checker will try to match the rule to the facts that are available from the XML model. A fact from the XML model will be on the form: element('UML:AssociationEnd ', ['xmi.id'='G.2', name='Rolle_A', visibility=public, isSpecification=false, isNavigable=true ordering=unordered aggregation=none targetScope=instance changeability=changeable], [CHILDELEMENTS]) element('UML:AssociationEnd ', ['xmi.id'='G.3', name='Rolle_B', visibility=public, isSpecification=false, isNavigable=true ordering=unordered aggregation=none targetScope=instance changeability=changeable], [CHILDELEMENTS]) The task will be to extract the attributes of each object, for instance it’s name, and use rules to compare different objects and make sur e they comply to the relevant consistency rule. To check that the exemplified AssociationEnds has different names, one must traverse the structure of the xmi document, until the element with the name 'UML:AssociationEnd'. Here the attribute name can be co mpared between the two AssociationEnds. The rule from 5.4.1 would be something like element(_, [_|[A|_]],_), element(_, [_|[B|_]],_), ( A==B - > print(‘Equal role names detected’) ).

This may look very cryptic, but the essence is that element(_, [_ |[A|_]],_) extracts the rolename of the first Role, and element(_, [_|[B|_]],_) takes care of the second. Then the comparison is made in the third line, and if the two names are equal, it would output some sort of alert.

5.4.3 OCL Accuracy and unambiguity in specifications have been, for a long time, the aims of the branch of computer science known as “formal methods”, and attempts have been


33

made to combine them with object -oriented modelling. One of these attempts has its origin in the Object Management Group (OMG), and is called OCL - Object Constraint Language. OCL has since 1997 been a part of the UML standard. [Abreu, 2001] This is a language that allows specifying invariants, preconditions, postconditions, guard conditions, and other types of const raints on different parts of object -oriented models. It is based on mathematical set theory and logic, but was designed for usability and is easily grasped by anybody familiar with object -oriented modelling concepts in general, and UML notation in particul ar. OCL is a pure expression language. Therefore, an OCL expression is guaranteed to be without side effect. It cannot change anything in the model. This means that the state of the system will never change because of an OCL expression, even though an OCL expression can be used to specify such a state change (e.g., in a post -condition). All values for all objects, including all links, will not change. Whenever an OCL expression is evaluated, it simply delivers a value. OCL, which is an optional part of t he UML standard, is a language for expressing constraints over a collection of objects. OCL has even been used to define semantic aspects of the MOF and UML standards, and is also used in OMG’s XMI papers [OMG] to define the XMI stream production rules. OC L can also be used to define semantic constraints in MOF metamodels and UML models. However, since OCL has no inherent capability of data structure modelling, it will not directly be applicable to model or metamodel interchange. OCL is a formal, but simpl e notation, to be used in conjunction with UML diagrams and whose syntax has some similarities to those of object -oriented languages such as Java and C++. OCL is a formal language, which still remains easy to read and write. One of the strong points of OC L is its use of existential quantifiers used in formal logic, namely the symbols ∀ “for all” and ∃ “exists”. This is a strong quality, as it says a lot about what objects are included in a selection in a very precise way. The example in 5.4.1 represented in OCL:

Association.AssociationEnd -> forAll(x, y | x.name = y.name implies x = y)

A note on OCL is that although it is primarily intended for use alongside a UML model, it is quite possible that OCL also could be used as a tool in the consistency checking of more general data. If OCL can be used to enforce consistency on a UML model represented in XMI, this means that it should also be able to do the same with “ordinary” XML documents. An interesting note about OCL is that the RTF made a change to the X MI specification from 1.0 to 1.1. In addition to the existing specification format in Pseudo -code and OCL that were used in version 1.0, a more formal specification was made in EBNF (Extended Backus-Naur Form). The goal was to better clarify the resulting output and more clearly state the productions in terms of final form rather than in


34

terms of a process. Although the results of both methods are the same, this is perhaps an indication of OCL not being as formal as one could have hoped.

5.4.4 Xlinkit Xlinkit’s rule format is based on well -formedness of the model according to their well -formedness rules. These well-formedness rules are expressed in their own rule language, which allows arbitrary first order logic expressions, restricted to equality as the only predicate and finite sets of DOM nodes as the only type of set allowed. Because the language is still experimental, not all rules have been expressed yet and some have not been validated against test data. Xlinkit also uses the existential quantifie rs in its rule language, represented as “forall” and “exists”. In [Nentwich et.al., A] it is stated that OCL is more expressive than xlinkit, although it is also claimed that OCL will have difficulty in making diagnostics beyond true and false. Also OCL is very strongly coupled to UML and not able to specify constraints across heterogeneous data documents. The example from 5.4.1 repeated with xlinkit’s rule format: Forall a in $associations ( forall x in $a/Foundation.Core.Association.connection/Foundati on.Core.AssociationEnd (forall y in $ a/Foundation.Core.Association.connection/ Foundation.Core.AssociationEnd ( $x/Foundation.Core.ModelElement.name/ text()=$y/Foundation.Core.ModelElement.name/text() implies $x===$y ) ) ) Here the a represents the Assoc iation that is being checked, x,and y represents AssociationEnds.

5.4.5 Other rule formats One other rule format we assessed was Rule ML (Rule Markup Language). The feeling was that this was not directly relevant to our project, although it could easily come in handy in more general consistency checking applications The Rule Markup Initiative is a group that has put Rule ML forward. This is a language that is supposed to permit both forward inferencing and backward inferencing rules in XML for deduction, rewriting and other inferential and transformational tasks. It appears that it’s main goal is to be a contender for standardisation in conjunction with the semantic web. [Rule ML]


35

66.. TTeecchhnnoollooggyy ddeessiicciioonnss

6.1 Development of a rule based consistency c hecker

6.1.1 Technology alternatives Before trying to develop a new consistency checker system, an assessment of the available applicable technologies must be made. Here, the term ‘applicable’ means not only what we have found to be relevant, but also wha t we feel we are able to handle and not least what we have access to freely. Several different aspects of technology selection must be considered; among these is the maturity of the chosen technology, the amount of documentation available and the state of acceptance in the software community for the technology. The main technology choices are model representation, programming language and way of parsing the model. In addition the choice of rule representation is an important issue. UML Model representatio n The alternatives we have looked at are mainly Rational’s mdl -format and the XMI format. In addition USE’s model format is also a model representation of this sort, but really falls out of consideration since it is not used outside the USE application and in addition is a subset of UML, which reduces its usefulness further. The mdl-format can be said to be a standard of some sort, since several UML tool vendors support it. But it is not an open format like XML, and XML also has the advantage of being a hot topic in the computer industry these days. The proprietors of the mdl-format, Rational, also has a hand in the development of the XMI format. Also

Properties Format Industrial

standard Complete UML

Supported by other tools (i.e. parsers)

Versatility of format

Mdl Partially Yes No Low XMI/XML YES Yes Yes High USE No No No Low

Table 4 – Model representation alternatives Not surprisingly our conclusion was to choose XMI as the model representation format. As this is a widely s upported format and covers the whole of UML, it is a format that will not easily become superseded by “the next big thing”. Also, a big plus from an implementation point of view is that there already exist tools, in many languages, for processing XMI (in t he form of XML-parsers).


36

The programming language In choosing the programming language to be used in the development, the main factors for deciding have been “what do we know” and “what will work best”. The alternatives that looked most likely were not surprisingly C++ and Java, as well as Prolog. Given our previous experience with the two, Java or C++ seemed to be the most natural choice of implementation language. Prolog had the benefit of having an inference engine embedded in the language, and as dis cussed earlier this could prove to be a very beneficial and efficient way of doing the implementation. One important factor when choosing the language is that the XML parsing is available as an accessible tool, since that is an important part of the model management. The before mentioned languages all have readily available packages to enable XML processing. Therefore these, namely Java, C++ and Prolog seemed to suit our needs.

Properties Language Prior

knowledge Available XML tools

Embedded Inference engine

External Inference packages

Java Good Yes No Not good C++ ok Yes No Not good Prolog Doubtful Yes Yes -

Table 5 – Implementation language alternatives When making a choice, our feelings were that we would need a goo d inference engine system in addition to the must of having XML parsing tools. In spite of the fact that we did not feel comfortable with the Prolog language, we felt that the need for the inference engine was too strong to avoid it. The inference engine p ackages and solutions we saw for the other languages did not seem to be what we were after. The model parser When looking for the XML parser to be used, the main alternatives in conjunction with C++ and Java would be DOM and SAX. The SWI -Prolog Prolog compiler also has tools for importing and handling XML files. SAX has the benefit of being a fast and efficient parser style, but suffers from having to read the XML-file sequentially. This means that if using a SAX parser, the XML would have to be read and processed a great number of times. The SAX protocol requires a lot more programming than the Document Object Model (DOM). It is also harder to visualize, since it is based on an event -driven model. The callback methods are provided, and the parser invokes them as it reads the XML data.) Finally, it is impossible to "back up" to an earlier part of the document, or rearrange it, any more than you can back up a serial data stream or rearrange characters you have read from that stream.


37

Some advantages with SAX is that it gives the best performance in XML processing, and it does not require huge amounts of memory while processing large XML documents. Other disadvantages than those of the serial access style, are that SAX requires creation of a custom object mod el and creation of eventlisteners/handlers. One of DOM’s properties include that DOM forces the use of a tree structuring of the data, something that works well for XML. The SWI-Prolog SGML parsing ability makes it possible to import XML documents as facts for Prolog inferencing. One of the largest disadvantages of this parser is lack of documentation, and prolog’s unorthodox approach compared to the regular parser styles. The alternatives here did not nudge us from our decision to implement in Prolog, and therefore it was the SWI -Prolog sgml2pl-package that was decided to be our XML parser. The rule format Several of the presented possible rule formats seem to be promising, while OCL has a clear relation to UML, xlinkit has already been used in a con sistency checker implementation. And most importantly all of them seem to be able to express what is needed for them to be useful. The aspect that decides it all, though, is how the rule format can be combined with the other technology aspects we have stud ied. If opting to go with OCL or xlinkit -like rules, we would have to program most of the consistency checker from scratch, making our own rule parser as well. As the want for a good inference engine was seen as the most important factor, we decided that we should try to implement the rules in the Prolog language. Summary In light of this discussion the decision was to do the implementation in SWI -Prolog, using its SGML (XML)-parsing ability on the XMI representation of the UML model. In this way we would have easy access to a well reputed inference engine without having to write one ourselves, or have to hassle with uncertainly supported inference packages from other sources.

6.1.2 The rule interface towards users A very appropriate question in all o f this is how users should be able to use a rule based general consistency checker. One thing is using existing rules, or perhaps adjusting some rules to better suit the users needs. Another aspect is the fact that


38

users perhaps need to invent totally new rules that do not already exist in the “rule base”. If the user has to deal with a very complicated way of expressing rules, there will be such a steep learning curve for using the consistency checker tool that it would probably not be useful. Clearly, Prolog is not an ideal interface for ordinary UML developers. Prolog is neither very common as a programming language, nor particularly easy to learn. So some kind of bridge from Prolog rules to a reasonably comprehensible form of making the rules would be a very useful artefact. When we examine the rule languages previously presented, we see that some of them are much easier to understand than Prolog. OCL and xlinkit are not very different from each other, and both are readable for anyone with just a littl e experience with logic expressions. One solution for rule definition for users without Prolog knowledge could be some kind of mapping from OCL or xlinkit rule format onto Prolog rules. Another solution we see as being plausible is the development of a g raphical user interface for rule synthesis. That way, users with no experience with these kind of rules whatsoever should be able to define checks they want to have carried out. This interface could include choices for which artefacts in the UML model that should be checked, and what kind of consistency the user wants to check. Lastly, an idea arises that involves the future of the modelling tools themselves. What if the modelling tool itself had all the consistency checking possibilities? The user could if desired be warned about inconsistencies interactively while the model was developed. This in fact just means an upgrading of the already existing consistency checking facilities in the modelling applications.

6.1.3 Presentation of consistency checker re sults When running consistency checks on multi megabyte models, one can easily end up with very large amounts of errors and warnings. Therefore the presentation of the results is an important part of making the consistency checker useable. A simple idea would be to define an indexation of the error/warning types. This way it would be simple to filter out the types of errors and warnings that are interesting, just by selecting the results that contain the desired index from the total result.

6.2 A prolog based consistency checking tool In light of the discussion earlier, we decided on implementing the consistency checker tool using SWI-Prolog, with its SGML parsing ability.


39

Figure 10 proposes how the model information is tran sferred from a UML modelling tool into the consistency checker application. The application uses the rules chosen by the user to produce a preliminary result, which in turn can be filtered so as to present only the desired level of severity.

SWI PrologSGML parser

Extracting themodel information

XMI UMLmodel

Imported usingthe sgml2pl

package for SWI-Prolog

XML ”by”sgml2pl

Result

Result filterOutput to

user

Consistencyrules

Prolog factset

RationalRose

UML model

Unisys XMI UMLexporter

Legend

Data

Process

Consistencychecking!

(1)

(2)

(3)

Figure 10 – Information and process flow

The first part would be to import the model and convert the relevant parts to facts. This is represented in the parts marked with (1). The next step is to execute the actual check with the rules on the facts, as shown in (2). The part marked with (3) shows the results being cleaned up for presentation to the user.


40

77.. RReessuull ttss

This chapter is split into two parts. The first is about some tests we ran with the Genova consistency checker, and the second part is about the implementation of prolog consistency checking.

7.1 Applying the Genova consistency checker on UML models

7.1.1 Description of the models To examine model consistency, one has to have some models to examine as well. In this project we will be using five different models, two from Genera and three from IDI. Table 6 shows some characteristics for the different models and their files. Model name mdl

size XMI size (with diagrams)

# diagrams

# packages

# classes

Lisa1 4,21 MB

5,57 MB (6,98 MB)

~140 123 Categories

718 Classes

Lisa5 5,44 MB

9,60 MB (11,6 MB)

~192 131 Categories

737 Classes

eCourse 3,31 MB

6,09 MB (7,45 MB)

~128 121 Categories

203 Classes

Loan Arranger

248 KB 310 KB (373 KB)

9 2 Categories

12 Classes

Parking Garage

197 KB 210 KB (268 KB)

11 2 Categories

12 Classes

Table 6 – Model des criptions Note: Use Case and Logical View are Categories (a synonym to packages in the REI interface), so that all models (with a use case diagram and a class diagram) will contain at least these packages. On the larger models some of the diagrams were empty or nearly empty, so the number of diagrams are given without total precision.


41

7.1.2 Results from the Genova consistency checker on two real UML projects As part of the summer job at Genera and the early stages of this project work the Genova consistency checker was applied to Rational Rose UML models from two different projects, one commercial and the other academic. The first two models came from a development project called LISA that Genera has running for NSB (the Norwegian railway service). It is a booking system to be used by NSB employees working with customer relations. The two UML models (Lisa1 and Lisa5) are taken from different times in the project, giving us a chance to look at the changes that occur while a system is in development. The last model has its origin in a diploma thesis at the Norwegian University of Science and Technology and is a BSCW style web service called eCourse. The system was later improved as part of a fourth year software architecture course held by Dr. Letizia Jacc heri. Since the Genova consistency checker is specially constructed for the Genova development tool some of the test are not relevant or applicable to the eCourse model. Some also check parameters that are not available in Rational Rose without the Genova extension. The LISA models have been made using the Genova extension of Rational Rose. The checks implemented in the Genova consistency checker are described in the ‘user guide’. It is immediately apparent that the models contain a large number of potent ial garbage. “Garbage” is model elements that exist in the model, but not in any of the diagrams. If you delete an element in a diagram in Rational Rose it is just removed from the diagram, not the entire model. This has the effect of leaving a lot of unintentional garbage, as any modeller will most likely make several changes in the course of a development process. The eCourse model and the two LISA models have respectively 421, 300 and 301 lines of potential garbage, where each line represent one element in the model. One interesting aspect is that the numbers for the two LISA models are virtually identical although there is development time between them. A closer look reveals that it is a lot of the same elements. This would indicate that most of the gar bage is created early in the project when the model is created. The changes along the way do not make much of an impact. What we refer to here as garbage consists of classes, use cases and associations that has been added to a diagram and later removed. W hich element type makes the majority of this varies between the two projects. The garbage in the eCourse model consists of about 69% classes, while in the LISA model it is about 88% associations. In the three models there is also a certain lack of set car dinality on the ends of associations, although in very different amounts. With 697 lines the eCourse model has far more of this phenomena than the two LISA models with only 38 lines (same amount in both). The reason is most likely that the developers at Ge nera use their own development tool Genova. This requires that the modeller is very specific in the


42

work done. Since there is such a large lack of cardinality in the eCourse model there has probably not been too much focus on that aspect of the modelling. The last inconsistency to be shared by all three models are classes with multiple nameless 'opposite class' role names. This means that the role names on the far sides of one or more associations belonging to a class are lacking. The eCourse model has 120 lines while the two LISA models have 20 and 21 lines. The reason for the larger number in the eCourse model may again be that this inconsistency is more important to remove when using the Genova tool because it will impact on the effectiveness of the DB functionality. Such considerations do not have to be taken by the developers on the eCourse model. The remaining checks in the Genova consistency checker gave results only for the two LISA models. The reason for this is, as mentioned before, the fact that many of the checks are specially constructed to prepare models for the Genova development tool. An association's owner class must contain a primary key. In the two LISA models there are 3 and 4 lines concerning the lack of this. An inconsistency showing up in much greater numbers is when you have two (or more) attributes in a model with the same name but different types. This indicates that an error have been made as these attributes might be meant to hold the same kind of information. The consistency ch ecker reported 464 and 539 lines of this phenomenon in the two LISA models. This is an increase of about 16% from Lisa1 to Lisa5. Classes with stereotype “Dialog” must have a class with stereotype “Application” class as root node. Exactly the same 18 line s were reported for both LISA models. This could mean that this part of the UML model has not been substantially altered since the beginning of the modelling. The same seems to be true for the check that finds classes with stereotype “Entity” that is not p ersistent. Both models get the identical 15 lines in the report generated by the consistency checker. The same 19 dependencies are reported as being neither of stereotypes «Contains» nor «activates» in both LISA models. Dependencies have to be one of the two stereotypes mentioned above. «Activates» dependencies must have «Dialog» end nodes and «Contains» dependencies must go from a «Application» class to a «Dialog»class. A class can belong to a “Group”, where all members of the group must have certain attributes and associations. By giving an attribute the name of a group and the stereotype ”Group” the class becomes a member. Two attributes in the LISA models refer to “Group” classes that do not exist. The attributes of classes with stereotype “Group” must have stereotype “Attribute”, “Association” or “Group”. There is one attribute in the LISA models without one of these stereotypes. Both models contain the same 6 persistent classes that lack a primary key attribute. This is important to correct when usin g the DB generator in the Genova development


43

tool. If the contents of an object of that class are going to be stored in a DB it will require a primary key. One interesting aspect is that the numbers of inconsistencies for the two LISA models are virtually identical. This seems to indicate that the majority of the inconsistencies are created early on in the project. Not only is the number of inconsistencies in the two LISA models close, but also it is to a large extent the same ones. Very few got removed du ring the development time that elapsed between the two model files. An extract of the results produced when running the Genova consistency checker on the Lisa5 model is included in the appendices. The two small models (Loan Arranger and Parking Garage) w ere also run through the Genova consistency checker, but the results were not very relevant. This was because the models were very small, as well as not using any of Genera’s special stereotype modelling options. The complete output of the consistency chec ks of these models is nevertheless also included in the appendices.


44

7.2 Implementation of a rule based consistency checker Here we present how the implementation works, with excerpts from the code. The complete code can be found in “ Appendix E. The prolog implementation”. We have called the checker “xcon”.

7.2.1 Getting the facts The following section refers to the part (1) in Figure 10. The first step is to import the XMI document and translate it into prolog facts that we can apply tests to. We begin with clearing any existing facts about any models. By using the command load_xml_file(File, Target) , we can load the XMI document into memory. retractall(element(_,_,_), load_xml_file(Term,[DrWho|_]), assert(DrWho),

The following step is to “enter” into the parent element, to extract the child elements that we are going to use as facts for testing. Once these elements are found, we “assert” them to make sure that they stay in memory. element(_,_,[_| [element(_,_,[element(_,_,[element(_,_,C)|_])|_])|_]]), member(O,C), assert(O),

This operation extracts the class and association elements and stores them. This is not a general way of doing this, but it works! The actual code is a bit more complex as it handles the possibility of no elements. A predicate called xcon incorporates the above code samples. This sequence of events is triggered by typing xcon(<name of xmi file>). ?- xcon(‘test.xml’).

This action has to be done before any checks can be execut ed, and for each time a new model is to be checked.

7.2.2 Applying a check on the model This part is covered by part (2) in Figure 10. The first check implemented is the rule that states that the role names of an association should not be equal, the same presented in chapter


45

5.4 The rules. We first extract elements of type Association, element('UML:Association',C,[element(_,_,[element(_,A,_)|[element(_,B,_)|_]])|_])

And use a funct ion that takes us to the name attribute for the association and the roles del_first(C,L), del_first(A,K), del_first(B,Q),

and then extract the names themselves head(Y,Q), head(X,K), head(Z,L),

Finally the actual check is performed with ( Y = X - > nl, print('WARNING!'), nl, print('The two role names in the association with '),print(Z),print(' are identical.') ; nl, print('OK') ) .

If the name of the first role (X) is equal to the name of the second role (Y), then the message that the association with n ame (Z) has role names that are identical is printed out, else a message saying “OK” appears. To execute this check, a predicate called role_name(A,B,C) has been made, where A is the attributes of the first role, B is the attributes of the second role, an d C is the attributes of the association. ?- role_name(A,B,C).

This outputs all associations, and gives a warning if the role names are named alike. After starting this check, the user has to press semi -colon to step through the different associations.

7.2.3 Example of execution The following is an example of what execution of the check on Figure 11 looks like, how it is started and run, and how the results appear.


46

Klasse_A

Klasse_C

Klasse_DKlasse_B

1..n

+Rolle_A

+Rolle_B

1..n

Assosiasjon_AB

0..n

0..1

+Rolle_C0..n

+Rolle_B 0..1

Assosiasjon_BC

+Rolle_X+Rolle_X

Assosiasjon_BD

Figure 11 – The test2 model

?- consult('xcon.pl'). % xcon.pl compiled 0.00 sec, 0 bytes Yes ?- xcon('test2.xml'). 'XCon XMI consistency checker v0.2 BETA' No ?- role_name(A,B,C). 'OK' A = ['xmi.id'='G.2', name='Rolle_A', visibility=public, isSpecification=false, isNavigable=true, ordering=unordered, aggregation=none, targetScope=instance, ... =...] B = ['xmi.id'='G.3', name='Rolle_B', visibility=public, isSpecification=false, isNavigable=false, ordering=unordered, aggregation=none, targetScope=instance, ... =...] C = ['xmi.id'='G.1 ', name='Assosiasjon_AB{3BCADF96020F}', visibility=public, isSpecification=false, isRoot=false, isLeaf=false, isAbstract=false] ; 'OK' A = ['xmi.id'='G.5', name='Rolle_C', visibility=public, isSpecification=false, isNavigable=true, ordering=unordered, aggregation=none, targetScope=instance, ... =...] B = ['xmi.id'='G.6', name='Rolle_B', visibility=public, isSpecification=false, isNavigable=false, ordering=unordered, aggregation=none, targetScope=instance, ... =...] C = ['xmi.id'='G.4', name='Assosiasjon_B C{3C06F8920014}', visibility=public, isSpecification=false, isRoot=false, isLeaf=false, isAbstract=false] ; 'WARNING!' 'The two role names in the association with 'name='Assosiasjon_BD{3C06FAD000AD}'' are identical.' A = ['xmi.id'='G.8', name='Rolle_X', visibility=public, isSpecification=false, isNavigable=true, ordering=unordered, aggregation=none, targetScope=instance, ... =...] B = ['xmi.id'='G.9', name='Rolle_X', visibility=public, isSpecification=false, isNavigable=false, ordering=unordered, aggregat ion=none, targetScope=instance, ... =...] C = ['xmi.id'='G.7', name='Assosiasjon_BD{3C06FAD000AD}', visibility=public, isSpecification=false, isRoot=false, isLeaf=false, isAbstract=false] ; No


47

A fact that can seem peculiar is that the result of the check actually is printed out before the artefacts being checked. This is an effect caused by prolog’s way of doing things, and although it should be possible to switch them we did not feel that it was imperative. In Appendix G, another run of the check is sho wn for the Parking Garage model.


48

88.. EEvvaalluuaatt iioonn ooff rreessuull ttss It seems like the Genova consistency checker is not too useful when applied to models that were not meant for it. Most of the Genova consistency checker tool checks are aimed at Genera’s special s tereotypes and database add-ins. Although it would not be too difficult to expand this solution to include more inconsistency scenarios, it seems that it makes more sense to develop a more general tool, that is not reliant on Rational Rose and that could easily accommodate new rule suggestions. We implemented the rule based consistency checker in Prolog, a language we were not very familiar with. In spite of this we did manage to construct a functioning prototype. The way we extracted elements from the XML structure were based on knowledge of the UML XMI structure, and thus it cannot be said to be a general rule tool. This way of doing things would not work on a general XML document, as they could and would be structured in totally other ways than UML XM I. If the checker is to be general, a way to traverse the document without pre -knowledge of its structure has to be implemented. Since this project specifically revolves around UML models, and the implementation is connected to XMI, we concentrated on getting the checker working on that specific document type. Also it has to be admitted that this checker does not really improve on the Genova consistency checker in that new rules have to be implemented with programming. But it does show that it is possible to browse and check XMI models with prolog, and therefore it should be feasible to expand on this to implement a truly general checker. When looking on Figure 10, we can see that only parts (1) and (2) were implemented. Part (3) was not given priority to at this point.


49

99.. CCoonncclluussiioonn Firstly, implementing a full-fledged consistency checker in Prolog proved to be a more complicated task than first anticipated. Because of the complex nature of the Prolog language, even small sub tasks took a long time to make. Our opinion is that a consistency checker on a higher level could be implemented in two ways from here on. One way would be using a “regular” implementation language like Java or C++, but perhaps still try to use the Prolo g inference engine as some kind of imported package. The other could be to continue to refine the prolog solution as it is, in order to make general rules possible. In addition, one consideration in this is that if there is to be some sort of user interfac e with a Prolog consistency checker, one should probably opt to use another language to program the interface anyway. To write a complete consistency checker system in Prolog, the developers should at least have a certain level of experience with the lang uage. Further work into the specific topic of the consistency checker theoretically could be to identify the exact rules applicable to such a system. In the more practical sense it could be to implement a truly general consistency checking tool and also as introduced in chapters 6.1.2 and 6.1.3 one could improve the user interface considerably so as to ease the usage for ordinary UML developers. Also the cleanup process of the results should be implemented. As for the results from the Genova consistency checker, one conclusion is that this solution is not very useful when looked upon from other viewpoints than as a Genova user. For models not developed with the Genova process, it does not produce impressive results. As stated earlier in the paper, cons istency checking does not only apply to UML models, or models in particular. The concept of document consistency is of current interest, and a buzzword in that context is the semantic web. Consistency checking of general documents should be possible, since the format of XML goes a long way in structuring information, yet it does not limit the contents. A few steps into the future in this area would be to make a document consistency checker for XML documents of all types.


50

GGlloossssaarryy

DTD Document Type Definition. A kind of template belonging to an

XML document. Defines the XML document’s structure.

REI Rose Extensibility Interface. Utilises the Rose script language to give the opportunity to extend the Rational Rose application through scripts. The Genova consistency checker uses REI to access the UML model.

Rose script A scripting language resembling VB script.


51

RReeffeerreenncceess [Alur et. al., 2000] Alur, R., McMillan, K.L., Peled, D., Model -Checking of

Correctness Conditions for Concurrent Objects , Information and Computation vol 160 no 1 -2 pages 167-188 , 2000, "citeseer.nj.nec.com/article/alur96modelchecking.html"

[Abreu, 2001] Abreu, F.B., Adding preciseness to UML modeling and evaluation: using the Object Constraint Language (OCL), presenta tion for NTNU, Trondheim, October 2001

[Berners -Lee et. al., 2001]

Berners-Lee, T., Hendler, J. and Lassila, O., The Semantic Web, Scientific American, May 2001, “http://www.scientificamerican.com/2001/0501issue/0501berners-lee.html”

[Carlson, 2001] David Carlson: "Modeling XML applications with UML: Practical e -Business Applications" Addison-Wesley Pub Co

[Conradi, 1999] Reidar Conradi: ``Kommentar til UMLs nye Object Constraint Language (OCL)'', DND/Østlandet seminar om UML og komponentbasert utvikling, Geilo, 19-20 April 1999, 44 foiler. SU-report 11/99.

[Conradi et. al., 2000]

Reidar Conradi, Torgeir Dingsøyr, and Tor Stålhane, IDI, NTNU, ”Preliminary NTNU report of the OO Reading Techniques (OORT) exercise in course 7038 on Programming Quality and Process Improvement, spring 2000, v1.12”

[Cook et. al., 1999] Steve Cook, Anneke Kleppe, Richard Mitchell, Bernhard Rumpe, Jos Warmer, and Alan Wills, OMG Analysis & Design PTF UML 2.0 REQUEST FOR INFORMATION RESPONSE, December 1999, “The Amsterdam Manifesto on OCL”

[Harmon, 2000] Harmon, P., The Java Market: Part I, Component Development Strategies, August 2000

[Howse et. al.,] Stuart Kent, Computing Laboratory, University of Kent, Canterbury, UK, John Howse, School of Maths & Computing, University of Brighton, Lewes Road, Brighton, UK, “Mixing Visual and Textual Constraint Languages”


52

[Krishnan, 2000] Krishnan, P., Consistency checks for UML, Software Engineering Conference, 2000, APSEC 2000, Proceedings, Seventh Asia-Pacific , 2000, Page(s): 162 –169 “http://ieeexplore.ieee.org/iel5/7203/19407/00896695.pdf?isNumber=19407”

[Lindland et. al., 1994]

Lindland, O.I., Sindre, G. and Solvberg, A., Understanding quality in conceptual modeling, IEEE Software vol 11 issue 2 March 1994 pages 42 – 49.

[Nentwich et.al., A] Christian Nentwich, Wolfgang Emmerich and Anthony Finkelstein, Department of Computer Science, University College London, “Static Consistency Checking for Distributed Specifications”

[Nentwich et.al., B] Christian Nentwich, Licia Capra, Wolfgang Emmerich and Anthony Finkelstein, Department of Computer Science, University College London “xlinkit: A Consistency Checking and Smart Link Generation Service”

[Nentwich et.al., C] Christian Nentwich, Licia Capra, Wolfgang Emmerich and Anthony Finkelstein, Department of Computer Science, University College London “xlinkit: A Consistency Checking and Smart Link Generation Service”

[Nentwich et.al., D] Nentwich, C., Capra, L., Emmerich, W. & Finkelstein, A. "xlinkit: A Consistency Checking and Smart Link Generation Service"

[Nentwich et.al., E] Christian Nentwich, Wolfgang Emmerich and Anthony Finkelstein Department of Computer Science, University College London, “Better Living with xlinkit”

[Revheim, 2000] Torbjørn Revheim “Consistency Checking of Heterogeneous Distributed Documents”, University College London, mars 2000

[Travassos et. al., 2000]

Travassos, G. H., Shull, F., Carver, J., Basili, V. R., Conradi, R. “Object-Oriented Reading Techniques (OORTs) for Design Documents: general and technical aspects v1.4”

[Jess] Java Expert System Shell http://herzberg.ca.sandia.gov/jess/

[OMG] Object Management Group - XMI http://www.omg.org/technology/xml/index.htm


53

[Sun] JavaTM APIs for XML Processing (JAXP) http://java.sun.com/xml/jaxp.html

[SWI-Prolog] SWI-Prolog Home http://www.swi.psy.uva.nl/projects/SWI-Prolog/

[Unisys] Unisys Rose XML Tools http://www.unisys.com/news/releases/2000/jan/01196854.asp

[USE] USE - A UML-based Specification Environment http://www.db.informatik.uni-bremen.de/projects/USE/


54

AAppppeennddiicceess

Appendix A. Some consistency rules sorted by type. These are some rules collected from the Genova consistency checker, the xlinkit rule base, as well as some that have been thought out during this project. The categories are errors and warnings.

The rules marked with an * may not be relevant for general UML development, as they are specific to the Genera modelling process. Also, rules marked with xlinkit are taken from xlinkit’s rule base.

Errors:

Relation checks explanation remarks Cardinality must be set for all associations

This check looks through all associations and determines whether cardinality is set for both ends.

A class can not have several similar 'opposite class' role names

This check looks through all associations and determines whether any class has two or more identical role names at the ends of the opposite classes.

At most one AssociationEnd in an association may be an aggregation or composition.

In aggregations and compositions, only one of the association ends can be of the aggregation or composition type

xlinkit

If an Association has three or more AssociationEnds, then no AssociationEnd may be an aggregation or composition

Aggregations and compositions do not allow for ternary associations

xlinkit

Class checks No Attributes may have the same name within a Class

All attributes in a class are identified by name, and therefore the name must be unique


55

Dependencies <<Activates>> dependencies must have <<Dialog>> end nodes

This check looks through all dependencies with stereotype <<Activates>> and determines if they have any end nodes without stereotype <<Dialog>>.

*

<<Contains>> dependencies must go from <<Application>> to <<Dialog>>

This check looks through all dependencies with stereotype <<Activates>> and determines whether they go from a node with stereotype <<Activates>> to a node with stereotype <<Dialog>>.

*

Attribute checks A <<Domain>> attribute's corresponding Domain must exist

This check looks through all attributes with stereotype <<Domain>> and checks that the Domain in question actually exists.

Class stereotype checks <<Application>> classes must be root node in a dependency tree

This check looks through all dependency trees determines whether they have classes with stereotype <<Application>> as root nodes.

*

<<Boundary>> classes can not be persistent

This check looks through all classes with stereotype <<Boundary>> and checks that they are not persistent.

<<Control>> classes can not be persistent

This check looks through all classes with stereotype <<Boundary>> and checks that they are not persistent.

<<Dialog>> classes must have an <<Application>>

This check looks through all classes with stereotype

*


56

class as root node <<Dialog>> and checks that they have an <<Application>> class as root node.

<<Domain>> classes should only have the attribute 'definition'

This check looks through all classes with stereotype << Domain >> and checks that they don’t have more than the ‘definition’ attribute.

*

<<Entity>> classes should be persistent

This check looks through all classes with stereotype <<Boundary>> and checks that they are persistent.

Group class checks A Group definition must exist and the class in question must conform to it

If a class is a membe r of a group the group definition must exist in a class in the model.

<<Group>> class attributes must have certain stereotypes

This check looks through all classes with stereotype << Group >> and checks their attributes are either of stereotype <<Attribute>>, <<Association>> or <<Group>>.

*

A Group can not be a member of a group it contains

This check looks through all classes with stereotype << Group >> and checks they are not members of groups they contain.

Interface / virtual class A realizing class for an interface must realize all the methods in the interface.

When implementing an interface, the implementation class must contain all the methods of the interface

xlinkit

Class/sequence - diagram inconsistency

Checking that operation names in sequence diagrams exist in class diagrams.

For an operation to be valid in a sequence diagram, it must be a defined operation in the class that it is called from


57

Warnings: Association checks Association Ends (Roles) for one Association should not have the same name

This check looks through all associations and makes sure that they do not use the same role name on both ends of the association

Attribute checks Are there two attributes with the same name but different types?

This check looks through all attributes and determines whether there exists any with the same name but different types.

The type of the Parameters should be included in the Namespace of the Classifier

Attributes should have a type

xlinkit

Garbage finder Finds unused design artifacts

This category contains only one check, which looks for elements present in a package that does not exist in a diagram. This is of interest since these items might be garbage unconsciously left behind.

OO-warnings Parallel operations in subclasses

If subclasses of the same superclass have the same operation, perhaps the operation should be moved to the superclass.


58

Appendix B. Rules from xlinkit.com’s UML checker These rules has been included because this is the most thorough c ollection of rules defined in a rule language that we have found. First the rule description in prose is given, then the rule in xlinkit’s rule language. Associations

• The AssociationEnds must have a unique name within the Association forall a in $associ ations ( forall x in $a/ Foundation.Core.Association.connection/Foundation.Core.AssociationEnd ( forall y in $a/Foundation.Core.Association.connection/ Foundation.Core.AssociationEnd ( $x/Foundation.Core.ModelElement.name/ text()=$y/Foundation.Core.ModelElement.name/text() implies $x===$y ) ) )

• At most one AssociationEnd may be an aggregation or composition

forall a in $associations ( forall x in $a/Foundation.Core.Association.connection/Foundation.Core.AssociationEnd ( $x/Foundation.Core.AssociationEnd.aggregation/@xmi.value!='none' implies not exists y in $a/Foundation.Core.Association.connection/Foundation.Core.AssociationEnd ( $y/Foundation.Core.AssociationEnd.aggregation/@xmi.value!='none' and not $x===$y ) ) )

• If an Association has three or more As sociationEnds, then no AssociationEnd may be an aggregation or composition

forall a in $associations ( not exists x in $a/Foundation.Core.Association.connection/Foundation.Core.AssociationEnd ( exists y in $a/Foundation.Core.Association.connection/Foundati on.Core.AssociationEnd ( exists z in $a/Foundation.Core.Association.connection/Foundation.Core.AssociationEnd ( not $x===$y and not $y===$z and not $x===$z and $x/Foundation.Core.AssociationEnd.aggregation/@xmi.value!='none' or $y/Foundation.Core.AssociationEnd.aggregation/@xmi.value!='none' or $z/Foundation.Core.AssociationEnd.aggregation/@xmi.value!='none' ) ) ) )

• The connected Classifiers of the AssociationEnds should be included in the Namespace of the Association

forall a in $associations ( forall x in $a/Foundation.Core.Association.connection/ Foundation.Core.AssociationEnd/ Foundation.Core.AssociationEnd.type/*[1] ( exists y in $a/ancestor::Foundation.Core.Namespace.ownedElement/*[@xmi.id=$x/@xmi.idref] ( ) ) )


59

Association Class

• The names of the AssociationEnds and the StructuralFeatures do not overlap forall a in $associationclasses ( forall s in $a/Foundation.Core.StructuralFeature/* ( not exists c in $a/Foundation.Core.Association.connection/Foundation.Core.AssociationEnd ( $s/Foundation.Core.ModelElement.name/text()=$c/Foundation.Core.ModelElement.name/text() ) ) )

• An AssociationClass cannot be defined between itself and something else. forall a in $associationclasses ( not exists c in $a/Foundation.Core.Association.connection/Foundation.Cor e.AssociationEnd ( $a/@xmi.id=$c/Foundation.Core.AssociationEnd.type/*[1]/@xmi.idref ) ) Association End

• The Classifier of an AssociationEnd cannot be an Interface or a DataType if the association is navigable from that end

forall e in $associationend s ( exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.DataType () or exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.Interface () implies not exists x in $e/../Foundation.Core.AssociationEnd/ Foundation.Core.AssociationE nd.isNavigable[@xmi.value='true'] () )

• An Instance may not belong by composition to more than one composite Instance

forall e in $associationends ( exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.DataType () or exists x in $e/Foundatio n.Core.AssociationEnd.type/Foundation.Core.Interface () implies not exists x in $e/../Foundation.Core.AssociationEnd/ Foundation.Core.AssociationEnd.isNavigable[@xmi.value='true'] () ) Behavioral Feature

• All parameters should have a unique name forall e in $associationends ( exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.DataType () or exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.Interface () implies not exists x in $e/../Foundation.Core.AssociationEnd/ Foundati on.Core.AssociationEnd.isNavigable[@xmi.value='true'] () )


60

• The type of the Parameters should be included in the Namespace of the Classifier

forall e in $associationends ( exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.DataType () or exists x in $e/Foundation.Core.AssociationEnd.type/Foundation.Core.Interface () implies not exists x in $e/../Foundation.Core.AssociationEnd/ Foundation.Core.AssociationEnd.isNavigable[@xmi.value='true'] () ) Class

• If a Class is concrete, all the Operations of the Class should have a realizing method in the full descriptor

forall c in $classes ( $c/Foundation.Core.GeneralizableElement.isAbstract/ @xmi.value='false' implies forall o in $c/Foundation.Core.Classifier.feature/ Foundation.Core.Operation ( exists m in $c/Foundation.Core.Classifier.feature/ Foundation.Core.Method ( $o/@xmi.id=$m/Foundation.Core.Method.specification/ Foundation.Core.Operation/@xmi.idref ) ) ) Classifier

• No Attributes may have the same name within a Classifier forall c in $classifiers ( forall x in $c/Foundation.Core.Classifier.feature/Foundation.Core.Attribute ( forall y in $c/Foundation.Core.Classifier.feature/Foundation.Core.Attribute ( $x/Foundation.Core.ModelElement.name/text()=$y/Foundation.Core.ModelElement.name/text() implies $x===$y ) ) )

• No opposite AssociationEnds may have the same name within a Classifier forall c in $classifiers ( forall x in id($c/Foundation.Core.Classifier.associationEnd/ Foundation.Core.AssociationEnd/ @xmi.idref)/../ Foundation.Core.A ssociationEnd[Foundation.Core.AssociationEnd.type/*[1]/ @xmi.idref!=$c/@xmi.id] ( forall y in id($c/ Foundation.Core.Classifier.associationEnd/Foundation.Core.AssociationEnd/ @xmi.idref)/../Foundation.Core.AssociationEnd[Foundation.Core.AssociationEnd.type /*[1]/ @xmi.idref!=$c/@xmi.id] ( not $x===$y implies $x/Foundation.Core.ModelElement.name/text()!=$y/Foundation.Core.ModelElement.name/text() ) ) )


61

• The name of an Attribute may not be the same as the name of an opposite AssociationEnd or a ModelElement contained in the Classifier

forall c in $classifiers ( forall a in $c/Foundation.Core.Classifier.feature/Foundation.Core.Attribute ( forall x in id($c/Foundation.Core.Classifier.associationEnd/ Foundation.Core.AssociationEnd/ @xmi.idref)/../ Foundati on.Core.AssociationEnd[Foundation.Core.AssociationEnd.type/*[1]/ @xmi.idref!=$c/@xmi.id] ( $a/Foundation.Core.ModelElement.name/ text()!=$x/Foundation.Core.ModelElement.name/text() ) and forall y in $c/Foundation.Core.Namespace.ownedElement/* ( $a/Foundation.Core.ModelElement.name/text()!=$y/Foundation.Core.ModelElement.name/text() ) ) )

• The name of an opposite AssociationEnd may not be the same as the name of an Attribute or ModelElement contained in the Classifier

forall c in $classifiers ( forall x in id($c/ Foundation.Core.Classifier.associationEnd/Foundation.Core.AssociationEnd/ @xmi.idref)/../Foundation.Core.AssociationEnd[Foundation.Core.AssociationEnd.type/*[1]/ @xmi.idref!=$c/@xmi.id] ( forall a in $c/Foundation.Core.Classifier.feature/Foundation. Core.Attribute ( $a/Foundation.Core.ModelElement.name/text()!=$x/Foundation.Core.ModelElement.name/text() ) and forall y in $c/Foundation.Core.Namespace.ownedElement/* ( $y/Foundation.Core.ModelElement.name/text()!=$x/ Foundation.Core.ModelElement.name/text() ) ) )

• For each Operation in a specification realized by a Classifier, the Classifier must have a matching Operation.

forall c in $classifiers ( forall x in id($c/Foundation.Core.Classifier.specification/*[1]/@xmi.idref)/ Foundation.Core.Classifier.fe ature/Foundation.Core.Operation ( exists y in $c/Foundation.Core.Classifier.feature/Foundation.Core.Operation ( $x/Foundation.Core.ModelElement.name/text()=$y/Foundation.Core.ModelElement.name/text() and $x/Foundation.Core.BehavioralFeature.parameter/ Foundation.Core.Parameter/ Foundation.Core.ModelElement.name/text()=$y/ Foundation.Core.BehavioralFeature.parameter/ Foundation.Core.Parameter/Foundation.Core.ModelElement.name/text() ) ) ) Component

• A Component may only contain other Components forall c in $components ( forall o in $c/Foundation.Core.Namespace.ownedElement/* ( name($o)='Foundation.Auxiliary_Elements.Component' ) )


62

Constraint

• A Constraint cannot be applied to itself forall c in $constraints ( forall x in $c/Foundation.Core.Constrain t.constrainedElement/* ( $c/@xmi.id!=$x/@xmi.idref ) ) Datatype

• A DataType can only contain Operations, which all must be queries forall d in $datatypes ( forall x in $d/Foundation.Core.Classifier.feature/* ( name($x)='Foundation.Core.Operation' and $x/Foundation.Core.BehavioralFeature.isQuery/@xmi.value='true' ) )

• A DataType cannot contain any other model elements forall d in $datatypes ( not exists x in $d/Foundation.Core.Namespace.ownedElement/* () ) Generalizable element

• A root cannot have any G eneralizations forall g in //Foundation.Core.GeneralizableElement.isRoot[@xmi.value='true']/ .. ( not exists x in $g/Foundation.Core.GeneralizableElement.generalization () )

• No GeneralizableElement can have a parent Generalization to an element which is a leaf

forall g in $generalizableelements ( not exists p in id(id($g/Foundation.Core.GeneralizableElement.generalization/ Foundation.Core.Generalization/ @xmi.idref)/ Foundation.Core.Generalization.supertype/*[1]/@xmi.idref)/ Foundation.Core.GeneralizableE lement.isLeaf[@xmi.value='true'] ( ) )

• The parent must be included in the namespace of the GeneralizableElement forall g in $generalizableelements ( forall p in id($g/Foundation.Core.GeneralizableElement.generalization/ Foundation.Core.Generalization/ @x mi.idref)/ Foundation.Core.Generalization.supertype/*[1] ( exists x in $g/ancestor::Foundation.Core.Namespace.ownedElement/* ( $p/@xmi.idref=$x/@xmi.id ) ) ) Interface

• An Interface can only contain Operations. forall i in $interfaces ( forall f in $i/Foundation.Core.Classifier.feature/* ( name($f)='Foundation.Core.Operation' or name($f)='Behavioral_Elements.Common_Behavior.Reception' ) )


63

• An Interface cannot contain any ModelElements forall i in $interfaces ( not exists x in $i/Foundation.Core.Namespa ce.ownedElement/* () )

• All Features defined in an Interface are public forall i in $interfaces ( forall f in $i/Foundation.Core.Classifier.feature/* ( $f/Foundation.Core.ModelElement.visibility/@xmi.value='public' ) ) Method

• If the realized Operation is a query, then so is the method. forall m in $methods ( id($m/ Foundation.Core.Method.specification/Foundation.Core.Operation/@xmi.idref)/ Foundation.Core.BehavioralFeature.isQuery/@xmi.value='true' implies $m/Foundation.Core.BehavioralFeature.isQuery/@xmi.value='true' )

• The signature of the Method should be the same as the signature of the realized Operation

forall m in $methods ( $m/Foundation.Core.BehavioralFeature.parameter/Foundation.Core.Parameter/ Foundation.Core.Parameter.type/*[1]/@xmi.idref=id($m/Foundation.Core.Method.specification/ Foundation.Core.Operation/@xmi.idref)/Foundation.Core.BehavioralFeature.parameter/ Foundation.Core.Parameter/Foundation.Core.Parameter.type/*[1]/@xmi.idref )

• The visibility of the Method should be the same as for the realized Operation forall m in $methods ( $m/Foundation.Core.ModelElement.visibility/ @xmi.value= id($m/Foundation.Core.Method.specification/Foundation.Core.Operation/ @xmi.idref)/Foundation.Core.ModelElement.visibility/@xmi.value ) Namespace

• If a contained element, which is not an Association or Generalization has a name, then the name must be unique in the Namespace.

forall n in $namespaces ( forall x in $n/Foundation.Core.Namespace.ownedElement/*[(not (name(.)='Foundation.Core.Association')) and (not (name(.)='Foundation.Core.Generalization'))] ( forall y in $n/Foundation.Core.Namespace.ownedElement/*[(not (name(.)='Foundation.Core.Association')) and (not (name(.)='Foundation.Core.Generalization'))] ( $x/Foundation.Core.ModelElement.name/text()=$y/ Foundation.Core.ModelElement.name/text() implies $x===$y ) ) )


64

• All Associations must have a unique combination of name and associated Classifiers in the Namespace

forall n in $namespaces ( forall x in $n/Foundation.Core.Namespace.ownedElement/ Foundation.Core.Association ( forall y in $n/ Foundation.Core.Namespace.ownedElement/Foundation.Core.Association ( $x/Foundation.Core.ModelElement.name/text()=$y/Foundation.Core.ModelElement.name/text() and $x/Foundation.Core.Association.connection/ Foundation.Core.AssociationEnd/ Foundation.Core.AssociationEnd.type/*[1]/ @xmi.idref=$y/Foundation.Core.Association.connection/ Foundation.Core.AssociationEnd/Foundation.Core.AssociationEnd.type/*[1]/ @xmi.idref implies $x===$y ) ) ) Structural feature

• The connected type should be included in the owner's Namespace forall s in $structuralfeatures ( exists x in $s/ancestor::Foundation.Core.Namespace.ownedElement/*[@xmi.id=$s/ Foundation.Core.StructuralFeature.type/*[1]/@xmi.idref] ( ) ) Types

• A Type may not have any methods forall t in $types ( not exists x in $t/Foundation.Core.Classifier.feature/Foundation.Core.Method () )

• The parent of a type must be a type forall t in $types ( forall p in id(id($t/Foundation.Core.GeneralizableElement.generalization/ Founda tion.Core.Generalization/ @xmi.idref)/ Foundation.Core.Generalization.supertype/*[1]/@xmi.idref) ( id($p/Foundation.Core.ModelElement.stereotype/Foundation.Extension_Mechanisms.Stereotype/ @xmi.idref)/Foundation.Core.ModelElement.name/text()='Type' ) )


65

Appendix C. Example of xlinkit

A small UML model was made with deliberate faults, then exported to XMI and submitted to the xlinkit on-line UML consistency checker. The model tested here was this:

Class A

Operation 1()

Class B

Operation 2()

+Role X

0..*

+Role X

0..*

0..*

0..*

One of the inconsistencies here is that the associat ion roles (or associationends as it is called in the xlinkit rules) have the same name. The result was represented in two ways, in XML and an HTML translation. The part that represents the inconsistency mentioned above is highlighted in the XML version. <!DOCTYPE HTML SYSTEM "http://www.xlinkit.com/DTD/LinkBase.dtd"> <xlinkit:LinkBase date="Wed Oct 31 14:09:12 GMT+00:00 2001" docset="http://www.idi.ntnu.no/~borretze/testtt.xml" ruleset="http://www.xlinkit.com/UML/RuleSet.xml?noprocess=true" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xlinkit="http://www.xlinkit.com"> <xlinkit:ConsistencyLink ruleid="http://www.xlinkit.com/UML/association.xml?noprocess=true#/ consistencyruleset/consistencyrule[1]"> <xlinkit:State>inconsi stent</xlinkit:State> <xlinkit:Locator xlink:href="http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Association[1]" xlink:label xlink:title></xlinkit:Locator> <xlinkit:Locator xlink:href="http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Association[1]/Fo undation.Core.Association.connection[1]/ Foundation.Core.AssociationEnd[1]" xlink:label xlink:title></xlinkit:Locator> <xlinkit:Locator xlink:href="http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Managemen t.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Association[1]/Foundation.Core.Association.connection[1]/ Foundation.Core.AssociationEnd[2]" xlink:label xlink:title></xlinkit:Locator> </xlinkit:ConsistencyLink> <xlinkit:ConsistencyLink ruleid="http://www.xlinkit.com/UML/class.xml?noprocess=true#/ consistencyruleset/consistencyrule[1]"> <xlinkit:State>inconsistent</xlinkit:State> <xlinkit:Locator xlink:href="http://www.idi.ntnu.no/~borre tze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[1]" xlink:label xlink:title></xlinkit:Locator> <xlinkit:Locator xlink:href="http://www.idi.ntnu.no/ ~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[1]/Foundation.Core.Classifier.feature[1]/Foundation.Core.Operation[1]"

66

xlink:label xlink:tit le></xlinkit:Locator> </xlinkit:ConsistencyLink> <xlinkit:ConsistencyLink ruleid="http://www.xlinkit.com/UML/class.xml?noprocess=true#/ consistencyruleset/consistencyrule[1]"> <xlinkit:State>inconsistent</xlinkit:State> <xlink it:Locator xlink:href="http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[2]" xlink:label xlink:title></xlinkit:Locator> <xlinkit:Locator xlink:href="http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[2]/Foundation.Core.Classifier.feature[1]/ Foundation.Core.Operation[1]" xlink:label xlink:title></xlinkit:Locator> </xlinkit:ConsistencyLink> </xlinkit:LinkBase>

LinkBase Document Set: http://www.idi.ntnu.no/~borretze/testtt.xml

Rule Set: http://www.xlinkit.com/UML/RuleSet.xml?noprocess=true

Last Check: Wed Oct 31 14:11:14 GMT+00:00 2001

Consist ency Link State: inconsistent

Rule: http://www.xlinkit.com/UML/association.xml?noprocess=true

Resource:

URL: http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/ Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Association[1]

Resource:

URL: http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/


67

URL:

http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/ Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Association[1]/ Foundation.Core.Association.connection[1]/ Foundation.Core.AssociationEnd[2]

Consistency Link State: inconsistent

Rule: http://www.xlinkit.com/UML/class.xml?noprocess=true

Resource:

URL:

http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/ Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[1]

Resource:

URL:

http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/ Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[1]/Foundation.Core.Classifier.feature[1]/ Foundation.Core.Operation[1]

Consistency Link State: inconsistent

Rule: http://www.xlinkit.com/UML/class.xml?noprocess=true

Resource:

URL:

http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/ Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[2]

Resource:

URL:

http://www.idi.ntnu.no/~borretze/testtt.xml#/XMI/XMI.content[1]/ Model_Management.Model[1]/ Foundation.Core.Namespace.ownedElement[1]/ Foundation.Core.Class[2]/Foundation.Core.Classifier.feature[1]/


68

Foundation.Core.Class[2]/Foundation.Core.Classifier.feature[1]/ Foundation.Core.Operation[1]

Generated by xlinkit.com


69

Appendix D. Results from the Genova consistency checker The following tables show the output of the Genova consistency checker when applied to some UML models. The Loan Arranger model from [Conradi et. al., 2000] Element Name Element Type Element Information Parent Package Error Type

LoanArranger Class Use Case View Does not exist in any diagram

Association Between Loan Arranger and Receive Reports Use Case View

Does not exist in any diagram

lends Association Between Lender and Loan Logical View

The association's owner class does not contain a primary key

Association Between Bundle and Loan Arranger Logical View

There is no cardinality at the class Loan Arranger

Association Between Bundle and Loan Arranger Logical View

There is no card inality at the class Bundle


There is no cardinality at the class Receive Reports


There is no cardinality at the class Loan Arranger

Loan Class Logical View Has multiple nameless 'opposite class' roles

Bundle Class Logical View Has multiple nameless 'opposite class' roles

Loan Arranger Class Logical View Has multiple nameless 'opposite class' roles

id Attribute Belongs to class Lender Logical View

Has same name, but different type than attribute in Borrower

Lender Class Is persistent Logical View Has no primary key attribute Loan Class Is persistent Logical View Has no primary key attribute Borrower Class Is persistent Logical View Has no primary key attribute Fixed_Rate Loan Class Is persistent Logical View Has no primary key attribute Variable_Rate Loan Class Is persistent Logical View Has no primary key attribute Bundle Class Is persistent Logical View Has no primary key attribute The Parking Garage model from [Conradi et. al., 2000] Element Name Element Type Element Information Parent Package Error Type

Ticket dispenser Class Use Case View Does not exist in any diagram

gate Class Use Case View Does not exist in any diagram

Control Unit Class Use Case View Does not exist in any diagram

Driver Class Use Case View Does not exist in any diagram

Parking_Garage Class Logical View Has multiple nameless 'opposite class' roles


70

An excerpt (about 5%) of the result when running the Lisa5 UML model through the consistency checker:

Element Name Element Type

Element Information Parent Package Error Type

Ruteoppslagshjelper Class GUIklasser Does not exist in any diagram tGroup Class psLost+Found Does not exist in any diagram ssGroup Class psLost+Found Does not exist in any diagram RSFS_SvarForsinkelseStrekning Class Ruteforsinkelse Does not exist in any diagram RFFT_ForespoerselForsinkelseTog Class Ruteforsinkelse Does not exist in any diagram RSFT_SvarForsinkelseTog Class Ruteforsinkelse Does not exist in any diagram I001_ForespoerselRuteopplysning Class Reiserute Does not exist in any diagram I101_SvarRuteopplysning Class Reiserute Does not exist in any diagram

Association

Between BookingProfil and Tilordning ymDomene Does not exist in any diagram

Association

Between Billett and Billettrapport bsDomene Does not exist in any diagram

Association Between Billett and Billettside bsDomene Does not exist in any diagram

Association

Between Billettside and Billettlinje bsDomene Does not exist in any diagram

Finne ordre Use Case Ordre Does not exist in any diagram Fullføre ordre Use Case lost+found Does not exist in any diagram Opprette ordre Use Case lost+found Does not exist in any diagr am Finn alternative avganger Use Case Salg Does not exist in any diagram

Association

Between Formular and Billettrapport ssDomene


Association

Between Formular and Billettrapport bsDomene


RPrisPRelasjon Association

Between RelasjonsPris and PrisetRelasjon psDomene


OppgjorOppgjtrans Association

Between Oppgjor and Oppgjorstransaksjon osDomene


Association

Between Bestilling and Merknad ssDomene

There is no cardinality at the class Merknad

Association

Between Bestilling and Merknad ssDomene

There is no cardinal ity at the class Bestilling

Association Between ssDomene There is no cardinality at the


71

Merknad and BestiltTjeneste

class BestiltTjeneste

BestiltTjeneste Class ssDomene Has multiple nameless 'opposite class' roles

Billettlinje Class ssDomene Has multiple nameless 'opposite class' roles

Postnummer Class ksDomene Has multiple nameless 'opposite class' roles

KurvProfil Class ymDomene Has multiple nameless 'opposite class' roles

tidspunkt Attribute

Belongs to class Ruteoppslagshjelper GUIklasser

Has same name, but different type than attribute in Billetthode

opprettet Attribute

Belongs to class EBestStatus ssEnumerations

Has same name, but different type than attribute in Bestilling

avgang Attribute

Belongs to class ETidspunkt ssEnumerations

Has same name, but different type than attribute in SokRelasjon

avgang Attribute

Belongs to class ETidspunkt ssEnumerations

Has same name, but different type than attribute in RuteForesporsel

kjonn Attribute

Belongs to class BestiltDelstrekning ssDomene

Has same name, but different type than attribute in Kunde

kjonn Attribute


Has same name, but different type than attribute in PlassArt

kjonn Attribute


Has same name, but different type than attribute in Kupe

kjonn Attribute


Has same name, but different type than attribute in Kupe

rullenr Attribute Belongs to class Verdibilag osDomene

Has same name, but different type than attribute in Vekslepenger

rullenr Attribute

Belongs to class Vekslepenger osDomene

Has same name, but different type than attribute in Forsikring

rullenr Attribute

Belongs to class Vekslepenger osDomene

Has same name, but different type than attribute in L isaBillett

belop Attribute Belongs to class Forsikring osDomene

Has same name, but different type than attribute in LisaBillett

belop Attribute Belongs to class LisaBillett osDomene

Has same name, but different type than attribute in BlankobillettInt

AnnenTjeneste Dialog

Logical View/Salg/ssDialoger/SalgsDialog

does not have an application as a root node in the dialog structure

AvansertePlasskriterier Dialog

Logical View/Salg/ssDial

does not have an application as a root node in the di alog


72

oger/SalgsDialog structure

OverstyrRefusjon Dialog


does not have an application as a root node in the dialog structure

VognerITog Dialog


does not have an application as a root node i n the dialog structure

SalgsstedPrSelger Class Is of stereotype <<entity>> osDomene Should be persistent

Verdibilag Class Is of stereotype <<entity>> osDomene Should be persistent

Vekslepenger Class Is of stereotype <<entity>> osDomene Should be persistent

Forsikring Class Is of stereotype <<entity>> osDomene Should be persistent

Dependency

from LisaLuke to AnnenTjeneste


is not <<Contains>> or <<Activates>>

Dependency

from Prisadministrasjon to TilleggDia

Logical View/Prisadministrasjon/psDialoger


Dependency

from OppgjoersSystem to AapneKasse

Logical View/Oppgjorssystem/osDialoger


BookingGroup Attribute ymDomene Refers to a <<Group>> class that does not exist

SalgsTallGroup Attribute ymDomene Refers to a <<Group>> class that does not exist

fraAntallDagerFoerReise Attribute

Belongs to class rGroup psLost+Found

Is not of either <<Attribute>>, <<Association>> or <<Group>> stereotype

Formular Class Is persistent ssDomene Has no primary key attribute Postnummer Class Is persistent ksDomene Has no primary key attribute


73

Appendix E. The prolog implementation The following is the Prolog code made for this project. /* XCon XML consis tency checker Torger Kielland & Jon Arvid Børretzen Copyright (C) 2001 Norwegian University of Science and Technology. All rights reserved. */ xcon(Term) : - retractall(element(_,_,_)), print('XCon XMI consistency checker v0.2 BETA'), nl, load_xml _file(Term,[DrWho|_]), assert(DrWho), element_finder. element_finder : - element(_,_,[_|[element(_,_,[element(_,_,[element(_,_,C)|_])|_])|_]]), count(C,N), ( N > 0 - > member(O,C), assert(O) ), N is N - 1, element_finder2(N,C). element_finder2(N,C) : - ( N > 0 - > N is N - 1, member(O,C), assert(O), element_finder2(N,C) ). element_finder_tag : - element('XMI',_,[_|[element(_,_,[_|[A|B]])|_]]), assert(A), count(B,N), ( N > 0 - > member(O,B), assert(O) ), N is N - 1, element_finder2(N,B). elemen t_finder_tag2(N,B) : - ( N > 0 - > N is N - 1, member(O,B), assert(O), element_finder_tag2(N,B) ). /* Test tools */ compare_name(Term1, Term2) : - ( Term1 == Term2 - > print('They are equal.') ; print('They are not equal.') ). bl(Term,Attr) : - element(Term1,Term2,_), ( Term1 == Term - > Attr=Term2 ). /* Individual checks */ version_check(X) : - bl('XMI', K), ( member(X, K) - > print('Correct'), print(X) ; print('No') ). /* The check below determines whether an associations two role names are identical */


74

role_name(A,B,C) : - element('UML:Association',C,[element(_,_,[element(_,A,_)|[element(_,B,_)|_]])|_]), del_first(C,L), del_first(A,K), del_first(B,Q), head(Y,Q), head(X,K), head(Z,L), ( Y == X - > nl, print('WARNING!'), nl, print('The two role names in the association with '),print(Z),print(' are identical.') ; nl, print('OK') ). /* Procedures */ add(X,L,[X|L]). del_first(A,C) : - head(B,A), delete(A,B,C). head(H,[H|_]). count([],0). count([_|R], N) : - count(R,N1), N is N1 + 1.


75

Appendix F. User Guide to Genova consistency checker

User guide – Consistency Checker v1.0 Start -up You start the program by opening ‘Tools’ ->’Genova DB’->’Check Model Consistency’. You will then get a window that looks like this:

Explanation of functionality Scope The ‘Scope’ option buttons lets you choose which parts of the Rose model to run the checks on. There are four different options available:

• ‘Complete model’ Uses everything contained within the ‘Logical View’ package.

• ‘Package with subs’

Uses the package chosen in the Rose modelmenu (upper left side) with sub. packages.

• ‘Current package’

Uses the package chosen in the Rose model menu without sub packages.

• ‘Current classes’ Uses the class or classes chosen in modelmenu or the current diagram.


76

Check categories The consistency checks are grouped into seven categories. The first category ‘Garbage finder’ is special as it contains only one check. This check is the only one that has a scope constraint and was therefore kep t alone. If you choose this category you’ll notice that only ‘Complete model’ scope option is clickable. The other six categories contain two to six checks. These can be set individually by pressing the ‘edit’ buttons next to each category. You will then get a new window with a checkbox for each check in that category. Every check (except 3.3) in every category is set to true by default at start -up. The checkbox ‘Toggle All/None’ gives you the opportunity to mark all or none of the check category checkboxes. Predefined checksets This feature makes it possible to store the choices you have made concerning categories and individual checks. By writing a new name in the text field of the combobox and pressing the ‘Add’ button, the current settings will be a dded to list of predefined checksets. Deleting a checkset can be achieved by marking the checkset in question and then pressing the ‘Delete’ button. If you want these changes to be permanent you must press the ‘Save’ button. The predefined checksets contain, not only which categories to use, but also which individual checks to use in each of the categories. Output The results generated by the consistency checker can be presented in either Rose’s viewport or Microsoft Excel. This choice is made by usin g the ‘Output’ droplist. The Rose viewport is a text window where the results are written line by line. The results generated in Microsoft Excel can be sorted by element name, element type, parent package and error type. This way you can chose which order you want to sort out the inconsistencies in your model.

Explanation of categories and individual checks Garbage finder This category contains only one check, which looks for elements present in a package that does not exist in a diagram. This is of interest since these items might be garbage unconsciously left behind.


77

Relation checks 1. ” An association's owner class must contain a primary key”: This check looks through all associations and finds out if the owner class does not have a primary key or if the association does not have foreign key. 2. “Cardinality must be set for all associations”: This check looks through all associations and determines whether cardinality is set for both ends. 3. “A class can not have several similar 'opposite class ' role names”: This check looks through all associations and determines whether any class has two or more identical role names at the ends of the opposite classes. 4. “<<Activates>> dependencies must have <<Dialog>> end nodes”: This check looks through al l dependencies with stereotype <<Activates>> and determines if they have any end nodes without stereotype <<Dialog>>. 5. “<<Contains>> dependencies must go from <<Application>> to <<Dialog>>”: This check looks through all dependencies with stereotype <<Ac tivates>> and determines whether they go from a node with stereotype <<Activates>> to a node with stereotype <<Dialog>>. Attribute checks 1. “All primary key attributes must be persistent”: This check looks through all primary key attributes and determ ines whether any are not persistent. 2. “Are there two attributes with the same name but different types?”: This check looks through all attributes and determines whether there exists any with the same name but different types. 3. “A <<Domain>> attribute 's corresponding Domain must exist”: This check looks through all attributes with stereotype <<Domain>> and checks that the Domain in question actually exists. Class stereotype checks 1. "<<Application>> classes must be root node in a dependency tree": This check looks through all dependency trees determines whether they have classes with stereotype <<Application>> as root nodes. 2. "<<Boundary>> classes can not be persistent": This check looks through all classes with stereotype <<Boundary>> and checks that they are not persistent. 3. "<<Control>> classes can not be persistent":


78

This check looks through all classes with stereotype <<Boundary>> and checks that they are not persistent. 4. "<<Dialog>> classes must have an <<Application>> class as root no de": This check looks through all classes with stereotype <<Dialog>> and checks that they have an <<Application>> class as root node. 5. "<<Domain>> classes should only have the attribute 'definition'": This check looks through all classes with stereotype << Domain >> and checks that they don’t have more the ‘definition’ attribute. 6. "<<Entity>> classes should be persistent": This check looks through all classes with stereotype <<Boundary>> and checks that they are persistent. Enumeration class checks 1. “<<Enumeration>> attribute's corresponding Enumeration must exist": This check looks through all attributes of type << Enumeration >> and checks that the Enumerators in question exist in the model. 2. "<<Enumeration>> class attributes must have a Name and unique InitValue": This check looks through all classes with stereotype << Enumeration >> and checks that they have the attributes Name and InitValue. InitValue must be unique. 3. "<<Enumeration>> classes must have GenovaEnumerator as superclass": This check looks through all classes with stereotype << Enumeration >> and checks that they have the GenovaEnumerator class as superclass. Group class checks 1. "A Group definition must exist and the class in question must conform to it": If a class is a member of a group the group definition must exist in a class in the model. 2. "<<Group>> class attributes must have certain stereotypes": This check looks through all classes with stereotype << Group >> and checks their attributes are either of stereotype <<Attribute>>, <<Association>> or <<Group>>. 3. "A Group can not be a member of a group it contains": This check looks through all classes with stereotype << Group >> and checks they are not members of groups they contain. Persistent class checks 1. "Persistent classes must have a primary key": This check looks through all persistent classes and checks that they have or inherit a primary key.


79

2. "Persistent classes must have at least one persistent attribute": This check looks through all persistent cl asses and checks that they have or inherit a persistent attribute.


80

Appendix G. Results from the prolog consistency checker In [Conradi et. al., 2000] the following model called Parking Garage is used as an example.

Monthly_ticket

purchase_date : Date

IsValid()Create()

Non-reserved_ticket

Time_paid : StringAmount_Paid : Float

IsValid()Create()DriverLeft()

Card_Readers

location : String

InsertTicket()

Ticket

Number : Integer

IsValid()DriverLeft()Destroy()

Gate

Loacation : String

Open_Gate()Close_Gate()

Parking_Garage

k : Integerr : Integero : Integer

ValidateTicket()TicketRequested()TicketTaken()NewMonthlyTicket()PayTicket()CheckAvailSpots()

0..10..n 0..10..n 1 n1 n

1

1..n

1

1..n

When running the check implemented on this model the results were as follows: ?- role_name(A,B,C). 'WARNING!' 'The two role names in the association with 'name='{Parking_Garage - Card_Readers}{37AEFD9200DD}'' are identical.' A = ['xmi.id'='G.42', name='', visibility=public, isSpecificati on=false, isNavigable=false, ordering=unordered, aggregation=none, targetScope=instance, ... =...] B = ['xmi.id'='G.43', name='', visibility=public, isSpecification=false, isNavigable=false, ordering=unordered, aggregation=none, targetScope=instance, ... = ...] C = ['xmi.id'='G.41', name='{Parking_Garage - Card_Readers}{37AEFD9200DD}', visibility=public, isSpecification=false, isRoot=false, isLeaf=false, isAbstract=false] ; 'WARNING!' 'The two role names in the association with 'name='{Parking_Garage - Ticket}{ 37AEFE0300E9}'' are identical.' A = ['xmi.id'='G.45', name='', visibility=public, isSpecification=false, isNavigable=false, ordering=unordered, aggregation=aggregate, targetScope=instance, ... =...] B = ['xmi.id'='G.46', name='', visibility=public, isSpec ification=false, isNavigable=false, ordering=unordered, aggregation=none, targetScope=instance, ... =...] C = ['xmi.id'='G.44', name='{Parking_Garage - Ticket}{37AEFE0300E9}',


81

visibility=public, isSpecification=false, isRoot=false, isLeaf=false, isAbstract=f alse] ; 'WARNING!' 'The two role names in the association with 'name='{Gate - Parking_Garage}{3815D10101BF}'' are identical.' A = ['xmi.id'='G.48', name='', visibility=public, isSpecification=false, isNavigable=true, ordering=unordered, aggregation=none, t argetScope=instance, ... =...] B = ['xmi.id'='G.49', name='', visibility=public, isSpecification=false, isNavigable=true, ordering=unordered, aggregation=aggregate, targetScope=instance, ... =...] C = ['xmi.id'='G.47', name='{Gate - Parking_Garage}{3815D1010 1BF}', visibility=public, isSpecification=false, isRoot=false, isLeaf=false, isAbstract=false] ; No

All the role names triggered warnings, as they all were the same. In fact all of them were nameless!