Research on Consistency Checking of Different Aspects Models of the Information System

VILNIUS GEDIMINAS TECHNICAL UNIVERSITY

Rūta DUBAUSKAITĖ

RESEARCH ON CONSISTENCY CHECKING OF DIFFERENT ASPECTS MODELS OF THE INFORMATION SYSTEM

DOCTORAL DISSERTATION

TECHNOLOGICAL SCIENCES, INFORMATICS ENGINEERING (07T)

Vilnius 2012 Doctoral dissertation was prepared at Vilnius Gediminas Technical University in 2008–2012.

Scientific Supervisor Prof Dr Olegas VASILECAS (Vilnius Gediminas Technical University, Technological Sciences, Informatics Engineering – 07T).

Consultant – įrašoma, jeigu reikia Assoc Prof Dr Name SURNAME (Vilnius Gediminas Technical University, Technolo- gical Sciences, Electrical and Electronic Engineering – 01T).

VGTU leidyklos TECHNIKA 2022-M mokslo literatūros knyga http://leidykla.vgtu.lt

ISBN 978-609-457-298-2

VILNIAUS GEDIMINO TECHNIKOS UNIVERSITETAS

Rūta DUBAUSKAITĖ

INFORMACINĖS SISTEMOS SKIRTINGŲ ASPEKTŲ MODELIŲ DARNOS TIKRINIMO TYRIMAS

DAKTARO DISERTACIJA

TECHNOLOGIJOS MOKSLAI, INFORMATIKOS INŽINERIJA (07T)

Vilnius 2012 Disertacija rengta 2008–2012 metais Vilniaus Gedimino technikos universi- tete. (Disertacija ginama eksternu.) – įrašoma, jeigu reikia

Mokslinis vadovas (eksternui – Mokslinis konsultantas) prof. dr. Olegas VASILECAS (Vilniaus Gedimino technikos universitetas, technologijos mokslai, informatikos inžinerija – 07T).

Konsultantas – įrašoma, jeigu buvo skirtas doc. dr. Vardas PAVARDĖ (Vilniaus Gedimino technikos universitetas, technologijos mokslai, elektros ir elektronikos inžinerija – 01T).

Abstract

Modelling of information systems (IS) involves development of different models that present various aspects of a system. Expression of an IS through various models is related to the problem of ensuring consistency of different models, which is very important for IS design, models transformation and finally IS program code generation tasks. In order to improve ensuring consistency of IS models in a design phase, a method of checking consistency of IS models is proposed. The method is based on rules among different aspects models defined for the metamodel. It also includes requirements for consistency rules. Assigning an enforcement level and verification of rules according to the metamodel of a modelling language are the most important ones. The dissertation consists of these main parts: introduction, review of the related researches, our proposal, experiments and conclusions. Chapter 1 presents the analysis of publications related with the problem of this thesis. Therefore, the concept of consistency of IS models is analysed; specifications of IDEF and UML, object-oriented modelling methods and design tools are analysed from the perspective of ensuring consistency. Special methods of models checking and their consistency rules are also researched. According to the results obtained during the analysis conclusions are drawn, and the tasks for the dissertation are reconsidered. Chapter 2 describes the author’s of thesis proposed method of checking consistency of IS different aspects models, paying special attention to the requirements for consistency rules. A method of consistency checking of IS different aspects models not related with a specific modelling language was proposed. It is also specialised for UML models. The processes of ensuring consistency and approach of evaluating consistency are proposed. The Z notation is used to formalise the method. In Chapter 3 the experiments aimed at the evaluation of the proposed method are described. The proposed requirements for consistency rules are evaluated using a questionnaire, and the collected data are processed applying a paired t-test method. The proposed method is also implemented in a software prototype for MagicDraw UML tool. The thesis is finished with general conclusions on the accomplished research. The results of the dissertation are published in 12 scientific articles. 5 articles are in the reviewed scientific periodical publications and 7 articles are in other scientific editions. 1 article is accepted for publication in other scientific editions. 10 presentations on the subject have been given in conferences at the national and international level.

Reziumė

Projektuodami informacinę sistemą sukuriame skirtingus modelius pagal duo- menų, procesų ir kitus aspektus. Šiuo atveju yra rizika, kad sistemos specifikaci- joje bus darnos pažeidimų dėl tarpusavyje nesuderintų modelių. Darnūs ir ne- prieštaringi modeliai yra reikalingi tolesniam pradinių modelių transformavimui ir galiausiai IS programinio kodo generavimui. Siekiant pagerinti modelių darną projektavimo fazėje, disertacijoje yra pasiūlytas IS skirtingų aspektų modelių darnos tikrinimo metodas. Siūlomas metodas yra grindžiamas taisyklėmis tarp skirtingų aspektų modelių. Taisyklės apibrėžiamos modeliavimo kalbos meta- modelio lygmenyje. Siūlomas metodas taip pat apima darnos taisyklių reikala- vimus. Svarbiausi iš jų yra vykdymo lygmens priskyrimas taisyklėms ir taisyklių verfikavimas pagal modeliavimo kalbos metamodelį. Pagrindinės disertacijos dalys yra: įvadas, 3 skyriai ir išvados. Pirmasis skyrius skirtas susijusios literatūros apžvalgai. Jame pateikta darnos (angl. consistency ) sąvokos analizė, pristatyta IDEF ir UML specifikacijų, objektinių modeliavimo metodų ir projektavimo įrankių analizė darnos požiūriu. Šiame skyriuje taip pat yra analizuojami specialūs modelių tikrinimo metodai ir juose naudojamos darnos taisyklės. Skyriaus pabaigoje formuluojamos išvados ir tikslinami disertacijos uždaviniai. Antrajame skyriuje pristatomas IS skirtingų aspektų modelių darnos tikrinimo metodas, ypatingas dėmesys skiriamas darnos taisyklių reikalavimams. Sukurtas darnos tikrinimo metodas nepriklausomas nuo konkrečios modeliavimo kalbos. Jo pritaikomumas iliustruotas specializuojant pasiūlytą metodai UML modelių darnai tikrinti. Darbe pateikiami siūlomi darnos taisyklių reikalavimai, darnos užtikrinimo procesų detalūs aprašymai bei darnos įvertinimo būdas. Z notacija naudojama siūlomam metodui formalizuoti. Trečiajame skyriuje pateikiami eksperimentų, skirtų įvertinti darnos tikrinimo metodą, rezultatai. Pasiūlyti darnos taisyklių reikalavimai įvertinti naudojant klausimyną ir surinkti duomenys apdoroti naudojant paired t-test metodą. Pasiūlyto metodo įgyvendinamumas taip pat iliustruotas sukuriant siūlomo metodo programinės įrangos prototipą, skirtą MagicDraw UML įrankiui. Darbas baigiamas išvadomis apie atliktą tyrimą. Disertacijos tema paskelbta 12 mokslinių straipsnių, iš jų 5 periodiniuose recenzuojamuose žurnaluose, 7 kituose leidiniuose. 1 straipsnis yra priimtas spausdinti į recenzuojamą tarptautinės konferencijos leidinį. Atliktų tyrimų rezultatai pristatyti 10-yje konferencijų vykusių užsienyje ir Lietuvoje.

Notations

Abbreviations BS – Business System; CMOF – Complete MOF; CPN – Colored Petri Net; CSP – Communicating Sequential Processes; DL – Description Logic; EMOF – Essential MOF; IDEF – Integrated DEFinition language; IS – Information System; YSM – Yourdon System Methodology; MCC – Model Consistency Checker; MDA – Model Driven Architecture; MOF – Meta Object Facility; OCL – Object Constraint Language; OCLE – OCL Environment; OMG – Object Management Group; OMT – Object Modelling Technique; OO – Object-Oriented; vii

OOAD – Object-Oriented Analysis and Design; OOM – Object-Oriented Model; OOSE – Object-Oriented Software Engineering; ORM – Object Role Modelling; OWL-DL – Ontology Web Language; RIDE – Rule-based Inconsistency Detection Engine; RUP – Rational Unified Process; SS – Software System; STRADIS – Structured Analysis and Design of Information System; UML – Unified Modelling Language; USE – UML Specification Environment; VBScript – Visual Basic Script.

Terms Aspect is a projection into a model, which is seen from a given perspective. Aspect model means elements that can be visualised by several the same aspect diagrams (adopted from (Querlat, Teniente 2008)). Backward chaining (or backward reasoning) is an inference method that can be described as working backward from the goal(s). Backward chaining systems usually em- ploy a depth-first search strategy (Russel, Norvig 2010). Checking of a model is a process that determines if the model is syntactically correct or/and adequate to the reality (the term is adopted from (Pakalnickiene, Nemuraite 2007)). Classifier is a classification of instances; it describes a set of instances that have features in common. Classifier is an abstract metaclass. E.g. A class is a classifier of objects; an association is a classifier of links. Consistency of IS models means that the structures, features and elements that appear in one aspect model are compatible and in alignment with the content of other aspect models (adopted from (Rozanski, Woods 2005)). Consistency rule is a constraint among different aspects models. Diagram is a view of the information contained in a model (Rational 2003). Forward chaining is one of the two main methods of reasoning when using inference rules . Forward chaining starts with the available data and uses inference rules to extract more data (from an end user, for example) until a goal is achieved. Inference is the process which from one or more propositions formulates another propo- sition (Andress 2012). Invariant for the metaclass is a rule that must be satisfied by all instances of that metaclass of the model (the term is adopted from (OMG 2010)). Model is an abstraction of the physical system, with a certain purpose. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail (OMG 2010a).

viii

Production system or production rule system is a computer program which consists primarily of a set of rules (productions) sometimes called working memory, of facts (or assertions) which are called working memory elements and a rule interpreter (Klahr 1987). A production system is a reasoning system that uses forward-chaining derivation techniques. Reasoning is a process for drawing conclusions from accepted premises (kind of inference) (Andress 2012). Rule interpreter is a mechanism for prioritizing productions when more than one is triggered. Rule interpreters generally execute a forward chaining algorithm for selecting productions to execute to meet current goals, which can include updating the system's data or beliefs (Klahr 1987). Semi-formal language defines syntax of language formally, but diagrams have no formal semantics (Cheng 2001), most semantics are defined informally, using natural language (OMG 2010). Semi-formal model is an abstraction of data that is expressed by semi-formal modelling language. Transformation is the process of creating a correspondence between records and fields of a source schema to (often different) records and fields in a destination schema (Mi- crosoft 2004). Translation is the process of changing the format of an instance message (Microsoft 2004). UML model is an abstraction of the physical system, created with a certain purpose and expressed in UML. Well-formedness rules of the metaclass are defined as a set of invariants for the metaclass, which must be satisfied by all instances of the metaclass for the metamodel to be meaningful (OMG 2010). Coherence rules between diagrams usually are not classified to well-formedness rules (Egyed 2006).

Contents

INTRODUCTION ...... 1 The Investigated Problem ...... 1 Importance of the Thesis...... 3 The Object of the Research ...... 4 The Goal of the Thesis ...... 5 The Tasks of the Thesis ...... 5 Research Methodology ...... 5 Importance of Scientific Novelty ...... 6 Participation in Scientific Projects ...... 6 Practical Significance of the Achieved Results ...... 7 The Defended Statements ...... 7 Approval of the Results ...... 8 Structure of the Dissertation ...... 9 Acknowledgements ...... 9

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS OF THE INFORMATION SYSTEM ...... 11 1.1. Definitions of Consistency and the Model ...... 11 1.1.1. Consistency or Integrity ...... 12 1.1.2. Information Integrity in Security Context ...... 12

1.1.3. Data Consistency in Database Context ...... 12 1.1.4. Consistency Conflicts ...... 13 1.1.5. Consistency of Models ...... 13 1.1.6. Models According to the Level of Formality ...... 14 1.2. Analysis of Information System Modelling Languages and Methods ... 15 1.2.1. Integrated Definition Language...... 15 1.2.2. Unified Modelling Language ...... 17 1.2.3. Object-Oriented Modelling Methods ...... 19 1.2.4. Summary of Analysis of Modelling Languages and Methods ...... 20 1.3. Checking of Different Aspects Models ...... 20 1.3.1. Methods of Checking Models, Expressed in Integrated Definition Language ...... 20 1.3.2. Methods of Checking Models Expressed in Unified Modelling Language ...... 22 1.3.3. Analysis of Consistency Rules ...... 26 1.4. Analysis of Design Tools Using Unified Modelling Language from the Perspective of Ensuring Consistency ...... 31 1.4.1. Reasons for Choosing this Language and its Tools ...... 32 1.4.2. MagicDraw UML 17.0 ...... 33 1.4.3. PowerDesigner 16.1 ...... 35 1.4.4. Poseidon for UML 8.0, Visio 2010 ...... 36 1.4.5. Rational Software Architect 11.3.1 ...... 36 1.4.6. Comparative Analysis of the Design Tools ...... 37 1.5. Conclusions for Chapter 1 ...... 38

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS OF THE INFORMATION SYSTEM ...... 41 2.1. General Framework of the Models from Consistency Perspective ...... 42 2.2. Proposal for Consistency Checking of the Different Aspects Models and Requirements for Consistency Rules ...... 43 2.2.1. The Layers of System and Model – Information System and Its Models Checking ...... 45 2.2.2. Metamodel Layer – Metamodel and Description of Consistency Rules ...... 46 2.2.3. Metametamodel Layer – Essential Meta Object Facility ...... 48 2.3. Formal Specification of the Proposal ...... 49 2.4. Approach on Consistency Checking Information System Models, Expressed in Unified Modelling Language ...... 52 2.4.1. Requirements for Models Expressed in Unified Modellig Language54 2.4.2. Consistency Rules of Models, Expressed in Unified Modelling Language ...... 55

xii

2.5. Description of the Method ...... 74 2.6. Conclusions for Chapter 2 ...... 83

3. APPLICATION OF THE PROPOSED METHOD ...... 85 3.1. Evaluating the Proposed Requirements for Consistency Rules Using Questionnaires ...... 87 3.1.1. Experiment Definition ...... 87 3.1.2. Experiment Planning ...... 88 3.1.3. Analysis and Interpretation ...... 91 3.2. Evaluating the Proposed Method with MagicDraw UML Tool ...... 95 3.2.1. ConsistencyConstraints4UML Module Prototype ...... 96 3.2.2. Modelling of Books Library ...... 101 3.2.3. Checking and Evaluating Consistency of the Models ...... 102 3.3. Conclusions for Chapter 3 ...... 106

GENERAL CONCLUSIONS ...... 107

REFERENCES ...... 109

A LIST OF THE AUTHOR'S SCIENTIFIC PUBLICATIONS ON THE TOPIC OF THE DISSERTATION ...... 117

ANNEXES ...... 119 Annex A. Part of Metamodel of Unified Modelling Language ...... 119 Annex B. Consistency Rules Provided in Different Studies ...... 120 Annex C. Questionnaire Used to Evaluate the Proposed Requirements for Consistency Rules ...... 130

xiii

List of Figures

Fig. I.1. Example of relationships among the diagrams of information system different aspects models ...... 2 Fig. 2.1. Horizontal, evolution and vertical consistency of information system models . 42 Fig. 2.2. Structure of detailed description of consistency rule its associations with metamodel of modelling language ...... 44 Fig. 2.3. Fragments of the metamodel for class model and protocol state machine ...... 56 Fig. 2.4. Fragments of the metamodel for protocol state machine and class model ...... 59 Fig. 2.5. Fragments of the metamodel for sequence and class models ...... 59 Fig. 2.6. Metaelements used in a formal consistency rule 5 ...... 63 Fig. 2.7. Fragments from the metamodel that are important for consistency rule 6 ...... 65 Fig. 2.8. Fragments from the metamodel that are important for consistency rule 7 ...... 67 Fig. 2.9. Part of the metamodel used by consistency rule 9 ...... 69 Fig. 2.10. The metaelements that are used in consistency rule 10 ...... 71 Fig. 2.11. The metaelements that are used in consistency rule 11 ...... 71 Fig. 2.13. Use case diagram of the method ...... 75 Fig. 2.14. Creation of extended method for models, expressed in unified modelling language, consistency checking ...... 78 Fig. 2.15. Checking consistency of models, expressed in unified modelling language ... 80 Fig. 2.16. Evaluation of consistency of information system models ...... 82 Fig. 3.1. Understanding of different methods by specialists with various qualifications 93 Fig. 3.2. Count of answers ‘yes‘ to questions about unambiguity and reliability of consistency rules from two methods ...... 94

Fig. 3.3. Checking models, expressed in unified modelling language, using consistency rules ...... 95 Fig. 3.4. Extension profile for validation rules ...... 97 Fig. 3.5. Implementation of a consistency rule ...... 98 Fig. 3.6. Implementation of consistency rules ...... 99 Fig. 3.7. Importing the developed software prototype ...... 100 Fig. 3.9. Part of input models to the consistency checking process ...... 102 Fig. 3.10. Checking models of books library using a developed software prototype .... 103 Fig. A.1. Fragment of metamodel of unified modelling language ...... 119

xvi

List of Tables

Table 1.1. Excerpts from IDEF0 specification ...... 16 Table 1.2. Excerpts from specification of unified modelling language 2.3 ...... 18 Table 1.3. Comparison of approaches of ensuring the models ...... 24 Table 1.4. Results of consistency rules analysis ...... 28 Table 1.5. Comparison of the design tools ...... 37 Table 2.1. Enforcement level of consistency rules ...... 48 Table 2.2. Metaelements associated by consistency rules ...... 55 Table 2.3. Description of consistency rule 1 ...... 57 Table 2.4. Description of consistency rule 2 ...... 58 Table 2.5. Description of consistency rule 3 ...... 60 Table 2.6. Description of consistency rule 4 ...... 61 Table 2.7. Description of consistency rule 5 ...... 62 Table 2.8. Description of consistency rule 6 ...... 63 Table 2.9. Description of consistency rule 7 ...... 66 Table 2.10. Description of consistency rule 8 ...... 67 Table 2.11. Description of consistency rule 9 ...... 69 Table 2.12. Description of consistency rule 10 ...... 70 Table 2.13. Description of consistency rule 11 ...... 72 Table 2.14. Description of consistency rule 12 ...... 73 Table 2.15. Application of the method of models consistency checking to specific semi- formal modelling language ...... 75 Table 2.16. Extension of the method ...... 77 Table 2.17. Checking consistency of models, expressed in unified modelling language 79 xvii

Table 2.18. Removing inconsistencies ...... 81 Table 3.1. Evaluation of the proposed and three similar methods according to specific features ...... 86 Table 3.2. Participants and their choice from companies ...... 87 Table 3.3. Dependent and derivative variables ...... 89 Table 3.4. Paired t-test ...... 90 Table 3.5. An example of the summary of answers to the questions...... 92 Table 3.6. Count of answers ‘yes’ regarding the quality of consistency rules ...... 93 Table 3.7. Average count of answers ‘yes’ ...... 93 Table 3.8. Application of the paired t-test ...... 94 Table 3.9. Evaluating consistency of library models ...... 105 Table B.1. Consistency rules ...... 120

xviii

Introduction

The Investigated Problem

The models of processes, states, structure and other models are created when an information system is modelled by various aspects. Aspect is a projection into a model, which is seen from a given perspective. Zahman Enterprise architecture framework suggested modelling aspects are data (things), function (process), network (location), people, time and motivation (business rules) (McGovern, 2003). Aspect model means elements that can be visualised by several the same aspect diagrams (adopted from (Querlat, Teniente 2008)). For example, a sequence model consists of elements that can be represented by 3 sequence diagrams. Sometimes the models of different aspects are not interrelated and even more, contradictory information can be provided in them. For example, it is possible that elements created in one model are not used in another model. Despite the created data model, sometimes it is not used when modelling data flows. Moreover, a change of a model is often not reflected in another model. Expression of an IS through various models is related to the problem of consistency ensuring of different aspects models. Consistency means that the structures, features and elements that appear in one model are compatible and in

1 2 INTRODUCTION alignment with the content of other models (Rozanski, Woods 2005). Constraint associating different aspects models is called a consistency rule . Inconsistency of models is influenced by a number of factors, such as: The existence of multiple views (models) for the same system, they give the details of different concerns but with a possible overlap among them. Iterations that produce a new, more refined description of the system (Huzar 2004). Nature and complexity of the system. The used modelling language, consistency rules are usually expressed implicitly. Skills and experience of a designer. The time available to produce the information system project, etc. It is necessary to emphasize that in this study/research we consider that consistency means matching of elements and features among different aspects models, while well-formedness is more associated with one aspect models (matching one aspect model to the metamodel). There are a lot of modelling languages allowing modelling different aspects of IS, e.g. UML – unified modelling language (class, activity, states and other aspects), IDEF – integrated DEFinition language (function, data, ontology and etc.), ORM – object role modelling (data, rule). Fig. I.1 demonstrates examples of relationships among several diagrams. The text with arrows between the diagrams provides an example of what information should conform each other.

Fig. I.1. Example of relationships among the diagrams of information system different aspects models

INTRODUCTION 3

An example of a consistency rule among UML sequence model and UML class model is: Call message of a sequence model should have an operation assigned . It means the operation of the object called in a sequence model should appear in a class model. Consistency is usually divided to three types. The first type of consistency is horizontal consistency, which expresses consistency between different models within the same version. Evolution consistency means consistency between different versions of the same aspect models (Straeten et al. 2003). Vertical consistency is checked at different levels of abstraction between different aspects models (Lucas et al. 2009; Usman et al. 2008). Sometimes different versions of the same aspect model are not stored, and usually one model evolutionates by adding details. Moreover, latest versions of models can be used for generating other models or a source code in model- driven architecture (MDA). Therefore, we analyse the issue of checking horizontal consistency among different aspects models. Further consistency concept is used instead of horizontal consistency because of simplicity.

Importance of the Thesis

The consistency problem has been widely discussed in the publications of recent years. That demonstrates the importance of ensuring consistency of IS models in a design phase. Various methods were proposed to check consistency: methods based on translating semi-formal models to formal models and detecting consistency conflicts using inference mechanism of a formal language according to constraints (Chanda et al. 2009; Sapna, Mohanty 2007; Egyed 2007 and others); methods based on checking semi-formal models using constraints (Borba, Silva 2010; Shinkawa 2006; Straeten 2004 and others). Semi-formal model is an abstraction of data that is expressed by semi- formal modelling language. Semi-formal language defines syntax of a language formally, but diagrams have no formal semantics (Cheng 2001), most semantics are defined informally, using a natural language (OMG 2010). None of the analysed methods has been accepted as standard. None of the related researches deals with the quality of consistency rules. Ambiguous, not conforming to the metamodel of a modelling language, sometimes meaningless consistency rules reduce the reusability and practical applicability of the proposed methods. In this research we present a new method for consistency checking of IS different aspects models using rules and paying special attention to the requirements for consistency rules.

4 INTRODUCTION

The issue of models consistency is particularly important within the scope of model-driven architecture (MDA) (Lucas et al. 2009). MDA gained more and more importance in information system development during the last few years (Berkenkotter 2008; Pakalnickiene, Nemuraite 2007). The main idea in MDA is the platform-independent model (PIM) that serves as a source for transformation to platform-specific models (PSM). PSM is used for code generation (Mokhati et al. 2007). Unambiguous and consistent models are necessary for the successful accomplishment of the tasks of model transformation and finally for code generation (Berkenkotter 2008), (McGovern et al. 2003), (Rozanski, Woods 2005). Therefore, checking consistency of the related models should be one of the cen- tral aims of IS development process. Consequently, consistent models influence the quality of software, and software systems are very important for enterprises because programs help to manage business systems, e.g. indicate problematic transport zones (Jaki- mavicius and Burinskiene 2009), monitor sewage and analysis of water re- courses (Dzemydiene et al. 2008), etc. The problem of consistency checking of IS models is especially important because several analysts or designers modelling the same system can use different terms for the object of domai. If the information system is large and complex, the risk of consistency conflicts in the models is bigger. Therefore, the issue of ensuring consistency is even more relevant. The results of solving this problem are of great importance for the development of a more detailed method of consistency checking of specific IS models and improving methodology of IS development. Moreover, the obtained results may be used in a design tool in order to automate the process of consistency checking. There are a lot of methods of IS developing, many modelling languages, various methods of consistency checking; therefore, it is obvious that the proposed method not related with a specific modelling language could be adapted for a specific part of IS development methodology.

The Object of the Research

The object of the research is methods for ensuring consistency of IS different aspects models.

INTRODUCTION 5

The Goal of the Thesis

The main goal of the research is to improve methods for checking consistency of IS different aspects models providing a method of checking consistency of IS different aspects models, including requirements for consistency rules and processes of ensuring consistency.

The Tasks of the Thesis

The following tasks have to be performed to achieve the main goal: 1. To analyse the chosen IS modelling languages allowing to model different aspects and IS modelling methods from the perspective of ensuring consistency. 2. To investigate special chosen methods for checking IS different aspects models. 3. To explore several design tools from the perspective of ensuring consistency. 4. To propose a method for checking consistency of IS different aspects models for the selected group of models, e.g. for semi-formal or formal models. 5. To develop a software prototype of the suggested method. To specify consistency rules according to the proposed requirements. To evaluate the proposed method and feasibility of implementation.

Research Methodology

Information analysis and comparative research methods have been used to analyse the methods of consistency checking, methodologies of modelling IS and design tools. The research generalisation, logical induction and conceptual modelling methods have been used to summarise the existing methods and to propose a method for checking consistency of IS different aspects models. Experimental research method was applied to test the proposed method.

6 INTRODUCTION

Importance of Scientific Novelty

A new method of checking consistency of IS different aspects models is provided in the thesis. 1. A method of consistency checking of IS different aspects models not related with a specific modelling language was proposed: 1.1 The requirements for consistency rules have not been published by other authors are provided. Using the requirements for consistency rules allows improving the quality of a set of consistency rules. Assigning an enforcement level for consistency rules allows reacting to violations of consistency rules more precisely. 1.2 The processes of ensuring consistency and approach of evaluating consistency of IS models are described in detail. The related researches provide not sufficiently detailed description of processes of IS models checking in order to real- ise the proposal in practice. 2. A specialised method for checking consistency of IS UML models is proposed. A set of consistency rules that is specified according to the suggested requirements is proposed. It differs from the rules provided by other authors because rules that are specified according to the proposed requirements are: 2.1 more understandable as they are defined at three levels, and the associated OMG UML metaelements are referred at the rule of metamodel specific level (meanwhile other authors often use their own metadescriptions of UML models in the rules and their descriptions); 2.2 more reliable because they do not contradict to OMG UML metamodel and the known origin of the rule justifies the necessity of the rule.

Participation in Scientific Projects

While preparing the thesis, the author participated in the scientific projects described below:

INTRODUCTION 7

1. “Business Rules Solutions for Information Systems Development (VeTIS)”; registration number B-07042; participation time: July 2007–December 2009. 2. “Teaching, Research, Innovation in Computing Education Project (TRICE)”; registration number 142399-LLP-1-2008-1-BG- ERASMUS-ENW within the framework of LLP Erasmus Thematic Networks. Participation time: April 2009–December 2009.

Practical Significance of the Achieved Results

The achieved results can be used to automate a process of checking consistency of IS different aspects models: The obtained results are applied in Lithuanian State Science and Studies Foundation, a high technology development program for 2007–2013 project “Business Rules Solutions for Information Sys- tems Development (VeTIS)”, 2007–2009. The proposed consistency rules are based on OMG UML metamodel, therefore they may be realized in design tools that enable to create IS UML models. A prototype of the proposed method is implemented in MagicDraw UML tool.

The Defended Statements

1. The proposed requirements for consistency rules improve the understandability of the rules, increase reliability regarding the conformity to the metamodel of the modelling language and the defined origin. 2. Assigning an enforcement level for consistency rules allows reacting to violations of consistency rules more precisely. 3. The proposed method of consistency checking of IS different aspects models allows detecting consistency conflicts of semi-formal IS different aspects models.

8 INTRODUCTION

Approval of the Results

12 articles focusing on the subject of the dissertation are published: 1 article is referred in ISI Web of Science database (Vasilecas, Dubauskaite, Rupnik 2011), 2 articles are printed in the scientific journal, referred in CEEOL database (Du- bauskaite, Vasilecas 2009; Dubauskaite, Vasilecas 2008), 2 papers are in other reviewed scientific periodical publications (Dubauskaite, Vasilecas 2008a; Du- bauskaite, Vasilecas 2009a), 4 articles are in the material reviewed during international conferences (Dubauskaite, Vasilecas 2010; Vasilecas, Dubauskaite 2009; Dubauskaite, Vasilecas, Saulis 2009; Dubauskaite, Vasilecas 2008b), 1 article is reviewed during a national conference (Dubauskaitė, Būgaitė, Vasile- cas 2008), and 2 papers are in other proceedings (Dubauskaite, Vasilecas 2009b; Dubauskaite Vasilecas 2008c). 1 article is accepted for printing in the material reviewed during international conferences (Dubauskaite, Vasilecas 2012). The results of the dissertation were presented at the following 10 scientific conferences: 1. The 20th International Conference on Information Systems Devel- opment (ISD2011), 2011, Scotland, Edinburgh. 2. International Conference on Computer Systems and Technologies CompSysTech'10, 2010, Bulgaria, Sofia. 3. The 14th International Conference of Computer Specialists “Days of Computer Specialists 2009”, 2009, Lithuania, Kaunas. 4. The 12th Conference for Lithuanian Junior Researchers “Science – Future of Lithuania”, 2009, Lithuania, Vilnius. 5. International Conference on Computer Systems and Technologies CompSysTech'09, 2009, Bulgaria, Ruse. 6. The 2nd International Conference on Innovative Information Tech- nologies, IIT-2008, 2008, Lithuania, Vilnius. 7. The 14th Conference on Information and Software Technologies IT 2008, Lithuania, Kaunas. 8. The 11th Conference for Lithuanian Junior Researchers “Science – Future of Lithuania”, 2008, Lithuania, Vilnius. 9. The 6th International Conference “Researches of Technology in West Lithuania”, 2008, Lithuania, Klaipėda. 10. The 13th Joint Conference of Universities “Information Technolo- gies”, 2008, Lithuania, Kaunas.

INTRODUCTION 9

Structure of the Dissertation

The dissertation consists of three main chapters. Chapter 1 introduces the analysis of the related researches. The proposed method of consistency checking of IS different aspects models is provided in Chapter 2. Chapter 3 presents the experiment performed to evaluate the suggested approach. The total scope of the dissertation is 154 pages, 28 figures, 33 tables.

Acknowledgements

First of all, I would like to thank my Scientific Supervisor Olegas Vasilecas. He supported me during all my studies. I was taught to hear advice, ask questions and express my ideas. Thank you for a different and innovative approach to my research problem. Thank you for encouraging me to seek and accomplish my goal. Also, I would like to say many thanks to my colleagues and friends at Vil- nius Gediminas Technical University. You have been beside me all those years. Your support encouraged me to continue my work and finally to achieve the goal. Very special thanks to my family: my parents Zita and Algimantas who encouraged me to choose this road and constantly supported me during all these years. Many thanks to my friend Mindaugas for unconditional support and for listening to my complaints.

Rūta Dubauskaitė

1. Consistency of Different Aspects Models of the Information System

The task of this chapter is to present relevant literature analysis and to analyse the current situation and problems in checking consistency of IS models. Section 1.1 presents the concepts of consistency and the model. Section 1.2 discusses specifications of IS modelling languages and methods of IS development in the context of consistency. Section 1.3 analyses the methods of checking IS different aspects models. Section 1.4 presents current possibilities to check consistency of IS different aspects models using design tools. Finally, Section 1.5 summarises the main problems of checking consistency of IS models and the revised tasks for the dissertation.

1.1. Definitions of Consistency and the Model

Several definitions of consistency and integrity appear in the existing literature. The definitions of these concepts mostly depend on the context (e.g. security) or metadata hierarchy (e.g. information, model). In this research consistency of IS different models is investigated. Therefore, a consistency concept is associated

11 12 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... with a model concept. The final subsection presents definitions of the models according to the level of formality.

1.1.1. Consistency or Integrity According to ISO/IEC (1997), consistency expresses the matching ratio. Consis- tency means that the structures, features and elements that appear in one model are compatible and in alignment with the content of other models (Rozanski, Woods 2005). Sometimes an integrity concept is used instead of a consistency concept. According to Caplinskas (1997), consistency is part of integrity. Integrity also involves the following quality characteristics: accuracy of facts, accuracy of values, conformity, and accuracy of time.

1.1.2. Information Integrity in Security Context According to FIPS security requirements specification (FIPS 200:2006), information integrity is defined as guarding against improper information modification or destruction, and it includes ensuring information non-repudiation and authenticity In security context information integrity can be characterized as representa- tional faithfulness (Boritz 2004), i.e. does information faithfully represent reality? Integrity has four necessary characteristics (Boritz 2004): correctness (accuracy): does the information correspond to reality? completeness: are all relevant aspects of reality represented? timeliness: does the information represent current reality? validity: is information processed according to authorized procedures.

1.1.3. Data Consistency in Database Context A consistency concept is also used as a quality characteristic of data. The consistency dimension captures the violation of rules (Batini, Scannapieco 2006). In relational database theory integrity constraints are instantiations of such rules. Integrity constraints are the properties that must be satisfied by all instances of database schema. For example, let us consider an Employee relation schema with attributes Name , Surname , Age , WorkingYears and Salary . An example of

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 13 the domain constraint defined on the schema is Age is included between 0 and 110, If working years are less than 3, than salary could not be more than EUR 25.000 per year . Constraints can be not only for one relation, they can also express key dependencies, functional dependencies and others (Batini, Scan- napieco 2006). According to Baronas (2005), data consistency is correctness and completeness of information saved in the database. In relational database, data consistency is ensured by the requirements for mandatory values (not null), primary and foreign keys of tables, data values and domain rules that are realised by trig- gers. Analysis of concepts of data and model consistency is also presented in Dubauskaite’s and Vasilecas’s paper (2009a).

1.1.4. Consistency Conflicts The concept of consistency may also be explained using definitions of inconsistencies. According to Pfeiffer and Gehlert (2005), consistency conflicts are divided into three groups: type, structural, and name. Type conflicts arise when the same fact is represented by using different constructs of the modelling language. Structural conflicts occur when the description of reality at different levels of abstraction (abstraction conflict) or domain terms are modelled at different levels of detail (Kashyap, Sheth 1996). An example of a structural conflict in E- R models is when the same Issue is modelled as Publication in one model and as Book in another model ( Book and Publication are at different levels of abstraction). An example of detail conflicts is different attributes for a Writer and Au- thor , Authors have only a name , and Writers have a name and address (Pfeiffer, Gehlert 2005). Naming conflicts are caused by the usage of synonym and homonym terms, e.g. Client, Customer, Consumer or Writer, Author, etc.

1.1.5. Consistency of Models Consistency of models means that the structures, features and elements that appear in one model are compatible and in alignment with the content of other models (Rozanski, Woods, 2005). According to Simmonds and Bastarrica (2005), consistency is a state in which two or more elements, which overlap in

14 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... different models of the same system, have a satisfactory joint description. The task is to ensure consistency of a model, consistency of diagrams depends on accuracy of a model. A model can be visualised by several diagrams. Consistency can be classified to vertical (inter-model), horizontal (intra- model), evolution, semantic or syntactic. Vertical or inter-models consistency is checked at different levels of abstraction between different aspects models (Lucas, Molina, Toval 2009; Usman et al. 2008). Horizontal or intra-models consistency can be defined as a matching ratio between models at the same level of abstraction (ISO/IEC 1997). Evolution consistency is validated between different versions of the same aspect model (Straeten et al. 2003). All mentioned types of consistency can express syntactic or semantic conformance of different aspects models. Syntactic consistency expresses matching of models to the specifications of a metamodel. Semantic consistency requires that a model would be compatible to semantic meanings defined by a metamodel (Lucas, Molina, Toval 2009; Usman et al. 2008). In this paper, we concentrate on improving models syntactic and semantic horizontal consistency of different aspects of IS models expressed by a semi- formal language.

1.1.6. Models According to the Level of Formality According to the level of formality, IS models can be divided into three groups: formal, semi-formal, and informal (Vasilecas, Lebedys 2005). A model is formal if it is represented using a language having a well- defined form (syntax), meaning (semantics), and possibly rules of analysis, inference, or proof for its constructs (OMG 2009). According to Gogolla (2004), a formal language is specified at meta-level syntax, semantics and proof system. A formal model can be created using graphical or textual notation (syntax).The semantics might be defined more or less formally. A diagram with boxes and lines and arrows that is not supported by a definition of the meaning of a box, and the meaning of a line and of an arrow is just an informal diagram (OMG 2009). Formal models are often too complex to be used in practice. Semi-formal models are widely used; therefore, they are of interest for us. Examples of semi- formal languages are UML (Matta, Furia, Rossi 2004; Cavarra, Riccobene,

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 15

Scandurra 2004), IDEF (Barjis 2009). UML is a semi-formal language because the diagrams have no formal semantics (Cheng 2001), most semantics are defined informally, using a natural language (OMG 2010). IDEF and UML languages are chosen for the detailed analysis because they allow modelling different aspects of IS.

1.2. Analysis of Information System Modelling Languages and Methods

In this chapter we briefly present IDEF and UML modelling languages allowing to model different aspects and several object-oriented modelling methods from the perspective of ensuring consistency. The motivation of this research is necessity to find out how detail associations among different aspects models are described in specifications of modelling languages and modelling methods. Specifications of IS modelling languages and methods were investigated according to these criteria: what rules are provided: well-formednees or/and consistency, and expression of rules: implicit, explicit, informal (in a natural language), formal.

1.2.1. Integrated Definition Language The IDEF suite contains several graphically based notations for modelling various aspects of an enterprise. The parts of IDEF suite describe subsets of modelling languages and they are called methods. The main IDEF methods are: (1) IDEF0 is a function modelling method; (2) IDEF1 is an information modelling method; (3) IDEF1X is a data modelling method; (4) IDEF3 is a process description capture method; (5) IDEF4 is an object-oriented design method; (6) IDEF5 is an ontology description capture method. These IDEF methods are described in more detail in documentation provided by Knowledge Based System, Inc. (KBSI 2010). IDEF0 and IDEF1X are widely used in the government, industrial and commercial sectors, supporting modelling for a wide range of enterprises and application domains (FIPS 1993). These techniques are FIPS (Federal Informa- tion Processing Standards) standards (FIPS 1993; FIPS 1993a); therefore, IDEF0 and IDEF1X models are analysed in more detail in the dissertation. IDEF models can be defined as a set of one or more IDEF diagrams that depict the functions (IDEF0) of a system, and/or data (IDEF1X) and/or other view of a system with graphics, text and glossary (FIPS, 1993).

16 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

IDEF0 model is a function model. Sometimes it is called ICOM (Input Control Output Mechanisms). Function transforms inputs into outputs under the influence of a control, using the mechanisms provided (Kim et al. 2003). The box is the basic construct of IDEF0 model. The box is composed of a rectangle representing some fragment of the enterprise activity—function—and of four types of arrows representing connections with surroundings: input, control, output, and mechanism. Inputs and outputs are information or physical objects. Controls activate or regulate or synchronise the function. Mechanisms are resources necessary to perform the function. Outputs of one function marked with the box can be inputs or controls of other boxes. Boxes may be structured into other boxes with a higher level of precision. The diagram in which the A0 top box appears represents the context of the model and is called a context diagram. It represents the overall purpose of the system and its interfaces with an external environment. Other IDEF0 diagrams decompose the context diagram. IDEF1x model is data model. IDEF1x models have components similar to constructs of entity-relationship (E-R) models: entities, attributes, and relationships. Entities represent “the things of interest” about which data is kept, real or abstract. They have a form of rectangles on diagrams. Attributes represent characteristics of entities, shown on diagrams by listing their names into an entity rectangle. Relationships connect entities, shown in the diagram by lines connect- ing rectangles.

Table 1.1. Excerpts from IDEF0 specification

No. Excerpt from IDEF0 specification Comment (FIPS, 1993) 1. Each box shall have a minimum of one Well-formedness rule. control arrow and one output arrow. 2. A box shall have zero or more input Well-formedness rule. arrows. 3. Input Arrow: the class of arrows that A consistency rule may be de- expresses IDEF0 Input, i.e., the data or rived that it is necessary to asso- objects that are transformed by the ciate Input of IDEF0 with IDEF1x function into output. models that presents the structure of the data. 4. Output Arrow: the class of arrows that A consistency rule may be de- expresses IDEF0 Output, i.e., the data rived that it is necessary to asso- or objects produced by a function. Out- ciate Output of IDEF0 with put arrows are associated with the right IDEF1x models that presents the side of an IDEF0 box. structure of the data.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 17

IDEF0 and IDEF1X methods are independent of each other; however, they may be used for a description of the same system, and the need for merging IDEF0 and IDEF1X models into one integrated model is obvious. Integration of IDEF models is presented in the paper by Shen et al. (2004). The merged models may have consistency conflicts, ambiguity information may be provided, lack of same attributes in one model may occur or the same attribute may have a different name in various diagrams, etc. IDEF specifications are analysed in order to detect if consistency requirements among different aspect models are defined. The analysis of IDEF specifications demonstrates that they present well- formedness explicitly and consistency rules implicitly (Table 1.1). Implicit expression of consistency requirements influences a problem of inconsistency. Moreover, another factor of inconsistency is non-existence specification or a method that integrates descriptions of different aspects IDEF models. In 2003 Kim et al. stated that no modelling framework had been defined to interconnect individual IDEF notations. After almost ten years our research shows that the situation is similar. However, new methods of integration of different aspects IDEF models have appeared. They are presented in Chapter 1.3.1. Specifications of IDEF, e.g. IDEF0, IDEFx1, etc. are also called methods of modelling; however, they provide guidelines for modelling only one aspect. Meanwhile, UML has both specification and specific modelling methods of various aspects models.

1.2.2. Unified Modelling Language Unified Modelling Language (UML) is OMG specified visual language for specifying, constructing, and documenting the artefacts of software systems (OMG 2010a). It is a general-purpose modelling language that may be used with all major object and component methods, and it may be applied not only for all application domains but also for business process and data structure (OMG 2011). UML 2.3 defines fourteen types of diagrams, divided into three categories: seven diagrams represent a static structure (e.g. Class Diagram, Package Diagram); three diagrams represent general behaviour (e.g. Use Case Diagram, Activity Diagram, and State Machine Diagram); and four diagrams represent different aspects of interactions (e.g. Se- quence Diagram, Communication Diagram) (OMG 2005). UML diagrams contain graphical elements (nodes connected by paths) that represent elements in the UML models. A UML model consists of elements such as packages, classes, and associations (OMG 2007). An UML model is an aspect model expressed by UML language.

18 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

UML models are stored in an XML file, which is defined by XMI files, provided with UML specifications (OMG 2010, OMG 2010a). There are two UML specifications: Infrastructure specification (OMG 2010) and Superstructure specification (OMG 2010a). The UML infrastructure specification defines the foundational language constructs required for UML. It is complemented by UML Superstructure, which defines user level constructs required for UML. The analysis of UML 2.3 Superstructure specification demonstrates that well-formedness rules are presented explicitly in a natural and in a formal language (OCL – Object Constraint Language); meanwhile, consistency rules are provided implicitly (Table 1.2).

Table 1.2. Excerpts from specification of unified modelling language 2.3

No. Excerpt from UML 2.3 Superstructure Comment specification 1. A UseCase must have a name. self.name A well-formedness rule ex- -> notEmpty() pressed in a natural language and in OCL. 2. The final state cannot have any outgoing A well-formedness rule ex- transitions. self.outgoing->size() = pressed in a natural language 0 and in OCL. 3. A protocol state machine is always defined A consistency rule may be de- in the context of a classifier. It specifies rived that it is necessary to de-

which operations of the classifier can be fine a class (because only a 1 called in which state and under which con- class from all the classifiers dition, thus specifying the allowed call se- has operations) which states are quences on the classifier’s operations. A modelled by a protocol state protocol state machine presents the possible machine. and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions. 4. The protocol references a protocol state A consistency rule may be de- machine that describes valid sequences of rived that it is necessary to as- operation and reception invocations that sociate a ProtocolTransition of may occur at this port. ProtocolStates model and an Operation of Class model.

1 Classifier describes a set of instances that have features in common. E.g. A class is a classifier of objects, an association is a classifier of links.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 19

The analysis of IS modelling languages shows that an issue of consistency is not solved directly in them. The next section presents the analysis of several IS modelling methods using UML from the perspective of ensuring consistency of different aspects models.

1.2.3. Object-Oriented Modelling Methods The initial versions of UML are originated from three leading object-oriented methods: Booch, OMT, and OOSE (UML 2007). The analysis of these methods is presented in our paper (Dubauskaite, Vasilecas 2009). It is necessary to note that there are a lot of object-oriented system development methods, for example, OAA (Object Oriented Analysis), UP (Unified Process), RUP (Rational Unified Process), ICONIX, Newton, etc. Several methods are chosen for the detailed analysis: three methods (Booch, OMT, OOSE) that are provided by developers of UML and other three methods that are newer popular object-oriented methods. There is Maciaszek (2001) method, OOAD presented by Bennet et al. (2010), and RUP (Rational Unified Process). The analysis of these methods from the perspective of consistency ensuring is presented below. The original developers of the UML Grady Booch, James Rumbaugh, and Ivar Jacobson provide the core of the language in the Booch (Booch 1991), OMT (Rumbaugh 1991) and OOSE (Jacobson 1992) methods. The analysis of Booch, OMT and OOSE reveals the instructions how to develop different aspects models (for example, static or dynamic). Instructions are provided in a natural language and expressed in an implicit way. They may serve as a source of well-formedness rules. Examples of such instructions for developing a dynamic model of OMT are: a process must have at least an input flow and an external flow; a flow is between processes or between the file and the process, or process and external input, external output (Conoles et al. 1996). The OMT, Booch and OOSE methods define general models relations (flow of models development); however, the relationships of elements in different aspects models are not described. Meanwhile, some of newer methods also provide consistency requirements implicitly, for example: Statecharts must also be consistent with other models. Every action should correspond to the execution of an operation on the appropriate class, and perhaps also to the despatch of a message of other object (Bennet et al. 2010). The preparation of interaction diagrams (either sequence or collaboration diagrams) involves the allocation of operations to classes. These operations should be listed against the correct classes in the

20 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

class diagram, and if operations signatures have been specified in full these must be consistent. The interaction diagrams and classes should be mutually consistent (Bennet et al. 2010). Each activity will be defined by one or more operations in one or more collaborating classes (Maciaszek 2001). It should be noted that one of the analysed object-oriented methods RUP (Kruchten 2000; Rational 2011) does not deal with the issue of consistency among different aspects models.

1.2.4. Summary of Analysis of Modelling Languages and Methods The analysis of IDEF and UML specifications shows that well-formedness rules are presented explicitly while consistency rules2 are presented implicitly. Some of the analysed modelling methods (OOAD and Maciaszek) that use UML also provided consistency requirements in the description of methods. The analysis of IDEF and UML specifications demonstrates that consistency of different aspects models is not ensured in specifications of modelling languages. Only in few of the analysed object-oriented methods the issue of consistency checking is mentioned; however, no method for checking consistency is provided.

1.3. Checking of Different Aspects Models

Special methods for checking IS models are analysed, and the obtained results are presented in the following subsections.

1.3.1. Methods of Checking Models, Expressed in Integrated Definition Language IDEF modelling concepts and tools have been incrementally developed over a number of decades. Nevertheless, there is no modelling framework that has been defined to interconnect individual IDEF notations (Kim et al. 2003). Therefore, the problem of achieving an integrated use of multiple IDEF notations and their supporting systems engineering tools is left to the users to be solved. It is import not only to integrate two separate IDEF models, which are described by two different, unrelated specifications, but also to ensure that the integrated models are consistent. Consistent models are necessary for successful

2 Object-Oriented Analysis and Design

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 21 accomplishment of a models transformation task and even a code generation task. The problem of consistency conflicts of IDEF models is closely related to the problem of models integration. Hence several approaches of IDEF models integration are analysed, and it is researched whether they include a sub-problem of ensuring consistency.

Kim et al. Approach Kim et al. (2003) suggest translating IDEF models to UML models. Static and dynamic UML models are integrated by the same metamodel. The paper presents analogy of IDEF and UML diagrams and their elements (Kim et al. 2003). Having translated IDEF models to UML, the methods of checking UML models may be used. However, a disadvantage is that translation requires additional resources, and, moreover, it is not proved that information is not lost during the translation process. Shen’s et al. Approach Another approach of IDEF models integration is suggested by Shen et al. (2004). In this case integration means using several different modelling approaches together. A guideline is proposed for using a composite of IDEF0, IDEF3 and DFD modelling methods to establish a set of business process models from different perspectives (Shen et al. 2004). According to Shen et al. (2004), it is stated that usage of the IDEF family of modelling methods ensures that consistent semantics are applied. However, the analysis of UML indicates that using one integrated approach for different aspects models does not solve a problem of inconsistency. Usually different tools exist for IDEF0, IDEF1x and other IDEF notations. However, if these models may be used for a description of the same system, it is reasonable and required to merge both models into one in a clear and concise manner. Several existing tools offer such a facility, and the resulting model is called IDEF0/IDEF1X integrated model. However, the tools do not offer any mechanism to control if an integrated model has been constructed correctly (Kacprzak, Kaczmarczyk 2006). Kacprzak and Kaczmarczyk‘s Approach The third analysed approach of the ways to overcome the problem of integration and consistency checking of IDEF models suggests the usage of matrix and Estelle language (Kacprzak, Kaczmarczyk 2006). The simplest way to merge two IDEF models into one integrated model is to use a matrix called integration matrix in which M0 arrows of IDEF0 model are linked together with M1X attributes of IDEF1x model, where M0 arrows are concrete input, output, control

22 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... and mechanism elements of IDEF0 function model. More information on IDEF0 and IDEF1x models is provided in Chapter 1.2.1. Verification of correctness of the integrated models is very important. This may be performed using a formal description technique Estelle (ISO ISO/IEC 9074:1997). Estelle language is commonly applied for specifications of computer network protocols (Budkowski, Dembinski, Diaz 1988). The main idea is to convert both IDEF0 and IDEF0/IDEF1X models into specifications in Estelle (Kacprzak, Kaczmarczyk 2006). The consistency of models is checked according to the criteria of correctness and conformity. The criteria define correct link- ing of attributes to objects and other elements. The main disadvantages of this approach are: Integration is performed at the model level; therefore, it is necessary to merge models in every domain, in every IS project. Consistency checking is based on translation IDEF models and consistency requirements to a formal language. Then inconsistencies are detected by forward chaining reasoning algorithm of a formal language according to consistency rules. A translation task requires additional time. Complexity of a formal language sometimes makes it hard for developers to understand and to use it practically.

1.3.2. Methods of Checking Models Expressed in Unified Modelling Language First methods of UML models checking were based on translation of the models to formal models. Initial studies on consistency of models were presented in the workshop on Consistency Problems in UML-based Software Development II (Huzar et al. 2003). These and other methods of checking UML models are analysed, and their comparison is made in this chapter. Initial researches on checking UML models appeared in 2002. Liu et al. (2002) were the first ones to suggest the paradigm of checking UML models based on a reasoning mechanism of a formal language. Its idea is translating UML models and their consistency rules to any formal language. Then inconsistencies are detected using a reasoning mechanism (a forward chaining algorithm or engine that implements it). The approach presents a production system for checking consistency. The production system or production rule system is a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules (productions) about behaviour and a database, sometimes called working memory, which maintains data about the current state of knowledge, and a rule interpreter. Rule interpreters (in this case RIDE engine) execute a forward chaining algorithm for detecting whether the knowledge base meets productions. The language used for production is undis-

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 23 closed in this work and in Ibrahim’s et al. (2011) paper. The unknown language reduces the reusability and practical applicability of the approach. Further studies enhanced the approach based on the reasoning mechanism of formal languages. They define consistency rules and suggest express UML models in the known formalism. Rash and Wehreim (2003) suggest using Proc- ess Algebra CSP (Communicating Sequential Processes), Object-Z; Straeten et al. (2003, 2004) and his co-workers (Simmonds, Bastarrica 2005) propose description logic; Malgouyres (2006) suggest Constraint Logic Programming (CLP); Miloudi et al. (2011) prefer Z language. More information on approaches of UML models consistency checking based on description logic may be found in Ahmad and Nadeem‘s (2010) paper. One of the disadvantages of these is that formal languages are usually not used in practice although they are more precise. Shinkawa (2006), Kotulski (2007), Borba and Silva (2010), Wang et al. (2012) refine the approaches of UML models checking by suggesting the usage of formal languages which have visual expression, for example, Colored Petri Net (CPN), Node-label-controlled (NLC) graphs, semantic network with OCL (Object Constraint Language) rules and OWL-DL (Ontology Web Language). More information on ontology and elicitation of rules from it can be found in Dubauskaite’s and Vasilecas papers (2008a; 2008) The main disadvantage of these approaches is that their models and rules are not defined for UML metamodel provided by OMG. Formal models are mapped to descriptions of UML models, defined by Shinkawa (2006), Kotulski (2007) and other researchers. Moreover, translation requires additional resources. Another group of approaches of UML models checking, which is evolved almost in parallel with approaches based on UML models translating to formal models, are constraint-driven. The main idea of them is suggestion to check original UML model according to the defined constraints. Studies of this group differ in the checked property (consistency or correctness) and the language for expressing rules if analysed from the point of UML model checking. Chiorean et al. (2004), Pakalnickiene and Nemuraite (2007), Berkenkötter (2008) suggest checking correctness of UML models according to OCL rules, that constrain one aspect model. Chen and Motet (2009) propose controlling grammar in C-Control for expressing correctness rules. Other analysed works propose approaches of checking consistency of UML models. Egyed (2007) presents UML analyser tool where he implemented consistency rules among UML models. The main disadvantages of the approach is that rules and algorithm of checking consistency of IS models are not presented explicitly. Sapna and Mohanty (2007) provide several examples of OCL consistency rules and their translation to SQL, Chanda et al. (2009) suggest several consistency rules expressed in the context free grammar. More details about the research of the related approaches of

24 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... checking UML models consistency is provided in our previous paper (Vasilecas, Dubauskaite, Rupnik 2011). Comparison of the analysed approaches of defined parameters is provided in Table 1.3. Comparison of Approaches

Table 1.3. Comparison of approaches of ensuring the models

Checked property

Author, Year, Technique of ensur- Design or checking of No. [reference] ing consistency the models tool UML models Paradigmof checking Correctness Consistency

1. Liu et al. 2002 Production system - + RIDE (Rule-based In- (used language is consistency Detection undisclosed) Engine ) 3 2. Rasch, Process algebra CSP, - + FDR (tool for CSP-OZ Wehrheim 2003 Object-Z (CSP-OZ) model checking). 3. Straeten, Sim- Description logic - + Loom (DL knowledge monds, Mens, (DL) representation system, Jonckers 2003; reasoning engine), Straeten 2004; RACOON (Poseidon Simmonds, Bas- for UML, Saxon trans- tarrica 2005a; lator, RACER logic reasoning engine), Po- seidon for UML, MCC plug-in 4. Malgouyres, Constraint Logic + - - Motet 2006 Programming (CLP) 5. Shinkawa 2006 Colored Petri Net - + - Usinginference/reasoning mechanism/engine (CPN) formalism 6. Kotulski 2007 Graphs, Node-label- - + - controlled (NLC) graph grammar

3 FDR – failures divergence refirement

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 25

Table 1.3. (continued)

Checked property Author, Technique of ensur- Design or checking of No. Year, ing consistency the models tool [reference] UML models Correctness Consistency Paradigmof checking

7. Borba, Silva Production system: - + Knowledge-Based 2010 predicates and produc- System for Mainte- tion rules are generated nance Registration from semantic network and Consistency and OCL rules 8. Ibrahim et al. Logical approach - + - 2011 (used language is undisclosed) nism/engine 9. Miloudi et al. Z language + - - 2011

10. Usinginference/reasoning mecha- Wang et al. Ontology (OWL-DL, + - - 2012 DL Safe rules) 11. Chiorean et al. OCL + - - 2004 12. Pakalnickiene OCL + - MagicDraw UML et al. 2007 13. Egyed 2007 Consistency rules hard - + Rational Rose with coded to UML Ana- integrated UML Ana- lyzer tool lyzer 14. Sapna, Mo- OCL, SQL - + - hanty 2007

16. Usingconstraints Berkenkötter OCL + - USE tool 2008 15. Chen, Motet. Controlling grammar + - - 2009 in C-Control Chanda et al. Context free grammar - + - 16. 2009

26 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

Approaches of checking UML models consistency are compared according to the following parameters: Paradigm of ensuring consistency of UML models shows a general approach used for ensuring consistency; Technique, language or approach used in the analysed paper to ensure consistency; The checked property indicates whether correctness (constraint is defined for one aspect model) or consistency (constraints among different aspect models) are checked; A design tool used for the implementation and testing of the suggested approach. The existence of both a considerable amount of studies/approaches on consistency of models (see Table above), specific workshops (Kuzniarz et al. 2002; Huzar et al. 2003), technical reports (Hubaux 2009, Straeten 2011) and surveys (Usamn et al. 2008; Lucas et al. 2009; Ahmad and Nadeem 2010) attempting to deal with this kind of problems is a proof of the importance of UML models consistency. The scope of our analysis is narrower. We pay attention to checking horizontal consistency and deeper researching consistency rules. Moreover, our analysis of the related researches involves the latest publications. Hence our research gives more attention to consistency of UML models. Therefore, the papers that analyse conformance of different aspects models (expressed by consistency rules) are selected for a more detailed analysis. The results of consistency rules are presented in the following chapter.

1.3.3. Analysis of Consistency Rules A full, non-redundant, clear and meaningless set of consistency rules is necessary for the method of specific IS models, e.g. UML models, consistency checking; in particular, for automation of the consistency checking process. Therefore, 50 consistency rules were elicited from 10 related researches (see Table 1.4) and examined in order to: a) evaluate consistency rules, excluding redundant rules; b) find out whether the provided rules may be understood unambiguously; c) determine whether they conform to specification of a model – OMG UML metamodel; d) find out whether they are meaningful, i.e. whether they really show a conflict of consistency. Further these four aforementioned issues are presented in detail.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 27

Redundancy and Originality of Consistency Rules First of all, the rules are divided into groups depending on what different aspect models they associate. Various classifications of rules are presented in Du- bauskaite’s and Vasilecas’s the paper (2008b; 2008c). Grouping of rules is necessary in order to compare them and decide whether their meaning is similar or the same. We assign the same originality identification number (ID) to the rules of the same group. Two examples of similar rules provided by different authors are laid out below. Consistency rules with originality ID 1: Rule 1: Any use case can be described by an activity. (If a use case is changed, the activity diagram should be changed.) (Borba, Silva 2010); Rule 2: Each CPN model appears at least in one activity CPN model (Shinkawa 2006). According to the context of the paper, CPN model is a use case model expressed in Colored-Petri Net (CPN); Rule 3: Each use case has at least an activity diagram (Ibrahim et al. 2011); Rule 4: An action/activity state in the activity diagram has a one- to- one mapping with an event of a use case in the use case diagram (Chanda et al. 2009). Consistency rules with originality ID 2: Rule 5: Every message of an object must correspond to the signature of a method of a class (Sapna and Mohanty 2007); Rule 6: Message name must match a class method (Egyed 2007); Rule 7: Messages between the modified classes mean that the corresponding sequence diagram should be amended (It represents the messages exchanged between class instances) (Borba, Silva 2010). The analysis of consistency rules demonstrates that similar rules are provided not only in different literature sources; however, redundancy of rules also exists in sets of consistency rules provided by the same authors, e.g. three Sapna and Mohanty’s (2007) rules (Rule 5, Rule 8 and Rule 9) intersect partially: Rule 8: Each object and message in a sequence diagram must have a corresponding class and method in the class diagram ; Rule 9: Each object in a sequence diagram must reference a valid class in the class diagram and a valid object in the state diagram . The summary of the rules analysis is presented in Table 1.4. The count of consistency rules associating UML models of specific aspects provided in the specific research is presented in Table 1.4, Part “Associated different aspects models”. The line “Different rules” demonstrates how many various rules are presented in different approaches among the same two aspects models.

28 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

Table 1.4. Results of consistency rules analysis

Associated different aspects models

Consistency rules

Class–State Class–Sequence Class–Activity Class–UseCase – Sequence State – Sequence Activity – Sequence case Use Activity-State Activity-Use case Total Expressedain natural language AssociatedOMGUML metamodelmetaelements are specified Expressedain formal language

Egyed 2007 1 1 2 + Sapna, Mohanty 2007 2 2 1 1 1 2 1 1 1 12 + 1 formal 1 rule Chanda et al. 2009 3 1 4 + + Liu et al. 2002 1 1 + + Rasch, Wehrheim 2003 5 5 + + Straeten, Simmonds, 2 4 1 7 + + Mens, Jonckers 2003; Straeten 2004; Simmonds, Bastarrica 2005a; Shinkawa 2006 3 2 5 + Kotulski 2007 1 1 + Borba, Silva 2010 1 1 1 1 1 2 1 1 1 10 + + Ibrahim et al. 2011 3 3 + + Author,[reference] Year Total: 10 8 5 3 4 7 3 2 8 50 Different rules: 7 6 3 2 3 5 2 2 3 32

The three last columns of Table 1.4 indicate whether the rule expressed in a natural language or/and a formal language and whether the associated metaelements from OMG UML metamodel (OMG 2009; OMG 2009a) are defined. A number or a plus sign (+) are in the intersections of the related approaches and the columns. A plus sign indicates that all the rules provided in the paper have specific expression; otherwise, a number shows the count of rules expressed in a natural language, containing metaelements from OMG UML specification or having a formal expression.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 29

All the analysed rules are expressed in a natural language, and most rules have a formal expression. Ambiguity and formality of consistency rules The rules expressed in a natural language may be interpreted ambiguously, for example, Rule 10 : Changes in the internal Dynamics of the class indicate that the state diagram must be changed (Borba, Silva 2010). What specific elements have to be associated? A production rule for Rule 10 is provided in the following paragraph, where CD means a class diagram and SD is a state diagram: If AttributeCD = YES Then AttributeSD = YES A formalized rule has the same level of abstraction; therefore, the issue of what specific elements have to be associated is open. What OMG UML metamodel element does AttributeSD conform to? Rule 11 : Dangling feature reference arises when a stimulus, event, guard or action references an attribute or operation that does not exist in the corresponding class (Straeten et al. 2003). Is this a requirement for class and state models? (A formal expression for this rule is not provided in the Straeten et al. (2003) paper). Rule 12 : A specification consisting of an Object-Z class and an associated state machine has the property of method liveness if in the corresponding process in the semantic model every method will always eventually be executed again (Rasch, Wehrheim 2003). Is a semantic model a state model? Is a method an operation, transition or a message? Object-Z expression for Rule 12 is provided below:

Rasch and Wehrheim (2003) do not associate their rules with OMG UML metamodel. Therefore, it remains unclear exactly how to map elements from their UML models description to OMG UML metamodel. Rule 13: Swimlines in the Activity diagram (represented as class- Name in the activity state) must be presented as a unique class in a class diagram (Chanda et al. 2009). What is an activity state? Swim- line, partition, etc. The formal expression for Rule 13:

30 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

Chanda et al. 2009 define the formal rules using elements from their own description of UML models. Chanda et al. do not provide mapping of metaelements of OMG UML metamodel. Rule 14 : For each actor in a use case diagram there must exist a matching class in the activity diagram (Sapna and Mohanty 2007). Does ”Matching class” mean a swimline, partition, or an object for flow specification? (A formal expression for this rule is not provided by Sapna and Mohanty (2007)). The analysis of consistency rules demonstrates that rules expressed in a natural language may be interpreted ambiguously. To sum up the analysed consistency rules, it is possible to draw a conclusion that the main reasons of ambiguity are the following ones: incompleteness, a different structure of rules, e. g. associated elements (see Rule 10, Rule 12), or models (see Rule 11) are not defined explicitly, some rules have associated elements and models; meanwhile, other rules have only elements or models; synonyms for the same elements, UML metamodel is usually not used in rules, e.g. is a semantic model a state model? Is a method a protocol transition (whether a semantic model is a state model) or an operation or something else in Rule 12? Contradiction and Conformance to OMG UML Metamodel The analysis of consistency rules reveals that there are rules contradicting model requirements expressed in OMG UML specification. Examples of such rules are: Rule 15 : Each state in a state diagram must be related to one and only one class (Sapna and Mohanty 2007). According to OMG UML metamodel (2010), state machines may be used to specify behaviour of various model elements. For example, they can be used to model behaviour of classes, use cases, actors, subsystems, operations, or methods. Hence Rule 15 is a too strict requirement. Rule 16 : Each object and message in a sequence diagram must have a corresponding class and method in the class diagram (Sapna, Mo- hanty 2007) . According to OMG UML specifications (OMG 2010), only calling messages have to be defined in a class (in case mes- sageSort is either synchCall or asynchCall, then a message has to refer to an Operation). Rule 17 : For each actor in a use case diagram there must exist a matching class in the sequence diagram (Sapna and Mohanty 2007). Classes are not presented in a sequence model explicitly.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 31

Meaningless and Necessity of Consistency Rules Rule 18 : A specification consisting of an Object-Z class and an associated state machine has the property of method executability if in the corresponding process in the semantic model every method is executed at least once (Rasch and Wehrheim 2003). What is the source of the rule? What is IS development methodology or OMG UML metamodel? E.g., does the method getClientData() really have to be used in State model? May be the rule is valid under certain conditions; however, they are not provided. Rule 19 : Instance definition missing occurs when an element definition does not exist in the corresponding class diagram(s): Classless instance arises when an object in a sequence diagram is the instance of a class that does not exist in any class diagram (Straeten et al. 2003). It is a too strict requirement that each object should have a corresponding class, for example an object responsible for visualisa- tion of entities, for user interface is usually not in class models. Rule 20 : Each class and activity in an activity diagram must have a corresponding class and method in the class diagram (Sapna and Mohanty 2007). If method behaviour is detailed by an activity model, the requirement that activity should have a corresponding method is meaningless in case the method does not use other methods. In other case one method uses other methods; however an activity model usually does not use a name of methods, activity names are expressed in a natural language. What is the source of the rule that improves the necessity of the rule? Moreover, classes are not used in activity models explicitly; they are types of objects that specify the object flow. The analysis of consistency rules demonstrates that it is not sufficiently clear whether all the rules are really necessary for consistent models and whether they are valid in all situations.

1.4. Analysis of Design Tools Using Unified Modelling Language from the Perspective of Ensuring Consistency

The last task of the analysis of the related researches is exploring several design tools. It is necessary to note that a concept “design tools” is used instead of the term ”CASE (Computer-Aided System Engineering) tools“ because in this case it is required that the tool should allow modelling IS, and other features such as

32 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... code generation, testing of a program code are not mandatory. Meanwhile, CASE tool usually automates almost all phases of IS development. The analysis of a design tool is carried out in order to get the answers to the following questions: whether design tools ensure creating correct or even more consistent models; whether they have possibility to check models, what property (correctness or/and consistency) they check; and what is the possibility of extension the tool with new features.

1.4.1. Reasons for Choosing this Language and its Tools Several tools that allow creating UML models were chosen for detailed analysis. The reasons why UML is worth paying attention to are explained below: UML allows modelling various aspects of IS; UML is likely to be the most popular modelling language (Silingas and Butleris 2009); There are many modelling tools supporting UML (Shen, Compton, Huggins, 2002); It was developed by OMG (Object Management Group), which also introduced MDA (Model Driven Architecture) (Lucas, Molina, Toval, 2009). Consistency of UML model is especially important in MDA, for automatic transformation of initial model to specific model and finally code generation tasks (Rozanski, Woods 2005; Berk- enkötter 2008); UML is the most popular semi-formal modelling language (Berk- enkotter 2008). It is considered as the standard for the object-oriented modelling (Mokati et al. 2007), and usually object-oriented methods are used for a detailed analysis and following implementation. There are a lot of design tools that can be used for developing UML models. The examples of commercial UML tools are Gentleware Poseidon for UML (is available at www.gentleware.com/download.html), IBM Rational Rose (is available at www-01.ibm.com/software/rational/), Sybase PowerDesigner (is available at www.sybase.com/products/modelling/development/powerdesigner), NoMagic MagicDraw (is available at www.magicdraw.com/), Microsoft Visio (is available at office.microsoft.com/en-us/visio/), IBM Rational System Archi- tect (is available at http://www.ibm.com/developerworks/downloads/r/ systemarchitect/) and others. While ArgoUML (is available at argouml.tigris.org/), Open ModelSphere (is available at www.modelsphere.org/) StarUML (is available at http://staruml.sourceforge.net/en/), Umbrello UML

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 33

Modeller (is available at http://uml.sourceforge.net/) are open sources of UML tools. The usage of these tools enables us to create, modify a model of information system, and it is especially important for large systems. The issue of quality, especially of consistency of IS models, is also relevant. This chapter presents the results of analysis of NoMagic MagicDraw UML, Sybase PowerDesigner, Poseidon for UML, IBM Rational System Architect and Microsoft Visio tools from the perspectives of checking consistency of IS models and extension of these tools. Commercial tools were selected for the detailed analysis because they are widely used, and moreover, they usually have more facilities compared to open source tools. Our decision also depended on eco- nomical factors (the university has licences for MagicDraw and PowerDesigner) and personal factors (experience of working with the tools). Visio tool is incor- porated into the widespread Microsoft Office package; therefore, it is worth paying attention to. Poseidon for UML, IBM Rational System Architect is chosen at random from commercial tools, and trial versions are explored.

1.4.2. MagicDraw UML 17.0 MagicDraw UML enterprise edition 17.0 has facility to check the produced models according to validation rules. A validation rule captures some condition, which must be checked against the model. Validation rules are specified as invariant constraints in the model. There are three types of constraints that MagicDraw can evaluate: classifier level constraints, constraints on metaclasses, and constraints on stereotypes. Classifier level constraints are placed on the classes, data types and other classifiers of the model. These constraints are evaluated on all the instances of these classifiers. The example of this classifier constraint is Limit of Credit cannot be bigger than 500 . Constraints on metaclasses are placed on one of the classes in the UML Standard Profile::UML2.3 Metamodel. This constraint is evaluated on all the model elements of that kind, e.g. if a constraint is placed on Actor metaclass, then this constraint applies to all the actor elements in the model. Here is an example rule (specified in OCL2.0), which mandates that all actor names in the model must be capitalized (MagicDraw 2011a): context Actor inv capitalize: let startwith:String = name.substring(1,1) in startwith.toUpper()= startwith

34 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

The third group of constraints involves constraints on stereotypes. A stereotype is a specific metaclasses on the existing UML metamodel element (Magic- Draw 2011a). Constraints on stereotypes are applied to all the model elements that have this stereotype applied to them. Constraints may be classified not only according to types, but they are also grouped according to the application domain. MagicDraw UML 17.0 has eight suites of rules for checking (MagicDraw 2011a): completeness of models, correctness of models, and XML, DDL schemes, Java, C++ specific models and other domains. Validation suites, available for validating, depend on what profiles your model includes. A profile is a package of UML stereotypes, tagged values and constraints for modelling a concrete aspect of the system, e.g. graphic user interface (OMG 2010a). In this chapter the analysis of completeness and correctness of suites is presented in detail because they are most closely related to our research. A completeness suite includes 22 rules, and a correctness suite consists of 14 rules, they are in UML Standard Profile. A completeness suite has a collection of rules, which check whether models are more-or-less finished, there are no gaps, and the elements have the essential information fields filled in. Examples of a completeness rule: Not initial state should have incoming transitions. Instances should have a classifier specified. Actors should be named. A call message should have an operation assigned. Specify parameter types for operation. Completeness of models depends on correctness of models and vice versa. A correctness suite has a collection of rules, checking for common mistakes while modelling in UML. The examples of these rules, realised in MagicDraw are: There should be one constrained element for OCL2.0 constraints. All the features in the interface should be public. Leaf Element should not be abstract. Lower multiplicity value should be lower than upper multiplicity value. If at least one operation of a classifier is abstract, a classifier should be abstract. It is important to note that the two rules among class and sequence models are provided in sets of completeness and correctness rules: Call message should have an operation assigned, and Call to message from a foreign classifier.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 35

An automatic validation process can be activated by command Validation from Analysis menu. Previously analysed rules are provided as OCL 2.0 expressions in Magic- Draw UML. In general, MagicDraw supports 2 languages for expressions that can be evaluated: OCL2.0 is used for validation rules, specified in OCL language. Only OCL invariants are evaluatable in MagicDraw. Other types of OCL constraints (def, init, derive, pre, post, body) can be modelled for documentation purposes. Binary is used for more advanced expressions, which are not easily expressed in OCL. These expressions are written in Java, compiled, and specified in the MagicDraw’s classpath. Then these expressions can be specified as a validation rule expression (MagicDraw 2011). MagicDraw tool can be extended with new rules, expressed in OCL or Java code. When the rules are OCL invariants, then a package with constraints might be exported as a module and used by any other project of IS modelling. If the rules are expressed in Java code, it is necessary to create a plug-in for Magic- Draw, which can be also reused for checking models of other systems. The analysis of MagicDraw UML 17.0 from the perspective of checking IS model consistency shows that tools have 36 rules for checking completeness and correctness of IS models. Most rules check one aspect models.

1.4.3. PowerDesigner 16.1 There are 35 OOM (Object-Oriented Model) groups of checks available in Sy- base PowerDesigner Architect 16.1 tool (Sybase 2011). The examples of groups of constraints are use case, class, message, state, event, activity, and association. Examples of constraints implemented in PowerDesigner tool are: The name of a class has to be unique. Data type has to be assigned to the attribute. Circular dependency cannot be among packages. All checks, except several examples, are undisclosed in documentation and hard coded to PowerDesigner tool. New validation rules may be defined by the user using a graphic user interface. However, the rules may be used for the purpose of documentation only. It means that rules are not included into the automatic process of model validation, which is activated by command Check Model from Tools menu. The rules that are documented in the model are not used in the process of model checking. Therefore, if we want to include new rules into the process of model validation, it is necessary to extend the PowerDesigner tool with a new profile (Sybase 2011b). Custom checks (Profile) are model checks, written in

36 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

VBScript. Custom checks are listed with standard model checks in the Check Model Parameters dialog box. A more detailed analysis of MagicDraw and PowerDesigner is provided in the article (Dubauskaite and Vasilecas 2012).

1.4.4. Poseidon for UML 8.0, Visio 2010 Gentleware Poseidon for UML Community Edition 8.0 and Microsoft Visio Pro- fessional 2010 provides elements, defined in UML metamodel, for creating a model. However, most constraints defined in UML specification (OMG 2010) are not implemented in the tool. There is no ability to check consistency of information system model according to explicitly defined constraints on one aspect model or on different aspects models. Poseidon for UML may be extended with new features developing a plug-in, written in Java language (Boger, Gra- ham, Köster 2006); meanwhile, Visio tool has a possibility to include new macros, written in Visual Basic Language or include a new plug-in (sometimes called add-in or add-on), written in .NET language.

1.4.5. Rational Software Architect 11.3.1 IBM Rational Software Architect 11.3.1 has a facility to check the model according to the rules. All implemented constraints are hard coded, and they are not shown to the designer. A checking process according to the constraints for one aspect model can be activated by the command from Report menu: ‘Unified Rules Check‘. More information is provided in IBM paper (2010). The user can identify the rules that are violated by models, e.g.: Class Client: R73 - Warning - class has no attributes . Class Client: R75 - Warning - class has no operations . Rational Software Architect has a function of checking consistency among a class and sequence models (Select Reports, Word Reports, Object Model Re- ports, Sequence Class Xref Report), how to activate this function is described in IBM paper (2010a). Examples of consistency rules are: A message with no association on Any Class Diagram. Associations with no Events on Ay Sequence Diagram. The tool contains several consistency rules among a class and sequence modes. Rational Software Architect tool may be extended with new rules among other aspects models using built-in support for Microsoft Visual Basic for Ap- plications, which enables the user to write native macros (IBM 2012).

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 37

1.4.6. Comparative Analysis of the Design Tools Table 1.5 gives a summary of the analysed NoMagic MagicDraw, Sybase Pow- erDesigner, Gentleware Poseidon for UML, IBM Rational System Architect and Microsoft Visio tools.

Table 1.5. Comparison of the design tools

Rational Compared Magic- Power- Poseidon Software Design Draw Designer for UML Archi- Visio 2010 Comparison tools 17.0 16.1 8.0 tect criteria 11.3.1 1. Model in confor- + + partially + partially mity with metamodel 2. Correctness + + - + - checking 3. Consistency partially - - partially - checking 4. Language for ex- OCL, Visual Java Visual Visual pressing/ implemen- Java Basic Basic Basic (for tation rules Macros), .NET (for plugin) 5. Technique of module, plug-in plug-in macros macros, tools extension with plug-in plug-in new rules

The criteria for comparison are: A model in conformity with a metamodel. Possible values are “+” (almost conform) and “partially” conform. If a model is in conformity with UML metamodel, it is checked according to one rule: name of a class has to be unique . If the tool does not allow creating a class with the same name in the model, then it is assumed that the model almost conforms to the metamodel. It is said “almost” because it is not checked whether all constraints defined in a metamodel are implemented in the tool. If the tool allows creating two classes with the same name, it is assumed that the model partially conforms to the metamodel. It is said “partially” because a tool does not implement

38 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ...

all the constraints defined in the specification of UML; however, it provides metaelements defined in a metamodel. Correctness checking – constraints are defined at the metamodel level for one aspect model, e.g. for a class diagram. Consistency checking – constraints are among 2 and more different aspect models at the metamodel level. Value “partially” means that there are only several rules that constrain two different aspect models, e.g. Class and Sequence. Meanwhile, other aspects models and their relationships (e.g. a class and states) are not included. Language for expressing/ implementation rules. Technique of tools extension with new rules. Examples are developing a module or plug-in, or macros or using other techniques for the extension of the tool with new rules. Despite the existence of many tools, it is not easy to develop models that conform to UML metamodel. Moreover, not all available tools have a facility to check IS models, and almost all defined constraints are for one aspect models.

1.5. Conclusions for Chapter 1

In this chapter the author presented IS modelling languages and methodologies, methods of models checking, and design tools in the context consistency of different aspect models. Having analysed IDEF, UML specifications and OMT, Booch, OOSE, Maciaszek, OOAD and RUP modelling methods, we concluded that consistency rules are not described or provided implicitly. This factor may cause some diffi- culties in creating different aspects models that match each other. Consistency depends not only on the used modelling language and modelling methods but also on the used design tools, on skills and experience of the designer, nature and complexity of the system, the time available to produce an information system project, etc. In this thesis it is researched how to check consistency paying attention to the used modelling language, methods, designer experience, and tools. Literature-based research demonstrates that the issue of IS models consistency is relevant and dealt with in many studies. The analysis of the related researches shows that approaches of checking IDEF or UML models may be divided into two groups. The first group of approaches is based on translation of different aspects models into formal models, expressing constrains in the same formal language as well and using a reasoning mechanism of a formal system for detecting inconsistencies.

1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... 39

The main advantages of these approaches are: • formal models are more precise than semi-formal models; • ease of check consistency – availability of inconsistency detection algorithms of formal systems and inference engines of a design tool that implement these algorithms; • most methods check consistency because constraints are defined among different aspect models. The main disadvantages of these approaches are: • a formal language is not popular in practice. Formal models are often not sufficiently understandable for software engineers; • the analysed approaches do not prove that translation from semi- formal models to formal models is correct and that information is not lost. Moreover, a formal language has to be able to reflect all constructs of a semi-formal language; • model translation from one language to another language requires additional time. The second group of approaches is based on constrains that are used for checking UML and IDEF models. In case of checking IDEF models forehand it is necessary to translate IDEF models to UML models in order all aspects models should be joined by the same metamodel (Specifications of IDEF are not in- terconnected directly). The main advantages of these approaches are: an original semi-formal model is checked (translation to other language is not necessary); semi-formal IDEF, UML or other models are widely used. However, most methods from this group use constrains only on one aspect models. Several approaches allow checking consistency. For example, the approach proposed by Egyed (2007) uses some constraints among different aspects models. But the defined consistency rules are hard coded to UML Analyzer tool. Apart from the checking paradigm, algorithm of checking consistency is undisclosed. We give special attention to consistency of different aspects UML models; therefore, consistency rules from all analysed studies were researched in detail. Analysis of consistency rules shows that most rules are expressed in a natural and formal language. Rules expressed in a natural language may be interpreted ambiguously. Formal rules usually use their own description of UML models. Therefore, it remains unclear what elements of OMG UML metamodel they conform to. Moreover, some consistency rules do not conform to OMG UML metamodel, and their practical necessity is doubtful. To sum up the existing researches, it is evident that the issue of semi-formal models consistency is relevant. The above mentioned disadvantages of the re-

40 1. CONSISTENCY OF DIFFERENT ASPECTS MODELS ... lated studies indicate that there is a need to improve the approaches of consistency checking. The analysis of UML design tools demonstrates that most of them allow developing models that do not conform to UML metamodel. It means that consistency rules have to associate metaelements from different aspects models despite the fact that they are directly associated in metamodel.

2. Consistency Checking Method of Different Aspects Models of the Information System

In this chapter we describe the proposed method for consistency checking of IS different aspects models. The structure of the method description is provided as follows. It starts with the description of the proposed general framework of enterprise models from consistency perspective. Then it is continued by the description of the approach on consistency checking of IS models and the proposed structure of consistency rules specification (it reveals the requirements for consistency rules). Further chapters explain specialization of the proposed approach to UML models and provide several proposed consistency rules. The final subchapter presents the proposed method considering its beforehand presented fragments. The main parts of the method are the following ones: Application of the method of IS models consistency checking for a specific semi-formal modelling language. The process of creating consistency rules specification. The process of consistency checking of IS models. Evaluating consistency of IS models.

41 42 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Certain parts of the chapter were published in scientific articles of Vasile- cas, Dubauskaite and Rupnik (2011), Vasilecas and Dubauskaite (2009), Du- bauskaite and Vasilecas (2010), Dubauskaite, Vasilecas and Saulis (2009).

2.1. General Framework of the Models from Consistency Perspective

A review of the existing literature indicates a wide variety of consistency definitions. Sometimes a term of consistency is used for expressing conformance of diagrams, sometimes of models. In this section the author of the dissertation suggests a general framework of models in business, information and software systems. These levels of a system are presented in detail by Caplinskas, Lu- peikiene and Vasilecas (2002). The key purpose of this proposal is to provide more clarity to the concept of consistent models, emphasising IS models relationships with consistency, aspect models and diagrams concepts.

Fig. 2.1. Horizontal, evolution and vertical consistency of information system models

Figure 2.1 illustrates the place of horizontal, evolution and vertical consistency in IS models graphically. Definitions of different types of consistency are provided in Chapter 1.1.5. It should be noted that all horizontal relationships of models are not displayed for the reasons of clarity. IS has several different aspects models. If an enterprise is modelled using IDEF, then aspects are function, data, process, etc. If it is used, any modelling framework categorization of aspects can be different, e.g. Zahman framework is independent of a specific modelling language, and aspects are data, function, network, people, time, and motivation (business rules). The authors (Bajec et al.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 43

2003; Bajec and Krisper 2005) propose a method how to keep a motivation aspect model (business rules) at the business level in line with the rules that are implemented at the system level. Developing models of a higher level is based on lower level models. Every aspect model can be visualised by several different diagrams. Every diagram is based on a model. It means that if a model is consistent, a diagram is consistent as well. Therefore, the main issue is to ensure consistency of IS models. The presented general framework of IS models enables clear conception of horizontal, vertical and evolution consistency of IS model and diagrams. In this work we focus on horizontal consistency of IS models. To make our dissertation more concise, we use a term “consistency“ instead of a term “horizontal consistency“. The next chapter presents the suggested approach for consistency checking of information system models.

2.2. Proposal for Consistency Checking of the Different Aspects Models and Requirements for Consistency Rules

Having carried out the analysis of ensuring consistency of IS models, we arrived at two main conclusions. Firstly, it is worth improving methods of checking IS models consistency based on consistency rules of a semi-formal model compared to the methods based on translation of a semi-formal model to a formal model and on inference mechanism of a formal language. It should be noted that a semi-formal model is defined by OMG (2007) as a model that is expressed by using a language which syntax is expressed formally, but semantic is presented implicitly, usually in a natural language. The usage of semi-formal languages is useful for modelling information systems because these languages are more understandable in comparison with a formal language and more precise in comparison with natural languages. Additional activities of IS semi-formal model translation to the formal specification require additional time, and, moreover, methods do not prove the correctness of translation. Secondly, using consistency rules may allow detecting conflicts of models consistency; however, the analysis of the related researches reveals that most rules are ambiguous, do not conform to OMG UML metamodel and they are sometimes meaningless. Therefore, that has negative impact on reusing rules and developing a more comprehensive set of rules. Consequently, it is necessary to improve the specification of consistency rules.

44 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

According to the results obtained during the analysis of the related researches, a method of checking consistency of semi-formal different aspects IS models is proposed.

Structure of detailed description of consistency rule its associations with metamodel of modelling language Four modeling Four layers of OMG of layers

Fragment of EMOF +nestedPackage 0..* NamedElement 0..1

+nestingPackage Package +owningPackage +packagedElement (metametamodel) PackagableElement 0..* +ownedType 0..1 0..* 0..1 +package TypedElement +type Type

M3: model of a model of a model a of model a of model M3: +typedElement 0..* 0..1 StructuredFeature Classifier +memberEnd +assosiation

+class +ownedAttribute 2..* 0..1 Property Association Class 0..1 0..* +owedEnd +owningAssociation

0..* 0..1

«instance» «instance» «instance» «instance» {xor} {xor}

Structure of detailed description of consistency rule Simplified metamodel of (metamodel) Consistency rule in Metamodel modelling langauage natural language independent 1 level MetaElement uses is detailed

M2: model of a model model a of model M2: 2..* 1..* has Description Metamodel 1..* Structured contains 1 1 0..* consistency rule specific 1..* level 1 is formalized Rule Origin Scope of validity Package for different aspect model 1 Formal/program Enforcement Formal consistency has code rule (e. g. OCL) 1 1 level «instance» level

is visualized by 1 Diagram «instance» 1..* Instance of IS different aspect model

M1: model M1: consistency rule 2..* is checked according to 0..* 1..* is expressed in 1 Information system

M0: system M0: Fig. 2.2. Structure of detailed description of consistency rule its associations with metamodel of modelling language

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 45

The main ideas of the proposal are the following ones: 1. Check consistency of semi-formal IS models using consistency rules; 2. Define consistency rules among different aspects IS models according to these requirements : 2.1 Define consistency rules at three abstraction levels: metamodel, independent, metamodel specific and formal/program code. 2.2 Verify consistency rules according to a metamodel of modelling language. 2.3 Motivate the necessity of rules defining its origin. 2.4 Assigning enforcement level to consistency rules according to their scope of application. Having achieved that the proposed method would better correspond to the existing OMG standards, it is defined using: Four modelling layers architecture (M0, M1, M2, M3), which OMG uses for its standards, like MDA. The purpose of this architecture is understanding the relationships among various OMG standards (Kleppe et al. 2004). Essential MOF (EMOF), which is one of two compliance points (EMOF and CMOF (Complete MOF)) of MOF (Meta-Object- Facility). MOF is an OMG standard (OMG 2011) that defines the language to define a modelling language. A primary goal of EMOF is to allow simple metamodels to be defined using simple concepts while supporting extensions for more sophisticated metamodelling using CMOF. The idea of modelling is based on three levels applied from OMG MDA (Model driven architecture) standard (OMG 2003). The scheme of the proposal is presented in Fig. 2.2. Description of consistency rule does not belong to metamodel level (it is not metamodel of instances of consistency rules). But it associates elements of metamodel of modelling language (Fig. 2.2).

2.2.1. The Layers of System and Model – Information System and Its Models Checking A model captures a view of an information system. It is an abstraction of the IS, with a certain purpose. This purpose determines what is to be included in the model and what is irrelevant. Thus the model completely describes those aspects

46 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ... of the physical system that are relevant to the purpose of the model, at the appropriate level of detail (OMG 2010a). One aspect models can be visualised by one or several the same type diagrams. The diagrams are designed to provide comprehensive information on the related set of concepts; however, it should be noted that in many cases the representation of a concept in a given diagram displays only a subset of its features (the subset that is relevant in that context). The same concept may appear in multiple diagrams with different feature subsets (OMG 2010a). A consistency rule has to be evaluated on all the model elements of a constrained element kind. It means that consistency of several different aspects models is checked according to instances of consistency rules. In general, a method of ensuring IS models consistency, the processes of IS models checking and removing inconsistencies are presented in our paper (Du- bauskaite and Vasilecas 2009). The following subsection presents the requirements for consistency rules and their specification in details.

2.2.2. Metamodel Layer – Metamodel and Description of Con- sistency Rules Major originality of the proposal is highlighted in dark grey in the Fig. 2.2. MDA architecture is adapted to rules models in order to solve the problems of ambiguity and that the rules would be both understandable and precise. MDA provides an approach for specifying a system independently of the platform that supports it (PIM – Platform Independent Model), dependent on platforms (PSM – Platform Specific Models) and transforming the system specification into one for a particular platform (program code) (OMG 2003). In adapted MDA transformation schema between different abstraction levels a platform is changed to a metamodel. A task of rules transformation is out of scope of our research. How- ever, this issue is analysed in Sosunovas (2008) doctoral dissertation. According to the adapted MDA it is required to model consistency rules in series. Every consistency rule has to be expressed at three levels: metamodel independent, metamodel specific and formal/program code. At the metamodel independent level a rule is expressed in a natural language. It is necessary for general understanding of the rule, even for the developer who has not special knowledge of modelling languages. Rules expressed in a natural language can be interpreted variously. In order to reduce ambiguity it is required to elaborate a consistency rule expressed in a natural language. At the metamodel specific level a structured consistency rule refers to OMG UML metamodel metaelements. It is important to emphasize that it is required to associate metaelements from UML specification developed by OMG because the reviewed related researches show that

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 47

UML models descriptions provided by various authors use different concepts for the same objects. At this level it is also required to define an aspect model, which contains an instance of the associated metaelement. To simplify a metamodel depended rule it is recommended to divide it into two parts. The first part is a rule expressed in a natural language using concepts from a metamodel. The second part of matamodel specific rules shows the associated metamodel elements with a defined aspect explicitly. The third level of a consistency rule is a formal or program code level. It is not mandatory to express a consistency rule in a formal or programming language because formal rules are seldom used in practice. Moreover, a specific program code is usually not provided in the specification. On the other hand, formal rules can be interpreted unambiguously, and program level rules can reduce time of IS development. The process of rules elicitation is described in our papers (Dubauskaite et al. 2008; Dubauskaite and Vasilecas 2009a). Expressing of consistency rule at a metamodel level (M2) makes the consistency rules more usable compared to the rules expressed at a model level (M1) because meta-level constraints are independent from a specific implementation platform (Bajec and Vavpotič 2008). It is necessary to note that at a metamodel level we propose defining only common constraints to different aspect models; meanwhile, domain specific rules are defined for every model of specific IS. More information about domain specific rules are presented in the papers (Va- silecas and Lebedys 2007; Nemuraite et al. 2008; Smaizys and Vasilecas 2009). The authors (Vasilecas, Lebedys 2009) of the research studied the derivation of domain rules from IS models and their usage for data validation. Meanwhile the paper (Nemuraite et al. 2008) presents a method for checking one aspect model based on rules. In order to prove the necessity of a rule, to reduce a number of meaningless rules it is required to provide a description of a consistency rule. The description has to include an explanation of the rule, a definition of its origin and a scope of validity in an implicit way. The origin of the rule can be OMG UML metamodel specification, IS development methods, e.g. RUP, ICONIX, Newton, practical work analysis, etc. The analysis of the existing consistency rules demonstrates that constraint, which is valid, is always too strict in practice. Moreover, consistency rules are defined at a metamodel level, and it means that they are sufficiently general. General rules usually do not include specific cases. Hence there are situations when the detected violations of consistency rules do not mean a consistency conflict. Therefore, it is proposed to define an enforcement level of a consistency rule. It indicates the necessity of reaction (if it is necessary to modify models) to the detected consistency conflicts. If the detected violations of rules show con-

48 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ... sistency conflicts dependent on specific situations, then IS engineer or a knowledge expert can decide whether the situation is inconsistent. A consistency rule can be assigned with one of three enforcement levels that are presented in the following table.

Table 2.1. Enforcement level of consistency rules

Enforcement level of a Type of a message about the consistency rule violation of a consistency rule Low Information Medium Warning High Error

Explanation why one or another enforcement level is chosen has to be provided in the rule description (a scope of validity). Examples of consistency rules specification are provided in Chapter 2.4.2.

2.2.3. Metametamodel Layer – Essential Meta Object Facility According to EMOF, which provides a language to define a modelling language, it is evident that concepts of modelling languages are grouped to packages. One or several packages are usually used to represent one system aspect. In OMG UML specification groups of packages are called language units. A language unit consists of a collection of tightly coupled modelling concepts that provide users with the power to represent aspects of the system under study according to a particular paradigm or formalism. The main elements of a sub-metamodel (in UML language unit) are classes, their properties and associations among them. Association ends have two roles that clarify what roles the class plays in the relationship. Roles and attributes of a class are expressed as a property of that class. In our method it is proposed to define consistency rules on class, properties and associations of the metamodel. The proposal of consistency checking among different aspects models was presented in this chapter. Its formal definition, specialization to UML models and detailed description of the method (algorithm of the usage of the proposal, the process of consistency checking, etc.) are presented in the following chapters.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 49

2.3. Formal Specification of the Proposal

This chapter presents a formal definition of the proposal described informally in Chapter 2.2. A formal specification of a method or a system is a description of a method or a system using a mathematical notation (Bowen 2003). The first advantage of using mathematics is that it is precise, unlike the more ambiguous natural language and diagrams, which are often used for specifications. Secondly, the like- lihood of errors in a design is reduced. Thirdly, formal specification is also read- able enough by a tool. Certainly, a natural language should also be included to give an informal description of the system and to relate the mathematical description to the real world. Finally and most importantly in industry, the overall costs should be lowered. Errors corrected at a design stage can be cheaper to correct than if they are detected later. The main disadvantage of using formal methods is the barrier of the notation, which may contain unfamiliar symbols. More people understand a natural language than mathematics. The specification language must first be learned, and then experience in its use needs to be gained before its full benefits can be attained (Bowen 2003). However, the suggested proposal is expressed in a formal specification because of the presented advantages. Z notation (Bowen 2003) is used to formalize the approach of ensuring consistency of IS model. The Z notation is intended for the formal specification of computer-based systems. It is based on the first order predicate logic and Zer- melo-Fraenkel set theory. Z notation was accepted as the ISO standard in 2002 (ISO/IEC 13568:2002). There is also a special extension of Z formal specification language for modelling object-oriented system. It is called Object-Z (Roger, Rose 2000). Our scheme of proposal does not have classes with methods; therefore, features of standard Z are sufficient for formalizing the proposal. The specification has been created with TOZE tool, which supports standard Z and Object-Z (TOZE 2008). Based on the results of the analysis of the related researches (Bowen 2003; Teltumde et al. 2011; Srichetta 2011, Vasilecas et al. 2008), the author proposes the following expression of the schema on ensuring consistency of IS models (Fig. 2.2): It is important to highlight that this characterization of our proposal includes a simplified specification of a metamodel of a modelling language due to clarity, and it is independent on a specific modelling language. The explanation of the Z notation is not presented in this chapter. State- ments of the Z notation are explained in parallel with the explanation of the formal specification of the proposal for ensuring consistency of IS models.

50 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

SchemeOfEnsuringConsistencyOf_IS_models

∧ CHAR class i: CLAS| i:N class i :P(Z× ) CHAR property i: PROP| i:N property i :P(Z× ) CHAR association i: ASSOC| i,j:N association i : P(Z× ) ⇮ (P(Z× class i) P(Z× class j)) CHAR metaelement i : METAEL| i:N metaelement i : P(Z× ) ∨ ∨ (P(Z× class i) P(Z× property i) P(Z× association i)) ∧ CHAR package i : PACK| i:N package j :P(Z× ) CHAR instance i : INST| i,j:N instance i: P(Z× ) ((metaele- ⇮ ∨ ⇮ ∨ ment i class i) (metaelement i __ property i) (associa- ⇮ ∨ ⇮ tion i metaelement i) (consistencyrule i formalrule i)) ∧ naturalrule i : NRULE| i:N naturalrule j :P(Z×statement i) CHAR detalisation i :DETAIL | i:N detalisation i : P(Z× ) ⇮ ∨ ((naturalrule i structuredrule i) __ ( __ sturcturedrule i ⇮ formalrule i)) sturcturedrule i: SRULE| i,j:N structuredrule i ∧ ∧ :P(Z×statement i) _ (sturucturedrule i→(P(Z× class i) ∨ ∧ ∨ __ P(Z× class i)) (P(Z× class i) P(Z× property j)) ∧ ∨ __ (P(Z× property i) P(Z×property i)) association i) formalrule i: FRULE| i,j:N formalrule i : _ ∧ ∧ P(Z×statement i)_ P(Z×LC) _ P(Z×QUANT) _ description i: DESC| i,j:N decription i :P(Z×statement i) ∧ ∧ __ :(P(Z× rule i) P(Z× origin) P(Z× scope i)) enforcementlevel i: ELEVEL| i:3 enforcementlevel i ∨ ∨ __ :(enforcementlevel i→info warning error) ∧ CHAR model i: MOD| i:N model i :P(Z× ) ∧ CHAR diagram: DIA| i:N diagram i :P(Z× ) consistencyrule i: CRULE| i,j:N consistencyrule i :P(Z×statement i) _instance(formalrule i) ∧ CHAR relation: REL| i:N relation i: P(Z× ) ((metaele- ⇮ ∨ ⇮ ∨ ment i package i) __ (structuredrule i metaelement i) ⇮ ∨ (structuredrule i description i) (formalrule i ⇮ ∨ ⇮ enforcementlevel i) (model i diagram i))

CLASS = {class | i : N} is a set of classes in a metamodel of a modelling language. A class (class i) is a word which consists of a set of a sequence of characters (P (Z × CHAR)). It represents types of IS models elements. Examples of

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 51

4 classes in a UML metamodel are Actor, Use case, Include , etc. N is a set of positive integers. PROP = {property i | i : N} is a set of attributes representing properties of class (class i), like Name, Visibility of NamedElement, isCovering, isDisjoint of GeneralizationSet, etc. It consists of a set of a sequence of characters (P (Z × CHAR)). N is a positive integer which indentifies a count of attributes. ASSOC= {association i | i : N} is a set of classes relationships, such as association, generalization, aggregation, etc. An association (association i) is a function denoting relationships between classes (class i). For example, generalize (BehavioredClassifier, UseCase) means that BehavioredClassifier aggregates UseCase or in other words UseCase implements all features of BehavioredClas- sifier, compose (UseCase, Include) means Include is a part of UseCase, and consistency exists without it. These relations are represented graphically in Annex A. METAEL= {metaelement i | i : N} is a set of specific classes (class i), properties (property i) and associations (association i). A metaelement (metaelement i) can be one of three types: class, property or association. PACK={pack i | i : N} is a group of classes (class i) in a metamodel of a modelling language. Package is usually created according to the aspect of the model, for example UseCases, StateMachine. Package can consist of several subpackages, e.g. Interactions package includes BasicInteractions and Frag- ments. It is necessary to note that sometimes a higher level package is called a language unit. INST= {instance i | i : N} is a set of relationships of a class and its instance, for example all metaelements of UML are instances of MOF. An instance (instance i) is a function denoting relationships between the class and the instance. NRULE= {naturalrule i | i : N} is a set of constraints among different aspect models. The rule (naturalrule i) consists of a combination (set) of statements. DETAIL= {detalisation i | i : N} is a set of relationships between less and more detailed elements. A detalisation (detalisation i) is a function denoting relationships between two elements with different granularity. In this case naturalrule i is detailed by structuredrule i; or structuredrule i is detailed by formalrule i. SRULE = {structuredrule i | i : N} is a set of constraints between classes (class i); or class (class i) and property (property i) of another class; or properties; or on association (association i) of metaelements (metaelement i) from different aspect models (model i). FRULE = {formalrule i | i : N} is a set of statements, which are connected by logical connectivities (LC) and quantifiers (QUANT).

4 In the UML SuperStructure specification (OMG 2011b), the included relationship defines that a use case contains the behaviour defined in another use case.

52 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

DESC = {description i | i : N} is a compilation of descriptions of the rule (P(Z× rule i)) and origin (P(Z× origin i)) and scope of validity of the rule (P(Z× scope i)). ELEVEL = {enforcementlevel i | i : 3} can have one of three values: info, warning or error. MOD = {model i | i : N} is a set of different aspects models. Model (model i) is a title of an aspect model, which consists of a set of a sequence of characters (P (Z × CHAR)). Examples of models in a UML metamodel are useCase, statesModel model, etc. N is a positive integer, which indentifies a count of models. Elements of one model are usually grouped to package. DIA = {diagram i | i : N} is a set of diagrams. Diagram (diagram i) is a title of a diagram which consists of a set of a sequence of characters. Examples of diagrams in a UML metamodel are useCase, statesModel model, etc. CRULE= {crule | i : N} is a set of instances of consistency rules (formalrule i). REL= {relation i | i : N} is a set of relationships. A relation (relation i) is a function denoting relationships between classes: metaelement and package; or a structured rule and metaelement; or a structured rule and description; or a formal rule and enforcement level; or a model and diagram.

A method not related with a specific modelling language of ensuring consistency of IS models can be applied for: semi-formal modelling languages that allow modelling different aspect of IS (e.g. UML, IDEF); or methodologies of IS modelling that include various aspects of semi- formal models (e.g. RUP, STRADIS). The following chapter explains the application of the proposal for consistency ensuring of UML models.

2.4. Approach on Consistency Checking Information System Models, Expressed in Unified Modelling Language

The process how to apply the proposed method to specific IS modelling language is described in Chapter 2.5.1. When applying the proposal for checking consistency of IS models (Fig. 2.2) to specific models the main task is a definition of consistency rules on metaelements. In this chapter several consistency rules on metaelements from UML metamodel are provided. In Chapter 1.2.2 it is explained why models, expressed in UML, are worth paying attention to.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 53

UML metamodel is defined by two OMG UML specifications. OMG UML Infrastructure specification defined general constructs required to UML. In this case OMG Superstructure specification (OMG 2010a) is actual for consistency rules definitions because it provided specific metaelements for different aspect models. The adapted Querlat‘s and Teniente‘s (2008) concept of an aspect model is used in this research. An aspect model involves elements that can be visualised by several diagrams of the same aspect. In UML 2.3 there are 14 different types of diagrams. The main of them are a class, activity, use case, state machine, sequence, etc. Metaelements for modelling the same aspect of the system are usually contained in several packages that are called a language unit that provide users with the power to represent aspects of the system under study according to a particular paradigm or formalism. For example, the Activities language unit provides for modelling behaviour based on a workflow-like paradigm, while the State Machines language unit enables modellers to specify discrete event-driven behaviour using a variant of the well-known statecharts formalism. The State Machines language unit consists of two packages: State- Machines::BehaviorStateMachines and StateMachines::ProtocolStateMachines . According to the proposal, consistency rules among different aspects models are expressed at three levels. The third level is formal/program code. There- fore, prior to writing specification of consistency rules, languages for expressing formal rules or/and program code have to be selected. We propose expressing consistency rules of UML models in OCL or any programming language, e.g. java: Simple checking rules have to be defined in a formal OCL 2.0 language (OMG 2006). If a rule is not violated, then the OCL constraint has to give an answer “true”. If a consistency conflict is detected, the result of checking according to the rule expressed in OCL should be “false”. More advanced rules can be expressed in java or other program code. Binary is usually used for the more advanced expressions, which are not easily specified in OCL (MagicDraw 2011). The main reasons for selecting OCL are: OCL is part of UML. According to OMG OCL, specification Object Constraint Language is used to describe expressions on UML models (OMG 2006). Well-formedness rules that are part of UML specification are specified in OCL. OCL is a formal language. It means the constraints may be interpreted unambiguously.

54 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

OCL may be used in design5 tools (No Magic MagicDraw6 17.0, Sparx Enterprise7 Architect 6.5 , Altova Umodel 2010 , VisualParadigm 7.0 ) for checking models. Specified rules are implemented and used for checking specific UML models. Therefore, prior to specifying rules, assumptions about UML models are presented.

2.4.1. Requirements for Models Expressed in Unified Modellig Language The requirements for UML models are assumptions about the models that they should conform to. The following requirements are necessary only for the rules defined in the subchapter. The requirements for UML models: 1. Information system has to be modelled in the aspects of use case, class, activity, sequences and states using OOAD method presented by Bennet et al. (2010). Note. OOAD also includes component and implementation aspect models, but they are out of scope of our research. The goal of pro- posing consistency rules is to illustrate the application of the proposed approach but not to provide a complete set for rules. 2. UML models have to conform to UML 2.2 specification (OMG 2009). Note. This requirement is derived from the first requirement. 3. Every element of a model has to be represented at least in one diagram. If an element is not used in any diagram, there is a large prob- ability that it is unnecessary. Therefore, sometimes the concepts of a model and a diagram are used as synonyms. 4. UML models may have consistency conflicts. It means that not all detected consistency conflicts have to be fixed. Several consistency conflicts, especially with a low enforcement level, may be tolerated by IS developer. The following chapter presents several consistency rules to illustrate the application of the approach.

5 6 www.sparxsystems.com 7 www.altova.com/umodel.html www.visual-paradigm.com/product/vpuml/

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 55

2.4.2. Consistency Rules of Models, Expressed in Unified Modelling Language The chapter presents several proposed consistency rules to check consistency of UML models. The rules constrain the metamodel of UML. The examples of rules are defined for the main UML aspect models: Class, Activity, Se- quence/Communication, UseCase, and Protocol State Machine. Sequence and Communication models are grouped to one group because the purpose of both of them is to model the interaction of objects. It should be noted that in UML 2.2 four kinds of models belong to the interaction group: timing, sequence, interaction overview, and communication. Timing and interaction overview models are outside the scope of the research (see the requirements for UML models that are presented in Chapter 2.4.1).

Table 2.2. Metaelements associated by consistency rules

Interaction Protocol (Sequence/ Use Model State Activity Case Machine Communica- tion)

Metaelement

Context ProtocolTransition Interaction Lifeline Message Activity ActivityPartition Case Use Actor Class R2 R3 R10 Operation R1 R5 R9 Visibility of Opera- R6 Class tion isAbstract R4 navigableOwnedEnd R7 Interaction Interaction x x x R12 (Sequence/ Lifeline x x x Communica- tion) Message R8 x x x Activity x x R9 Activity Activity Partition x x R11

56 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

The suggested set of rules is incomplete; the main goal is to illustrate how to apply the proposed approach to the concrete modelling language. The associated elements of different aspects models by consistency rules are presented in the following table. Rule ID is showed in intersection of the row and column that present the associated elements. According to the proposed approach, a consistency rule is defined among the elements from different aspect models; therefore, intersection of the elements from the same aspect model is marked by x in Table 2.2. The proposed consistency rules among different aspects models elements are presented in detail in the next sections. Consistency Rules for Class and Protocol State Models Examples of consistency rules among Class and Protocol State models are provided below. Consistency rule R1 constrains the protocol state model, and it requires defining transition of states by specifying operation, which execution causes changes of the state. Figure 2.3 bellow shows the elements of UML metamodel for IS Class and Protocol State Machines models that are associated by consistency rule R1. Dashed lines with arrows present relationships of UML metamodel and IS model. Elements of different aspect models associated by consistency rule R1 are shown using a dashed line without arrows.

Fig. 2.3. Fragments of the metamodel for class model and protocol state machine

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 57

Table 2.3. Description of consistency rule 1

Consistency rule ID R1 Rule at a metamodel inde- Transition from one class state to another state can pendent level be caused by calling operation of the class. Rule at the Rule Protocol transition of protocol state model has to be metamodel defined by operation of the class model. specific Associated Operation of ProtocolTransition of Pro- level metaelements Class model tocol State Model Enforcement level Medium Description According to OOAD, significant changes of the state of the object are modelled using state diagrams (Bennet et al. 2010). There are two types of state models: protocol state and behaviour state machine models. A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier can be called and in which state (OMG 2009). According to the UML metamodel, which part is in Fig. 2.3, operation is not mandatory for protocol transition. But in practical situations it is necessary to know what operation execution causes the transition of states. Having analysed OOAD UML metamodel specification (OMG 2009) and specific information system models (MSISD 2009a, MSISD 2009, MSISD 2010), we arrived at the conclusion that it is necessary to define an operation, which determines movement of an object from one state to another state. The transition can be also caused not only through execution of an operation (it is activated by call event) but also by other events, e.g., time, creation, destruction, signal. Therefore, an enforcement level of this rule is medium.

Note. State machines can be used for describing states not only of classes but also the behaviour of other model entities such as use-cases, actors, subsystems, operations, or methods (MagicDraw 2011a). Hence the protocol state model is a specific case of the state machine.

Consistency rule R1 may be expressed formally as OCL invariant: context ProtocolTransition inv ProtocolTransition_notDefined: self.refered->notEmpty()

58 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

R2 constrains a protocol state machine. It requires defining the class which states are modelled.

Table 2.4. Description of consistency rule 2

Consistency rule ID R2 Rule at a metamodel inde- The class which states are modelled has to be known pendent level in the Protocol states model. Rule at the Rule Context of protocol states has to be defined by the metamodel class. specific Associated Context of Protocol Classifier of Class model level metaelements State Machine Enforcement level High Description A protocol state machine presents possible and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions (OMG 2009). Only classifier of a class has operations; therefore, it can be derived that a protocol state machine is used to model states of classes. In this manner context – the class, which operations can be called, and their execution that determines changes of states of the object have to be defined. The origin of this constraint is the analysis of UML superstructure specification provided by OMG (OMG 2009) and OOAD method, which in- troduce that OOAD method. According to OOAD, significant changes of the state of the object (described by the class) are modelled using state diagrams (Bennet et al. 2010).

The metamodel level consistency checking rule ID2 constrains Protocol- StateMachine and is expressed as OCL invariant: context ProtocolStateMachine inv protocolStates_without_context: self.oclAsType(StateMachine).region.context-> notEmpty()

Figure 2.4 demonstrates the elements of UML metamodel and IS models, associated by consistency rule R2.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 59

Fig. 2.4. Fragments of the metamodel for protocol state machine and class model

Consistency Rules for Class and Sequence Models Examples of consistency rules between Class and Sequence models are described below.

Fig. 2.5. Fragments of the metamodel for sequence and class models

60 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.5. Description of consistency rule 3

Consistency rule ID R3 Rule at a metamodel inde- Type of the object used in Sequence model has to be pendent level defined in Class model. Rule at the Rule The type of lifeline should be specified. metamodel Associated Class of class model Type of Lifeline specific metaelements level Enforcement level Medium Description Having identified classes, interactions of these objects have to be specified precisely (Bennet et al. 2010). (Object is the instance of a class). Object existence at particular time is represented by lifeline. Interaction of objects with an emphasis on time is captured by Sequence model. The rule requires defining a class (type) of the object (represented by lifeline). Type of lifeline shows an associated class. When matching a class is known, then it can be checked: whether the message of lifeline has associated operation of class ( Inv1 ); whether the called message has public visibility (only public operations can be called by other objects) ( Inv2 ), and etc. We derived consistency rule R3 concluding the results of the analysis of IS OOAD method, UML metamodel specification and MagicDraw UML tool. The constraints ( Inv1 and Inv2 ) are implemented in MagicDraw UML tool. They illustrate the necessity of our proposed consistency rule R3. According to the UML metamodel (Fig. 2.5), lifeline may be associated or not associated with a class (a class is type of an object). Therefore, violation of consistency rule R3 should be a warning (enforcement level – medium) but not an error. Sometimes lifeline may be associated with web application that does not have a corresponded class in a class model.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 61

Consistency checking rule R3 may be expressed in OCL: context Lifeline inv lifeline_without_type: not self.represents.type.oclIsUndefined() The second example of a consistency rule for interaction and class models is presented in the following table.

Table 2.6. Description of consistency rule 4

Consistency rule ID R4 Rule at a metamodel inde- Abstract class cannot be instantiated in a sequence pendent level model. Rule at the Rule Type of Lifeline in Sequence/Communication model metamodel cannot be a class that is Abstract. specific Associated Type of Lifeline of Se- Class of Class level metaelements quence/Communication model model Enforcement level High Description In OOAD method, it is mentioned that an abstract class has no instances (Bennet et al. 2010). This requirement also conforms to the metamodel of UML. According to UML Superstructure specification (OMG 2009), a Classifier from UML Kernel package has an attribute isAbstract. If the value of attribute isAbstract is true, it means the Classifier does not provide a complete declaration and can typically not be instantiated. A class inherits features of classifiers because Classifier is a superclass of Class. Therefore, Class also has an attribute isAbstract, and the requirements for an abstract class may typically not be instantiated.

Fig. 2.5 illustrates what and how metaelements of the rule are associated. They (metaelements) are used in the following OCL expression, which defines the R4.

context Lifeline inv abstract_class_instantiated:

not self.represents.type.isAbstract = #true The next example of a consistency rule associates a message and an operation.

62 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.7. Description of consistency rule 5

Consistency rule ID R5 Rule at a metamodel inde- Call Message of an object has to be associated with pendent level Operation of a class. Rule at the Rule Message, which is caused by CallEvent, should have metamodel an operation assigned. specific Associated Operation of Class Message of Interaction level metaelements model model. Enforcement level High Description According to OOAD, Message specifies the sender and receiver objects and the actions of stimulus (Bennet et al. 2010). An object is represented by Lifeline in a sequence diagram.

A Message may correspond8 to calling an operation or raising a signal (Bennet et al. 2010), e.g. creating or destroying an Instance (MagicDraw 2011a). When a Message represents an Operation invocation, the arguments of the Message are the arguments of the CallEvent occurrence on the receiving Lifeline. A call event may cause the invocation of a behaviour that is a method of the operation referenced by the call request, if that operation is owned or inherited by the classifier that specified the receiver object (OMG 2009). Hence, the origin of this rule is OOAD method (Bennet et al. 2010) and UML Superstruc- ture specification (OMG 2009). According to it, which fragment is provided in Fig. 2.6, CallEvent may have only one operation assigned. Therefore, the enforcement of this rule is high. If Call Message is created, it is required to refer its operation of Class.

A small excerpt of UML metamodel provides metaelements used in OCL expression of the rule:

8 Signal is an asynchronous communication that may have parameters (Bennet et al. 2010)

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 63

context Message inv callmessage_without_operation: ((not receiveEvent.oclAsType (MessageOccurrenceSpecification).event. oclIsUndefined()) and (receiveEvent.oclAsType (MessageOccurrenceSpecification.event. oclIsTypeOf(CallEvent))) implies not receiveEvent.oclAsType (MessageOccurrenceSpecification). event.oclAsType(CallEvent). operation.oclIsUndefined()

Message 0..1 0..1 MessageEnd OccurrenceSpecification /messageKind : MessageKind +sendEvent * messageSort : MessageSort 0..1 0..1 1 +event +receiveEvent Event MessageOccurrenceSpecification

MessageEvent

Operation +operation CallEvent 1 *

Fig. 2.6. Metaelements used in a formal consistency rule 5

The metamodel level constraint will check all lifelines of Interaction model if they do not violate the rule. In case consistency conflict is detected, the result of invariant is false. The following rule is also related to call message of lifeline that refers to operation of the class. Private operations cannot be called from a foreign class. This consistency relationship between the operation of a class in a class model and a message of lifeline in an interaction model is expressed by the following consistency rule.

Table 2.8. Description of consistency rule 6

Consistency rule ID R6 Rule at a metamodel inde- Visibility of operation, which is assigned to Call pendent level Message, has to be not private.

64 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.8. (continued)

Rule at the Rule Visibility of operation, which is assigned to Message metamodel that is caused by Call Event, has to be not private. specific Associated Visibility of Operation Message of Interaction level metaelements of Class model model Enforcement level High Description Visibility determines whether other classes or objects can use a particular field or invoke a particular method. E.g. protected visibility of operation or variable means that the element is accessed within its own packages and, in addition, by a subclass of a class in another package (Koffman, Wolfgang 2010). Private visibility means that the element may only be used by the class which it belongs to (Bennet et al. 2010), a class cannot access private features of another class (OMG 2009). When the message in a sequence model is caused by CallEvent, then the message has to be assigned with the operation (see the previous consistency rule R5). Consequently, it is natural to require that a call message of an interaction model would be assigned with not private operation of a class model, because a sender object calls message from another object.

Constraint for Message can be expressed as OCL invariant: context Message inv private_operation_call: let sourceLifeline:Lifeline = self.sendEvent.oclAsType (MessageOccurrenceSpecification).covered->any(true) in let targetLifeline:Lifeline=self.receiveEvent .oclAsType(MessageOccurrenceSpecification).covered ->any(true) in (sourceLifeline <> targetLifeline) implies (let sourceType:Type = sourceLife- line.represents.type in let targetOperation:Operation =self.receiveEvent.oclAsType (MessageOccurrenceSpecification).event.oclAsType (CallEvent).operation in (not sourceType. oclIsUndefined() and not targetOperation. oclIsUndefined()) implies ((targetOperation. visibility <> VisibilityKind::private) or (targetOperation.UMLClass = sourceType)))

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 65

Some fragments of the UML metamodel that are important for defining this consistency rule are provided in the following figure. 1 Lifeline * OccurrenceSpecification +covered * NamedElement

TypedElement

0..1 +represents * ConnectableElement 0..1 +type Type

Message 0..1 0..1 MessageEnd +sendEvent /messageKind : MessageKind 0..1 0..1 messageSort : MessageSort +receiveEvent

<> NamedElement MessageOccurrenceSpecification VisibilityKind Name : String [0..1] visibility : VisibilityKind [0..1] public private +event protected MessageEvent Event package 1

+operation Operation CallEvent 1 *

Fig. 2.7. Fragments from the metamodel that are important for consistency rule 6

In order one class could call operations of other classes several requirements have to be fulfilled; for example, communication should be allowed by visibility, associations, multiplicity, and others. The following consistency rules express the requirement that a message of lifeline of the sequence model would conform to the association direction in class model. The metamodel elements that are used for getting source lifeline, target lifeline, for navigating from lifeline to called messaged and assigned operation are provided in Fig. 2.7. Other metaelements used in this rule are provided in figure 2.8.

66 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.9. Description of consistency rule 7

Consistency rule ID R7 Rule at a metamodel inde- Calling direction of a message has to conform to the pendent level direction of association. Rule at the Rule Operation, which is assigned to Message that is metamodel caused by Call Event, should be navigableOwne- specific dEnd. level Associated navigableOwnedEnd of Message of Interaction metaelements Association in Class model model Enforcement level High Description An association is a connection between two classes that represents the possibility of their instances participating in a link (Bennet et al. 2010). Object is the instance of a class. Objects can interact with each other by calling messages that have to conform to operation of the class (see consistency rule R5). Consequently, messages are relationships between objects (OMG 2009). (Note. Link in OOAD conforms to relationship in UML specification). Therefore, calling direction of a message has to conform to the direction of association.

A property related to an Association by memberEnd or its specializations represents an end of the association. memberEnd represents participation of instances of the classifier connected to the end in links of the association. owningAssociation references the owning association of this property. navigableOwnedEnd represents the navigable ends that are owned by the association itself. An end property of an association that is a navigable owned end of the association indicates that the association is navigable from the oppo- site ends. An open arrowhead on the end of an association indicates that the end is navigable. A small x on the end of an association indicates that the end is not navigable. An association with neither end marked by navigability arrows means that the association is navigable in both directions (OMG 2009).

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 67

Fig. 2.8. Fragments from the metamodel that are important for consistency rule 7

The consistency rule R7 can be expressed by the following OCL:

context Message inv not_navigable_operation_call Property::isNavigable(): Boolean isNavigable = not classifier->isEmpty() or association.owningAssociation. navigableOwnedEnd->includes(self) Let openend: AssociationEnd=self.endData-> selected(ed|ed.value->size()=0)->asSequence()->first().end in opened.isNavigable() Consistency Rule for Interaction and Protocol State Model Models An example of a consistency rule for Interaction and Protocol State models is described below.

Table 2.10. Description of consistency rule 8

Consistency rule ID R8 Rule at a metamodel inde- A sequence of object messages has to be allowed by pendent level a protocol state model of the corresponding class.

68 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.10. (continued)

Rule at the Rule A sequence of messages of objects has to be allowed metamodel by a protocol state machine of the corresponding specific class. level Associated Sequence of Messages of Sequence of Protocol- metaelements Sequence/Communication Transitions of Protocol model State model Enforcement level Medium Description Movement from one state to another is called a transition, and it is triggered by an event. Hence, an event is occurrence of a stimulus that can trigger a state change and that is relevant to the object (in case of ProtocolTransition of Protocol State model), or to application (in case of Transition of ProtocolState model). Transition can be specified by defining an event, a guard condition (not mandatory) and an action (not mandatory). A guard transition is only evaluated at the moment that its associated event is fired. An event can have parameters and a return value, and in the object-oriented system it is implemented by a message. Every event should appear for the appropriate object of the interaction diagram. (Bennet et al. 2010). Order of the invocation of messages and the legal transitions that a classifier can trigger is expressed in protocol state machines (OMG 2009). Consequently, a sequence of object messages has to be allowed by a protocol state model of a corresponding class. The enforcement level of this rule is medium because not all messages have correspondent Proto- colTranstion in a protocol state model.

Consistency Rules for Use Case, Activity and Class Models Examples of consistency rules for Use Case, Activity and Class models are described below.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 69

Table 2.11. Description of consistency rule 9

Consistency rule ID R9 Rule at a metamodel inde- Activity diagram has to be associated with a use case pendent level that behaviour it (activity) explains or with operation that it detailed. Rule at the Rule Activity has to be associated with a corresponding metamodel use case or operation. specific Associated Activity of Use case of Use case model level metaelements Activity model or Operation of Class model Enforcement level Medium Description Activity diagrams can be used to model a system function represented by a use case. They can be also used at a low level to model the detail of how a particular operation is carried out (Bennet et al. 2010). Therefore, it is required to associate an activity diagram with the use case or operation of the class. Sometimes more complicated actions of an activity model can also be detailed by an activity diagram (Hay 2011). Therefore, the enforcement of the rule is medium.

+subject *

Classifier BehavioredClassifier +nestedClassifier * RedefinableElement Actor

* +useCase ExtensionPoint +extensionPoint +useCase UseCase * 1 0..1 +class Behavior NamedElement Class +superclass * Activity +activity +node ActivityNode * 0..1 *

+class +ownedOperation Operation Action 0..1 *

Fig. 2.9. Part of the metamodel used by consistency rule 9

70 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

UML metamodel elements on which constraint R9 is defined, and the main related metaelements are provided in Fig. 2.9. Examples of consistency rules between Class and Use Case models are described below.

Table 2.12. Description of consistency rule 10

Consistency rule ID R10 Rule at a metamodel inde- Class has to define what data about an actor of a use pendent level case model has to be saved. Rule at the Rule Actor of Use case model has to be associated with metamodel Class of Class model. specific Associated Class of class model Actor of Use Case model level metaelements Enforcement level Medium Description Class diagrams are used to describe objects. Objects can be physical, such as computers, people or abstract, such as information or knowledge. Nouns in the documents of an enterprise are a preliminary class (Eriksson, Penker 2000). Names of actors are nouns. Actors perform processes and usually it is necessary to know, to save data about an actor (Filev et al. 2003; Bennet et al. 2010). For example, what a client provides a request for a room, what the administrator confirms the reservation, etc. Having analysed real practical information systems models (MSISD 2009, MSISD 2009a, MSISD 2010) and the related literature, we arrived at the conclusion that there is a medium possibility that an actor of a use case model has a corresponding class in a data model. The possibility of this relationship is medium because there are actors about which the data are not gathered, for example, an unregistered user.

The fragments of UML metamodel are provided in Figure 2.10. The main elements, associated by the rule are highlighted with grey shadow. These elements do not have direct relationship in UML metamodel. The figure also shows the context of associated elements for clarity.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 71

BehavioredClassifier

RedefinableElement Actor Classifier

+nestedClassifier +extensionPoint * ExtensionPoint +useCase UseCase * 0..1 +class StructuralFeature Class Relationship +superclass *

* +subsettedProperty Association Property +memberEnd +association * isDerived : Boolean * isDerived : Boolean 2..* 0..1 isReadOnly : boolean isDerivedUnion : Boolean +ownedEnd +owningAssociation +class +ownedAttribute /default : String agregation : AggregationKind * 0..1 0..1 +redefinedProperty* /isComposite : Boolean +navigableOwnedEnd 0..1 * * * +OwningProperty 0..1 ValueSpecification 0..1 +defaultValue * +/endType 0..1 0..1 +oposite <> 1..* AggregationKind Type +class +ownedOperation Operation none shared 0..1 * composite

Fig. 2.10. The metaelements that are used in consistency rule 10

A fragment of UML meta-model on which rule R11 is defined is represented in Figure 2.11.

RedefinableElement BehavioredClassifier Classifier +subject * 0..1 Actor * +useCase +ownedUseCase * +extensionPoint+useCase ExtensionPoint UseCase * 1

ActivityGroup NamedElement Behavior

+superPartition 0..1 +partition 0..* * ActivityPartition * Activity +subpartition

Fig. 2.11. The metaelements that are used in consistency rule 11

72 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.13. Description of consistency rule 11

Consistency rule ID R11 Rule at a metamodel inde- Every actor that performs activities in an activity pendent level model has to be defined in a use case model. Rule at the Rule Every ActivityPortition (Swimline in a diagram) in metamodel Activity model has to be associated with the corre- specific sponding actor in Use Case model. level Associated Actor of Use Case ActivityPartition of Activ- metaelements model ity model Enforcement level Medium Description The necessity of this rule is motivated by two reasons: results of analysis of real UML models and OOAD modelling method. According to OOAD, an activity diagram can be used to model a system function represented by a use case (Bennet et al. 2010).The analysis of some thirty use case and activity models developed by VGTU9 Master’s students of engineering informatics (MSISD 2009; MSISD 2009a, MSISD 2010) shows that synonyms of actors are often used in use case and activity diagrams. For example, a customer is in the use case diagram, while a client is in the activity diagram. A customer and a client means the same actor for the designer, but a customer and a client will be different actors for the program; therefore, we get an inconsistent situation. Another example of synonyms used by students is a registrar, an administrator in a hotel system. There are several ways to solve this problem. One of them is using ontology. It allows showing what concepts are synonyms (OMG 2005a; Goncalves, Wat- son, Fox 2008). Another way of solving the problem is using consistency rules to detect this inconsistency. Then a consistency rule, which is described in this table, is necessary. The scope of validity is medium because new actors can appear at a more detailed level (activity diagram), e.g. sub-systems, programs, etc.

9 Vilnius Gediminas Technical University

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 73

Consistency Rule Use Case and Sequence/Communication Models Sequence and Communication (also called Collaboration) diagrams are used for visualizing an interaction model (OMG 2009). An interaction is an important sequence of interactions between objects. The main difference between sequence and communication diagrams is that sequence diagrams show time-based object interaction while communication diagrams show how objects associate with each other (Rational 2003). Examples of consistency rules among Use Case and Se- quence/Communication models are described below.

Table 2.14. Description of consistency rule 12

Consistency rule ID R12 Rule at a metamodel inde- Sequence/Communication diagram has to be associ- pendent level ated with a use case whose behaviour it (interaction diagram) explains. Rule at the Rule Interaction of a sequence or communication diagram metamodel has to be associated with the corresponding use case. specific Associated Interaction of Use case of Use case level metaelements Sequence/ model Communication model Enforcement level Medium Description According to Queralt and Teniente (2008), one use case is detailed with null or many sequence diagrams. Bennet et al. (2010) also stated that sequence diagrams help to identify a detailed level of the operations that are necessary to implement for the func- tionality of operation. Consequently, a sequence diagram, which represents the interaction of objects, has to be associated with a use case. Enforcement of the rule is medium because relationships of a use case and a sequence diagram are not mandatory. According to OOAD method, interaction of objects can be visualized both by a sequence and communication diagram (Bennet et al. 2010). Therefore, the consistency rule constrains sequence and communications diagrams.

The rule R12 requires associating the metamodel elements Interaction of Sequence/Communication model and Use Case of UseCase model (Fig. 2.12).

74 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

NamedElement Behavior * InteractionFragment +fragment 0..1

Interaction OccurrenceSpecification ExecutionSpecification

RedefinableElement BehavioredClassifier Classifier +subject * 0..1 Actor * +useCase +ownedUseCase * +extensionPoint +useCase ExtensionPoint UseCase * 1

Fig. 2.12. The metaelements which are important for consistency rule 12

A set of consistency rules is not complete, its purpose is to illustrate realiza- tion of the proposed approach. More details about our suggested approach and consistency rules are provided in documentation of project “Business Rules Solutions for Information Systems Development“ (VeTIS 2009). The software prototype, which implements our proposed approach and includes examples of consistency rules, is presented in Chapter 3. The following subchapter presents the proposed method (using use cases and activities diagrams) considering its beforehand presented fragments (the structure of the proposal, and a set of consistency rules).

2.5. Description of the Method

The structure of methods for checking consistency of IS models was presented in Chapters 2.2 and 2.3. It was specialised for IS models, expressed in UML (see Chapter 2.4). In this chapter the proposal is elaborated. The usage of the method is presented in Figure 2.13 by use case diagram. The main tasks are “Apply the method of IS models consistency checking to the specific semi-formal IS modelling languages”, “Extend the method of UML models consistency checking”, “Check consistency of IS models”, “Check consistency”, “Remove inconsistencies” and “Evaluate consistency of IS models”.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 75

Usage of the method of IS models consistency checking

Review the struture of detailed description of consistency rule Extended the method of UML Review the process of models consistency checking IS models checking <> Knowledge <> engineer Create the method of consistency checking of Apply the method of IS models IS models consistency checking to the specific semi-formal IS <> modelling language <> Create set of consistency rules Implement the method of IS models consistency checking Software Check consistency of engineer UML models

<> Check consistency of Remove IS models inconsistencies Modelling <> engineer

Evaluate consistency of IS models

Fig. 2.13. Use case diagram of the method

Below in Tables 2.15–2.18 the main use cases are described in more detail. The structure of use case specification can vary, but usually use case name, unique use case ID, actor, brief description, preconditions, main flow, alternative flows and post conditions are included (Armour, Miller 2001; Masciazek 2001).

Application of the IS Models Consistency Checking Method to Specific Semi-Formal Modelling Language The proposed of checking consistency of IS models approach not related with a specific modelling language can be applied to any semi-formal modelling language, e.g. IDEF. The task of application is specified in Table 2.15.

Table 2.15. Application of the method of models consistency checking to specific semi- formal modelling language

Use case name Apply the method for IS models consistency checking to the specific semi-formal IS modelling language Unique ID UC2

76 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Table 2.15. (continued)

Actor(s) Knowledge engineer Brief Knowledge engineer creates a method for checking consistency of description semi-formal models (except UML models because they are included in a separate use case UC1). Preconditions There is a necessity to check consistency of specific semi-formal models. Knowledge engineer has enough knowledge about the specific language. The chosen specific language allows modelling a system from various perspectives. Knowledge engineer knows any formal modelling language. Main flow 1. Examine the method for IS models consistency checking. 2. Collect data about new consistency rules using elicitation methods. 3. Specify rules at a metamodel-independent level. 4. Define elements of a metamodel related by the rule. 5. Specify a rule at the metamodel specific level. 6. Express simpler rules in a formal language. 7. Define the enforcement level of the rule (more information on enforcement levels is provided in Chapter 2.2.2). 8. Explain the necessity, enforcement level (see the step above) of the rule). 9. Repeat 3–8 steps for each rule. 10. If it is necessary, modify the proposed process of IS models checking. Alternative If the selected semi-formal language is UML, then forward to task flows “Extend the method of UML consistency checking”. Consistency rules can be defined on class or/and attribute or/and association of metamodel. Enforcement level of the rule can be low, medium, high. Post conditions The method for checking consistency of IS models expressed in a semi-formal language is created.

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 77

Extension of the Method for Different Aspect UML Models Checking The application of proposed approach of IS models checking of checking consistency of IS models is illustrating applying it to UML. The task how to extend the proposed method for different aspects UML models checking is described in Table 2.16.

Table 2.16. Extension of the method

Use case name Extend the method of UML models consistency checking Unique use case ID UC1 Actor(s) Knowledge engineer Brief description Knowledge engineer adds new consistency rules to method for UML model consistency checking. Preconditions There is a necessity to add new consistency rules to the proposed method for UML models consistency checking. Knowledge engineer has enough knowledge about the UML. Knowledge engineer knows OCL language. The method for UML model consistency checking is developed. Main flow 1. Examine the method for UML model consistency checking. 2. Collect data about new consistency rules using elicitation methods. 3. Specify rules at a metamodel independent level. 4. Define elements of metamodel associated by the rule. 5. Specify rule at the metamodel specific level. 6. Express simpler rules in a formal OCL language. 7. Define the enforcement level of the rule (more information on enforcement levels is provided in Chapter 2.2.2, which presents the requirements for consistency rules). 8. Explain the necessity, enforcement level (see the step above) of the rule. 9. Repeat 3–8 steps for each rule. Alternative flows Enforcement level of the rule can be low, medium, high. Post conditions The method is extended with new rules specification.

78 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Knowledge engineer

Necessity to add new consistency rules to the proposed method of UML Examine the method of UML models models consistency checking consistency checking

[does rule exist unspecfied in detail] Collect data about new rules using elicitation methods [no] [yes] Rules can be acquired Specify rules at metamodel from IS metamodel independent level specifications, IS modelling methods, practical projects etc. Define elements of UML metamodel related by the rule

Specify the rule at metamodel specific level

[is the rule complicated] [no] Express the rule in formal OCL language [yes]

Define the enforcement level of scope of cases when rule the rule allows detecting real consistency conflict, [scope of validity is] which requires changes of models) [often] [seldom] [no] [sometimes]

Assign enforcement Assign enforcement level Assign enforcement level 'high' to the rule 'medium' to the rule level 'low' to the rule

[yes]

Explain the necessity of the rule and Define the origin of [is necessary the selected enforcement level the rule refining of the rule]

Fig. 2.14. Creation of extended method for models, expressed in unified modelling language, consistency checking

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 79

Checking Consistency of IS Models, Expressed in UML or other Semi- Formal Modelling Language

Table 2.17. Checking consistency of models, expressed in unified modelling language

Use case name Check consistency of UML models Unique use case ID UC3 Actor(s) Modelling engineer, System Brief description Modelling engineer activates System (if the method is implemented in a software system) and detects consistency conflicts according to the defined consistency rules among various aspect models. Preconditions Method for UML models consistency checking is created. Method for UML models consistency checking is implemented. Models of IS are created. If MagicDraw UML is used for modelling IS, then the suggested module for UML consistency checking can be used for consistency checking. Main flow Main flow presents the process of UML models consistency checking, which can be/is implemented in UML design tool. 1. Select semi-formal different aspect IS models. 2. Check consistency rule with all instances of the rule. 3. If constraint is violated, append a list of consistency conflicts. 4. Repeat steps 2–3 for all consistency rules. If the method is implemented, steps 2–3 are performed automatically by the system. Alternative flows A consistency conflict can be shown as an error, warning or information message depending on enforcement level of the consistency rule. The proposed consistency rules can be used as recommendations for modelling (not only in automated process of consistency checking). Post conditions Consistency conflicts are detected.

80 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Select IS models, expressed Activate the conistency in UML checking function

Select consistency rule

Check constraint with [is consistency rule violated] [no] instances of elements [yes] <> Create description of consistency conflict

Add constrained Add conistency rule expressed element in natural language

Review enforcement level of consistency rule [enforcement level is] [high] [low]

[medium]

Interpretate Interpretate Interpretate consistency consistency conflict consistency conflict conflict as error as warning as information

Add interpretation of enforcement level

[no] [all consistency rules are checked] Append list of consistency conflicts [yes]

Show list of consistency conflicts

Fig. 2.15. Checking consistency of models, expressed in unified modelling language

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 81

Removing inconsistencies

Table 2.18. Removing inconsistencies

Use case name Remove inconsistencies Unique use case UC4 ID Actor(s) Modelling engineer Brief description Modelling engineer improves consistency of IS model by removing the detected inconsistencies. Preconditions Consistency conflicts are detected. Main flow 1. Review a message of consistency conflicts. 2. Examine if the situation is inconsistent, especially for the violated rules with interpretation of enforcement level ‘warning’ and ‘information’. 3. If the detected conflict is really a violation of consistency, then modify IS models and resolve the inconsistent situation. 4. Repeat steps 1–3 for all consistency conflicts. 5. Finally, it is recommended to execute again task ‘IS models checking’ because changes in IS models can cause new consistency conflicts. Alternative flows If the detected consistency conflict does not call inconsistency in a specific situation, then skip the step of consistency correction. Post conditions The IS models are consistent according to the defined consistency rules.

The task of UC5: “Evaluate consistency of IS models“ is described in the following section. Evaluating Consistency of IS Models In this chapter we provide the proposed approach to evaluate the consistency of IS models. Our proposal focuses on Miller et al. (2009) research which guides how to select an appropriate assessment technique.

82 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

Select semi-formal IS models, which Determine the number of consists of several different aspect models constraints (n)

setup Set total sum of possible Set total sum of actual counts of Set initial rule index counts of violations i-th violations of rules producted by to 1 (i=1) rule to 0 (se=0) i-th rule to 0 (sv=0)

test Compare if value of rule number i is less or equal to total count of rules n (i<=n)

body Count of rule instances (i-th e) setup Define initial i-th rule instance number (j=0)

test Compare if value of i-th rule instance j is less or equal to total count of rule instaces (j<=ei)

body

test Check if j-th rule instance is false according to i-th rule

body

Increase the number of violations of i-th rule ( vi=vi+1)

Product weight of i-th rule and count of violatios of i-th rule vi and add it to previous production (s1=s1+wi*vi) More important rule has bigger weight (higher enforcement Product weight of i-th rule and count of rule instances i-th e and level) add to precious production (s2=s2+wi*ei)

Increase the number of performed rule (i=i+1)

A set of possible values of inconsistency or consistency coefficient is [0..1] The value 1 means that models are consistent according to all defined consistency constrains

Count inconsistency coefficient by dividing Count consistency coefficient actual count of consistency conflicts producted by subtracting inconsistency by weights (sv) from possible count of coeficient from 1 (1-sv/se) violations producted by weights (se)

Fig. 2.16. Evaluation of consistency of information system models

2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS.... 83

Consistency value can be calculated according to formula:

(1) where, C – coefficient of model consistency, n – count of consistency rules; i – consistency rule number (index), v – count of violated consistency rule with index i, e – count of instantiated rules according to consistency rule with index i, w – weight/importance of enforcement of consistency rule with index i, for example: weight of high enforcement level is 3; weight of medium enforcement level is 2; weight of low enforcement level is 1. A set of possible values of consistency coefficient is [0..1]. The value 1 means that the model is consistent according to all defined consistency constrains, while 0 means that all possible consistency conflicts according to consistency rules occur. A lower value of consistency coefficient means bigger inconsistency. The process how to evaluate the consistency of IS models is presented in Fig 2.16.

2.6. Conclusions for Chapter 2

In Chapter 2 the author presented a method for checking consistency of IS models using consistency rules. The following main 3 results were obtained in the chapter. Firstly, the scheme of the proposal is defined using 4 modelling layers architecture of OMG: 1. IS models consistency checking according to instances of consistency rules (M0-sytem, M1-model layers). 2. The structure of detailed description of consistency rules (M2 – metamodel layer) and requirements for consistency rules. The main contribution is: 2.1 A proposal of assigning consistency rules with enforcement levels. 2.2 The requirement to verify rules according to the metamodel of a modelling language.

84 2. CONSISTENCY CHECKING METHOD OF DIFFERENT ASPECTS MODELS ...

2.3 Definition of the origin of consistency rules. 2.4 Description of rules at 3 levels. 3. Relationships of consistency rules with metaelements (M2- metamodel and M3-metametamodel layers). In general, constrained elements are defined on the essential MOF model. The second result is the approach of checking consistency of IS models, expressed in UML, which propose a set of consistency rules according to the previously defined structure of consistency rules specification (requirements to consistency rules). A set of consistency rules is not complete, and its purpose is more to illustrate feasibility of our proposal. Finally, the method for semi-formal IS models consistency checking is proposed. The method is based on the previously presented proposal. The main parts of the method are: 1. Application of the proposed method for specific semi-formal consistency checking of IS models. 2. Extending the suggested approach for UML models consistency checking. 3. The process of IS models consistency checking. 4. The process of removing inconsistencies. 5. An approach of evaluating consistency of IS models is also proposed.

3. Application of the Proposed Method

Chapter 3 presents the experiments where the proposed method for checking consistency of IS models is applied. Some parts of the chapter are published in scientific publications (Vasilecas, Dubauskaite, Rupnik 2011; Dubauskaite, Va- silecas 2010; Dubauskaite, Vasilecas, Saulis 2009). The first experiment is aimed at the evaluation of the proposed requirements for consistency rules. We demonstrate how various consistency rules from different papers (Egyed 2007; Sapna, Mohanty 2007; Chanda et al. 2009) and our rules (specified using the proposed requirements) are understood by analysts, designers, programmers, and quality engineers. The researches of Egyed (2007), Sapna, Mohanty (2007) and Chanda et al. (2009) are selected for the experiment because their approaches are the most similar to our proposal compared to other analysed related researches. The experiment is performed using questionnaires; and the collected data are processed using t-test method. The second experiment is the extension of MagicDraw UML tool with the UML models consistency checking module prototype. The purpose of the inves- tigation is to test consistency of specific IS models using a developed software prototype. Comparison of our proposed method with the three most similar methods of other researchers is provided in the following table. 85 86 3. APPLICATION OF THE PROPOSED METHOD

Table 3.1. Evaluation of the proposed and three similar methods according to specific features

Method Feature/Comparison Egyed 2007 Sapna, Chanda Our Criteria Mohanty et al. method 2007 2009 1. Technique of checking Consistency OCL, Context OCL, java consistency of IS models rules hard SQL free and other coded to grammar executable UML Ana- language lyzer tool 2. Language for expressing UML UML UML Semi-formal IS models modelling language, UML is included 3. Is a process of checking Partially Partially Partially Yes consistency defined? 4. Are requirements No No No Yes of consistency rules defined? 5. Are examples of Yes Yes Yes Yes UML consistency rules provided? 6. Is a set of consis- No No No Partially

tency10 rules qualita- tive ? Specification of consistency rules 7. Is there a tool for Yes No No Yes s- automating process of IS models consistency checking? 8. Is a enforcement No No No Yes level of the detected violation of a con-

sistency11 rule provided ? Implementation of consi tency rules

10 Unambiguous, known origin and practical necessity, conformance to the metamodel of the

11modelling language. It indicates the necessity of performing changes of models according to a consistency rule.

3. APPLICATION OF THE PROPOSED METHOD 87

Quality of consistency rules and possibility to detect consistency violation in IS models, expressed in UML, is checked experimentally and is described in the following subchapters.

3.1. Evaluating the Proposed Requirements for Consistency Rules Using Questionnaires

The experiment is aimed at the evaluation of the proposed requirements for consistency rules that are expressed using a structure of consistency rules specification. We use Wholin et al. (2000) recommendations how to define the idea of an experiment, to plan and perform it.

3.1.1. Experiment Definition Evaluation of the proposed structure of consistency rules specification is performed seeking to give an answer to the questions whether the rule that meets the proposed requirements is less ambiguous, is more reliable (conformance to metamodel, defined origin), and is more reusable (rules are more understandable for IS engineers having different qualification) than the specifications of rules provided by other authors. Comparison of our consistency rules specified according to the defined requirements and consistency rules provided by other authors is carried out according to the defined criteria, which are described further.

Table 3.2. Participants and their choice from companies Company Number of participants NoMagic Europe 2 InfoEra 3 Technologies and Innovation Centre (TIC) 1 Bank of Lithuania 2 Vilnius Gediminas Technical University 2 Scope Baltija 2 Mazeikiu Nafta 2 Total: 14

88 3. APPLICATION OF THE PROPOSED METHOD

In this study the questionnaire is filled in by 14 specialists that have theo- retical or/and practical knowledge about UML. The participants are from various companies (Table 3.2). A number of participants, lack of their qualification randomization, provided specific specifications of consistency rules and other factors mean that there is some risk that these and other unknown factors may affect the outcome of the comparison. However, the efforts have been made to minimize the aforementioned effects. The study is based on the initial hypothesis that the proposed method is not better than the previous methods of specifying consistency rules.

3.1.2. Experiment Planning The experiment involves: evaluating 4 our rules and 4 rules provided by other authors (Egyed (2007), Sapna, Mohanty (2007) and Chanda et al. (2009)); each rule is evaluated according to the answers to 4 questions (questions are about knowing of semantic, associated metaelements, conformance to the metamodel, knowing the origin of the rule); and 1 general question about qualification of the respondent.

Variables Used in the Study Independent variables . The independent variables describe the treatments and are thus the variables for which the effects should be evaluated. The independent variable of interest in this study is the specification of consistency rules. These are consistency rules provided by other authors (a previous method), and the rules that are specified according to our proposed requirements (the proposed method). Dependent variables . The dependent variables are the response variables that describe the effects of the treatments described by the independent variables. Evaluation of the proposed and a previous method according to the quality of consistency rules is performed according to derivative variables. Dependent variables and variables derived from them are presented in Ta- ble 3.3. Dependent variables 1, 2, 3 and 4 may have one of three possible values: yes, may be, no. The answer means if it is a clear answer to the provided question. E.g. Do you know what metaelements are associated by the rule? Yes (It is clear what metaelements are associated), May be (It is not clear what metaelements are associated, but I can predict them, or know one of the associated metaelements), No (I do not know what metaelements are associated). All the questionnaire is used to evaluate the proposed method is provided in Annex C. The participant can have one of five qualifications (possible values of dependent

3. APPLICATION OF THE PROPOSED METHOD 89 variable 5): IS analyst, IS designer, Programmer, IS quality engineer (tester) or other. The dependent variables are measured for every participant for every speci-

fication of a consistency rule.

Table 3.3. Dependent and derivative variables

No. Dependent variable Quality property Derivative variable for (DP) expressed by DP evaluating quality 1 Knowing of semantic Unambiguity Count of answers ‘yes’ for every rule 2 Knowing of associated specification. metaelements Total count of an- 3 Conformance to meta- Reliability swers ‘yes’" for rules model (not contradiction) specifications of the 4 Knowing of origin proposed method. Total count of answers ‘yes’ for rules specifications of the previous method. 5 Reusability (measure of Reusability understanding for engineers of different qualification)

Analysis The results of the measurements are analysed with standard procedures for hypothesis (H) testing. The paired t-test (Wohlin et al. 2000) (Table 3.4) is used to perform the analysis. The t-test is used when two samples resulted from the repeated measures are compared. In our case two methods of rules specification (our proposed method and a method provided by other researchers) are compared. If one group is used and every person uses both methods, then we have repeated measures and paired t-test should be used (Wohlin et al. 2000). If instead of one group two groups independently use two different methods, the results would be independent samples, and an ordinary t-test could be applied.

Data Used in the Study The participants from various companies (Table 3.2) have to evaluate specifications of consistency rules. The questionnaire is provided in Annex C. It presents specifications of consistency rules used in the study and questions with possible

90 3. APPLICATION OF THE PROPOSED METHOD answers that are used for collecting data. Example of summary of answers to the questions is presented in Table 3.5.

Table 3.4. Paired t-test Paired t-test Input Paired samples: ( x1, y1), ( x2, y2) … and ( xn, yn). In this case n- a number of participants that provided answers to the questionnaire; x- a count of positive (‘yes) answers about the proposed method; y- a count of positive (‘yes) answers about a previous method.

H0 (Null H0: The expected mean of differences ( di = xi, -yi) is 0 (µd = 0); hypotheses) H1: The expected mean of differences is more than 0 (µ d > 0) H1 (Alterna- tive hypotheses) Calculations n v d − d 2 d ∑ ( i ) t = i =1 Calculate 0 , where S d = n − Sd n 1 Criterion t > t If 0 α,n−1 reject H0 (H0: µ 0 > 0) and accept H1 (H1: µ 0 > 0), where t α , f is the upper α percentage point of the t distribution with f degrees of freedom, which is equal to n – 1. The distribution is tabulated in Table A1 from Wohlin et al. book (2000), which presents critical values two-tailed t-test (5 %) and are available on the Internet as well.

Validity of the Results Validity of results is discussed with respect to internal and external validity. The internal validity is concerned with the validity within the given environment and the reliability of the results. The following threats to the internal validity have been considered: History : when treatments are applied, there is a possibility that the circumstances are not the same for every occasion. Since the participants are from various companies, the assignments are performed on many different occasions. If special events and disruptions occur, this affects only a few assignments for a few participants in a random fashion. While no systematic trends have been identified, this is not considered as an important threat to this study. Maturation : during the execution of the experiment, the subject may react differently over time. One effect to consider is that the partici-

3. APPLICATION OF THE PROPOSED METHOD 91

pants can become bored or tired, or they may become more positive to the tasks in the experiment. Since this experiment is performed during two months, this threat cannot be disregarded. No serious effects have been noticed. If some participants may have decreased or increased their interest, they have probably occurred randomly to participants. Therefore, this effect is not considered important. Testing : when the participants perform assignments repeatedly, it is possible that they learn the procedures of the study. Since the participants only knew that their data should be analysed but were not aware of the exact nature of the analysis or the objectives of the analysis, they have not changed because of it. Instrumentation : since the study is run without any extra/unknown instrumentation (questionnaires are prepared with MS word and sent by e-mail), this is not considered an important threat. The external validity is the question of how general the findings are. The following aspects of external validity have been considered: Generalizability of setting : the assignments conducted are relatively small assignments. They are performed individually by individual persons. This means that the results of the study at least are valid for small assignments developed individually. Generalizability of subjects : the study is conducted with IS specialists (analyst, designer, programmer, quality engineer), who are famil- iar with UML.

3.1.3. Analysis and Interpretation This chapter presents the data collected during the experiment operation and the analysis of this data by the paired t-test.

Visualization of the data Table 3.5 gives an example of the summary of answers to the questionnaire (Annex C) provided by one participant. Header rows of the table present checked property, abbreviation of a question and possible answers: ‘+’ means ‘yes’, ‘ +/-‘ – ‘may be’, ‘ - ‘ – ‘no’, A – analyst, D – designer, P – programmer, T– tester, O – other qualification. Answers ‘yes’ are used in further research; therefore, these answers are highlighted in grey background. Total count of ‘yes’ on each specification is also presented in data Table 3.5.

92 3. APPLICATION OF THE PROPOSED METHOD

Table 3.5. An example of the summary of answers to the questions

Checked property Unambiguity Reliability Reusability

Abbreviation ofquestion 1Understanding ofsemantics 2Knowing metaelements 3Conformance tometamodel 5Qualification 4 Origin, necessity

Answers

Author

ParticipantNo. No. Rule (Year) + +/- - + +/- - + +/- - + +/- - Total A/D/P/T/O 1 Proposed 1 1 1 1 3 method 2 Sapna, Mo- 1 1 1 1 1 hanty (2007) 3 Egyed (2007) 1 1 1 1 0 4 Proposed 1 1 1 1 3 method 1 5 Proposed Analyst 1 1 1 1 4 method 6 Chanda et al. 1 1 1 1 0 (2009) 7 Sapna, Mo- 1 1 1 1 3 hanty (2007) 8 Proposed 1 1 1 1 3 method Proposed method 13 Other method 4

Table 3.6 presents how many answers ‘yes’, which means the quality of the method from unambiguity and reliability viewpoints. The mean of the answers about every method is calculated according to the qualification of participants in order to evaluate how the method is understood by different respondents (Table 3.7).

3. APPLICATION OF THE PROPOSED METHOD 93

Table 3.6. Count of answers ‘yes ’ regarding the quality of consistency rules

Participant 1 2 3 4 5 6 7 8 9 10 11 12 13 14 No. Qualification

Total A O A D P T P A T D P T D D Method, count of 'yes' Proposed

13 10 14 12 10 8 8 11 9 14 12 8 11 12 152 method, x i Previous

4 7 10 9 8 9 10 9 7 8 7 6 9 5 108 method, y i

Table 3.7. Average count of answers ‘yes’

Analyst Designer Programmer Tester

Proposed method 12,67 12,25 10 8 Previous method 7,67 7,75 8,67 7,33

Data of Table 3.7 is presented graphically in Fig 3.1. The diagram demonstrates that IS engineers with different qualification understand the proposed consistency rules better compared to the previous rules. Average of count of 'yes' 9 ½ ¾ ¯ 9 ¾¯

Fig. 3.1. Understanding of different methods by specialists with various qualifications

The summarized collected data are presented graphically in Fig. 3.2. Maximum count of answers ‘yes’ provided by one participant on our proposed and previous method (provided by other authors) is 16 because there is a specifi-

94 3. APPLICATION OF THE PROPOSED METHOD cation of 4 consistency rules from every group of the methods, and every specification is evaluated using 4 questions (4 (specification)*4 (question/answer)=16 (maximum count of answers ‘yes’)). According to Fig. 3.2, our proposed method is better compared to the methods of other authors. This hypothesis is tested in the following section.

14 13 12 11 10 9 8 8 Proposed method 6

Participant No. Participant 5 Previous method 4 3 2 1 0 1 2 3 4 5 6 7 8 910111213141516 Count of answers 'yes'

Fig. 3.2. Count of answers ‘yes‘ to questions about unambiguity and reliability of consistency rules from two methods

Table 3.8. Application of the paired t-test Input The 14 paired samples obtained having calculated a total number of answers ‘yes’ (to the questions about unambiguity and reliability of consistency rules from two methods), provided by 14 participants (13, 4), (10, 7), (14, 10), (12, 9), (10, 8), (8, 9), (8, 10), (11, 9), (9, 7), (14, 8), (12, 7), (8, 6), (11, 9), and (12, 5). H0 H0: The proposed method has the same quality (unambiguity and reliability) as the previous method. H1 H1: The proposed method has better quality (more answers ‘yes’ about unambiguity and reliability) compared with previous method. Calculations Based on the data it can be seen that n = 14. The mean of differences is d = 3,143 (Formulas are provided in Table 3.4). It can be identified that Sd = 3,931 and t0 =4,011. Conclusions A number of degrees of freedom is f = n -1 = 14 – 1 = 13. In Table A1 from Wohlin et al. (2000) book, t0.025, 13 = 2.160. t0 =4,011>2.160= t 0.5, 13 therefore H 0 is rejected and H 1 is accepted with 95% (100%-5%) confidence level.

3. APPLICATION OF THE PROPOSED METHOD 95

The Main Analysis This section presents the main analysis of the collected results (Table 3.7) using paired t-test (Table 3.4). The results of calculations are presented in Table 3.8. According to the results of evaluation of consistency rules specifications, the proposed method is better than the other method of specifying rules. It allows understanding rules less ambiguously because their semantic is more understandable and the associated metaelements are known. The rules are also more reliable because their origin is known and they conform to the metamodel. Comparison of total count answers ‘yes’ shows that the quality of the proposed rules is by approximately 40,74% better than the quality of consistency rules specifications provided in previous researches (Egyed (2007), Sapna, Mo- hanty (2007) and Chanda et al. (2009)).

3.2. Evaluating the Proposed Method with MagicDraw UML Tool

The initial experiment was performed participating in Technology Development Program Project "Business Rules Solutions for Information Systems Develop- ment (VeTIS)". The idea of the experiment was to apply and test the proposed method for IS models consistency checking practically and to evaluate the obtained results. OCL was used for expressing consistency rules. UML models were selected as IS models and MagicDraw UML tool as a tool for UML models development. The main idea of the experiment is presented in Figure 3.3.

Fig. 3.3. Checking models, expressed in unified modelling language, using consistency rules

96 3. APPLICATION OF THE PROPOSED METHOD

Object constraint language (OCL) was selected for expressing consistency rules because: consistency rules would be interpreted unambiguously (OCL is a formal language); and consistency rules would be compatible with well-formedness rules of UML metamodel that are also expressed in OCL. UML is chosen because it is a popular semi-formal modelling language and more usable in practice compared to formal languages. UML models can be developed using various design tools Gentleware Po- seidon for UML, IBM Rational rose, Sybase PowerDesigner, NoMagic Magic- Draw UML, IBM Rational System Architect, Open ModelSphere, StarUML, Umbrello UML Modeller and other. The suitable IS modelling tool was selected based on the analysis results of the mentioned tools. Detailed results of this analysis are presented in Chapter 1.4. MagicDraw UML was chosen because it allows expressing constraints in OCL and has a lightweight technique for tool extension – modules.

3.2.1. ConsistencyConstraints4UML Module Prototype A prototype of the ConsistencyConstraints4UML software module prototype is developed to carry out the experiment of automatic checking consistency of IS models. The experiment is also described in the papers of Dubauskaite and Vasi- lecas (2009), Vasilecas and Dubauskaite (2009) and Dubauskaite et al. (2009). This chapter presents implementation description of a module prototype ConsistencyConstraints4UML for MagicDraw UML 16.0 tool. Magic- Draw UML provides a validation mechanism (called Validation Profile) for extending tool with new rules, because UML is a method-independent language. Therefore, the UML modelling systems do not enforce those method-dependent rules, which are not standardized and vary among many different methods (Viti- utinas, Silingas, Telksnys 2011). It is necessary to mention validation and verification concepts. In computer science verification means that a product, a service or a system meets standard or specification requirements; whereas validation refers to meeting the needs of the intended end-user or a customer (IEEE 1990; Sommerville 2006). Hence verification term is more suitable for checking a model according to the defined rules. However, a validation term is used in the following sections because it is used in user interface and documentation of MagicDraw UML, which is a tool of our experiment. Developing a software prototype, we use a lightweight technique for tool extension – module. The Validation profile, whose structure is presented in Fig. 3.4 is used for extending tool with a new suite of rules for checking consis-

3. APPLICATION OF THE PROPOSED METHOD 97 tency of models. Severity level matches enforcement level in our proposed approach, and enforcement level has three values: high (interpreted as an error), medium (interpreted as a warning) and low (interpreted as information). There- fore, three attributes of ‘SeverityKind‘ are used in our developed module.

<> Validation Profile

<> <> <><> validationSuite validationRule ConstraintConstraint [Package] [Constraint] -constrainedElement : Element [0..*] -abbreviation : String [0..1] -specification : ValueSpecification [1] -errorMessage : String [0..1] -severity : SeverityKind [1] = error -implementation : String [0..1]

<> SeverityKind <>debug{highlightColor = "gray"} <> <>info{highlightColor = "black"} ConsistencyConstraints4UML <>warning{highlightColor = "yellow"} <> <>error{highlightColor = "red"} <>fatal{highlightColor = "red"}

Fig. 3.4. Extension profile for validation rules

First of all, a package ConsistencyConstraints4UML is created and stereotype « validationSuite » is applied to it. Our developed suite of consistency rules (which is called ConsistencyConstraints4UML) is in grey in Fig. 3.4. The package groups related consistency rules and they can be invoked together. Then consistency rules R1, R2, R3, R5 and R6 are implemented. Consis- tency rule R1 constrains ProtocolTransition and requires to associate it with operation of class, which states are modelled, enforcement level of the rule is medium (weight is 2). The proposed values for enforcement levels “high“, “medium“ and “low“ are provided in Chapter 2.5.4. Detailed specifications of the implemented rules can be found in Chapter 2.4.2 according to ID of consistency rule (R1, R2, etc.). The mentioned chapter also presents all the process of evaluating consistency of IS models. Implemen- tation of the rule (OCL code) is also provided in the specification of a consistency rule. Consistency rule R2 constrains a protocol state machine. It requires defining the class which states are modelled. A enforcement level is high (weight is 3). In “description“ part of the specification of a consistency rules (see Chapter 2.4.2) it is explained why one or another enforcement level is assigned to the rules. Consistency rule R3 constrains Lifeline. Lifeline expresses object, which interacts with other object in a sequence model. R3 requires that a type of the

98 3. APPLICATION OF THE PROPOSED METHOD object used in a sequence model has to be defined in a class model. Consistency rule R5 constrains a message of a sequence model, and requires associating a call message with the operation of the class. Consistency rule R6 also constrains a message. It requires that visibility of the operation, which is assigned to the call message, has to be not private. The detailed specifications of the proposed consistency rules are presented in Chapter 2.4.2. Consistency rules are implemented as a UML Constraint (Stereotype «ValidationRule» extends the Constraint class) with «ValidationRule» stereotype applied. They reuse Constraint properties name, constrainedElement, and specification. Property constrainedElement of validation rule specifies a model element for which this rule is applicable. constrainedElement can be defined on metaclass, class or stereotype to which the rule is applied. Specification defines OCL invariant specification. A rule can be expressed not only in OCL but in Java as well. Attribute implementation of ValidationRule defines the Java class, which is used for validation rule implementation (if a rule is expressed in Java). The element with stereotype «ValidationRule» also describes validation errors. The abbreviation attribute is used for specifying a short name of the validation rule for grouping and filtering rules using validation user interface. The attribute errorMessage defines the textual error message, which is displayed when invalid model element is detected. It should explain the invalid situation and provide tips for solving it.

Fig. 3.5. Implementation of a consistency rule

The example of rule implementation is defined in Fig. 3.5.

3. APPLICATION OF THE PROPOSED METHOD 99

A consistency rule is expressed in OCL 2.0 (Specification part of Fig. 3.5), defined for element Lifeline of UML metamodel (Constrained metaelements are demonstrated in part of Fig. 2.5). The implemented consistency rule relates the sequence (more exactly Lifeline of Object) and class models (Class). The detailed process of ConsistencyConstraints4UML module implementation is defined in Fig. 3.6.

1. Create package for containing consistency rules ConsistencyConstraints4UML

2. Put stereotype "Validation Suite" on the package

3. Create the constraint element in the package

4. Put stereotype "Validation Rule" on constraint

5. Define rule name

6. Refer the main constraint element

7. Select the contraint specification langauge OCL 2.0

8. Write contstraint in OCL 2.0

9. Define error message for violated rule

10. Select the severity of rule

[is any unspecified consistency rule]

[no] [yes]

Fig. 3.6. Implementation of consistency rules

100 3. APPLICATION OF THE PROPOSED METHOD

Fig. 3.7. Importing the developed software prototype

Modelling engineer MagicDraw UML tool

[is ConsistencyConstraints4UML module loaded] [no] Import ConsistencyConstraints4UML [yes]

Start model validation procedure from "Analyse" menu

Select ConsistencyConstraints4UML If enforcement level of consistency rule is high, then validation suite severity level=error

If enforcement level of consistency rule is medium, then Select models for validation severity level=warning

If enforcement level of consistency rule is low, then Select minimal severity (enforcement) severity level=info level for searching consistency conflicts

Invoke models validation task Search for consistency conflicts according to defined constraints and validation setings [is nessesary to change the models] Review [are consistency conflicts detected] [no] validation error Show the list of validation errors with constrained element and severity level [yes] [yes] [no] Modify UML models Show message about [is any unreviewed validation error] succesful validation [yes]

[All errors are reviewed. Are models modified] [yes] [no]

Fig. 3.8. Usage of ConsistencyConstraints4UML

3. APPLICATION OF THE PROPOSED METHOD 101

The main files in the project are: ConsistencyModuleImplementation.mdzip – the file where Consis- tencyConstraints4UML rule set is created and tested; and ConsistencyConstraints4UML.mdzip – module prototype for consistency checking of UML models. After the implementation of consistency rules (ConsistencyModule Implementation.mdzip) they are exported to module ConsistencyCon- straints4UML model and tested with specific IS models. Test models are presented in Chapter 3.2.2. The result of export is the file ConsistencyCon- straints4UML.mdzip, which can be reused in other IS modelling projects for checking consistency of IS models. The developed module can also be extended with new rules. If the knowledge engineer wants to add new consistency rules using MagicDraw UML tool, first of all he/she has to select package Consis- tencyConstraints4UML and then to repeat 2–10 steps according to Fig. 3.6. The prototype of ConsistencyConstraints4UML module can be reused in a test or real project by importing the developed consistency module to standard MagicDraw UML tool (Fig. 3.6). When importing module (Fig. 3.7) in a settings part we can define read- ing/writing and loading to project parameters of module. The detailed process of the usage of ConsistencyConstraints4UML is presented in Fig. 3.8. The usage of ConsistencyConstraints4UML for checking consistency of the real IS models is presented in the following chapter.

3.2.2. Modelling of Books Library In this chapter we present development of a digital books library. Models are created according to OOAD method (Bennet et al. 2010), and their consistency is checked according to the proposed method. The library information system is modelled from class, states and sequences aspects. UML class diagram is used for representing classes of Customer, Book, BookCategory, Category, Loan, Penalty, Administrator, their properties and association. States of Book and Loan are represented using UML protocol states machines. Processes of search book by category, search book by keywords, login, make reservation, register loan, cancel reservation, register return, pay penalty, register customer and remove customer are modelled in UML sequence diagrams. Part of IS models is shown in Fig. 3.9.

102 3. APPLICATION OF THE PROPOSED METHOD

Fig. 3.9. Part of input models to the consistency checking process

The process of consistency checking of input models is described in the following section.

3.2.3. Checking and Evaluating Consistency of the Models The process of checking IS models, expressed using UML, is executed automatically (activated by command validate model).

3. APPLICATION OF THE PROPOSED METHOD 103

The input of the models validation function is models of books library and the output is a list of errors. Checking consistency of models every instance of a consistency rule is examined. The implemented consistency rules are presented in Chapter 3.2.1. If the rule is violated, then list of consistency conflicts is appended with a message of error or warning or information. The left column of Figure 3.10 provides UML models, developed using MagicDraw UML tool. The detected consistency conflicts are shown at the bottom of the right column in validation results section of Fig. 3.10. In the right column a states model is visualized using protocol state diagram and problematic places (which are related to the violated rules) are highlighted in different colour (errors in red, warning in yellow, info in black). The tool does not automatically resolve consistency conflicts because it does not know whether an inconsistency is tolerable or what choice of fixing inconsistencies is the best. But the task of modifying IS models according to the detected inconsistencies can be semi-automated; however, this issue is out of scope of our research. More information on choices for fixing inconsistencies is provided by Egyed (2007).

Fig. 3.10. Checking models of books library using a developed software prototype

104 3. APPLICATION OF THE PROPOSED METHOD

In this case a tool can be assistant that helps to detect violations of consistency. If the operation cancelReservation() is referred with transition of the Book from Provided to Canceled states and operation destroy() is referred with transition from Closed to final the state, then the consistency of the class and protocol states models would be improved. A severity level of the violated consistency rule R1 (violations are shown in the protocol state machine of Fig. 3.10) is Warning. ‘Warning’ meets a enforcement level ‘Medium’ and means if a rule is violated, then ‘sometimes’ it is necessary to perform changes of the model (see Table 2.1). An example of such a situation when there is no need to change a model according to the detected consistency conflict is transition from the choice point to states Finable and Closed in Fig. 3.10. Transition depends on the result of the previous operation ( registerReturn() ); therefore these transitions do not have to be associated directly with the operation and 2 violations of rule R1 can be ignored. Therefore value ‘2’ is in the cell where the count of violations of R1 of the modified models is presented. The count of violations of R1 of the initial models has been 4. The count of instances of R1 is 14 because there are 14 instances of metaelement ProtocolTransition , which is the main constrained metaelement in R1. The implemented consistency rules are presented in the previous Chapter 3.2.4. Their detailed specifications can be found in Chapter 2.4.2 according to ID of a consistency rule that is provided in the 3rd column of Table 3.9. Consistency rule R2 which constrains the protocol state machine is violated in one instance of the rule, where BookStates is used instead of Book defining class, which states are modelled using the protocol state machine. Consistency rule R3 requires defining that a type of the object used in a sequence model has to be defined in a class model. Six violations of the rule are detected. In two cases it is necessary to perform changes of the models because object named Book and Loan is used in the sequence model, but these names are not associated with the classes Book and Loan (types of the lifelines are not defined). In other 4 cases it is no need to perform any changes because according to OOAD (Bennet et al. 2010) a class model is used to model a data structure, where names of web pages, programming modules are not usually included. Therefore, lifelines, such as LibraryForAdministrator , SystemAccess , Reader- Profile and other can not be associated with any specific class. Consistency rule R5 is violated when a call message of lifeline is not associated with the operation of a class. If the called Message is referred to a private operation of a class, then consistency rule R6 is violated. A number of violations of every consistency rule and evaluation of consistency of initial and modified IS models is presented in Table 3.9. It presents the results of evaluating consistency of initial models and modified models. Initial

3. APPLICATION OF THE PROPOSED METHOD 105 models are modified according to the results of consistency checking that provide information on elements which violate consistency rules.

Table 3.9. Evaluating consistency of library models

Consistency rule, cr Count of Count of Derived data Checked instances violations No, ID Weight, models of cr i, c i of cr i, v i wi×v i wi×c i i wi Initial 1 R1 2 14 4 8 28 models 2 R2 3 2 1 3 6 of library 3 R3 2 31 6 12 62 4 R5 3 83 5 15 249 5 R6 3 83 2 6 249 Total: 44 594 Consistency 0,9260 coefficient: Modified 1 R1 2 14 2 4 28 models 2 R2 3 2 0 0 6 of library 3 R3 2 31 4 8 62 4 R5 3 83 0 0 249 5 R6 3 83 0 0 249 Total: 12 594 Consistency coefficient: 0,9798

Consistency coefficient of initial models of library is calculated according to formula (1), presented in Chapter 2.5.4. Consistency coefficient shows how many inconsistencies occur from all possible consistency conflicts including weight of a consistency rule. The count of possible consistency conflicts is the count of instances of a consistency rule. If the instance returns value is false, it is considered that a consistency conflict is detected. The models are modified according to the detected violations of consistency rules and then consistency of the models is checked again. The evaluation of consistency of modified models is also presented in Table 3.9. Comparison of consistency coefficients of initial and modified models shows that consistency of the initial models is improved. The proposed method allows detecting inconsistencies automatically, and in such a way it makes work

106 3. APPLICATION OF THE PROPOSED METHOD of a designer easier. If a designer modifies the models according to the detected violations, then consistency of IS models is improved. Moreover, detecting and fixing consistency conflicts in earlier phases of IS life cycle allows to reduce cost of IS development.

3.3. Conclusions for Chapter 3

In Chapter 3 the author has presented the application of the proposed method for specifying consistency rules and checking consistency of UML models. The results obtained in the chapter are as follows: According to the proposed requirements for consistency rules, the consistency rules of IS models, expressed in UML, were specified. Questionnaire about the quality of consistency rules that are specified according to the proposed requirements and the rules provided in the related researches is made. Data about unambiguity (knowing of semantic and associated metaelements), reliability (conformance/not contradiction to metamodel, knowing of origin), reusability (better understandability) of the proposed and the previous rules were collected using the questionnaire. The collected data were proceeded and hypotheses were tested using paires t-test method. The obtained results allowed accepting hypothesis that the proposed method is of a better quality (more answers ‘yes’ about unambiguity and reliability) compared to the previous methods with 95% reliance level. The rules are also more understandable for IS engineers. The method proposed in this thesis was also tested implementing some different consistency rules of states, class and sequences aspect models in the consistency module prototype, which was developed for MagicDraw UML tool (No Magic 2012). The second experiment showed that the usage of the proposed method allows detecting inconsistencies of different aspect models.

General Conclusions

During the research the following results were obtained, and these scientific and practical conclusions were formulated: 1. The analysis of UML and IDEF specifications and several object- oriented methods shows that they provide consistency requirements implicitly and can be used as a source of consistency rules acquisi- tion. 2. The analysis of methods for IS models consistency checking and their consistency rules shows the relevance of that the solved problem. Various methods using constraints for IS models or using algorithm/engine of a formal language for detecting inconsistencies are proposed. However there is no any comprehensive method how to check consistency and to create a more undersandable and more reliable set of consistency rules. 3. The analysis of UML design tools showed that some of them allow creating models that do not conform to OMG UML metamodel, and usually the tools have facility testing of UML models of correctness. Therefore, consistency rules may include metaelements that are associated in the metamodel and design tools can be extended with the

107 108 GENERAL CONLUSIONS

module for automatic checking of consistency of UML different aspects models. 4. A method of semi-formal models of different IS aspects checking based on consistency rules is created. A method of IS different aspects models not related with a specific modelling language is proposed. The feasibility of the proposed method is illustrated creating 12 consistency rules for UML models according to the proposed requirements. The rules are defined at the metamodel level; therefore, they can be implemented in any design tool that supports UML 2.2 metamodel. 5. The evaluation of the results obtained during the experiment showed that the proposed requirements for consistency rules improve the quality of a set of the rules (less ambiguity, more reliability) by approximately 41% in comparison with other similar methods. The consistency rules that are specified according to the proposed requirements are also more understandable by IS engineers compared with the rules provided by other researches. 6. The experiment performed demonstrated that the usage of the developed module ConsistencyConstraints4UML allows detecting consistency conflicts among different aspects models, and an enforcement level helps to decide whether it is necessary to react to violation of the rule and to change the model.

References

Ahmad, M. A.; Nadeem, A. 2010. Consistency Checking of UML Models using Description Lo- gics: A Critical Review , in Proc. of the 6th International Conference on Emerging Technologies (ICET 2010), Islamabad, 310–315. Andress, S.S. 2012. Reasoning & Inference [cited 29 April 2012]. Available from Internet: http://www.scribd.com/doc/12311209/Reasoning-Inference. Armour, F.; Miller, G. 2001. Advanced Use Case Modelling: Software Systems . United Kingdom, 425 p. Ayvazreys, Z.; Uysal, M. 2001. Designing an Object-Oriented Application Model by Booch methodology, Journal of Electrical &Electronics 1(2): 193–200. Bajec, M.; Krisper, M. 2005. A methodology and tool support for managing business rules in or- ganisations, Information Systems 30(6): 423–443. Bajec, M.; Krisper, M.; Rupnik, R. 2003. Tracking Business Rule Evolution to Support Is Mainte- nance , in Proc. of the 5th International Conference on Enterprise Information Systems (ICEIS 2003), France, 527–530. Bajec, M.; Vavpotic, D. 2008. A framework and tool-support for reengineering software development methods, Informatica 19(3): 321–344. Bargelis, A, Stasiskis, A. 2008. IDEF0 modelling technique to estimate and increase the process capability at the early product design stage, Mechanika 3(71): 45–50. Barjis, J. 2009. Collaborative, Participative and Interactive Enterprise Modelling, LNCS 24: 651– 662. nd Baronas, R. 2005. Duomenų bazių sistemos [Systems of Databases]. 2 ed. Vilnius, 184 p. Batini, C.; Scannapieco, M. 2006. Data Quality . New York, 262 p.

109 110 REFERENCES

Bennet, th S.; McRobb, S.; Farmer R. 2010. Object-Oriented Systems Analysis and Design Using UML . 4 ed. London, 698 p. Berkenkötter, K. 2008. Reliable UML Models and Profiles, ENTCS 217: 203–220. Biba, K. J. 1977. Integrity Considerations for Secure Computer Systems . Technical report MTR- 3153, The Mitre Corporation, 68 p. Boger, M., Graham, E., Köster, M. 2006. Poseidon for UML: User Guide [cited 13 April 2011]. Available from Internet: http://cs.adelaide.edu.au/docs/PoseidonUsersGuide.pdf>. Booch, G.; Rumbaugh, J.; Jacobson, I. 1998. The Unified Modelling Language User Guide . Lon- don. 512 p. Borba, C.F.; Silva, A. E. 2010. Knowledge-Based System for the Maintenance Registration and Consistency among UML Diagrams, LNCS 6404: 51–61. Boritz, J.E. 2005. IS practitioners‘ views on core concepts of information integrity, International Journal of Accounting Information Systems 6(4): 260–279. Bowen, J. 2003. Formal Specification and Documentation using Z: A Case Study Approach . Thomson Publishing, 315 p. Budkowski, S.; Dembinski, P.; Diaz, M. 1988. ISO Standardized Description Technique Estelle , in Proc. of the International Workshop on Software Engineering and its Applications, Toulouse. Caplinskas, A. 1996. Programų sistemų inžinerijos pagrindai I [Fundamental of Software System Engineering I]. Vilnius, 294 p.

Caplinskas, A.; Lupeikiene, A.; Vasilecas, O. 2002. Shared Conceptualisationth of Business Sys- tems, Information Systems and Supporting Software , in Proc. of 15 International Baltic Confer- ence, Databases and Information Systems II (BalticDB&IS'2002), Tallinn, 109–120. Cavarra, A.; Riccobene, E.; Scandurra, P. 2004. A framework to simulate UML models: moving from a semi-formal to a formal environment , in Proc. of the 2004 ACM Symposium on Applied Computig (SAC’04), New York: 1519–1523. Ceponienė, L. 2006. Informacijos sistemų reikalavimų analizės ir transformavimo į projektą metodas [Method for Information System Requirements Analysis and Transformation to Design]. Doctoral dissertation, Kaunas. Chanda, J., et al. 2009. Traceability of Requirements and Consistency Verification of UML Use- Case, Activity and Class diagram: A Formal Approach , in Proc. of International Conference on Methods and Models in Computer Science 2009 (ICM2CS09), New Delhi: 1–4. Chen, Z.; Motet, G. 2009. A Language-Theoretic View on Guidelines and Consistency Rules of UML, LNCS 5562, 66–81. Cheng, H. C. 2001. A Metamodel-Based Approach to Formalizing UML , in Proc. of the 25th An- nual International Computer Software and Applications Conference (COMPSAC'01), Wasshing- ton. Chiorean, D., et al. 2004. Ensuring UML models consistency using the OCL Environment, ENTCS 102: 99–100. Chonoles, M. J.; Quatrani, T.; Lockheed, M. 1996. Advanced Concepts Center, Rational Software Corporation. Succeeding with the Booch and OMT methods: a practical approach . Addison- Wesley, 378 p. Dzemydienė, D.; Maskeliunas, S.; Dzemyda, I. 2008. Interoperability of Information System Components for Monitoring Sewage and Intelligent Analysis of Water Resources, Technological and Economic Development of Economy 14(3): 260–278.

REFERENCES 111

Egyed, A. 2006. Instant Consistency Checking for the UML , in Proc. of the 28th International Conference on Software Engineering (ICSE 2006), Shanghai: 381 –390 . Egyed, A. 2007. Fixing inconsistencies in UML design models , in Proc. of the 29th International Conference on Software Engineering (ICSE 2007), New York: 292–301. Eriksson, H.; Penker, M. 2000. Business Modelling with UML: Business Patterns at Work . John Wiley & Sons, Inc., 459 p. Filev, A., et al. 2003. Professional UML with Visual Studio .NET— Unmasking Visio for Enter- prise Architects . WileyPublishing, 360 p. FIPS. 1993. Integration Definition for Function Modelling (IDEF0). Federal Information Process- ing Standards . Publication 183, National Institute of Standards and Technology. FIPS. 1993a. Integration Definition for Information Modelling (IDEF1X). Federal Information Processing Standards . Publication 184, National Institute of Standards and Technology. FIPS. 2006. Minimum Security Requirements for Federal Information and Information Systems. Federal Information Processing Standards. Publication 200, National Institute of Standards and Technology. Gogolla, M. 2004. Benefits and problems of formal methods, LNCS 3036: 1–15. Goncalves, M. A.; Watson, L. T.; Fox, E. A. 2008. Towards a Digital Library Theory: A Formal Digital Library Ontology, International Journal on Digital Libraries 8(2): 91–114. Hay, D. C. 2011. Requirements Analysis: From Business Views to Architecture , New Jersey, 496 p. Hubaux, A., et al. 2009. Towards a Unifying Conceptual Framework for Inconsistency Manage- ment Approaches: Definitions and Instantiations . Technical Report P-CS-TR WP4CM-000001, Belgium. Huzar Z., et al . (Eds.) 2004. Proceedings of Workshop on UML Modelling Languages and Appli- cations, UML 2004 . Portugal. Huzar Z., et al . (Eds.). 2003. Proceedings of Workshop on Consistency Problems in UML-based Software Development II, Workshop UML 2003 . Berlin. IBM. 2010. XML Modelling [virtual disc on IMB server]. Rational Software Architect 11.3.1 help system. IBM. 2010a. UML for Information System Architecture [virtual disc on IMB server]. Rational Software Architect 11.3.1 help system. IBM. 2012. Extending Rational System Architect [cited 27 May 2012]. Available from Internet: Ibrahim, N., et al. 2011. Consistency Rules between UML Use Case and Activity Diagrams Using Logical Approach, International Journal of Software Engineering and Its Applications 5(3): 119– 134. IEEE. 1990. IEEE Standard Glossary of Software Engineering Terminology. IEEE Std. 610.12. ISO/IEC 13568:2002 Information Technology – Z Formal Specification Notation – Syntax, Type System and Semantics. Switzerland, 2002. 196 p. ISO/IEC 1997. Information Technology – Software quality characteristics and metrics – Part 3: Internal Metrics . International Organization for Standardization and International Electrotechnical Commission. Jacobson, I. 2011. Object-oriented software engineering: A Use Case Driven Approach . Revised ed. Addison-Wesley, 400 p.

112 REFERENCES

Jacobson, I., et al. 1999. The unified software development process . Boston: 512 p. Jakimavicius, M.; Burinskiene, M. 2009. A GIS and multi- criteria-based analysis and ranking of transportation zones of Vilnius city, Technological and Economic Development of Economy 15(1): 39–48. Kacprzak, M.; Kaczmarczyk, A. 2006. Verification of integrated IDEF models, Journal of Intelli- gent Manufacturing 17(5): 585–596. Kashyap, V.; Sheth, A. 1996. Semantic and schematic similarities between database objects: a context-based approach, The International Journal on Very Large Data Bases 5(4): 276–304. KBSI. 2010. IDEF Family of Methods. A Structured Approach to Enterprise Modelling & Analy- sis [cited 21 January 2011]. Available from Internet: . Kim C.H., et al. 2003. The complementary use of IDEF and UML approaches, Computers in In- dustry 50: 35–56. Klahr, D.; Langley, P.; Neches, R. 1987. Production System Models of Learning and Develop- ment . Cambridge, 478 p. Kleppe. A.G.; Warmer, J.B.; Bast, W. 20 04. MDA Explained– The Model Driven Architecture : Practice and Promise . Addison-Weley, 171 p.

Koffman,rd E. B.; Wolfgang, P. A. T. 2010. Data Structures: Abstraction and Design Using Java . 3 ed. Canada, 832 p. Kotulski, F. L. 2007. Assurance of system consistency during independent creation of UML diagrams , in Proc. of the International Conference on Dependability of Computer Systems (DepCoS- RELCOMEX 2007), Szklarska Poreba: 51–58. nd Kruchten P. 2000. The Rational Unified Process An Introduction . 2 ed. Canada, 320 p. Kuzniarz L., et al. (Eds.) 2002. Proceedings of Workshop on Consistency Problems in UML-based Software Development, UML 2002 . New York. Liu ,W.; Easterbrook, S. M.; Mylopoulos, J. 2002. Rule-based detection of inconsistency in uml models , in Proc. of the 5th International Conference on the Unified Modelling Language, UML’02, London: 106–123. Lucas, F. J.; Molina, F.; Toval, A. 2009. A systematic review of UML model consistency management, Information and Software Technology 51: 1631–1645. Maciaszek, L. A. 2001. Requirements Analysis and System Design: Developing Information Sys- tems with UML . Harlow, 378 p. MagicDraw. 2011. MagicDraw Architecture Made Simple: OPEN API User’s Guide [disc]. MagicDraw UML 17.0 help system. MagicDraw. 2011a. MagicDraw Architecture Made Simple: User Manual [disc]. MagicDraw UML 17.0 help system. Malgouyres, H.; Motet, G. 2006. A UML model consistency verification approach based on metamodelling formalization , in Proc. ACM Symp. on Applied Computing (SAC’2006), Dijon:1804– 1809. Matta, A.; Furia, C.; Rossi, M. 2004. Semi-formal and formal models applied to flexible manufacturing systems, LNCS 3280: 718–728. McGovern, J., et al. 2003. The Practical Guide to Enterprise Architecture . New Jersey, 306 p. Microsoft. 2004. Transformation vs. Translation: MSDN Library [cited 29 April 2012]. Available from Internet: .

REFERENCES 113

Miloudi, K. E.; Amrani, Y. E.; Ettouhami, A. 2011. An Automated Translation of UML Class Dia- grams into a Formal Specification to Detect UML Inconsistencies , in Proc. of the Sixth Interna- tional Conference on Software Engineering Advances (ICSEA 2011), Barcelona: 432–438. Mokhati, F.; Gagnon, P.; Badri, M. 2007. Verifying UML Diagrams With Model Checking: A Re- writing Logic Based Approach , in Proc. of the Seventh International Conference on Quality Soft- ware (QSIC), Portland: 356–362. MSISD (Master students from information system department of Vilnius GediminasTechnical University). 2009. Information System Engeneering . Laboratory works, Vilnius. MSISD (Master students from information system department of Vilnius Gediminas Technical University). 2009a. Methods and Techniques of IS development . Laboratory works, Vilnius. MSISD (Master students from information system department of Vilnius Gediminas Technical University). 2010. Software system enegineering . Labaratory works, Vilnius. Nemuraitė, L.; Ceponienė, L.; Vedrickas, G. 2008. Representation of business rules in UML&OCL models for developing information systems, LNBIP 15: 182–196. No Magic. 2012. Magic Draw tool [cited 23 May 2012]. Available from Internet: . OMG. 2003. MDA Guide Version 1.0.1 [cited 30 May 2012]. Document Number: omg/2003-06- 01. Available from Internet . OMG. 2005. Introduction to OMG's Unified Modelling Language [cited 12 March 2011]. Avail- able from Internet . OMG. 2005a. OntologyDefinition Metamodel [cited 2 September 2009]. Available From Internet: . OMG. 2005b. Documents associated with UML Version 2.0 [cited 2 February 2012]. OMG Documents: formal/2005-07-05. Available from Internet . OMG. 2006. OCL 2.0 Specification [cited 29 October 2009]. Available from Internet: . OMG. 2009. Unified Modelling Language (OMG UML), Superstructure, v2.2 [cited 18 August 2012]. OMG Document: formal/2009-02-02. Available from Internet < http://www.omg. org/spec/UML/2.2/Superstructure/PDF>. OMG. 2009a. Common Variability Language (CVL) [cited 2 March 2011]. Available from Inter- net: . OMG. 2010. Unified Modelling Language (OMG UML), Infrastructure, v2.3 [cited 3 May 2012]. OMG Document: formal/2010-05-03. Available from Internet . OMG. 2010a. Unified Modelling Language (OMG UML), Superstructure, v2.3 [cited 15 May 2012]. OMG Document: formal/2010-05-05. Available from Internet . OMG. 2011. Meta Object Facility (MOF) Core Specification [cited 6 June 2012]. Document Number: formal/2011-08-07. Available from Internet . OMG. 2011. Unified Modelling Language [cited 18 March 2011]. Available from Internet . Pakalnickiene, E.; Nemuraite, L. 2007. Checking of conceptual models with integrity constraints, Information technology and control , 36(3): 285–294.

114 REFERENCES

Pfeiffer, D.; Gehlert, A. 2005. A framework for comparing conceptual models , in the 2nd Work- shop on Enterprise Modelling and Information Systems Architectures Concepts and Applications (EMISA 2005), Klagenfurt: 108–122. Protégé. 2006. XMI Backend Technical Background [cited 18 September 2008]. Available from Internet: . Queralt, A.; Teniente, E. 2008. Decidable Reasoning in UML Schemas with Constraints, Ad- vanced Information Systems Engineering, LNCS 5074, 281 –295. Rasch, H.; Wehrheim, H. 2003. Checking Consistency in UML Diagrams: Classes and State Ma- chines. Formal Methods for Open Object-Based Distributed Systems, LNCS 2884, 229–243. Rational. 2003. Using Rose RationalRose [CD-ROM]. Rational documentation, 258 p. Rational. 2011. Rational Unified Process: Best Practices for Software Development Teams [cited 6 October 2012]. Rational Software White Paper TP026B, Rev 11/01. Available from Internet: . Roger, D.; G. Rose. 2000. Formal Object-Oriented Specification using Object-Z. Macmillan Press Ltd., 229 p. Rosenberg, D.; Scott, K. 2001. Applying Use Case Driven Object Modelling with UML: An Anno- tated e-Commerce Example . Canada, 153 p. Rosenberg, D.; Stephens, M. 2007. Use Case Driven Modelling with UML: theory and practice . New York, 438 p. Rozanski, N.; Woods, E. 2005. Software System Architecture . London, 546 p. Russell, S.; Norvig, P. 2010. Artificial Intelligence: A Modern Approach . New Jersey, 1132 p. Sapna, P.G; Mohanty, H. 2007. Ensuring consistency in relational repository of UML models , in: Proc. of the 10th International Conference on Information Technology (ICIT 2007), Rourkela: 217–222. Saulis, A.; Vasilecas, O. 2008. Informacinių sistemų projektavimo metodai [Information Systems Development Methods]. Vilnius, 247 p. Shen, H., et al. 2004. Integration of business modelling methods for enterprise information system analysis and user requirements gathering, Computers in Industry 54: 307–323. Shen, W.; Compton, K.; Huggins, J., K. 2002. A Toolset for Supporting UML Static and Dynamic Model Checking , in Proc. of the 26th International Computer Software and Applications Confer- ence, Prolonging Software Life: Development and Redevelopment (COMPSAC 2002), Ox- ford:147–152. Shinkawa, Y. 2006. Inter-Model Consistency in UML Based on CPN Formalism , in Proc. of the 8th Asia Pacific Software Engineering Conference (APSEC’06), Washington: 411–418. Silingas, D.; Butleris, R. 2009. Towards Implementing a Framework Modelling Software Re- quirements in MagicDraw UML, Information Technology and Control 38(2): 153–164. Simmonds, J.; Bastarrica, C, M. 2005a. Description Logics for consistency checking of architec- tural features in UML 2.0 models . DCC Technical Report TR/DCC-2005-1, Chile. Simmonds, J.; Bastarrica, C.M. 2005. A tool for automatic UML model consistency checking , in: Proc. of the 20th IEEE/ACM International Conference on Automated Software Engineering, New York: 431–432. Smaizys, A.; Vasilecas, O. 2009. Business Rules Based Agile ERP Systems Development, Infor- matica 20(3): 439–460. th Sommerville, I. 2007. Software Engineering . 8 ed. Edinburgh, 840 p.

REFERENCES 115

Sosunovas, S. 2008. User Defined Templates for the Specification and Transformation of Business Rules . Doctoral dissertation, Vilnius. Srichetta, P. 2011. Conceptual Framework of Transforming Informal Requirements Specification to Z Specification, IPCSIT 14, 19–24. Straeten, R. V. D. 2004. Inconsistency detection between UML models using racer and nRQL , in the Third International Workshop on Applications of Description Logics (ADL’04), Germany. Straeten, R. V. D. 2011. Description of UML Model Inconsistencies . Technical Report SOFT-TR- 2011.01.15, Brussel. Straeten, R. V. D.; Simmonds, J.; Mens, T.; Jonckers, V. 2003. Using Description Logic to Main- tain Consistency between UML Models, LNCS 2863, 326–340. Sybase. 2011. Object-Oriented Modelling [disc]. PowerDesigner 16.1: help system. Sybase. 2011b. Customizing and Extending Power Designer [disc]. PowerDesigner 16.1: help system. Teltumde, P. S.; Patil, P. I.; Ambhire I. 2011. Formal Specification Concepts in Critical Analysis, International Journal of Computational Engineering & Management 14(10): 128–134. TOZE. 2008. TOZE – A Graphical Editor for the Object-Z Specification Language with Syntax and Type Checking Capabilities [disc]. TOZE help system. Usman, M., et al . 2008. A Survey of Consistency Checking Techniques for UML model , in Proc. of the 2008 International Conference on Advanced Software Engineering & Its Applications (ASEA 2008), Hainan: 57–62. Vasilecas, O.; Kalibatiene, D. 2008. Formal Transformation of Ontology Axioms to application Domain Rules , in Proc. of the International Conference on Computer Systems and Technologies (CompSysTech'08), Gabrovo: V.1-1–V.1-8. Vasilecas, O.; Lebedys, E. 2005. Business rules repository for business rules represented using UML , in Proc. of the International Conference on Computer Systems and Technologies (CompSysTech’05) Varna: II.5-1–II.5-6. Vasilecas, O.; Lebedys, E. 2007. Application of Business Rules for Data Validation, Information Technology and Control 36(3): 273–277. Vasilecas, O.; Lebedys, E. 2009. Implementation of restriction and validation rules , in Proc. of the 2nd International Conference on Health Informatics (HEALTHINF), Porto 230–236. Vavpotic, D.; Bajec, M. 2009. An approach for concurrent evaluation of technical and social aspects of software development methodologies, Information and software technology 51(2): 528– 545. VeTIS. 2009. Business Rules Solutions for Information Systems Development . Project reg. No. B- 07042, Kaunas&Vilnius. Vitiutinas, R.; Silingas, D.; Telksnys, L. 2011. Model-driven plug-in development for UML based modelling systems, Information technology and control 40(3): 191–201. Wang Z., et al. 2012. Ontology Based Semantics Checking for UML Activity Model, Information Technology Journal 11(3): 301–306. Wohlin, C., et al. 2000. Experimentation in Software Engineering: An Introduction . United King- dom, 204

A List of the Author's Scientific Publications on the Topic of the Dissertation

Papers in the Reviewed Scientific Journals Vasilecas, O.; Dubauskaite, R.; Rupnik, R. 2011. Consistency Checking of UML Business Model, Technological and Economic Development of Economy 17(1): 133–150. ISSN 2029-4913. (ISI Web of Science) Dubauskaite, R.; Vasilecas, O. 2009. Ensuring Models Consistency in the OMT, Booch, and OOSE Object-Oriented Methods, Information Sciences 50: 160–167. ISSN 1392-0561. (LISA) Dubauskaite, R.; Vasilecas, O. 2009a. An Open Issues in Business Rules – Based Information System Development, Innovative Technologies for Science, Business and Education 1(6): 3.1–3.5. ISSN 2029-1035. Dubauskaitė, R.; Vasilecas, O. 2008. Žiniatinklio paslaugų sistemų kūrimas grindžiamas ontologi- jomis [Ontology-based Web Services System Development], Information Sciences 46: 102–114. ISSN 1392-0561. (LISA) Dubauskaitė, R.; Vasilecas, O. 2008a. Web servisų sistemos tobulinimo kryptys [Trends of Web Services Evolution], Technologijos mokslo darbai vakarų Lietuvoje VI: 17–20. ISSN 1822-4652.

117 118 THE LIST OF SCIENTIFIC AUTHOR'S PUBLICATIONS ON THE TOPIC...

Other Papers Dubauskaite, R.; Vasilecas, O. 2012. Tool Support for Checking Consistency of UML Model , in Pooley, R.J.; Coady, J.; Linger, H.; Barry, C.; Lang, M. (Eds.), Proc. of the 20th International Conference on Information Systems Development (ISD2011) – Information Systems Develop- ment: Reflections, Challenges and New Directions, Edinburgh, Scotland, August 24–26. ISBN 978-1-4614-4950-8. (Accepted for publication) Dubauskaite, R.; Vasilecas, O. 2010. The Approach of Ensuring Consistency of UML Model Based on Rules , in Stoilov, T., Rachev, B. (Eds.), Proc. of the International Conference on Computer Systems and Technologies (CompSysTech'10), Sofia, Bulgaria, June 17–18, 71–76. ISBN: 978-1- 4503-0243-2. Vasilecas, O.; Dubauskaite. R. 2009. Ensuring Consistency of Information Systems Rules Models , in Stoilov, T., Rachev, B. (eds.), Proc. of the International Conference on Computer Systems and Technologies (CompSysTech'09), Ruse, Bulgaria, June 18-19, VI.6.1–VI.6.8. ISBN: 978-1-4503- 0243-2. Dubauskaite, R.; Vasilecas, O.; Saulis, A. 2009. The Checking of Information Systems Models Using Rules , in Gungor, A.; Aydin, N.; Karahoca, A.; Toklu, C. (eds.), Proc. of e-Learning conference’09. e-Learning and Knowledge Society (e-Learning 2009), Berlin, Germany, August 31– September 1, 312–316. ISBN 1313-9207. Dubauskaite, R.; Vasilecas, O. 2008b. Ontology for Web Services Systems , in Targamadzė, A.; Butleris, R.; Butkienė, R. (eds.), Research Communications: proc. of 14th conference on Informa- tion and Software Technologies (Information Technology 2008), Kaunas, Lithuania, April 23–24, 173–178. ISSN 2029-0039. Dubauskaitė, R.; Būgaitė, D.; Vasilecas, O. 2008. Verslo taisyklių išgavimo proceso aspektai ir požiūriai [The Aspects and Approaches of Business Rules Elicitation], in Informacinės technologijos: XIII-os tarpuniversitetinės magistrantų ir doktorantų mokslinės konferencijos pra- nešimų rinkinys, Kaunas: Lithuania, May 9, 58–61. ISBN 978-9955-25-480-5. Dubauskaitė, R.; Vasilecas, O. 2009b. Informacinių sistemų modelių darnos užtikrinimo prob- lemos [Problems of Ensuring Information Systems Models Consistency], in 6-os studentų mok- slinės-praktinės konferencijos „Akademinio jaunimo siekiai: ekonomikos, vadybos ir technologijų įžvalgos 2009” medžiaga, Klaipėda, Lithuania, April 28, 247–252. ISSN 2029-0217. Dubauskaitė, R.; Vasilecas, O. 2008c. Ontologijų naudojimas universiteto e.publikacijų žiniat- inklio paslaugų taisyklių sistemai kurti [Ontology for Rules of University E-Publications Web Services] , in Adomėnas, G. P et al. (eds.) Informatika: 11-osios Lietuvos jaunųjų mokslininkų konferencijos „Mokslas – Lietuvos ateitis“ pranešimų rinkinys, Vilnius, Lithuania, April 9–11, 60–68. ISBN 978-9955-28-302-7.

ANNEXES

Annex A. Part of Metamodel of Unified Modelling Language

Fig. A.1. Fragment of metamodel of unified modelling language

119 120 ANNEXES

Annex B. Consistency Rules Provided in Different Studies

Relationships between UML class and sequence diagrams are analysed by Egyed (2007), Simmons et al. (2005a), and Straeten et al. (2003). Consistency between class and state diagrams is researched by Mokhati et al. (2007) and Egyed (2007). Mokhati et al. (2007) also analysed coherence between collaboration and state diagrams. Ceponiene (2006) researched UML state and sequence diagrams and presented a method of transformation of UML state diagram to UML sequence diagram and vice versa. Consistency rules associating different aspect models were elicited from 10 related studies and examined in order to evaluate consistency rules, excluding redundant rules, to find out whether the provided rules can be understood unambiguously, to determine whether they conform to specification of model – OMG UML metamodel (OMG 2010, OMG 2010a), and to find out whether they are meaningful. It means that it was aimed at identifying whether they really show a consistency conflict. First of all, the rules are divided into groups depending on what different aspects models they associate. Grouping of rules is necessary for comparing them and deciding whether their meaning is similar or the same. We assign the same originality ID for rules of the same group. The analysed consistency rules are provided in Table B.1.

Table B.1. Consistency rules

Rules among Class and State models

No. Rule Author Comment

No.thesisin Originality ID

1 Each class in a class diagram must Sapna, 1 In practice only states have a corresponding state. Mohanty of sophisticated classes 2007 were modelled but not all of them. It is a too strict requirement. The rule is related to the rule whose originality ID3.

ANNEXES 121

Table B.1. (continued)

2 Instance definition missing occurs Straeten et 1 when an element definition does al. 2003; not exist in the corresponding class diagram(s): Classless state- chart arises when the state diagram is associated to a class that does not exist in any class diagram. 3 10 Changes in the internal Dynamics Borba, 1 A general rule defines of the class indicate that the state Silva only related models but diagram must be changed (A state 2010 not their elements. represents the internal dynamics of a class). 4 A specification consisting of an Rasch, 1 Object-Z class and an associated Wehrheim state machine has the property of 2003 satisfiability iff the corresponding process in the semantic model has at least one non-terminating run 5 11 Dangling (inherited) feature refer- Straeten et 2 Is this a requirement for ence arises when a stimulus, al. 2003; class and state models? event, guard or action references an attribute or operation that does not exist in the corresponding class (or its ancestors). 6 15 Each state in a state diagram must Sapna, 3 First of all, according to be related to one and only one Mohanty OMG UML specifica- class. 2007 tion states, using state models can be modelled not only of classes but also of use cases. Second, if we model states of class, then specific states models are used. These are protocol states models. Hence, the rule is not verified with OMG UML specification.

122 ANNEXES

Table B.1. (continued)

7 A specification consisting of an Rasch, 4 It is not clear how this Object-Z class and an associated Wehrheim rule is checked auto- state machine has the property of 2003 matically. basic consistency if the corresponding process in the semantic model is deadlock free. 8 A specification consisting of an Rasch, 5 What is the origin of Object-Z class and an associated Wehrheim the rule? What IS de- state machine has the property of 2003 velopment methodol- method executability if in the cor- ogy or OMG UML responding process in the seman- metamodel? E.g. does tic model every method is exe- the method getClient- cuted at least once. Data() really have to be used in State model? May be the rule is valid under some conditions but they are not provided? 9 12 A specification consisting of an Rasch, 6 What is the origin of Object-Z class and an associated Wehrheim the rule? It is not clear state machine has the property of 2003 how this rule is method liveness iff in the corre- checked automatically. sponding process in the semantic model every method will always eventually be executed again. 10 Specification consisting of an Ob- Rasch, 7 What is the source of ject-Z class and an associated Wehrheim the rule? It is not clear state machine has the property of 2003 how this rule is method availability iff in the cor- checked automatically. responding process in the semantic model every method will always eventually be enabled again.

ANNEXES 123

Table B.1. (continued)

Rules among Class and Sequence models 11 8 Each object and message in a se- Sapna, 8, The requirement for quence diagram must have a cor- Mohanty 9 each object to have a responding class and method in 2007 corresponding class is the class diagram. too strict; in practice class for user interface usually is not in class models. Moreover, according to OMG UML specifications, only calling messages have to be defined in the class. 12 Instance definition missing occurs Straeten et 8 See comment on Rule when an element definition does al. 2003 11. not exist in the corresponding class diagram(s): Classless instance arises when an object in a sequence diagram is the instance of a class that does not exist in any class diagram. 13 5 Every message of an object must Sapna, 9 Rule 13 is redundant. correspond to the signature of a Mohanty Rule 11 and Rule 27 method of a class. 2007 include Rule 11 (both rules are provided in the same study). 14 6 Message name must match class Egyed 9 It is not clear whether 2 method 2007 elements with the same name have to be in models or one element refers to another element. 15 7 Messages between the modified Borba, 9 According to OMG classes mean that the correspond- Silva UML specifications ing sequence diagram should be 2010 (OMG 2010, OMG amended (Represents the mes- 2010a), class has opera- sages exchanged between class tions (not messages). instances)

124 ANNEXES

Table B.1. (continued)

16 Dangling (inherited) association Straeten et 10 reference arises when a certain al. 2003 link (to which a stimulus (or stimuli) is related) in a sequence diagram is an instance of an association that does not exist between the classes of the linked objects (or between the ancestors of these classes). 17 Multiplicity conflict: object in a Straeten 11 sequence diagram does not respect 2004; the multiplicity restrictions as imposed by the corresponding class diagrams. 18 Navigation conflict is another Straeten 12 inconsistency occurring between 2004; this class diagram and sequence diagram (searching for an association and corresponding association end(s) by which objects are linked to each other and over which an operation is called and which is not navigable). 19 13 Swimlines in Activity diagram Chanda et 13 What is activity state? (represented as al. 2009 className in activity state) must be present as a unique class in class diagram. Rules among Class and Activity models 20 20 Each class and activity in an activ- Sapna, 14, If a method behaviour ity diagram Mohanty 15 is detailed by activity must have a corresponding class 2007 model, then the re- and method in the class diagram. quirement that activity should have a corresponding method is meaningless in case a method does not use other methods.

ANNEXES 125

Table B.1. (continued)

In other cases one method uses other methods, but the activity model usually does not use a name of methods, activity names are expressed in a natural language. What is the origin of the rule that improves the necessity of the rule? Moreover, classes are not used in activity models explicitly; they are types of objects that specify the object flow. 21 Some of the action/activity states Chanda et 15 See comment on Rule in activity diagram whose activ- al. 2009 19. ity_node is either "action" or "decision" has a one-to-one mapping with a method of a class in class diagram. 22 Class name of the each object Chanda et 14 flow in Activity diagram must be al. 2009 present as a unique class in class diagram 23 9 Internal and external messages of Borba, 15 See comment on Rule the class are represented in the Silva 19. activity diagram (A modification 2010 in the activity diagram may cause the need of a different method in the class diagram.) Rules among Class and Use Case models 24 Each actor in a use case diagram Sapna, 16 Data about a non- must find a corresponding class in Mohanty registered user is usu- the class diagram. 2007 ally not saved and this user is not in the class model.

126 ANNEXES

Table B.1. (continued)

24 Each actor in a use case diagram Sapna, 16 Data about a non- must find a corresponding class in Mohanty registered user is usu- the class diagram. 2007 ally not saved and this user is not in the class model. 25 All actors shown in the use cases Borba, 16 are candidates for classes (When a Silva class is modified, correspondent 2010 actors should be verified in the Use Case Diagram) 26 The elements of G1 (require- Kotulski 17 A general rule, it is ments, use case graph) are con- 2007 more suitable for the nected with the elements of G2 design recommendation or G3 (classes) when they support than automated consis- fulfilment of this requirement (via tency checking of IS a vertical relation) model. Rules among Sequence and State models 27 9 Each object in a sequence diagram Sapna, 8, One part of the rule must reference a valid class in the Mohanty 18 repeats the require- class diagram and valid object in 2007 ments expressed in the state diagram. Rule 11, provided also by Sapna, Mohanty (2007). 28 Message sequence must match Egyed 19 Precondition: object of behaviour. 2007 the sequence has to be associated with the state model of the object‘s class. 29 Incompatible behaviour conflicts Straeten 19 indicate conflicting behaviour et al. definitions between state dia- 2003; gram(s) and sequence diagram(s) (More particularly this conflict arises when the ordered collection of stimuli received by an object in a sequence diagram does not exist as a sequence of events in the state diagram of that class).

ANNEXES 127

Table B.1. (continued)

30 Sending and receiving messages Borba, 20 The rule can be derived may be actions of the state dia- Silva from Rule 5 and Rule gram.( The actions of the state 2010 15. diagram correspond to sending and receiving messages). Rules among Sequence and Activity models 31 Each scenario of an operation can Borba, 21 be shown by an activity diagram Silva (A modification in the activity 2010 diagram may cause the need of a different method in the class diagram.). 32 The change in an activity diagram Borba, 21 can represent the change of the Silva sending of an operation in the 2010 sequence diagram. 33 For each place in an activity Shinkawa 22 model, which expresses an actor, 2006 there is at least one place in the sequence model, which indicates the same actor. 34 Each class in an activity diagram Sapna, 23 Class or object is in ac- must correspond to an object in a Mohanty tivity. sequence diagram. 2007 35 Each activity in an activity dia- Sapna, 24 Activity is usually ex- gram must correspond to a mes- Mohanty pressed in a natural lan- sage in a sequ ence diagram. 2007 guage, whereas messages usually have a stricter form which is similar to the program code. 36 For each transition in an activity Shinkawa 24 See comment on Rule CPN (Colored Petri Nets) model, 2006 35 (above). Transition is there is at least one transition in used for state models. sequence CPN models, which indicates the same action.

128 ANNEXES

Table B.1. (continued)

37 For any firing sequence of transi- Shinkawa 25 tions in an activity CPN model, 2006 there exists the same firing sequence of transitions in an sequence CPN model, or there are pieces of firing sequences which can compose the same sequences as that of the activity CPN model. Rules among Sequence and Use case models 38 Any use case can be described in Borba, 26 the sequence diagram (Every sce- Silva nario described in the sequence 2010 diagram should be described in the Use Case Diagram). 39 An object is absent from the spe- Liu et al. 26 The rule can be inter- cialized sequence diagram. 2002 preted ambiguously. Is there a requirement for a use case to have a corresponding sequence model? 40 17 For each actor in a use case dia- Sapna, 27 Classes are not pre- gram there must exist a matching Mohanty sented in the sequence class in the sequence diagram. 2007 model explicitly. Rules among Activity and State models 41 Each class and corresponding ac- Sapna, 28, Class in activity and in tivities in an activity diagram Mohanty 29 state models is not pre- must have a corresponding class 2007 sented explicitly. Mes- and message in the state diagram. sage is used for the sequence model. Knowledge expert may say that it is necessary to associate activity and protocol transition (but this information is not provided in the Rule explicitly).

ANNEXES 129

Table B.1. (continued)

41 Each class and corresponding ac- Sapna, 28, Class in activity and in tivities in an activity diagram Mohanty 29 state models is not pre- must have a corresponding class 2007 sented explicitly. Mes- and message in the state diagram. sage is used for the sequence model. Knowledge expert may say that it is necessary to associate activity and protocol transition (but this information is not provided in the Rule explicitly). 42 Actions may change activity flows Borba, 28 A general rule ex- in the Activity Diagram (If an Silva presses association activity is changed a state may be 2010 among models; how- created or excluded.). ever, it does not relate elements of models. Rules among Activity and Use case models 43 1 Any use case can be described by Borba, 30 an activity. (If a use case is Silva changed, activity diagram should 2010 be changed.) 44 2 Each CPN model appears at least Shinkawa 30 According to the con- in one activity CPN model. 2006 text, CPN model is a use case model expressed in Colored- Petri Net. 45 3 Each use case has at least an ac- Ibrahim et 30 tivity diagram. al. 2011 46 4 An action/activity state in activity Chanda et 30 What is the event of a diagram has a one- to-one map- al. 2009 use case? ping with an event of a use case in use case diagram. 47 14 For each actor in a use case dia- Sapna, 31 Does “Matching class“ gram there must exist a matching Mohanty mean swimline parti- class in the activity diagram. 2007 tion or an object for flow specification?

130 ANNEXES

Table B.1. (continued)

48 An actor that associates to the Ibrahim et 31 use case will be an activity par- al. 2011 tition in the activity diagram. 49 If an actor associates to a use Ibrahim et 30, case then the actor will be an al. 2011 31 activity partition in the associated activity diagram. 50 When an activity model is exe- Shinkawa 32 cuted, each use-case CPN model 2006 included in it acts correctly, that is, the pre-condition and the post-condition of the use case CPN model hold for any execution (A behavioural constraint).

Annex C. Questionnaire Used to Evaluate the Proposed Requirements for Consistency Rules

Assumption : participants have knowledge about UML. Please check one answer for all questions.

1. Specification of a consistency rule Consistency rule ID R1 Rule at a metamodel inde- Transition from one class state to another state can pendent level be caused by calling operation of the class. Rule at the Rule Protocol transition of protocol state model has to be metamodel defined by operation of the class model. specific Associated Operation of ProtocolTransition of Pro- level metaelements Class model tocol State Model Enforcement level Medium Description According to OOAD, significant changes of the state of the object are modelled using state diagrams (Bennet et al. 2010).

ANNEXES 131

Description (continued) There are two types of state models: protocol state and behaviour state machine models. A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier can be called and in which state (OMG 2009). According to the UML metamodel, which part is in Fig. 2.3, operation is not mandatory for protocol transition. But in practical situations it is necessary to know what operation execution causes the transition of states. Having analysed OOAD UML metamodel specification (OMG 2009) and specific information system models (MSISD 2009a, MSISD 2009, MSISD 2010), we arrived at the conclusion that it is necessary to define an operation, which determines movement of an object from one state to another state. The transition can be also caused not only through execution of an operation (it is activated by call event) but also by other events, e.g., time, creation, destruction, signal. Therefore, an enforcement level of this rule is medium.

1.1 Do you under- 1.2 Do you know 1.3 Does the rule 1.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (descrip- the rule? tion of application)? Yes Yes Yes Yes May be May be May be May be No No No No

2. Specification of a consistency rule Rule 2: For each actor in a use case diagram there must exist a matching class in the sequence diagram. 2.1 Do you under- 2.2 Do you know 2.3 Does the rule 2.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (description the rule? of application)? Yes Yes Yes Yes May be May be May be May be No No No No

3. Specification of consistency rule Rule 1: message name must match class method Rule 1 states that the name of a message must match a method in the receiver’s class.

132 ANNEXES

3.1 Do you under- 3.2 Do you know 3.3 Does the rule 3.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (description the rule? of application)? Yes Yes Yes Yes May be May be May be May be No No No No

4. Specification of consistency rule Consistency rule ID R2 Rule at a metamodel inde- The class which states are modelled has to be known pendent level in the Protocol states model. Rule at the Rule Context of protocol states has to be defined by the metamodel class. specific Associated Context of Protocol Classifier of Class model level metaelements State Machine Enforcement level High Description A protocol state machine presents possible and permitted transitions on the instances of its context classifier, together with the operations that carry the transitions (OMG 2009). Only classifier of a class has operations; therefore, it can be derived that a protocol state machine is used to model states of classes. In this manner context – the class, which operations can be called, and their execution that determines changes of states of the object have to be defined. The origin of this constraint is the analysis of UML superstructure specification provided by OMG (OMG 2009) and OOAD method, which in- troduce that OOAD method. According to OOAD, significant changes of the state of the object (described by the class) are modelled using state diagrams (Bennet et al. 2010).

4.1 Do you under- 4.2 Do you know 4.3 Does the rule 4.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and nec- the rule? are associated by UML metamodel? essary (description of the rule? application)? Yes Yes Yes Yes May be May be May be May be No No No No

ANNEXES 133

5. Specification of consistency rule Consistency rule ID R5 Rule at a metamodel inde- Call Message of an object has to be associated with pendent level Operation of a class. Rule at the Rule Message, which is caused by CallEvent, should have metamodel an operation assigned. specific Associated Operation of Class Message of Interaction level metaelements model model. Enforcement level High Description According to OOAD, Message specifies the sender and receiver objects and the actions of stimulus (Bennet et al. 2010). An object is represented by Lifeline in a sequence diagram. A Message may correspond to calling an operation or raising a signal (Bennet et al. 2010), e.g. creating or destroying an Instance (MagicDraw 2011a). When a Message represents an Operation invocation, the arguments of the Message are the arguments of the CallEvent occurrence on the receiving Lifeline. A call event may cause the invocation of a behaviour that is a method of the operation referenced by the call request, if that operation is owned or inherited by the classifier that specified the receiver object (OMG 2009). Hence, the origin of this rule is OOAD method (Bennet et al. 2010) and UML Superstruc- ture specification (OMG 2009). According to it, which fragment is provided in Fig. 2.6, CallEvent may have only one operation assigned. Therefore, the enforcement of this rule is high. If Call Message is created, it is required to refer its operation of Class.

5.1 Do you under- 5.2 Do you know 5.3 Does the rule 5.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (description the rule? of application)? Yes Yes Yes Yes May be May be May be May be No No No No

134 ANNEXES

6. Specification of consistency rule

6.1 Do you under- 6.2 Do you know 6.3 Does the rule 6.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (description the rule? of application)? Yes Yes Yes Yes May be May be May be May be No No No No

7. Specification of consistency rule Rule 10: Each class in a class diagram must have a corresponding state. 7.1 Do you under- 7.2 Do you know 7.3 Does the rule 7.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (description the rule? of application)? Yes Yes Yes Yes May be May be May be May be No No No No

ANNEXES 135

8. Specification of a consistency rule Consistency rule ID R9 Rule at a metamodel inde- Activity diagram has to be associated with a use case pendent level that behaviour it (activity) explains or with operation that it detailed. Rule at the Rule Activity has to be associated with a corresponding metamodel use case or operation. specific Associated Activity of Use case of Use case model level metaelements Activity model or Operation of Class model Enforcement level Medium Description Activity diagrams can be used to model a system function represented by a use case. They can be also used at a low level to model the detail of how a particular operation is carried out (Bennet et al. 2010). Therefore, it is required to associate an activity diagram with the use case or operation of the class. Sometimes more complicated actions of an activity model can also be detailed by an activity diagram (Hay 2011). Therefore, the enforcement of the rule is medium.

8.1 Do you under- 8.2 Do you know 8.3 Does the rule 8.4 Is the rule reliable stand semantic of what metaelements conform to OMG (known origin) and the rule? are associated by UML metamodel? necessary (description the rule? of application)? Yes Yes Yes Yes May be May be May be May be No No No No

9. What is your qualification? IS analyst IS designer Programmer Tester Other

Rūta DUBAUSKAITĖ RESEARCH ON CONSISTENCY CHECKING OF DIFFERENT ASPECTS MODELS OF THE INFORMATION SYSTEM Doctoral Dissertation Technological Sciences, Informatics Engineering (07T)

Rūta DUBAUSKAITĖ INFORMACINĖS SISTEMOS SKIRTINGŲ ASPEKTŲ MODELIŲ DARNOS TIKRINIMO TYRIMAS Daktaro disertacija Technologijos mokslai, informatikos inžinerija (07T)

2012 10 04. 13,0 sp. l. Tiražas 20 egz. Vilniaus Gedimino technikos universiteto leidykla „Technika“, Saulėtekio al. 11, 10223 Vilnius, http://leidykla.vgtu.lt Spausdino UAB „Ciklonas“ J. Jasinskio g. 15, 01111 Vilnius.