real-time uml to xmi conversion final version · real-time uml to xmi conversion shankar gopinath...

Real-Time UML to XMI Conversion

S H A N K A R G O P I N A T H

Master of Science Thesis Stockholm, Sweden 2006


S H A N K A R G O P I N A T H

Master’s Thesis in Computer Science (20 credits) at the IT Program Royal Institute of Technology year 2006 Supervisor at CSC was Henrik Eriksson Examiner was Stefan Arnborg TRITA-CSC-E 2006:107 ISRN-KTH/CSC/E--06/107--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se


Abstract

The development of certain systems at a large telecom company is done using Rational RoseReal Time. The goal of the project is to convert the implementation models designed with RoseRT into XMI (eXtensible Markup Language Meta Data Interchange). The generated XMI isthen suggested to be mapped to a Real Time Profile of UML 2.0.The generated XMI is fed intoa code generator to generate code and the code generation is carried out in a separatecomplimentary project called “XMI-based Code Generation for Real-Time Systems”.

The XMI conversion is done by a script written in EBS (Extended Basic Script) which wasdeveloped as a part of the project. For this conversion to be successful, mapping differentconcepts of Rose Real Time to an invented UML profile was necessary. This is because theXMI version chosen for conversion supports neither UML RT (Rose Real Time standard) northe UML 2.0 standard. Several real time concepts in UML RT are exported by means of specifictags represented in the XMI.

The Rose RT model is transformed to XMI in 2 stages. In Stage 1, the model is translated intoan XMI format which is compliant with a modified UML RT standard. In Stage 2, this XMI isthen fed into an XMI reader and the meta-model information in MOF (Meta Object Facility) isgenerated. The generated XMI is checked for the proof of concept by importing it into modelingtools and in the code generator through the NSUML XMI reader.

For making the models compliant with the Real Time Profile of UML 2.0, a set of mappingrules are suggested in this thesis. These rules could be implemented when a decision is made tocomply with the UML 2.0 based profile. The thesis is concluded by suggesting furtherdevelopments with the script, the different options available in future work and the requiredfuture work.

Konvertering av Real-Time UML till XMI

Sammanfattning

Ett stort telekommunikationsföretag använder Rational Rose RealTime för utvecklingenav vissa av sina system. Målet med detta examensarbete är att konvertera modellerutformande med Rose RT till XMI (eXtensible Markup Language MetadataInterchange). Den genererade XMIn föreslås använda en realtidsprofil av UML 2.0.XMIn importeras in i en annan kodgenerator som skapar kod från modellerna. Dennakodgenerering behandlas i examensarbetet ”XMI-baserad kodgenerering avrealtidssystem”.

Konverteringen till XMI görs med hjälp av ett skript skrivet i EBS (Extended BasicScript) som utvecklats som en del av detta examensarbetet. För lyckad konvertering varkartläggning av olika koncept i Rose Real-Time nödvändig för att skapa UML-profilen.Anledningen till detta är att den valda XMI versionen varken stöder UML Real-Time(Rose RT standard) eller UML 2.0 standard. Flera realtidskoncpet i UML RT exporterasmed hjälp av specifika XMI tags.

Rose RT modeller omvandlas till XMI i två steg. I första steget omvandlas modellernatill ett format i XMI som är anpassad till den skapade UML profilen. I det andra stegetläser en XMI-läsare in XMIn och metamodellinformation i MOF (Meta Object Facility)skapas. Den genererade XMIn undersöks för proof of concept genom att den importerasin i modelleringsverktyget och kodgeneratorn genom NSUMLs XMI-läsare.

En uppsättning regler föreslås för att anpassa modellerna till profilen av UML 2.0genom mappning mellan metamodellen och realtidsprofilen av UML 2.0 Dessa reglerkan implementeras när det beslutas att emigrera till profilen i UML 2.0. Denna rapportavslutas med förslag till framtida utveckling av skriptet för export av XMI, olikamöjligheter till framtida arbete och nödvändigt framtida arbete.

Keywords: UML 2.0, UML RT, Rose RT, RTP UML 2.0, RTP UML 1.4, UML 1.3, 1.4 , XMI (1.0 ,1.1,1.2,2.0,2.1),XML,OMG, MDA,MOF,CWM,mapping, capsules, classes, protocols, capsule roles, portroles, protocol roles, Code Generation, MDR, JMI.

Acknowledgements

First of all I sincerely thank my manager Mr. Roger Holmberg and my supervisor Mr. AkilanTiburtius for giving a wonderful opportunity to work on this project and for their excellentsupport and guidance throughout.

I thank my project partner Christofer Janstål for his precious contribution and support. I alsothank Christofer for his Swedish translation and feedbacks on the report. I am very grateful forthe direction and support that I received from Chris Knowles and David Pilfold which made metake the right approach. I express my utmost gratitude to Henrik Eriksson, Supervisor at KTHfor his support and feedbacks. I also thank Per Brand, Karl- Filip- Faxen of SICS for theirvaluable support and comments which made me gain greater insight into the subjects.

I also thank Ann Bengtson my coordinator and Stefan Arnborg, my Examiner. I am verythankful to Diarmuid Corcoran for his advice and feedback on the thesis work at various stages.I also thank Ludomir Rewo, Fredrik Lunnel, Qinghong Liu and Michael Williams for being ofsupport at various stages.

I would like to thank Andreas Rosblom for his advice, feedback and generosity in offeringspace for the thesis website internally in the telecom company. I also thank SamuelHabtessillasie, James Centerstam and Habib Malekdanesh for their time and effort on theinterview on questions on suggestions for improvement of Rose RT. I also would like to thankJuergen Wuest for the answers to questions that I posted in umlforum.

I would like to thank my beloved parents Savithri Gopinath, Manghat Gopinath and my fiancéeJustina for their invaluable love, wonderful support and much needed words instillingconfidence and encouragement, especially during tough times. I sincerely thank the reader fordedicating the time in reading this report.

Thank you once again!

Shankar GopinathStockholm, June 2006

Contents1 Introduction ............................................................................................................................ 1

1.1 Background ...................................................................................................................... 1

1.2 Problem definition............................................................................................................ 2

1.3 Goal.................................................................................................................................. 2

1.4 Major Tasks of the Project ............................................................................................... 3

1.5 UML and XMI Standards used for conversion ................................................................ 3

2 Technical background............................................................................................................. 4

2.1 UML Real Time (UML RT/Rose RT) ............................................................................. 4

2.1.1 Introduction........................................................................................................... 4

2.1.2 Real-Time UML Elements .................................................................................... 5

2.2 Open Technologies in the Project .................................................................................. 13

2.2.1 OMG (Object Management Group) Technologies.............................................. 13

2.2.2 JMI ...................................................................................................................... 26

2.3 What is a UML Profile and how is it built? ................................................................... 26

2.4 Extended Basic Scripting and Extensibility Reference.................................................. 27

2.5 Open Source XMI Handlers........................................................................................... 28

3 Technical Solution................................................................................................................ 29

3.1 Comparison of UML RT and UML 2.0 Standard .......................................................... 29

3.2 Comparison of XMI versions......................................................................................... 30

3.3 Comparison of XMI Versions, UML Versions and Supporting Tools ......................... 31

3.4 Comparison of XMI Versions and Open Source XMI readers ...................................... 32

3.5 Decisions Made on XMI and UML ............................................................................... 32

3.6 Invention of Profiles....................................................................................................... 33

3.6.1 Creation of RTP UML 1.4 .................................................................................. 33

3.6.2 Creation of RTP UML 2.0 .................................................................................. 34

3.7 Methodology .................................................................................................................. 35

3.8 Implementation .............................................................................................................. 36

3.8.1 STAGE 1: Mapping of UML RT Model to RTP UML 1.4 ................................ 36

3.8.2 STAGE 2: Generation of Metamodel.................................................................. 58

3.8.3 STAGE 3: Proposal for mapping to RTP UML 2.0 ............................................ 59

3.9 What about Diagram Information of the models?.......................................................... 61

4 Results .................................................................................................................................. 62

4.1 Verification .................................................................................................................... 62

4.2 Learning Process ............................................................................................................ 63

5 Options Available and Future Work..................................................................................... 64

5.1 Evaluation of Options .................................................................................................... 64

5.2 Checklist and Future Work ............................................................................................ 65

References................................................................................................................................... 66

OMG Documents: ................................................................................................................ 66

XMI Handlers:...................................................................................................................... 67

General Research Publications ............................................................................................. 68

IEEE Research Publications ................................................................................................. 68

Teaching and Projects........................................................................................................... 69

Literature .............................................................................................................................. 69

Miscellaneous ....................................................................................................................... 70

Appendix..................................................................................................................................... 71

A: How the code generator should work with Real-Time elements? ................................... 71

B: Pilot Study and Empirical Findings ................................................................................. 73

Study on code generators and their Evaluation.............................................................. 73

Brief improvement suggestions for Rational Rose Real Time....................................... 77

C: XMI Representation of Model Traffic System ................................................................ 78

D: Verification...................................................................................................................... 91

Syntax Verification ........................................................................................................ 91

Semantics Verification................................................................................................... 91

E: Developed Script for Export ............................................................................................ 92

F: Project plan....................................................................................................................... 93

Plan made during the start of the Project: ...................................................................... 93

Plan of working through ArgoUML - Plan Made in February: ..................................... 94

Plan of working through the Script: Latest Plan Made in March................................... 95

Glossary ...................................................................................................................................... 96

LIST OF FIGURES

Figure 1: Simple Representation of Work Flow of the Project_________________________________ 2Figure 2: Mapping Procedure and invented Profiles ________________________________________ 3Figure 3: Representation, Structural diagram, State diagram and Specification Dialog of a Capsule __ 7Figure 4: Types of Ports and their representations __________________________________________ 9Figure 5: Logical and Structural view of a Port in a Capsule _________________________________ 9Figure 6: Protocol Roles _____________________________________________________________ 11Figure 7: Protocol in Logical view _____________________________________________________ 11Figure 8: A Class representation of a Capsule with stereotype _______________________________ 14Figure 9: Constraint for Extension Mechanism____________________________________________ 15Figure 10: Tagged Value for Extension Mechanism ________________________________________ 15Figure 11: A simple relationship between Extensibility Mechanisms for an Element_______________ 16Figure 12: Meta Object Facility Architecture _____________________________________________ 17Figure 13: Meta Modeling Example: A Part of UML 1.4 Metamodel___________________________ 18Figure 14 : A Class Metamodel : M3 Layer description _____________________________________ 19Figure 15: XMI, Interoperability and Eclipse functionality __________________________________ 20Figure 16: Role of XMI in model transformation __________________________________________ 21Figure 17: A very simple class ________________________________________________________ 23Figure 18: UML representation of MDA_________________________________________________ 24Figure 19: MDA and code generation process ____________________________________________ 25Figure 20: Relationship of JMI, XMI and MOF ___________________________________________ 26Figure 21: Creation of an UML Profile__________________________________________________ 26Figure 22: Ecore XMI reader and functionality ___________________________________________ 28Figure 23:Rose RT Model to RTP UML 2.0 Metamodel through XMI __________________________ 35Figure 24: Relationship between ports, Protocols, Protocol roles _____________________________ 39Figure 25 : Representation of Real Time concepts: A sender and Receiver Capsule example________ 39Figure 26: Association relationship examples_____________________________________________ 43Figure 27 : Generalization relationship example __________________________________________ 45Figure 28 : Dependency relationship example ____________________________________________ 47Figure 29: Simple Metamodel of a State machine__________________________________________ 51Figure 30: State Diagram in a Capsule__________________________________________________ 51Figure 31: The Initial Control flow in the script ___________________________________________ 54Figure 32: The Branching of Control through different sections ______________________________ 54Figure 33: Export of Classes in XMI____________________________________________________ 55Figure 34: Export of Capsules in XMI __________________________________________________ 56Figure 35:Export of Protocols in XMI___________________________________________________ 57Figure 36: Export of Tags in XMI ______________________________________________________ 58Figure 37:Generation of RTP UML 1.4__________________________________________________ 59Figure 38: Methodology for RTP UML 2.0 Mapping _______________________________________ 60Figure 39: Generation of Capsule in C++ _______________________________________________ 71Figure 40: Mapping Capsules to RT Library _____________________________________________ 71Figure 41: Capsule Role Generation____________________________________________________ 72Figure 42: Port generation in C++ Code ________________________________________________ 72Figure 43: Generation of Protocols ____________________________________________________ 72Figure 44: A relation Dialog in BoUML _________________________________________________ 74Figure 45: A header file and its definition templates generated by the Generator _________________ 74Figure 46: Observed Benchmark of BoUML______________________________________________ 75Figure 47 : Traffic System Model with additional class _____________________________________ 78Figure 48: Sample State Machine for the Capsule TrafficSystem ______________________________ 87Figure 49: Verification of Syntax ______________________________________________________ 91Figure 50:Import into CodeGenie for Verification of metamodel ______________________________ 91Figure 51: Execution of the developed script on a Traffic System model ________________________ 92Figure 52: Plan during the beginning of the Project________________________________________ 93Figure 53: Working through both Unisys and Argo UML: Plan after the responsibilities were defined 94Figure 54: Performing different tasks in Script - Plan ______________________________________ 95

LIST OF TABLES

Table 1: Types of Capsule roles_________________________________________________________ 6Table 2: Access identifiers for Capsule Visibility ___________________________________________ 6Table 3: Types of Ports _______________________________________________________________ 8Table 4 : Major Elements and their roles in a State Machine _________________________________ 12Table 5 : Different kind of state diagrams in UML RT ______________________________________ 12Table 6: Brief Summary of OMG standards ______________________________________________ 13Table 7: Usage of XMI ______________________________________________________________ 22Table 8: XMI and UML versions compatibility - In brief ____________________________________ 22Table 9: XMI output for a simple model _________________________________________________ 23Table 10 : Comparison of UML RT and UML 2.0 Standard __________________________________ 29Table 11: Comparison of major features of XMI versions____________________________________ 30Table 12: Comparison of UML, XMI versions and supporting tools____________________________ 31Table 13: Comparison of XMI versions and Open Source XMI readers _________________________ 32Table 14: Decisions on the Choice of Versions ____________________________________________ 32Table 15:RTP UML 1.4 Evolution ______________________________________________________ 33Table 16 : RTP UML 2.0 Evolution _____________________________________________________ 34Table 17 : Mapping Core RT Concepts to RTP UML 1.4 ____________________________________ 36Table 18: Mapping Secondary RT concepts to RTP UML 1.4_________________________________ 37Table 19: RT Elements of State machine mapping to RTP UML 1.4____________________________ 38Table 20: Properties and Representation Common to all Elements in the Model__________________ 41Table 21 : Major Constructs of an Association relationship in XMI____________________________ 42Table 22: Example XMI Output for association ___________________________________________ 44Table 23 : Major Constructs of an Association relationship in XMI____________________________ 45Table 24: Example XMI output for Generalization _________________________________________ 46Table 25 : Major constructs in a Dependency relationship___________________________________ 47Table 26 : Example XMI of Dependency relationship _______________________________________ 47Table 27: XMI representation of Attribute and Operation ___________________________________ 48Table 28: Major Constructs of a Capsule in XMI __________________________________________ 49Table 29: XMI and common properties for State Machines __________________________________ 50Table 30: Major constructs of the state diagram example____________________________________ 52Table 31: Common constructs of Tagged Values __________________________________________ 53Table 32: Mapping RTP UML 1.4 to RT UML 2.0 _________________________________________ 60Table 33:Export of Diagram Information of elements ______________________________________ 61Table 34: Options available from the current point ________________________________________ 64Table 35 : Checklist of Goals and Future Work ___________________________________________ 65Table 36: Actions required by the code generator to work with RT Library______________________ 72Table 37: Other code generators in Market ______________________________________________ 76Table 38: Suggestions and Requests on Rose Real Time_____________________________________ 77Table 39 : Suggestion to an issue in Rose RT _____________________________________________ 77

LIST OF EQUATIONS

Equation 1:The UML RT Formula ______________________________________________________ 4Equation 2: Code Generation for Capsule formula__________________________________________ 5Equation 3: XMI Formula ____________________________________________________________ 19Equation 4: RTP UML 1.4 Formula ____________________________________________________ 33Equation 5: RTP UML 2.0 Formula- Suggestion 1 _________________________________________ 34Equation 6: RTP UML 2.0 Formula- Suggestion 2 _________________________________________ 34

1

1 IntroductionThe rationale of this chapter is to introduce to the user to the scenario of Real Time Modeltransformation to XMI, the general process of transformation, motivation of the project, the directionand development.

1.1 BackgroundRational Rose Real Time (Rose RT) is a prime software used for telecommunication systems to bemodeled in UML RT® standard and to be sufficiently deployed. The birth of XMI® has enabled thepossibility of converting the UML RT models into XMI which is used for model transformation andinteroperability of models.

XMI is an XML® (eXtensible Markup Language) based document representing model elements andtheir information in an interchangeable format. It is the standard specified by OMG® (ObjectManagement Group) for exchanging information of the models. This Information and detail of themodels involved is known as Metadata. In XMI, “X” stands for XML, “M” stands for Metadata and “I”for Interchange. This transformation of the models into XMI is indeed a major breakthrough infacilitating interoperability [6] [8] [10] [11] [12] [29] across various tools and platforms.

XMI is the XML representational format for interoperability of the designed and developed UMLmodels. The XMI is built from a metamodel storage facility called MOF® (Meta Object Facility) [SeeFigure 12: Meta Object Facility Architecture and Figure 16: Role of XMI in model transformation].This XMI generated would then be required to be fed into an XMI reader so that the metamodelinformation is built back. The metamodel information is then used for generation of code. Thegeneration of code is carried out by a code generator and is done by [24] in the project.

The platform design and development at the telecommunication company is done using a tool thatsupports a complete lifecycle of UML development environment in real time known as Rose Real Timeand uses RUP (Rational Unified Process) through ROOM (Real Time Object Oriented Modeling).Rational Rose Real Time functions vigorously with Capsules which can be thought of active structuredclasses with containment in UML 2.0. Capsules are the most important elements in a Rose Real Timemodel and their behavior is provided by an embedded state machine in them. This project involvesconverting the Real time models into XMI for migration of the models to a code generating tool togenerate code. XMI can be seen as a formalized standard for object data interchange fosteringcollaborative development. The XMI which is generated from Rose RT models is produced through a 4layer architecture called Meta Object Facility (MOF) where the 4 levels represent 4 different levels ofabstraction (See Figure 12: Meta Object Facility Architecture ).

When the XMI is read into the XMI reader, this process is reversed and the metamodel information inthe MOF is built back. This metamodel is used by a code generator to produce code. In addition toproviding input for code generation, XMI can provide DMI (Distributed Metadata Interchange),interoperability framework across a number of IDL (Interface Definition Language) platforms and alsoenables web publishing. Though there is a plethora of interoperability possibilities with XMI, XMI isused for transformation of Rose Real Time models in this project for the generation of code through anew code generating tool.

2

1.2 Problem definitionProcesses involved in transformation of UML Real Time Models to Code and the area of concentration:

Figure 1: Simple Representation of Work Flow of the Project

Processes 1, 2, 3, 4, 5 belong to the current project Real Time UML1 to XMI conversion and is the area ofconcentration of this work and report.

Processes 5, 6, 7 belong to the complimentary project XMI-based Code Generation of Real-TimeSystems and is carried out by the partner Christofer Janstål as a separate project.

Note: Process 5 is the link between the two projects.

The Model in Rose RT is transformed into an XMI format which is then fed into the XMI readerpresent in the code generator. The code generator usually has either its own XMI Reader or a thirdparty XMI plug in or may use some open source XMI plug in as well. This XMI Reader wouldproduce the metamodel information from the architecture called MOF (See Figure 12: Meta ObjectFacility Architecture) and is used by the code generator to produce code. T The current project woulddeal with the conversion of Rose Real Time Model into XMI using the XMI script and producing theModel information from the XMI reader (Process 5). In the complimentary project [24] carried out byChristofer Janstål, The Model Information (Process 5 in Figure 1: Simple Representation of WorkFlow of the Project ), is to be used in the code generator to produce Code. (Process 5, 6, 7)

1.3 Goal

To transform the Real time UML models developed using Rational Rose Real Time tool into a metadatainterchangeable format called XMI. This is done through a script written inside Rose Real Time. This XMIgenerated should be verified for its integrity to check if all the elements of the model are exported.

The XMI generation must be done after evaluating various XMI formats and UML formats, the XMI readersavailable and their compatibilities. This XMI generation would require mapping of various Real Timeconcepts such as Capsules, Ports, Protocols, State machine and their elements to a new Real Time Profile2 ofUML 1.4 which should be invented for export (See 1.5: UML and XMI Standards used for conversion).This UML profile must then be mapped to a Real Time Profile of UML 2.0. Initially, there was a goal forevaluating different code generators and suggesting improvements in Rational Rose Real Time. This wasundertaken and the results were documented.

1 Real-Time UML refers to UML RT® or Rose RT standard from Rational. This should not be confused with“Real Time UML” or “RT UML”, both standards of “Rhapsody from I-Logix”. Both are not OMG standards.2 For more information on What a Profile is please see 2.3:What is a UML Profile and how is it built? on Page 26

3

1.4 Major Tasks of the Project Mapped the concepts of Rose RT to an invented intermediary format called RTP UML 1.43 for

the export of models to XMI.

XMI versions and UML versions, their compatibilities, dependencies and tools which supportthem briefly documented.

A script for the export of Real Time Models to XMI 1.0 complying with RTP UML 1.4 waswritten and its working was documented.

XMI version 1.0, its syntax and semantics discussed for major elements.

Mapping from RTP UML 1.4 to a Real Time Profile UML 2.0 suggested.

Analyzed some code generators and Brief improvement suggestions made for Rose RT.

How the code generator should work with mapped elements is briefly discussed underAppendix A: How the code generator should work with Real-Time elements?

The tasks which require further work and improvements are listed under Section 5:OptionsAvailable and Future Work.

1.5 UML and XMI Standards used for conversionFor enabling the process of conversion of UML RT models into XMI, there has to be a set of mappingsmade from the UML RT standard to an invented profile of UML. The XMI format 1.0 was chosen forexport and it supports only till UML 1.3. Hence a profile was built in the beginning called RTP UML1.4 (Real Time Profile of UML 1.4) [See Equation 4: RTP UML 1.4 Formula] which is therepresentation of Real Time Concepts of UML RT in addition to UML 1.3 standard supported by XMI.

A set of mapping rules are suggested for mapping from RTP UML 1.4 to RTP UML 2.04 (Real TimeProfile of UML 2.0). This can be implemented directly by choosing XMI 2.0 as the standard of exportsince it supports UML 2.0. See3.3: Comparison of XMI Versions, UML Versions and SupportingTools . Thus the invented profiles and the XMI version relationship are portrayed in Figure 2 asfollows:

XMI 1.0 UML 1.3support till

UML RT concepts represented asextensibility mechanisms in XMI 1.0

RTP UML 2.0

RTP UML 1.4mapping

mapped to

Figure 2: Mapping Procedure and invented Profiles

3 RTP UML 1.4 is not an OMG standard. It is an invented profile in this project. See Equation 4: RTP UML 1.4Formula4 See Section 3.6 Invention of Profiles and Equation 6: RTP UML 2.0 Formula- Suggestion 2

4

2 Technical backgroundThe purpose of this chapter is to explain different concepts and terminologies used in the area of modeltransformation. These concepts are a key for understanding the coming chapters. The UML Real Timesection is based on the Rational Rose Real Time manual [35] whereas the OMG section is based onOMG specification documents [1] to [15].

2.1 UML Real Time (UML RT/Rose RT)

2.1.1 Introduction

2.1.1.1 What is UML RT?

UML RT aka Rose RT aka ROOM is the real time standard of UML defined by Rational Corporation.It functions rigorously through capsules which models a low level concurrency [36] to the system. It ismostly used for complex, event- driven and distributed system applications. It is also used widely intelecommunication industry where the functionality of the systems is event driven.

2.1.1.2 Evolution of UML RT

The UML RT is a standard that evolved from ROOM (Real Time Object Oriented Modeling). It is acombination of ROOM and UML [40].

Early version of ROOM:

ROOM is a visual modeling language with formal semantics. It was designed for specifying,visualizing, documenting, and automating the construction of complex, event-driven, and real-timedistributed systems [25]. It has role modeling concepts which has an architectural design concept. TheROOM modeling language has a terminology that is significantly different from the current ROOMstandard also known as the UML RT standard. For example: A Capsule in UML RT is called as anActor in the earlier version of ROOM. The current version of ROOM is also called as UML RT and isused in Rational Rose Real Time’s RUP (Rational Unified Process).

UML:It is a general-purpose modeling language for specifying, visualizing, constructing and documenting theartifacts of software systems, as well as for business modeling and other non software systems. UML isnot considered to be a formal specification language due to the lack of well defined fully explorativesemantics [33]. Despite of the lack of formal semantics, UML is used as a de facto standard in theindustry, business and academia for modeling systems. The modern version of UML RT or ROOM isformulated as follows in Equation 1.

Equation 1:The UML RT Formula

Resultant UML RT:

The standard arising from the combination of Early ROOM version and new UML transformation rulesled to the evolution of a more standard Real Time variant of UML called UML RT or Rose RT andvery rarely referred to as ROOM.

The focus of UML RT is on the following concepts:

5

Component oriented construction platform

Components are active and ready for compilation

Communication is mainly based on signal exchange.

Complex architecture

Event driven mechanism, timeliness and Distributed framework.

2.1.2 Real-Time UML Elements

2.1.2.1 CAPSULE

It is an Active class [35] which bears a skeleton similar to that of a class, in addition to attributes andmethods have state machines which give it its dynamic behavior. A capsule communicates with theoutside world through ports. It is a mix of conventional C++ classes and active capsule classes in termsof implementation. A Capsule is also an Active object [25] which owns a logical thread and initiatescontrol typically representing an active unit of computation. A Capsule has two types of diagrams.

1. A State Diagram/ Behavioral diagram, which is a directed graph consisting of states andtransitions which enable the transition to different states. A state diagram, hence describes the lifehistory of objects of a given class. A state machine can contain only one initial state and initialtransition, one top state, one or more simple states, the corresponding number of state transitionsbetween them and one or more choice points.

2. A Structure diagram, which is a collaboration diagram used for specifying the pattern ofcommunication but at the same time it is different from the conventional collaboration diagram becauseof the following reasons

There could be no association roles between capsule roles which are allowed in normalcollaboration diagram.

Ports could be shown on the boundary to indicate their public visibility. They can be shownaside the boundary if they are invisible and protected. This is also because capsulescommunicate with each other using ports and not operation invocation as in collaborationdiagram.

Capsule boundary shows capsule encapsulation and also ports as interfaces.

In collaboration diagram connectors are nothing but associations connecting capsule roles butin Capsule structure diagrams the communication is between capsule ports.

A structure diagram in a capsule might contain the following elements:

1. Non real time elements such as attributes and operations as in Classes.

2. Collaborating Capsule roles and port in it and the phenomenon of having such collaboration isknown as Capsule Collaboration

A sequence diagram is represented inside the Capsule structure diagram. The Capsule owns the portand capsule roles directly and port roles indirectly (See Figure 24: Relationship between ports,Protocols, Protocol roles). Capsule role is a specification of the capsule which gives it a particular rolein collaboration. The Capsule structure diagram elements determine the amount of code in its headerfile during generation of code as can be formally written as follows:

Equation 2: Code Generation for Capsule formula

Here “α” represents proportionality relationship.

6

Artifacts owned by a Capsule:

Capsule Roles, Ports and Port roles (indirectly through Ports).

The various artifacts of the capsule and the different elements present in it are depicted in Figure 3.

Types of Capsule roles:

There are 3 different types of Capsule roles. Capsule roles have a composition relationship with theCapsules and hence created and destroyed by them.

Fixed It is the default type of the capsule role. Such capsule roles are created anddestroyed automatically when their container is created and destroyed.

Optional Such capsule roles are created subsequently if necessary by the statemachine of the capsule and can be destroyed even before the container isdestroyed.

Plug in These are placeholders for capsule roles to be filled in dynamically. This isuseful sometimes because it is not always possible to know in advancewhich specific objects will play these roles at run time.

Table 1: Types of Capsule roles

Capsules could have different levels of visibility. They are as follows in Table 2

Visibility of a Capsule:

A Capsule in itself mostly has a public visibility allowing it to be accessed by other model elements butit could also have other values as in Table 2: Access identifiers for Capsule Visibility in some cases.However, the elements inside a Capsule are always private except the port.

The various possibilities of visibility are as shown in Table 2: Access identifiers for Capsule Visibility

Public Accessible by every other model element.

Implementation The Capsule is visible only to Capsules in the same package

Private Accessible only to itself and any friends it might have

Protected Accessible only to subclasses, friends and itself

Table 2: Access identifiers for Capsule Visibility

Capsules are the most vital part of UML RT standard. They help to model low level concurrency in thesystem. Their behavior is given by the state diagram which contributes to its dynamic behavior. Thedifferent views and elements in a Capsule is represented in the Figures 3(a) through 3(f) under Figure3: Representation, Structural diagram, State diagram and Specification Dialog of a Capsule

Example:

Consider the following set of diagrams of Capsules:

Figure 3: Representation, Structural diag

The Capsule is a class of stereotype “Cwith stereotype”<<Capsule>>”. In Figdefines the transition in between themare the transitions and they are definedand yellow are the three states. Fig 3(b)Light Capsule respectively. The sequerepresents the connectivity of capsulespecification of the capsule which repvarious capsule roles, ports other than a

See also Figure 24: Relationship betmetamodel. The Capsule role is represediagram of another capsule. This particicomposition relationship with the con“controller” is the capsule role and the c

Further, the capsule role owns port role“south”, “east” and “west” referencing t

aD

3(f) Capsule SpecificationDialog

3(a) Capsule in Logical view3(b) Capsule structure

diagram

Capsule

3(e) Structure Diagram ofCapsule : Sequence

iagram

TrafficLight

+ / control : LightControl

<<Capsule>>

(from Items)

7

ram, State

apsule”. H3(d), the

in the Trafwith the coand Fig 3nce diagras and theresents itsttributes, o

ween pornted in Fipation is rtainer capapsule “C

s which arhe protoco

/ controllerR1 : Controller+ / west

: LightControl

+ / north: LightControl

+ / east: LightControl

+ / south: LightControl

+ / control: LightControl

/ controllerR1 : Controller+ / west

: LightControl

+ / north: LightControl

+ / east: LightControl

+ / south: LightControl

+ / control: LightControl

3(c) Capsule role in the structure diagram of another

3(d) State Diagram of a Capsule

diagram and Specification Dialog of a Capsule

ence in Fig 3(a), the Capsule is represented as a classState Diagram shows that there are three states andfic System capsule. Here goGreen, goYellow, goRedde to be executed during the transition and red, green(e) shows the State and Structure diagram of a Trafficm in a capsule is also a structure diagram since ittime based exchange of messages. Fig 3(f) is thevarious properties and dependencies. It shows the

perations and any code written in it.

ts, Protocols, Protocol roles for a brief UML RTg 3(c) where the capsule participates in the structureeferred to as the collaboration. The capsule role has asule and cannot exist without it. In the Fig 3(c),

ontroller” is referenced.

e seen on the boundary of the capsule role as “north”,l “LightControl” which defines them.

8

2.1.2.2 PORT

Ports are objects that are created and destroyed by the Capsules and hence have a compositionrelationship with Capsule in the metamodel of UML RT. The purpose of ports is to exchange messageswith Capsule instances and is defined by Protocol roles. Ports play the role of a participant in acommunication relationship. Port role is a specific usage of a port needed in collaboration. Port role is aport which is bound to a Capsule role.

Requirement for communication:

Ports can communicate with each other only if they are defined by a common protocol (technically,protocol role) or by two different protocols which have the same definition.

Artifacts owned by a Port:

Port role

Different types of Ports:

Depending on the visibility of the port and the connection to the outside world, ports are classified intheir Termination criteria as Relay Port and End Port with the various combinations with visibility andconnection. The types of representation for the different types of ports are shown under Figure 4: Typesof Ports and their representations.

Visibility Criteria

Public This is a common setting. These ports can communicate with ports from othercapsules. They are located on the boundary of the Capsule. They are visible to allclients.

Protected These are used to connect capsules with capsules inside it. They are not visiblefrom outside.

Connection Criteria

Wired Port These are ports which are connected to other ports for sending messages

Non- wiredport

These ports are not connected to any port but can be used for communicationdynamically at run time

Termination Criteria

Relay Port Used to export the interfaces of capsule roles. They do not do any function exceptpassing the messaging arriving at them to capsule elements inside withoutexecution of any code a capsule might have. They are wired and public. Areconnected with another port in the same capsule. They facilitate encapsulation ofsub capsules.

End Port This can be public/protected/wired/nonwired. As the name suggests, this is whereall the signals sent by the capsules end. Messages to an end port can be executedby the state or behavior of the capsule.

Table 3: Types of Ports

Types of Ports:

Figure 4: Types of Ports and their representations

Example:

Consider the following set of diagrams depicting the various elements of ports. The interpretation isprovided in the section below.

Fig 5(a): The Logical view of Ports in a capsule

Figure 4 shows different combinationsof ports which are possible to be used ina capsule. Each type of port has adifferent representation and is used for adifferent purpose as a result of thecombination of 3 criterions namelyVisibility, Combination and Terminationas listed in Table 3: Types of Ports.

9

Figure 5: Logical and Structural view of a Port in a Capsule

Fig 5(b): The structuralview of ports inside aCapsule.

10

In Fig 5(a), the ports are present in the Capsule specification. The corresponding protocols whichdefine them are referenced. The logical view of the ports can show the visibility of them. For e.g. “+”means public, “-“is private and “#” is protected. Fig 5(b) shows the Structural view of the ports in aCapsule. Here it is possible to see 2 different types of ports: Here “east”, “west”, “north” and “south”are wired end ports. “Timing” is a protected non wired end port. The ports are owned by the Capsuleand hence each of the ports east, west, north and south has a composition relationship with the Capsule.

These ports are defined by the Protocol (actually they are defined by the Protocol role which is a part ofthe Protocol and is not shown here since its abstract). A port can be based or conjugated depending onthe definition from the protocol role. Fig 3(a) and Fig 3(b) show a port which is conjugated and isrepresented by a “~” symbol in front of the protocol which defines it. A conjugated port has the reversedefinition provided by the protocol in which the in and out signals are reversed. Fig 3(c) shows portroles which are represented as dots on the boundary of the Capsule role named “container”. Such portroles are wholly owned by the Capsule role as well as the Port. Deletion of either one of them wouldautomatically delete the port role as well and any connectors that it might have in the structure diagram.

A port role specification is visible only if a new protocol is defined different from the Real Timeprotocols such as Exception, External, Frame, Log and Timing. As in Fig 3(c), the port role is displayedon the boundary of the capsule role only if it is a relay port. This is because protected ports act onlywithin the capsule and are totally hidden from the outside world and when a capsule is used incollaboration with another capsule, protected ports are encapsulated and thereby nor visible.

2.1.2.3 PROTOCOL

These are rules which define the signals that can be exchanged by the ports in the capsules. TheProtocols define a set of messages which are nothing but In Signals or Out Signals with reference to theincoming and outgoing signals of the port. These signals are exchanged between two port objects. It canbe also defined as an agreement defining the valid types of signals that can be exchanged between themembers in the protocol. The members of a protocol play a specific role in the protocol. They are calledprotocol roles. Each such protocol role is specified by a unique name and a specification of messagesthat are received by that role as well as a specification of the messages that are sent by that role (eitherset could be empty).

There are additional elements that could be present in a protocol

The protocol may have a specification of the valid communication “sequences” which may bedefined by a state machine.

The protocol may also have a set of prototypical interaction sequences (these can be shown assequence diagrams).

Artifacts owned by a Protocol:

Protocol role.

Though the Protocol roles form a part of the Protocol as in Figure 6: Protocol Roles, they do not existbefore code can be generated. This is because the concept of Protocol role exists during run time and itis generated as base and conjugate protocols. This generation is based on the in and out signals sent andreceived through the ports of the Capsule to each other. Protocol role represents the communicationfrom one port to another port in a communication scenario.

Protocol roles in a Protocol:

Ex

Ash

2.

2.

Starbestaanta

Figure 6: Protocol Roles

ample:

Figure 7: Protocol in Logical view

detailed view of how Capsules, Ports, Protoown in Figure 24: Relationship between por

1.2.4 Other Major Elements in UML RT

1.2.4.1 State Machines:

ate Machines are used to describe and modee one of the most important elements in a Rehavioral elements which model a set of rolete machine defines the behavior of a Classd there are many elements inside a statebulated as in Figure 4: Types of Ports and th

rstsas

Hr

Figure 6: Protocol Roles shows the two types of rolesnamely base protocol role and conjugate protocol rolewhich are integrated into a protocol. Such type of rolesrepresents the communication from the perspective ofone of the participant (a capsule) in a communicationscenario. The base and conjugate protocol role havesignals which it receives known as “insignal” andsignals which travel out known as “outsignal” and theyare the inverse of each other. In other words, theinsignal definition of base protocol is the outsignaldefinition of the conjugate protocol and vice versa.Though two types of protocol roles exist in principle,they do not exist during modeling. Instead while thecode is generated, two classes named base andconjugate protocol roles are created deriving from thesame root protocol. One contains incoming signals andthe other contains the outgoing signals defined in theprotocol. More information on how the protocols getgenerated can be found under Appendix A: How the
code generator should work with Real-Time elements?
Figure 7: Protocol in Logical view shows the generalepresentation of a protocol. It could contain insignals and outignals. They define the signals that can be sent and receivedhrough the ports. In a Protocol definition, a data type ispecified in the data class field of the signal. The data can belso sent by reference; in this case the data class field of theignal is cleared.

The Structural view of a Protocol is shown under Fig 3(c).ere LightControl is the Protocol and its signals are green,

ed and yellow.

11

cols, Capsule roles, Port roles and Protocol roles relate ists, Protocols, Protocol roles under 3.7.

:

l the behavioral and dynamic aspects of the system. Theseal Time System. In contrast to interactions which are alsos which work together to perform a common behavior, a, Capsule or a protocol. State machines are event drivenmachine which refine its behavior. These are briefly

eir representations

12

STATE MACHINES

State State is a situation in the object’s period of existence when it can process events. A statemachine at least has one state which is the top state. A state can exhibit containmentwhere it has number of states inside it. A state has a name, entry and exit actions.

Transition It is the event which makes an object move from one state to another. A transition istriggered by an event and usually has a set of actions accompanying its execution

Guard This is a condition or a set of conditions placed on a trigger as a function which iscalled every time a trigger event is evaluated. Placing guard conditions will cause guardfunctions to be called for every message delivery. This will decrease the performance ofthe system. Guards are seldom used in Real Time Systems.

Choicepoint

This is a condition point very similar to a decision point in a flow chart where acondition is evaluated and based on the output the corresponding path is taken. Thedifference, however is that choice point can have any number of branching transitionswhich are taken based on the output of a certain condition of evaluation. Choice pointsare very commonly used in real time systems.

Junctionpoint

These represent either the source or destination of the transition segment. They areusually present on the boundary of the states. There are two types of Junction pointsnamely continuing junctions and terminating junctions

Event An Event triggers a transition. It is also known as trigger.

EventGuard

It is a combination of an Event and a guard that will trigger a transition.

Table 4 : Major Elements and their roles in a State Machine

2.1.2.5 Different Kind of State Diagrams in UML RT:

There are 3 different kinds of State machines in Rose RT. They are classified as follows:

Class and Use Case StateDiagrams

Capsule State Diagram Protocol State Diagram

Every trigger event is a simpletext which is not interpreted.

Usage:

Used for modeling thebehavior of a Class. It doesnot produce any code in codegeneration since it is forinformation purposes only.

All trigger events must have a port and asignal. There are some illegalities in Capsulestate diagram :

No final state is allowed. Junction points donot support continuation kind attribute. If atransition is interrupted it goes by default tohistory.

Usage: It enables modeling the behavior ofthe Capsule. It translates to code.

Every trigger event is a Signal.These signals are defined by theprotocol as usual.

Usage :

It is used for specifying how aprotocol should be used whilenot compromisingencapsulation. It does notproduce any code as it is forinformation purposes only.

Table 5 : Different kind of state diagrams in UML RT

2.1.2.5.1 Additional Items in UML RT:

Additional items in UML RT are non real time elements such as elements under the Use Case Viewsuch as user classes and actors, the component view which contains the components and packages forsoftware management for the programmers and deployment view which contains the processors anddevices used for System Engineering and deployment. It provides the possibility of modeling anyrelationships between them using the deployment diagram and also the package diagram.

13

2.2 Open Technologies in the Project

2.2.1 OMG (Object Management Group) Technologies

OMG is a non profit consortium of industry and academia which regulates, specifies, defines andpublishes standards for interoperable enterprise applications. OMG has several technologies regulatedwhich are aimed at providing cross platform independency. UML®,MDA®, XMI® , OCL® (ObjectConstraint Language) and CWM® (Common Warehouse Management) are all standards published bythe OMG .

Brief Summary of the Standards under OMG used in the project

Standard Function

UML Unified Modeling Language: It is a standard language for designing, specifying,constructing, developing and documenting the artifacts of a software system. Theindustry accepted standard versions are regulated by OMG and the latest publishedversion is UML 2.0

XMI XML5 Metadata Interchange: It is a standard for exchanging metadata informationthrough XML format. It can be used for representing any meta data whose metamodel can be represented in MOF.

MOF Meta Object Facility: It is a 4 layer architecture which is used for generation ofmeta models and can be exported from one platform to another, rendered indifferent formats and addresses the issues of both a designer and a programmerthrough the architecture.

CWM Common Warehouse Metamodel: It is a set of rules used for modeling metadata ina data warehousing environment. It is attributed to the M2 layer in the MOFarchitecture. It provides object that describe the origin of data and relatedinformation. It belongs to the M2 layer of the MOF.

OCL Object Constraint Language: Used for the proof and verification of Models throughuse of predicate logic with rules and constraints and using pre and post conditions.It is specially designed for taking a formal approach through declarations in UMLand was introduced by IBM®.

MDA It is an architecture specifying a set of rules in design supporting Model drivenEngineering. It aims at the transformation of Platform Independent Model (PIM) toPlatform Specific Model (PSM) based on certain specifications. The PlatformSpecific Model could be used for a variety of platform based applications andcould be also used to generate code. However applications of PSM such as codegeneration are not MDA processes. A code generation process that would use thePSM generated based on MDA is commonly known as MDA-based codegeneration.

Table 6: Brief Summary of OMG standards

The most vital technologies in this project are UML, XMI and MOF. Since this project deals more onextensibility mechanism of UML 2.0 to map to the Rose RT elements only this area is discussed inmore detail. More information about UML 2.0 and its diagrams could be found under [5] [41] and apractical introduction to UML can be found under [42].

5 XML is a W3C standard.

14

2.2.1.1 OMG UML 2.0 and Extensibility Mechanism

UML 2.0 is the latest published6 standard from OMG. It is used for visually constructing the structureand the behavior of the system. It can be used to create an abstract model of the system. It supportsData Abstraction, Flexibility, reuse, compatibility and extensibility. It is platform independent [5] [23].

UML 2.0 has Structural Diagrams, Behavioral Diagrams and Interaction Diagrams. The StructuralDiagram will detail upon the structure that an UML diagram must take. Behavioral Diagram defines thebehavior of the model and Interaction diagram is actually a subset of Behavioral diagrams andemphasize the way the flow of control between different entities in the model.

When a concept that is necessary to model is not present, it is introduced through means of extensionmechanisms. This is carried out extensively through this project for the facilitation of mapping variouselements to UML 2.0. This extensibility is not only available for UML 2.0 standard but also in earlierUML versions, where tagged values are mostly used for extensibility.

There are 3 different types of extension mechanisms in UML in general:

Stereotypes

Constraints (Using OCL)

Tagged Values

2.2.1.1.1 Stereotypes:

Stereotypes are used broadly for the following 2 purposes.

P1: To specify which metamodel element is adorning a model element on the diagram and this is themost common usage of a stereotype.

E.g.: A Class with a stereotype Capsule says that it is a Capsule and not actually a class.

P2: To indicate a specialized kind of metamodel element defined in a profile.

E.g.: Defining a new metamodel element in the M2 layer of the MOF enables the model torecognize the stereotype and perform actions according to it. This is done in a profile.

P1 is used for encapsulation of behavior of the Classifier and P2 is used in metamodeling used in theproject. Using stereotypes is the most common way of extending the functionalities of the UML 2.0metamodel. The literal translation of a stereotype in UML 2.0 terms is “special type of”. So when aClass is defined with a stereotype “Capsule”, it means that the item is a special kind of a Class. Theyare represented by enclosing the name of the stereotype between angle braces such as “<<” and “>>”. AStereotype can have a semantic impact on the metamodeling and is extensively used in this project.

Example: A Capsule is represented as a Class with a stereotype “Capsule” as follows

Figure 8: A Class representation of a Capsule with stereotype

6 The most recent standard is UML 2.1 which is still under development [39].Despite this there are already toolsmodelling in UML 2.1with XMI 2.1. Example : Altova Umodel 2006.

In Figure 8, a Capsule called TrafficSystem is represented as aClass with a stereotype “Capsule”. The stereotype here can alsointroduce additional values and constraints if necessary.

15

2.2.1.1.2 Constraints:

These are conditions attached to model element(s). A constraint has a semantic impact on a modelelement. If there are constraints attached to a stereotype, they apply to each model element which hasthis stereotype. This constraint is a part of Object Constraint Language in displaying pre and postconditions. The constraint is a user defined rule enclosed in “{“and “}” for refining the semantics andused for correctness [36]. A constraint is a way in which the user can express a restriction in a specificdomain in which the model element is designed.

Example: Two ports represented with a connector represented as Classes with a constraint as follows:

socket<<Port>>

plug<<Port>>

<<precondition>>{ (protocol(socket) = protocol(plug))| defprotocol(socket) =defprotocol(plug)}

Figure 9: Constraint for Extension Mechanism

2.2.1.1.3 Tagged Values

The tagged value is a field name and its value which represents a characteristic of a model element or atool or a collection. While the Rose RT Model is exported to XMI, tagged values can be used torepresent properties of model elements and can be applied to a model element or a stereotype. A taggedvalue can be used for basically any characteristic property of a model element. However, onlyproperties which cannot be represented in standard XMI syntax are normally considered to be exportedas tags. In general usage, tagged values are used for adding auxiliary information attached to a modelelement. A tagged value is a property name and value pair.

Example: The Tagged Value of a Capsule having a BackwardCompatible property cannot be exportedin the syntax of XMI 1.0. As with constraints, tagged values are also represented in the UML diagramin between “{“and “}” as in Figure 10 below.

BackwardCompatible:TrafficSystem{value = "false"}

TrafficSystemredgreenorange

changesignal()predictsignal()

<<Capsule>>

Figure 10: Tagged Value for Extension Mechanism

Tagged values are extensively used in the project for exporting various real time elements which are notsupported in the XMI syntax chosen for export. In fact, the code in the transition of state diagrams andall the code under operations are handled as tags. For e.g. an attribute in a standard class can beexported as a tagged value. However, only the elements that are not supported by default in the XMIDocument Type Definition (DTD) are exported in the form of tags. Any new tag used should beinterpreted in the metamodel and the appropriate action must be initiated. For e.g. In Figure 10, the tagBackwardCompatible must be looked for while reading the XMI back during metamodeling. It ismapped on to the Capsule TrafficSystem since the tag would be referencing the ID of the Capsule.

Figure 9 represents the constraint in creating themeta model for export of ports to the intermediateformat of RT UML 1.4.

The precondition according to OCL is specifiedand the two ports cannot communicate if theirdefinitions in the protocol are not the same. Theycould either have the same protocol or differentprotocols with same definitions. Hence here theprotocol of the socket represented as“protocol(socket)” and the “protocol(plug)” mustbe the same OR (represented as “|”), the signalsthat they define[represented as defprotocol()] mustbe the same.

Figure 10 displays a tagged value (or anamed property)of the CapsuleTrafficSystem called BackwardCompatibleand the value is set to false. This property is apart of the Capsule TrafficSystem. Many ofsuch properties are represented as taggedvalues which cannot be representedotherwise.

16

2.2.1.1.4 Relationship of all Extension Mechanisms:

TaggedValue

Element

0..1

0..n

0..1

0..n

characteristic

Stereotype

0..n

0..1

0..n

0..1

classification

Constraint

instantiated by

0..n

Figure 11: A simple relationship between Extensibility Mechanisms for an Element

With reference to Figure 11, there can be only 1 Stereotype for an element and it is a classification or a“special type of” artifact that defines the Element and is a part of the Element. The Tagged value iswholly owned by the element which the tagged value characterizes. There could be a number of taggedvalues for an element. It is used for defining all properties of the element which is not supported by thestandard semantics. The Tagged value is extensively used in meta modeling and mapping in this projectsince almost all the additional information can be exported as tags. There could be different constraintson an element or its relationship. These constraints are usually in the form of preconditions and postconditions defined in OCL. [22]

2.2.1.2 OMG MOF

2.2.1.2.1 Introduction

Meta Modeling:

Meta modeling is an accurate mechanism of defining modeling languages itself such that they aredefined as a result of disambiguation by relating the different elements to each other. It facilitates thecreation of transformation rules and definitions for mapping model elements to transform them intoother kinds of model elements into other models and representations. Metamodeling is also used tocompare different modeling languages. The mechanism of Metamodeling is widely carried out indescribing the concepts used in modeling itself. Metamodeling is carried out by all CASE tools and alsostandards such as UML 2.0 to describe itself. In such a metamodel there will be concepts such asClasses, Interfaces etc themselves modeled with their relationships between each other. Metamodelingis formally described through MOF (Meta Object Facility) which is considered as a standard fordescribing models and is used to describe itself and also UML.

Metamodel:

The mechanism of metamodeling produces the metamodel which contains the model of the elements inthe actual model. For example: Consider a UML RT system as the model. A model which woulddescribe the elements in the UML RT model such as capsules, ports and how they interact with eachother is a metamodel. In other words, it is the model of a language itself capturing its properties, syntax,and semantics and defines mappings to other variant languages. See Figure 24: Relationship betweenports, Protocols, Protocol roles.

Figure 11 displays the relationshipbetween the 3 Extension Mechanismsthat could be used to export theadditional features required in a Metamodel. Based on understanding fromOMG UML 2.0 Specification document[5].

17

2.2.1.2.2 MOF Architecture

MOF (Meta Object Facility) is metamodeling architecture of 4 layers [13] [43] from OMG. In theorythere can be any number of model metamodel layers but OMG has limited the number of layers to 4.The lowest layer in the MOF architecture is the M0 Layer. This layer commonly represents a real worldmodel (Object). M0 layer could also be represented by Objects, Code or Data as shown in Figure 12:Meta Object Facility Architecture.

Figure 12: Meta Object Facility Architecture

KEY

OODBMS – Object Oriented Data Base Management System

RDBMS -- Relational Data Base Management System

RSS -- Really Simple Syndication/Rich Site Summary

18

The second layer in the MOF architecture is the M1 layer. This layer is the description of the M0 layer.This layer has a model (a UML model) of the real world object, and is the generalized form of the M0layer. A typical example of this is an UML Model of a Real Time System.

The third layer is a more significant layer called the M2 layer. This layer contains the MetaInformation of the model known as the Meta Model layer. This layer is also known as the CommonWarehouse Meta model (CWM) [15] which is an OMG standard. A good example of this is themetamodel of an UML model, a model which describes the classes, capsules, state and activity.

This can be best illustrated with an example as in Figure 13: Meta Modeling Example: A Part of UML1.4 Metamodel.

Example: M2 Layer - A part of UML 1.4 Meta model:

Figure 13: Meta Modeling Example: A Part of UML 1.4 Metamodel

Here the artifacts of the modeling standard are itself modeled thereby constituting a metamodel. Thismetamodel describes how the basic elements like Class, Data type, Interface, Features relate to eachother. All elements including Data type are subsets of Classifier. The features are owned and destroyedby the class; there could be any number of sets of an element type in a Classifier. This is a model ofhow the UML standard should work with its various elements. OMG UML 2.0 also has a similarmetamodel.

The fourth and he final layer is the M3 layer known as the MOF layer. This layer is responsible forbuilding and managing meta-meta models. This layer will describe further on what a Class can contain.For instance a Class can have an attribute, an association relationship, an operation etc. Thisinformation is represented in the M3 layer. In other words, it defines the language for defining andconstructing the M2 layer. Consider the following Figure 14 : A Class Metamodel : M3 Layerdescription.

Here the element Class in the metamodel of M2 layer (For example the UML 1.4 metamodel) isdescribed in a more detailed format. The Class and its elements such as Operation, Properties (includingattributes, association) and generalization and dependency relationship is shown in the Figure 14

19

Example: M3 layer – A Language description for a Class in M2 layer:

Operation

Generalization

Property

Association

0..1

*

0..1

2*

0..1

+member+owned

+ownedBy end

2

+association0..1

Class

0..1*

0..1

+ownedAttribute

*0..1* 0..1

+ownedOperation

*

+general

*

+specific

*

Figure 14 : A Class Metamodel : M3 Layer description

MOF is used for describing MOF itself and UML. The XMI which operates between the M1, m2 andM3 layers to produce the output with the metamodel information. (See Equation 3: XMI Formula).When MOF is mapped to Java, Java Metadata Interface (JMI) is produced. JMI is very similar to XMIand the only way it differs from XMI is that the metamodel information is represented in Java syntaxrather than XML syntax. As a result of the architecture framework, the higher level of abstraction themore concrete the concepts are. Hence M0 is most concrete and M3 is least or in other words M3 isfully abstract.

2.2.1.3 OMG XMI

The XML Meta Data Interchange standard is specified by OMG for exchange of model informationacross different platforms. XMI combines the syntax of XML and is generated from the MOF 4 layerarchitecture Figure 12: Meta Object Facility Architecture . In other words, XMI is the Meta dataInterchange format which is defined according to MOF and can be represented as follows

Equation 3: XMI Formula

XMI is a result of drive for MDE (Model Driven Engineering) which aims at making modelinformation completely transformable. MDA is a variant of MDE licensed by OMG. XMI specifies alsohow to create XML schemas from models. XMI defines a set of rules that describe how to serialize theelements of a model to XML, and how to generate a DTD or schema for the XML files thus generated.

XML Meta Data Interchange (XMI) enables software and platforms to exchange MOF based modelsand metamodels. XMI transforms MOF based models and metamodels to its own common interchangeformat applying the production rules.

XMI has various versions. The first version of XMI was 1.0 and the latest version is 2.1 with 1.1, 1.2,and 2.0 in between. The Comparison of XMI and UML versions are formulated under the Table 8:XMI and UML versions compatibility - In brief and Table 12: Comparison of UML, XMI versions andsupporting tools. In general, the production of XMI is carried out by combining the XML DTD and themetamodel information.

20

2.2.1.3.1 Rules

XMI can be broadly classified into two elements:

1. The XML DTD Production Rules for producing XML Document Type Definitions (DTDs) forXMI metadata. XMI DTD provides the syntax specifications for XMI documents apart from allowinggeneric XML tools to be used to compose and validate XMI documents.

2. The XML Document Production Rules for encoding metadata in an XML format. The productionrules can apply in reverse fashion to decipher XMI documents and regenerate the metadata.

XMI is not XSD:

XMI is different from XML schema known as W3C XML Schema (XSD). In XSD, the UML attributes aredirectly mapped to XML elements or attributes in the XML file. The XSD schema could be referenced witha set of stereotypes, tagged values and constraints.

For metamodels to interchange its models through XMI, the following condition must be satisfied.

The metamodels must be able to be represented through the MOF, as an instance of the MOFModel.

Importance of XMI

XMI is the most important technology of this thesis. The ability of XMI to fully supportInteroperability is as important for moving models across as with moving documents across with XML.It is used as an integration and Interoperability facilitator for the entire model information. This XMIgenerated can be fed into an XMI reader which will build back the metamodel (M2 layer) of the MOF.

This Metadata information is then used in the metamodel and any necessary changes are made and thencould be used by a code generator to generate code. Alternatively, the XMI can be extracted as XMLMeta Information Model. [33]. This XMI can be then used for building the Common Warehouse Model(CWM) (M2 layer in MOF architecture) back and can be deployed over the web or could be used forData Warehousing or for Component Based Development. Using XMI for model transformation is theonly sensible method of transporting the MOF based metamodels (including UML itself) across variousplatforms till date.

Functionality and Usage of XMI:

The process of XMI generation and its functionalities is depicted in Figure 16: Role of XMI in modeltransformation.

Figure 15: XMI, Interoperability and Eclipse functionality

Figure 15 shows the flexibility of XMIas it can be fed across a number of toolsand platforms. It could be used in anEclipse based platform such as EclipseModeling Framework (EMF) which istightly connected to UML 2.0 syntax andthe Model Driven Architecture (MDA) tosupport the generation of code. MostMDA based code generation tools arebased on Eclipse. Hence, XMI couldprovide and facilitate an Eclipse basedcode generation environment.

21

Figure 16: Role of XMI in model transformation

Figure 16: Role of XMI in model transformation explains the functionality of XMI in a condensedformat. XML production is carried out from the basic structure of the design model (M1 layer of theMOF). It is combined with the validation of the Document Type Definition (DTD) of the XMI. Thisresults in the production of XMI.

22

The XMI document can be fed into an XMI reader and the metamodel can be generated back. Thismetamodel will be then used by the code generator to generate code. Alternatively the XMI could beextracted into XMI Metamodel. The XML DTD can be reversed back from this and the CommonWarehouse Metamodel which is used for warehousing can be also built back. The CWM belongs to theM2 layer of the MOF. These two namely the XML DTS and the CWM DTD can be used together toperform Data warehousing and for Component Based Development as in Figure 16.

The usage of XMI can be classified as follows:

Usage Explanation

Used in the interchange of UMLand other MOF compliant models

1. Between design tools for modeling and generators.2. Between tools and repositories (e.g. :NSUML, MDR)3. Between repositories

To publish design meta data on theweb

Since XMI follows the same syntax as that of XML in terms ofdocument formation, it could use the similarity with XML andHTML and make use of the transfer across the Web platform.

MOF based CORBA interfaces It could be used instead of MOF or some times with MOF basedCORBA interfaces to meta objects. It also supportsinteroperability with other broker architectures.

Table 7: Usage of XMI

Current drawbacks of XMI:

Subsequent XMI versions that are released are with significant changes in syntax andthe DTD of XMI is verbose.

Wide variety of choices with no clear recommendations. A same model element can beexported in many different ways. For example as a link, as a path, as a tagged value, oras supported in syntax. Many vendors use their own forms of export which renders lossof information in the model when imported back into other tools.

Versions of XMI:

The various versions of XMI and UML are tabulated as follows. A detailed version of comparison canbe found under Table 12: Comparison of UML, XMI versions and supporting tools

XMI version UML Version Compatibility Comments

1.0 1.3 Oldest version

1.1 1.4 and 1.3 --

1.2 1.4 and 1.3 Commonly used XMI version

1.3 1.4 and 1.3 Least used XMI version

2.0 2.0, 1.4 Most targeted

2.1 2.1, 2.0 ,1.4 Targeted

Table 8: XMI and UML versions compatibility - In brief

23

Example of XMI representation:

Figure 17: A very simple class

XMI header

(This is the first part in theXMI document) Thissection provides thegeneral information aboutthe document explainingthe versions, name andencoding standards.

<? xml version="1.0" encoding="ISO-8859-1”?>- - <XMI xmi.version="1.0" timestamp="Tue May 23 08:22:09 2006">- <XMI.header>- <XMI.documentation>

<XMI.exporter>Alpha testing tool</XMI.exporter><XMI.exporterVersion>0.1</XMI.exporterVersion></XMI.documentation><XMI.metamodel xmi.name="UML" xmi.version="1.3" /></XMI.header>

Model Information

(This is the second part inthe XMI document) Thissection provides generalModel Information.

- <XMI.content>- -<Model_Management.Model xmi.id="G.0" xmi.uuid="4472A99F0309"><Foundation.Core.ModelElement.name>testing</Foundation.Core.ModelElement.name>

<Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" />

- <Foundation.Core.Namespace.ownedElement>Contents of the Model

Class information in thisexample). All the contentsof the Model comebetween the construct<Foundation.Core.Namespace.ownedElement> andthe corresponding endingconstruct of the model.

<Foundation.Core.Class xmi.id="c1" xmi.uuid="447677C4032F"><Foundation.Core.ModelElement.name>testclass</Foundation.Core.ModelElement.name>

<Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="true" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="true" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" /><Foundation.Core.Class.isActive xmi.value="false" />

- <Foundation.Core.ModelElement.namespace><Foundation.Core.Namespace xmi.idref="G.0" /></Foundation.Core.ModelElement.namespace></Foundation.Core.Class>

End of the Document </Foundation.Core.Namespace.ownedElement></Model_Management.Model>

</XMI.content></XMI>

Table 9: XMI output for a simple model

Figure 17 is a model with a single class named“testclass”. The following is an example of XMI 1.0output for this Model named “testing” with a single classinside called “testclass” and the output XMI is groupedunder the following parts as under Table 9: XMI outputfor a simple model

24

2.2.1.4 OMG CWM

Common Warehouse Metamodel is an OMG standard used for metadata interchange among datawarehousing methodologies, data mining, for business intelligence, facilitating knowledge managementand other portal technologies [15]. CWM is a sister technology of XMI and MOF and its role in XMI isdescribed in Figure 16: Role of XMI in model transformation. Data warehousing is not used in thisproject but the usage of XMI enables us to take advantage of the various portal technologies along withdata warehousing practices for business intelligence in particular.

2.2.1.5 OMG MDA

Model Development Architecture (MDA) is a form of Model Driven Development (MDD). MDD is anapproach to software development that focuses on Models as the primary artifact in the development ofsystems, and Transformations as the primary operations on models. MDA operates around the basiccore standards of UML, MOF, XMI and CWM (Common Warehouse Metamodel)

Model Driven Architecture (MDA) and Executable UML are two instantiations of MDD [44]. Thefollowing Figure 19: MDA and code generation process shows the processes in MDA method ofexecution.

MDA has the following major elements [MDA Guide, 2003].

Common Information Model (CIM)

CIM is the MOF built from the XMI generated. This contains general information of the model in theform of metadata stored in the M3 layer of MOF.

Platform Independent Model (PIM) or the Domain Model:

PIM is independent of, and can be used with, platforms of any type. It hides the details necessary forparticular platforms. The Requirements of the application are fed into this model and the EnterpriseView is generated. The PIM corresponds to the context in which the services must be applied. [45] It isa combination of Business Process Model and the Design Model. The requirements of the application isspecified before executing the Business Process Model and then to populate it with information toproduce the information model. From the Enterprise view the most essential information is extractedand is presented in the Information View. The Enterprise view is a Business perspective view and theInformation view is the designer’s perspective for the next step which is rendering a Design Model.

Platform Facilities Specification or Platform Definition Model (PDM) or Platform Model (PM)PDM or PM is used to define the platform specific requirements and specifications to produce thePlatform Specific Model (PSM).PSM is produced by mapping the concepts of PIM with transformationrules (mapping rules) and producing a Component Structure Model. The following Figure 18: UMLrepresentation of MDA shows how the PIM, PSM and PM are related to each other.

Figure 18: UML representation of MDA

25

Figure 19: MDA and code generation process

Platform Specific Model (PSM)

This combines the specifications in the PIM with the details that specify how that system uses aparticular type of platform

It specifies a system in terms of the domain and of elements used in platforms (e.g. “homeinterface” and “session beans” in an EJB PSM, “column” and “foreign key” in a RDBPSM) combines the specifications in the PIM with the details that specify how that systemuses a particular type of platform.

26

It has two views, The Software Engineering View from which the mapping rules aredefines and the specifications for the Platform Facilities provided and it is transformed intothe Final product view and could be used for code generation.

2.2.2 JMI

Java Metadata Interface is defined by the Sun® Java® Specification Group unlike other OMGstandards such as MOF. It contains the same information as that of XMI. The only difference is that themetadata information is mapped to Java language in JMI. The relationship of JMI with XMI and MOFis shown in Figure 20: Relationship of JMI, XMI and MOF and The role of JMI is shown in Figure 12:Meta Object Facility Architecture , Figure 16: Role of XMI in model transformation and Figure 19:MDA and code generation process.

XMI MOF JMImapping to XML mapping to Java

Figure 20: Relationship of JMI, XMI and MOF

2.3 What is a UML Profile and how is it built?

A Profile is nothing but a metamodel of a domain of interest which is specialized, expressed andextended from a standard by the use of extensibility mechanisms present in that particular standard. Aprofile in UML enables the extension of its usage in a particular domain of interest.

UML Profiles are built usingextensibilitymechanisms such as Stereotypes, Constraints and Tagged values (Seesection 2.2.1.1) that can be applied to Elements, Attributes, Methods, Links, Link Ends, etc. Aprofile is a collection of such extensions that together describe some particular modeling problem andfacilitate modeling constructs in that domain and thus enables us to extend UML to the specificationsand requirements. This is shown in Figure 21: Creation of an UML Profile as follows:

UML

Stereotypes Tags Constraints

Extensibility Mechanisms of UML

Domain Specific Profile of UML

Domain Specific Requirements

Transformation ruleswith

realized through

produces

translated as

Figure 21: Creation of an UML Profile

27

2.4 Extended Basic Scripting and ExtensibilityReference

Extended Basic script is a scripting language which is almost similar to Basic programming with slightvariations in the syntax and has extended features. It can be compared to Visual Basic Scriptinglanguage. It enables to access the various elements in the model through the API provided by Rationalknown as Extensibility Reference Manual [35].

The Basic script has several operators and functions which are used in conjunction with the API ofRose RT to access and deal with the artifacts of Rose RT models. Some of the commonly usedfunctionalities are Special characters, Directives, Functions, Keywords, Methods, Operators, Properties,Statements, Picture caching and ability to handle Optional parameters. Several new types of constructs,enumeration data types etc can also be handled. It can also deal with other major tasks such as ErrorHandling, expression evaluation, literals and object precedence.

The API has special directives to access elements in the model through the Basic Scripting language.

Example (1):Consider the following two statements.

Dim myModel As RoseRT.ModelSet myModel = RoseRTApp.CurrentModel

This would enable the access of the current Rational Rose Real Time model. Here the “myModel” isdeclared as an array of Rose Real Time models and is set to the current model.The API allows manipulation of the various model elements by adding new artifacts modifying ordeleting them. However, only manipulation of elements was carried out in this project as the aim is toexport the models as it is to XMI. New types of elements are created for storage of the actual elementsfrom the model.

Example (2):

Consider the following snippet of code:

Type xmiProtocolid As Integeruuid As StringtheName As StringStereotypeDisplay As Integer

tag As Stringabstract As Booleanstereotype As Stringvisibility As Stringinvariants As String

End Type

In Example(2), even though there could be astatement such as “Dim Prot As RoseRT.Protocol”for the declaration of the protocols in the model, anew type such as xmiProtocol is created for storageof such protocols with all their properties.

Such type declarations are extensively used foreach artifact in the developed script for storage ofseparate elements in the array for manipulating andprinting them in XML schema into the XMI file.

28

2.5 Open Source XMI Handlers2.5.1.1 NSUML XMI Reader and Writer

It is the NSUML (“Ns” stands for Novosoft) XMI reader [16] for the XMI version 1.0 and 1.1 andsupports UML 1.3. This reader is used as a plug in most of the code generators or CASE tools whichsupport XMI 1.0 import. NSUML XMI reader was produced as a result of Open source project withSoundforge. ArgoUML® is the first tool to use NSUML XMI reader. It uses a repository for storage ofthe metamodels. JMI (Java Metadata Interface) is used for the generation of MOF from the XMI whichis provided as input. NSUML is a project generated from another project from Soundforge known asNSMDF which is responsible for reading in the metadata from the XMI. NSUML is a Java librarywhich actually manages this metadata. NSMDF is based on JMI orderings. The production of NSUMLhas ceased but it still remains as the Open source project in the market which handles XMI 1.0.Novosoft UML library provides various facilities such as implementation of complete UML 1.3physical metamodel, event notification, undo/redo support, reflective API and XMI loading with savingcapabilities.

2.5.1.2 MDR – XMI Reader and Writer

The MDR- XMI reader [17] plays a key role the import of XMI. This reader is implemented as arepository which produces MOF from the XMI using JMI. (Java Metadata Interface).It is a stand-alonerepository which works based on standards such as MOF, XMI and JMI. MDR provides integrationfeature which is used by individual components of software to communicate with each other. MDR isan implementation of MOF and is widely used by tools to implement MDA. The current MDR readercan read XMI versions 1.1 and 1.2 and generate the MOF back. MDR has components such as JMItools, MDR Engine, MDR Module, Netbeans MDR Explorer and other MDR based tools. Moreinformation on MDR can be found under [17].

2.5.1.3 Ecore XMI reader and writer for EMF

Ecore XMI reader from Eclipse Modeling Framework (aka EMF Ecore reader aka Ecore XMI reader) isanother Open Source XMI Handler which was unknown during the script development in the project.This works on XMI 2.0 with UML 2.0 which is a turning point in the approach that could be taken foradoption to an XMI standard. Ecore XMI reader uses Eclipse as the platform to access the Metamodelsfrom XMI and operate on them. Ecore EMF model is based on MOF 1.4[13]. Since Eclipse and UML2.0 are tightly connected in terms of support and compatibility, using an Eclipse based XMI reader suchas Ecore would provide the necessary support for building and executing metamodels without loss ofinformation. EMF supports the important OMG concept of MDA [46] as an input to the developmentand integration tools to produce multiple programming language output or data interchange format(XMI) representations. The code generation and XML serialization is ‘driven’ from the model which isbuilt back from the XMI generation. This would mean that using EMF Ecore would allow two wayproduction of XMI. EMF supports OMG XMI 2.0 XML serialization format and the use of UMLmodels for the analysis and design of EMF models as in Figure 22

Figure 22: Ecore XMI reader and functionality

29

3 Technical SolutionThe solution here is based on comparison of various features and compatibilities of various versions ofUML and XMI and also the concepts that has to be taken into consideration for mapping the elements.The Solution is then implemented in a 3 stage process and the results are checked thereafter.

3.1 Comparison of UML RT and UML 2.0 StandardROOM (Real Time Object Oriented Methodology) + UML = UML RT

The various concepts of UML Real Time and UML 2.0 are studied in the following table:

Concept orCriteria

UML Real Time Standard UML 2.0 Standard

Timeliness Time aware communication models andConcurrency management

Performance aware models

Capsules Process refinement techniques followed.

These are active classes withasynchronous messages sent through ports.They also have state machines associateswith them

Their behavior is defined and modified bystate machines.

Standard Data Refinement techniques.

Capsule doesn’t exist. The analogy is theclass with containment or structured class.They can also have state machine in them.However the real time constituents ofCapsule such as ports and their instances areabsent.

Their behavior is provided by operations.

Interfacing Protocols are used for Interfacing. Theydefine a communication pattern for the set ofmessages sent and received. They definesignals for the members of the Protocol. InSignal and Out signal are the two types ofsignals. Depending on this relation base andconjugate protocols are formed

Interfaces are used for Interfacingrelationships. There is an interface whichcan be attributed to that of a protocol. The InSignal and Out Signal correspond to therequired and supplied interfacesrespectively.

Ports The only public or visible entity in theCapsule is a port and they are used for theCapsules to communicate with the outsideentities. They communicate sending andreceiving signals using ports. Ports could beof two types which are relay and end ports.See 2.1.2.2

Ports are defined as Ports in UML 2.0standard. They are contained in a Classcompared to Capsule in UML RT and have aconnector to the other port to facilitatesending and receiving signals. The conceptof replicated ports is supported throughmultiplicity. The relay and end not supporteddirectly. The profile of UML 2.0 namely RTUML 2.0 can be used to address this.

Profiles Though the Real Time Profile is present, theability to build on it is absent.

These are used for Language Customizationsand is used for building new profiles of newor existing versions of UML

Transition& trigger

These are present in the Capsules and alsocould be present in a protocol state machineother than in Classes. The trigger is obtainedfor the transition to take place

Present.

Table 10 : Comparison of UML RT and UML 2.0 Standard

30

3.2 Comparison of XMI versionsThe following table shows a comparison of various XMI versions and their major differences. This is aset of major differences between the XMI versions which are of significance in exporting metamodelinformation [6] [7] [8] [9] [10] [11] [12].

XMI VersionsS.NO

Concept orFeature

XMI 1.0 XMI 1.1 XMI 1.2 XMI 1.3 XMI2.0

XMI 2.1

1 QualifiedElement Name

Fully package-qualified elementname"Foundation.Core.Class"

Only leafelement usedsuch as

"UML:Class"

Leaf elementused such as

"UML:Class"

Leaf elementused such as

"UML:Class"

Leafelementused such as

"UML:Class"

Leaf element usedsuch as

"UML:Class"

2 Metamodelinformation

XMI.metamodelused to identifythe metamodelused in thedocument

XMI.metamodel used foridentificationof metamodelinformation

XMI.metamodel used foridentification ofmetamodelinformation

XMI.metamodelused foridentification ofmetamodelinformation

XMI.metamodel used foridentification ofmetamodelinformation

Absent. As areplacement, eachmetamodel has 1 ormore namespaceswhich provides apermanent globalname for theresource.

No namespacesused formetamodelinformation

Namespacesintroduced.

Namespacesare combinedwith headerinformation

Namespaceseparated fromheader info

Namespaceseparated

Namespaceseparated

Namespaceseparated

3 Mixing ofNamespaces

Example: <XMI xmi.version=’1.1’ xmlns:UML=’//org.omg/UML/1.3’> <XMI.header><XMI.metamodel xmi.name=’UML’ xmi.version=’1.4’/>

Here the XMI of version 1.1 exports UML of version 1.4 but the name space suggests that UML 1.3 is used.

4 MOF & UMLUsed

MOF 1.3UML 1.3

MOF 1.3

UML 1.3

MOF 1.4

UML 1.4

MOF 1.4

UML 1.4

MOF 1.4

UML 2.0

MOF 2.0

UML 2.0, UML 2.16

5 SchemaGeneration

Not available Not available Not available Introduced &

Available

Available &changes indocumentformatintroduced

Available

6 XML ID NA NA NA NA Available asXml:id

Available as Xml:id

7 Linking ofElements

Is done by xmi.idfield

Done byxmi.idref fieldcommonly.

Done byxmi.idref field

Done byxmi.idref field

Done byxmi.idreffield.

Done by xmi:idreffield.

8 Identification ofelements

Xmi.id andxmi.uuid present

Xmi.id andxmi.uuidpresent

Xmi.id andxmi.uuidpresent

Xmi.id andxmi.uuid present

Xmi.id,xmi.labelandxmi.uuidpresent

Xmi.id, xmi.labeland xmi.uuid present

9 Serialization No serialization Noserialization

No serialization XMIserializationstreamlinedreducing numberof elementsrequired.

Serializationpresent

Serialization present

Table 11: Comparison of major features of XMI versions

31

3.3 Comparison of XMI Versions, UML Versions andSupporting Tools

The following table shows the comparison across XMI, UML versions and some of the tools thatsupport it at the time of writing this report.

XMIVERSION

UML Version TOOLS THAT SUPPORT IMPORT and EXPORT IN THISFORMAT

XMI 1.0 UML 1.3 andUML 1.4

ArgoUML (UML 1.3)

Enterprise Architect(UML 1.3)

MagicDraw 7.8 (UML 1.4)

MDR XMI Reader (UML 1.3)

Rational Rose Unisys Plug-in(UML 1.3)

Visual UML 4.0 (UML 1.3)

Rhapsody (UML 1.3),

Ideogramic UML (UML 1.3)

Visual UML (UML 1.3)

Silverrun Modelsphere (UML 1.3)


Rational Rose Unisys Plug-in,

Eclipse UML (UML 1.3)

Enterprise Architect.(UML 1.3)

Visual Paradigm (UML 1.4)


Enterprise Architect,

Metamill (UML 2.0)

Coral (UML 1.4)

Poseidon 3.0 (UML 1.4) Also supports export of XMI-DI (DiagramInformation)

XMI 2.0 UML 2.0 Embarcadero Describe

Altova UModel

Poseidon 2.4.1

Ecore for Eclipse Modeling Framework

XMI 2.1 UML 2.0 and

UML 2.1

Altova UModel

Table 12: Comparison of UML, XMI versions and supporting tools

Note: XMI 1.3 is not discussed here due to its low popularity and almost no tool exporting it.

32

3.4 Comparison of XMI Versions and Open SourceXMI readers

XMI Version UML Version Open Source XMI reader

1.0 1.3 NSUML

1.1, 1.2 1.3, 1.4 MDR

2.0 2.0 Ecore for Eclipse Modeling Framework

Table 13: Comparison of XMI versions and Open Source XMI readers

3.5 Decisions Made on XMI and UML

XMI Choice

Choice Made Reason Disadvantages

XMI 1.0 Simpler than other versions

No problems in tool support toimport XMI 1.0

XMI 2.0 was not chosen sincethe development was startedwith XMI 1.0 with tags. Thesyntax has to be changed toXMI 2.0 as the possibility ofusing EMF Ecore wasdiscovered as an Opentechnology XMI reader.

Much information might be lostIF the metamodel is not changedsince they are exported as tags.

XMI 2.0 is a better choice withEMF Ecore with support forUML 2.0 in the syntax.

UML Choice

Invented RTP UML 1.4

(RTP UML 1.4 wasinvented as anintermediate versionand mapping to RTPUML 2.0)

This is a new invention and thereason for this invention is toreach the goal. of targeting aUML 2.0 profile

None

Table 14: Decisions on the Choice of Versions

33

3.6 Invention of ProfilesDue to the lack of support of the XMI reader for exporting UML Real Time Models, creation of newprofiles was necessary. There were two profiles created. One is called RTP UML 1.4 and is currentlyimplemented and another is RTP UML 2.0 and is yet to be implemented. For a Profile to be fullyimplemented, it has to be done both in the XMI export and in the PIM to PSM transformation.

3.6.1 Creation of RTP UML 1.4

The RTP UML 1.4 Formula:

Equation 4: RTP UML 1.4 Formula

The standard of RTP UML 1.4 (Real Time Profile of UML 1.4) is introduced to make the mappingfrom Rose RT to RTP UML 2.0 clear. RTP UML 1.4 standard in XMI 1.0 is nothing but a combinationof the UML 1.3 supported in XMI 1.0 version and the Real Time concepts of UML RT which arerepresented as tags in XMI. Rose RT is an extension of the original UML 1.4 standard from OMG andhence is called as UML RT.

Reasons for Introducing RTP UML 1.4:

XMI 1.0 can export metamodel information only with UML 1.3 [2]. All additional information fromUML Real Time is exported with Extension mechanisms as under Section 2.2.1.1. This thereforebrings up the resultant XMI containing the information of UML RT but in syntax that supports onlyUML 1.3. Since Rose RT is originally an extension of UML 1.4, the resultant XMI therefore adheres toa standard which has an extension of UML 1.4 with Real Time Concepts. This standard is thereforecalled as RTP UML 1.4. This is depicted under the Table 15:RTP UML 1.4 Evolution below:

XMI Version UML Version Resultant UML Standard

1.0 1.3 1.3

1.0 extended withextensibility mechanisms

RT (extension of UML 1.4) RTP UML 1.4

Table 15:RTP UML 1.4 Evolution

34

3.6.2 Creation of RTP UML 2.0

Why should RTP UML 2.0 be invented when an OMG standardized Real Time Profile alreadyexists?

This is a very arguable question since there is an existing Real Time Profile of UML 2.0 known asUML Profile for Schedulability, Performance and Time from OMG [14]. However [14] does notprovide the concept of Capsules though it supports concurrency. Using [14] would lead to changing theprofile once again and hence it cannot be used for this project. Hence a new real time variant of UML2.0 was created.

XMI Version UML Version Resultant UML Standard

2.0/2.1 2.0 2.0

1.0 extended withextensibility mechanism

RTP UML 2.0 (mapped fromRTP UML 1.4)

RTP UML 2.0

2.0/2.1 extended withextensibility mechanism

RTP UML 2.0 (mapped from RTPUML 1.4)

RTP UML 2.0

Table 16 : RTP UML 2.0 Evolution

Current Suggestion 1:

Equation 5: RTP UML 2.0 Formula- Suggestion 1

Current Suggestion 2:

Equation 6: RTP UML 2.0 Formula- Suggestion 2

How can Real Time Profile of UML 2.0 created?

The Real Time Profile of UML 2.0, called in the project as RTP UML 2.0 is a variant of UML 2.0metamodel with Real Time Concepts embedded in it. This could be done in two different ways as inEquation 5: RTP UML 2.0 Formula- Suggestion 1 and Equation 6: RTP UML 2.0 Formula- Suggestion2. In this project Equation 5 is followed. Hence the Real Time Profile of UML 1.4 which was created inEquation 4 is used for the creation of a Real Time Profile of UML 2.0 by mapping the metamodel ofRTP UML 1.4 to the UML 2.0 metamodel as much as possible with XMI 1.0. Though Equation 5 andEquation 6 address the same goal, the difference lies in the choice of XMI version. The XMI version isdependent on the UML version as in Table 12: Comparison of UML, XMI versions and supportingtools. XMI 1.0 is chosen in this project and the export of Real Time Components is done by means ofextensibility mechanisms. The choice of XMI version is justified in 3.5: Decisions Made on XMI andUML and the explanation of Equation 5: RTP UML 2.0 Formula- Suggestion 1is provided in Section3.8.3: STAGE 3: Proposal for mapping to RTP UML 2.0. Examples of widely used Real Time Profileof UML are “UML Profile for Schedulability, Performance and Time”, a real time profile of UML 2.0from OMG [14] and SysML [47] a modeling language representing a subset of UML 2 with extensionsfor systems engineering applications.

35

3.7 MethodologyThe main methodology will be centered on Figure 23:Rose RT Model to RTP UML 2.0 Metamodelthrough XMI in this project. Here three different stages are defined. In the first stage, the Rose RTmodels are transformed to XMI of RTP UML 1.4 through the script. In the second stage, theMetamodel is generated and in the third stage, mapping rules to RTP UML 2.0 are proposed.

Figure 23:Rose RT Model to RTP UML 2.0 Metamodel through XMI

STAGE 1: Mapping and Conversion of UML RT Model

Mapping the concepts of the Rose RT to RTP UML 1.4

Properties and Representation for various elements in XMI 1.0

Writing the script for the transformation into XMI 1.0 with RTP UML 1.4 obtained throughextensibility mechanism with tags. (The Original XMI 1.0 supports only UML 1.3 in its syntax.However, in this project XMI 1.0 is used along with tags to facilitate the mapping.)

STAGE 2: Generation of Metamodel

It involves the process of generating the Meta model through the Meta Object Facility. This isdone by reading the XMI 1.0 through NSUML XMI reader.

STAGE 3: Proposal for Mapping to RT profile of UML 2.0

The metamodel of RTP UML 1.4 is combined with mapping rules to RTP UML 2.0 and a UMLMetamodel proposed to be built up.

36

3.8 Implementation

3.8.1 STAGE 1: Mapping of UML RT Model to RTP UML 1.4

The UML RT models are first mapped to the intermediate format chosen known as RTP UML 1.4 (Equation4: RTP UML 1.4 Formula). These findings were purely a result of explorative research indigenous of thisproject. It was carried out by trying different methods as to how an item could be exported in 1.0 version ofXMI and new methods were formulated at the end. The concepts of UML RT are mapped to concepts in RTPUML 1.4 standard. Table 14 shows how different concepts are mapped to RTP UML 1.4 standard.

Core RT Concepts

The Core concepts of UML RT to RTP UML 1.4 are tabulated as follows:

Concept Mapping to RTP UML 1.4 with XMI 1.0

Capsule Class with a stereotype ‘‘Capsule’’. A stereotype is used for exporting capsule sinceDuring meta modeling it is mapped on to Classes and it is designed to produce an XMIwhere its elements are private unless explicitly changed. The only elements which arepublic in a Capsule are its Ports. Capsules own the corresponding Capsule role in themand the ports.

Port Class with a composition relationship with the Capsules and has a stereotype ‘‘Port’’.The Port also references the other port which connects it (if it does) by means of abidirectional association. The port has a composition to the Capsule owning it andhas a realization relationship with the protocol.

Relay Port : Relay ports are modeled with visibility as public and has an associationrelationship with the other port which it connects to,

End Port: The visibility could be either public or protected depending on theinformation in the model and it could be connected to other port with an association orcould remain unconnected according to the model information.

Protocol Class with stereotype ‘‘Protocol’’. During meta modeling it is mapped on to asClasses. Protocols define the signals that can be sent through the ports. It ownsProtocol roles.

Protocol role: The information about a protocol role is not exported explicitly in theXMI though the in and out signals are defined in it. The “base” and “conjugated”protocol roles are created as subclasses of the protocol when the code is generated.

StateMachine

State Machine with State diagrams residing inside it. It has a composition relationshipwith the Capsule and is owned and destroyed by it. This is best represented in XMIunder owned elements or as association relationship with specification of a composition‘‘from’’ and ‘‘to’’ end. This would directly control the state machine under the capsule.The state machines under classes and protocols are also exported in the same fashionthough they are not generated as code.

Table 17 : Mapping Core RT Concepts to RTP UML 1.4

37

Secondary RT Concepts

The Secondary concepts of UML RT are mapped to RTP UML 1.4 as follows:

Concept Mapping to RTP UML 1.4 with XMI 1.0

Capsule role Class with a stereotype of “Capsule role” with a composition relationshipwith the corresponding Capsule and a composition relationship of thecorresponding “Port Role”.

Port role Class with a stereotype of “port role” having an aggregation relation with thePort, Port role will be an instance of Protocol role and hence will have ageneralization relationship.

Signals Attributes inside Classes with stereotype “InSignal” or “OutSignal”depending on the type.

Protocol role Protocol roles exist only during generation of code. Hence there is no suchconcept during mapping. For an overview of how it is generated in code in form oftransformation is discussed under Appendix A: How the code generator shouldwork with Real-Time elements? During generation a protocol is generated as aclass with two different subclasses: one base protocol role and another conjugateprotocol role. They form their roles based on the incoming and outgoing signalsthrough the port of the Capsule (participant in communication) in collaboration.

Transition Signal whose behavior is given by the transition source, transition targetand transition trigger. The t agged va lue s of the transi t ion conta in thecode presen t in the transitions. These tagged values have a name and a valueas discussed under Section 2.2.1.1.3:

Tagged Values .

Table 18: Mapping Secondary RT concepts to RTP UML 1.4

38

RT Elements of State Machine

The Real Time elements of a State machine can be tabulated as follows:

State Behavioral specifications with states with vertex and Composition and simple state.The composition state is the Initial state and all the states inside the state machine aresimple states.

Choicepoint

Pseudo states with references to the various transitions possible. These are extractedfrom the model Tags are used for the export of the condition for evaluation.

Guard Transition with reference to the condition in the tags. The transition has 3 paths. Atrigger, a guard condition, and an effect are the three parts of a transition. So all these3 will actually be transitions. The construct guard in XMI is used to specify thisrelationship.

Junction Point Pseudostate with the vertex which re f e r s t o the source or the destination of thetransition and termination state and specifies if its default, history or deep his tory.Continuing j un c t i o ns become defaul t value, t e rmina t i ng junctions becomehistory. Both Deep history and Shallow history are also Pseudo states. See Table 29:XMI and common properties for State Machines for information on what are the itemsare represented in XMI through Pseudostate

Event Guard This is a trigger with a guard condition hence it is exported as a transition and theconstruct “event” is used to refer to the event guard at the same time.

Event This is same as the trigger. It is specified by the construct event under associationrelationship of a transition.

Table 19: RT Elements of State machine mapping to RTP UML 1.4

Table 17, Table 18 and Table 19 define the mapping methodology as to how the various concepts ofReal Time UML are mapped into the new profile of RTP UML 1.4. These are the transformation ruleswhich were followed for exporting the models with the syntax of XMI 1.0 with additional tags attachedto them.

39

Relationship between Ports, Protocols, Protocol role and Capsule:

The Figure 24: Relationship between ports, Protocols, Protocol roles shows the metamodel of the realtime concepts such as ports, protocols, capsules and their subordinates. The Capsule can be representedas a Containment relationship or as a composition to itself. The Ports are owned by the capsule and isinstantiated by the Protocol Role. The Protocol owns the Protocol roles and the Signals which arecontained in it. The relationship as depicted in Figure 24: Relationship between ports, Protocols,Protocol roles is not supported in XMI syntax since it does not support UML RT. Hence this is done bymeans of establishing relationships according to the Figure 24: Relationship between ports, Protocols,Protocol roles during export of items in XMI.

End Port

Relay Port

<<Implements>>

Out SignalIn Signal

Protocol Role

Protocol

****

Connector

Capsule

**

Port

1

*

1

*

Port Role

**

Capsule Role**

**

Figure 24: Relationship between ports, Protocols, Protocol roles

Example of the Relationship between the Real Time Elements:

Figure 25 represents the real time model of a sender and a receiver Capsule through a port whichimplements the protocol through an interface. Here, the Port “toReceiver” belongs to the SenderCapsule and the port “toSender” belongs to the Receiver capsule. Both these Ports use the sameprotocol named Protocol through an interface called Interface.

Figure 25 : Representation of Real Time concepts: A sender and Receiver Capsule example

40

3.8.1.1 Properties and Representation for various elements in XMI 1.0

3.8.1.1.1 Common Properties of All Model Elements (Classifiers)

Classifier/Model Element could refer to any item and represent them in the model.

Properties Usage

ID This is used for identifying the classifier in the model and to reference it. This id is normallyreused in another model.

Example Representation:

xmi.id="theid". Here “theid” is alphanumeric and it may be referenced in one or more than oneplace for representing the relationships between the classifiers in

UUID* This is used for universally identifying the object across platforms and domains. This ID isuniversally unique. UUID stands for Universally Unique Identifier and is same as GUID(Globally Unique Identifier).

Example representation:

xmi.uuid="uuid899". Here “uuid899” is the unique identifier for the classifier. This UUID isnot used inside the model for referencing since it is done through xmi.id. However it can be usedto identify the classifier. There are certain elements that do not have a UUID. For representationfor such elements the ids are created.

Name This field is used for specifying the name of the classifier in the model.


<Foundation.Core.ModelElement.name>name </Foundation.Core.ModelElement.name>.

The “name” here refers to the name of the classifier in the model. There might be severalclassifiers with the same name in the same model.

Visibility This field is used for specifying the visibility of the classifier. The visibility could take thevalues Public, Protected, Private and Implementation.

“Public” is used when the classifier is publicly visible. It is accessible by the external libraryinterface and in any user model, it be used as the parent in an inheritance relationship. “Private”is used when the classifier is not visible outside its own structure It is not accessible or visible toexternal library interface. “Protected” is used when the sub classifiers are allowed access to theproperties of the super classifier. Implementation is used when the default access rights areprovided , where the classifier is visible only to other classifiers in the same package or level ofabstraction


<Foundation.Core.ModelElement.visibility xmi.value="public" />

IsSpecification

The field is used to determine if the classifier/element is a specification and a declarativedescription of the element’s role. The value of the field is a Boolean.


<Foundation.Core.ModelElement.isSpecification xmi.value="false" />.

This specifies that the particular element is not a declarative description.

Is Root The classifier/element is a root element and hence cannot be inherited from another. Thevalue of the field is a Boolean.

41


<Foundation.Core.GeneralizableElement.isRoot xmi.value="true" />

This specifies that the element is the root and thus can’t inherit from any other element.

Is Leaf The classifier/element is the last or final classifier


<Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" />

This specifies that the element is the leaf or the final classifier. “Is Leaf” and “Is Abstract”cannot be true at any single point.

IsAbstract

The classifier/element is abstract and is not concrete element.


<Foundation.Core.GeneralizableElement.isAbstract.xmi.value="false" />

This specifies if the element is an abstract value or not. This cannot be true if the IsLeaf istrue because if the element is the leaf element (leaf node), it should be concrete.

Namespaceand OwnedElement

The classifier/element has owned elements in it and the elements belonging to it is presentinside the tags. The namespace denotes the element information inside the classifier.

<Foundation.Core.Namespace.ownedElement> and

<Foundation.Core.Namespace.ownedElement>

Table 20: Properties and Representation Common to all Elements in the Model

* UUID does not exist by default for the elements listed under the following section. For such elements,UUID is created.

CREATION OF UUID for elements that do not have it by default:

The following elements don’t have UUID: Protocol In Signals () Protocol Out Signals () States (Composite State) Capsule Roles Ports Port Roles Capsule Structure diagram Classifier Role Transitions Junction Point Choice Point Connectors Guards Events Event Guards Parameters () Element hyperlinks (External Document)

Such items are subject to creation of UUID by the script.

42

3.8.1.1.2 Additional Basic Properties and representations of Classifiers in XMI:

All examples and constructs definitions are those which are common representations in XMI. For a fulllist of possible constructs please see [7].

RELATIONSHIPS

Association:

This is a relationship which defines the role played by two classifiers in context. There can be 3different kinds of associations.

1. Simple association2. Aggregation3. Composition

All the three different types of association have the same set of syntax with the change in the values ofthe properties. A Simple Association is a relationship between two classifiers where one would usinvokes the services of the other. Association can be thought of conduits which find each other duringrun time and exchange messages.

An Aggregation is a relationship between two classifiers where one is a part of the other whole and aComposition is a relationship which is a form of aggregation in which the whole part is responsible forthe creation and destruction of the part objects. In XMI, all these three relationships are representedusing a single format with different values. They also have the constructs under Table 17.There are twoends in an Association relationship and the syntax is same for each the end except for the id referencesacross. The full representation of all the constructs can be found under the XMI 1.0 DTD [7]. Theconstructs and their meaning are tabulated as follows:

Construct Meaning

<Foundation.Core.Association.connection> This represents the start of the Associationconnection

<Foundation.Core.AssociationEnd.isNavigablexmi.value=”false/true”/>

This represents if the association end is possibleto be navigated during the operation from thesource to target instance.

<Foundation.Core.AssociationEnd.orderingxmi.value="unordered" />

This represents if the Association End is orderedor unordered in a model. The values are orderedand unordered. Ordering is determined andmaintained by Operations adding the links.

<Foundation.Core.AssociationEnd.aggregationxmi.value="composite" />

This represents the Aggregation end in themodel. The values could be simple, aggregateand composite

<Foundation.Core.AssociationEnd.targetScopexmi.value="instance" />

This represents if the target scope is an instanceor not.

Multiplicity:

<Foundation.Data_Types.MultiplicityRange.lower>

<Foundation.Data_Types.MultiplicityRange.upper>

This represents the Multiplicity range in theassociation. The lower and upper are the limitson the association side.

<Foundation.Core.AssociationEnd.changeabilityxmi.value="changeable" />

This represents if the association end could bechanged or not.

Table 21 : Major Constructs of an Association relationship in XMI

Example:

Each relationship between two items has 6 specifications in XMI. The following 3 specifications arepresent for association from both the directions.

1. The Association specification of one classifier to another in 1 direction.

2. Role 1 in one of the association end.

3. Role 2 in the other association end.

Figure 18(a): A Simple association example

Figure 18(b) A Composition example

43

Figure 26: Association relationsh

The example in Figure 18(a) is a simple association betweennamed Controller. This relationship will be translated into X

1. An association specification from Trafficpost to Con

2. Role 1 of “Trafficpost” association ends in the “Traf

3. Role 2 of the “Controller” association end in the assassociation.

4. An association specification from “Controller” to “T

5. Roles 1 in “Controller” association end in the “Cont

6. Role 2 of the “Trafficpost” association end in “Cont

The above 6 relationships are same for aggregation and comsuch as navigable, static, friend etc.

Consider the figures 18(a), 18(b) and 18(c)

The XMI of the above relationships are the same except ththe above relationship translates as in Table 22 as follows.

Figure 18(c): An Aggregation example

ip examples

a class named “Trafficpost” and a capsuleMI with the following parts.

troller

ficpost” “Controller” association.

ociation from “Trafficpost” “Controller”

rafficpost”.

roller” “Trafficpost” association.

roller” “Trafficpost” association.

position relationships also with modifiers

e association connection type. The XMI of

44

Start ofassociationconnection

<Foundation.Core.Association.connection>

AssociationspecificationfromTrafficpostto Controller

<Foundation.Core.AssociationEnd xmi.id="G.2" xmi.uuid="4476D34B028B"><Foundation.Core.ModelElement.name /> (Since the association is not named here)<Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.AssociationEnd.isNavigable xmi.value="true" /> If the association end is navigable.

<Foundation.Core.AssociationEnd.ordering xmi.value="unordered" /><Foundation.Core.AssociationEnd.aggregation xmi.value="none" /> This is for indicating aggregation relationship on this end. This value is

“aggregation” or “composite” depending on the relationship present.<Foundation.Core.AssociationEnd.targetScope xmi.value="instance" />

Associationendmultiplicity(TrafficpostController)

- <Foundation.Core.AssociationEnd.multiplicity>- <Foundation.Data_Types.Multiplicity><Foundation.Data_Types.Multiplicity.range>(Specifies the multiplicity range)- <Foundation.Data_Types.MultiplicityRange xmi.id="id.1461014.1"><Foundation.Data_Types.MultiplicityRange.lower>0</Foundation.Data_Types.MultiplicityRange.lower><Foundation.Data_Types.MultiplicityRange.upper>1</Foundation.Data_Types.MultiplicityRange.upper> (The range of Multiplicity)</Foundation.Data_Types.MultiplicityRange></Foundation.Data_Types.Multiplicity.range> </Foundation.Data_Types.Multiplicity>

</Foundation.Core.AssociationEnd.multiplicity><Foundation.Core.AssociationEnd.changeability xmi.value="changeable" />

- <Foundation.Core.AssociationEnd.type> </Foundation.Core.AssociationEnd.type></Foundation.Core.AssociationEnd>

AssociationspecificationfromControllerTrafficpost withmultiplicity

<Foundation.Core.AssociationEnd xmi.id="G.3" xmi.uuid="4476D34B029B"><Foundation.Core.ModelElement.name /><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.AssociationEnd.isNavigable xmi.value="false" /><Foundation.Core.AssociationEnd.ordering xmi.value="unordered" /><Foundation.Core.AssociationEnd.aggregation xmi.value="none" /> This is for specifying association from this end

<Foundation.Core.AssociationEnd.targetScope xmi.value="instance" />- <Foundation.Core.AssociationEnd.multiplicity>- <Foundation.Data_Types.Multiplicity> <Foundation.Data_Types.Multiplicity.range>- <Foundation.Data_Types.MultiplicityRange xmi.id="id.1461014.2"><Foundation.Data_Types.MultiplicityRange.lower>0</Foundation.Data_Types.MultiplicityRange.lower>

<Foundation.Data_Types.MultiplicityRange.upper>-1</Foundation.Data_Types.MultiplicityRange.upper> Specifies multiplicityEnding of all open XML constructs here of Multiplicity<Foundation.Core.AssociationEnd.changeability xmi.value="changeable" />

- <Foundation.Core.AssociationEnd.type><Foundation.Core.Classifier xmi.idref="S.145.1214.56.3" /></Foundation.Core.AssociationEnd.type></Foundation.Core.AssociationEnd></Foundation.Core.Association.connection></Foundation.Core.Association>

Table 22: Example XMI Output for association

45

The 3 specifications in Table 22 namely the Association itself, the role 1 specification and the role 2specification is described from the other end as well thereby constituting a total of 6 parts. The id of theassociation is referenced from the other association end and thus they make a connection in therelationship in XMI. All the three types of associations have the same output except the change in thespecifications of aggregation value which can take the values “none”, “aggregate” and “composite” forsimple association, aggregation and composition respectively.

GENERALIZATION

The Generalization relationship is used for instantiating and for inheritance of the elements.

Construct Meaning

<Foundation.Core.GeneralizableElement.isRoot> This indicates the element is the root.

<Foundation.Core.GeneralizableElement.isLeaf> This indicates that the element is the leaf.

<Foundation.Core.GeneralizableElement.isAbstract> This is used to indicate of the generalizableelement is abstract or a concrete element.

<Foundation.Core.Generalization.child> This is used for representing the element whichinherits or simply the child.

<Foundation.Core.Generalization.discriminator/> This designates and represents the partition towhich the generalization link belongs to.

<Foundation.Core.Generalization.parent> This represents the parent in the generalizationrelationship.

Table 23 : Major Constructs of an Association relationship in XMI

The output of a Generalization relationship is similar to that of an Association relationship with the 6parts mentioned in Table 22: Example XMI Output for association and in Table 20: Properties andRepresentation Common to all Elements in the Model. In addition, it contains the constructs in Table 18in each of the classifier involved in the generalization relationship. (Both parent element and theinheriting element).

Example:

Consider the following generalization relationship:

Figure 27 : Generalization relationsh

In Figure 27, the “Trafficpost” class inherits from theCapsule named Controller and hence has the followingproperties in addition to Table 20 for fully representingthe generalization relationship.

ip example

46

Example Generalization relationship semantics:

Start of theclassdefinition ofTrafficpost

- <Foundation.Core.Class xmi.id="cl1" xmi.uuid="447677C4032F"><Foundation.Core.ModelElement.name>Trafficpost</Foundation.Core.ModelElement.name>

<Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="true" /> The Class “Trafficpost” is the leaf element here.<Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" /><Foundation.Core.Class.isActive xmi.value="false" />

- <Foundation.Core.ModelElement.namespace><Foundation.Core.Namespace xmi.idref="G.0" />

Generalization relationshipdefinition ofTrafficpostClass.

- <Foundation.Core.GeneralizableElement.generalization><Foundation.Core.Generalization xmi.idref="G.7" /></Foundation.Core.GeneralizableElement.generalization>

- <Foundation.Core.Namespace.ownedElement>- <Foundation.Core.Generalization xmi.id="G.7" xmi.uuid="447A184D014E">

<Foundation.Core.ModelElement.name /><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.Generalization.discriminator />

- <Foundation.Core.Generalization.child><Foundation.Core.GeneralizableElement xmi.idref="cl1" /> The Class is referenced using its ID. This appears in Child and hence refers tothe class “Trafficlight” which is inheriting from the Capsule Controller.

</Foundation.Core.Generalization.child>- <Foundation.Core.Generalization.parent>

<Foundation.Core.GeneralizableElement xmi.idref="S.147.2338.49.3" /> This is the other end of the Generalization relationship.

</Foundation.Core.Generalization.parent></Foundation.Core.Generalization>

Table 24: Example XMI output for Generalization

The generalization relationship is completed fully with the definition from the Capsule named“Controller” to the class “Trafficpost”. The generalization “Controller” to the class “Trafficpost” isidentical to the Table 22: Example XMI Output for association except that the reference of the idappears under the construct <Foundation.Core.Generalization.parent> instead of child. Thus the link isestablished and the generalization relationship is exported.

DEPENDENCY

This is a relationship which is used for representing element dependency on another element for resultor execution. There are primarily four kinds of dependency namely abstraction, binding, usage andpermission [36].

Abstraction - Used for representing abstract relationship between classifiers. <<refine>> and<<realize>> are the common stereotypes of abstraction relationship

Binding - Used for binding a set of actual parameters to a formal parameter list. The commonstereotype is <<bind>>

Usage - One classifier is the usage of the other because some services are provided by the other. Thecommon stereotype is <<usage>>

47

Permission - Type used for setting permissions for the element. The common stereotype used is<<friend>>

The output of XMI for a dependency follows the same constructs under association in Table 17 and inaddition to it contains the following defining elements.

Construct Meaning

</Foundation.Core.ModelElement.supplierDependency> and

<Foundation.Core.Dependency.supplier>

This is used to indicate the classifier supplyingthe dependency

</Foundation.Core.ModelElement.recieverDependency> and

<Foundation.Core.Dependency.client>

This is used to indicate the classifier receivingthe dependency

Table 25 : Major constructs in a Dependency relationship

The stereotypes could be included with the dependency to indicate the exact form of relationshipbetween the two classifiers involved in the dependency relationship.

Example:

Consider the following dependency relationship.

Figure 28 : Dependency relationship example

Example Dependency relationship semantics:

Start of Dependencyrelationship

<Foundation.Core.Dependency xmi.id="G.7" xmi.uuid="447A426D03B0">

Name (No namegiven fordependency here)

<Foundation.Core.ModelElement.name />

Declarativedescription andvisibility

<Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />

Dependency of theclient

- <Foundation.Core.Dependency.client><Foundation.Core.ModelElement xmi.idref="cl1" /></Foundation.Core.Dependency.client>

Dependencyreference from the“Controller”Capsule

- <Foundation.Core.ModelElement.supplierDependency><Foundation.Core.Dependency xmi.idref="G.7" /></Foundation.Core.ModelElement.supplierDependency>

Dependencyreference from thesupplier

- <Foundation.Core.Dependency.supplier><Foundation.Core.ModelElement xmi.idref="cap1" /></Foundation.Core.Dependency.supplier>

Table 26 : Example XMI of Dependency relationship

48

The dependency relationship is thus completed by the reference from the supplier in the dependencyapart from the constructs in Table 24: Example XMI output for Generalization and an associationrelationship output from Table 22: Example XMI Output for association and Table 20: Properties andRepresentation Common to all Elements in the Model. An aggregation is referred in the dependencyrelationship from Trafficpost to “Controller” capsule.

CLASS

The class is the most common classifier used in an XMI representation. It is used in modifying andcreating new profiles through the usage of Extensibility mechanisms. Here a class with an attribute andan operation is considered for export.

The major constructs required for an attribute and operations are as follows:

ATTRIBUTE

Construct Meaning<Foundation.Core.Attribute xmi.id">

<Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility<Foundation.Core.ModelElement.isSpecification>

The Common start of declaration of an attribute withgeneral specifications that a classifier possesses.

<Foundation.Core.Feature.ownerScope > Specifies whether the attribute appears in eachinstance of the Class or if only a single instance ofthe feature for the entire Classifier exists

<Foundation.Data_Types.Multiplicity> This is used for specifying the multiplicity of theelement.

<Foundation.Core.StructuralFeature.changeabilityxmi.value><Foundation.Core.StructuralFeature.targetscopexmi.value>

The structural feature here refers to the attribute itselfand the “targetScope” specifies if the targets areordinary instances or classifiers.

</Foundation.Core.Attribute.initialValue> For indicating initial value<Foundation.Data_Types.Expression>

<Foundation.Data_Types.Expression.language ><Foundation.Data_Types.Expression.body ><Foundation.Data_Types.Expression>

This defines and is used to evaluate to a set ofinstances when it is executed in a particular context.

OPERATIONS

<Foundation.Core.BehavioralFeature.isQueryxmi.value>

This indicates if the execution of the operationleaves the system changed or unchanged. “True” willleave it unchanged; “false” indicates that side effectsmay occur.

<Foundation.Core.Operation.concurrencyxmi.value>

Specifies the semantics of the concurrent calls to thesame passive instance.

<Foundation.Core.Parameter.type> This construct is used to define the parameter typeand its behavior is defined through it.

DATA TYPE

<Foundation.Core.DataType> This is used for referencing the data type of the item.The id is referenced by all attributes and elementswhich use the particular data type.

Table 27: XMI representation of Attribute and Operation

49

CAPSULE:

The Capsule is the same classifier as the Class. However it has the extensibility mechanism indicationby use of a stereotype that it is a “Capsule”. A “Capsule” has the following elements in addition toClass representation as under Table 9: XMI output for a simple model and Table 27: XMIrepresentation of Attribute and Operation.

Construct Meaning

<Foundation.Extension_Mechanisms.Stereotype xmi.id>

The Stereotype Id for and indicates the start of thestereotype specification.

<Foundation.Core.ModelElement.name> This represents the name of the stereotype and itis “Capsule”.

<Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" />

These are common properties as alreadydiscussed in Table 10.

<Foundation.Extension_Mechanisms.Stereotype.icon >

This is used to represent if there is an existence ofan icon to represent the stereotype.

<Foundation.Extension_Mechanisms.Stereotype.baseClass>

This is used to represent the base type classifier orclass of the stereotype which is “Class”.

<Foundation.Extension_Mechanisms.Stereotype.extendedElement>

<Foundation.Core.ModelElement xmi.idref ></Foundation.Extension_Mechanisms.Stereotype.extendedElement></Foundation.Extension_Mechanisms.Stereotype>

These constructs are used to refer to the id of theclass to which the stereotype is to be extended.

Table 28: Major Constructs of a Capsule in XMI

Capsule role:

A Capsule role occupies a particular position in the collaboration of the capsule. This is exported as anobject of the Capsule. In terms of XMI representation, the Capsule role is exported as another classwith an association of type composition with the Capsule. This is referenced by mentioning the id of theCapsule.

Port and Port Roles:

A Port is an object which is used for Communication of the Capsule to the outside world and is createdand destroyed by the capsule. It thus has a composition relationship with the Capsule. It could be of twotypes namely Relay Port and End Port as in Table 4. The Port is exported as a Class with stereotype“Port” and hence will have a “port” stereotype instead of “Capsule” as in Table 25for export apart fromthe relationship mentioned already.

Thus a Capsule modeling would look like Fig 16. The relationships between Capsules, Capsule roles,Ports and Port roles exist as in Fig 16 and hence follow the relationship with constructs as under Table17 and Fig 18(b) for composition between Capsule and Capsule role and Capsule and Port and willhave association constructs for means of specifying if it is connected to other port (For specification ofRelay and End ports) as under Table 16 and 17 and Fig 18(a).

50

PROTOCOL:

A protocol defines the set of insignals and out signals that can be sent and received by the port. The portis instantiated by a Protocol. Technically, a port should be instantiated by a protocol role but theprotocol role concept is abstract until it becomes code. Hence while exporting in XMI; it is rational toexport ports to be instantiated directly by corresponding protocol of definition and thereby having ageneralization relationship. The protocol is exported as classes with stereotype of “Protocol” instead of“Capsule” as in Table 28 and follows the generalization constructs(which includes association) as inTable 23 : Major Constructs of an Association relationship in XMI and Table 24: Example XMI outputfor Generalization.

STATE MACHINE

A state machine can be defined as a behavior that specifies the valid sequences of activities that anobject or interaction goes through during its life in response to events, together with its responses andactions. The State machines could be included in a Capsule, Class or a Protocol but only the statemachine in the Capsule has significance as only they are generated in code when compared to classstate machine or a protocol state machine.

Construct Meaning

<Behavioral_Elements.State_Machines.StateMachine

This marks the beginning of the state machine. This has thebehavior embedded in it.

<Behavioral_Elements.State_Machines.StateMachine.context>

This represents as to which classifier owns the state machine

<Behavioral_Elements.State_Machines.CompositeState>

A composite state is one which is the initial state which has anownership of control over the rest of the states. It contains otherstates (known as sub-states), allowing hierarchical state machines tobe constructed.

<Behavioral_Elements.State_Machines.Pseudostate>

This construct of pseudo state is used to combine and directtransitions and it is used to specify if the pseudo state is one of thefollowing:

Initial, Choice, Junction, Deep History, Shallow History, Join,Fork, Entry Point, Exit point, terminate. All these differenttypes of states can be handled by this construct.

Behavioral_Elements.State_Machines.SimpleState

This is a construct for a simple state. This is used by any state inbetween the composite and final state except the pseudo state.

Behavioral_Elements.State_Machines.SubState

This construct is used for a state that references another statemachine.

<Behavioral_Elements.State_Machines.StateVertex.incoming>

Behavioral_Elements.State_Machines.StateVertex.outgoing>

This is used for the incoming and outgoing state transitions in thestate.

</Behavioral_Elements.State_Machines.Transition.source><Behavioral_Elements.State_Machines.Transition.target>

This is used for the transition source and the target states.

Table 29: XMI and common properties for State Machines

51

The following Figure 29: Simple Metamodel of a State machine shows a simple metamodel of a Statemachine. The relationships of the elements are supported through the syntax of XMI 1.0. All theelements of the state machine are exported using one of the elements present in the Figure 29: SimpleMetamodel of a State machine. For example, Choice points and junction points are exported as Pseudostates. See Table 19: RT Elements of State machine mapping to RTP UML 1.4

Figure 29: Simple Metamodel of a State machine

Example:

Consider the following state machine in the Capsule named “Controller” with a state machine asfollows:

9

Figure 30: State Diagram in a Capsule

Fig 29 (a) simplestructure of a Capsulenamed Controller.

Fig 29(b) A state diagram included in theController Capsule

52

The Capsule specification is carried out in the same way as in Table 28: Major Constructs of a Capsulein XMI. The state diagram Fig 29(b) is then exported as a separate structure but with reference to theCapsule.

Example Major parts of State Diagram in Capsule semantics:

Construct Meaning

<Behavioral_Elements.State_Machines.StateMachine xmi.id>

This starts the behavioral specification


The association to the state machine constrained tobe a classifier or behavioral feature. The modelelement’s behavior is specified by the state machine


This is used to designate the top level state

<Behavioral_Elements.State_Machines.CompositeState xmi.id="st1">

This is a state which consists of sub states. This isthe top state by default and all the states belongunder this state.

<Behavioral_Elements.State_Machines.StateMachine.transitions>

This defines the transitions in the state machine

<Behavioral_Elements.State_Machines.Transition.source><Behavioral_Elements.State_Machines.StateVertex xmi.idref="G.1" />

This represents the source from which the transitiontravels. This is the state nsGreen in Fig 28 b

<Behavioral_Elements.State_Machines.StateVertex xmi.idref="G.3" />

This represents the vertex of the state machine.

Behavioral_Elements.State_Machines.Transition.target>

This represents the transition to the target statemachine.

<Behavioral_Elements.State_Machines.Transition.trigger>

This is used to represent the trigger that will initiatethe transition. This is included in change1 in Fig28(b).

Table 30: Major constructs of the state diagram example

The major constructs are repeated for each element and each state transition code is exported as taggedvalues with the corresponding reference of the element id. The state machine is then referenced to thecorresponding capsule to generate the full output of the Capsule with the state machine.

Issue of three types of State Machines:

Regardless of the different types of state machines namely Capsule State Machine (the most important),Class state machine and Protocol state machine, the export of the items in the state machine for all thethree classifiers are the same. For the difference between these three state machines please see section2.1.2.5: Different Kind of State Diagrams in UML RT:

TAGGED VALUES

These are used as extension mechanisms of the elements using one of the extensibility mechanisms asdescribed under section 2.2.1.1: OMG UML 2.0 and Extensibility Mechanism. These are constructswhich are frequently used for exporting items which cannot be exported otherwise using the syntax ofthe XMI format.

53

Construct Meaning

<Foundation.Extension_Mechanisms.TaggedValuexmi.id>

This is used for the id representation. Of thetagged item

<Foundation.Extension_Mechanisms.TaggedValue.tag><Foundation.Extension_Mechanisms.TaggedValue.value>

This is used for specifying the name of the tagand the value for it.

<Foundation.Extension_Mechanisms.TaggedValue.modelElement><Foundation.Core.ModelElement xmi.idref>

This is used for referencing the model elementto which the tagged value is referring to.

Table 31: Common constructs of Tagged Values

Example:A tagged value for a Capsule on Persistency is tagged as follows:

<Foundation.Extension_Mechanisms.TaggedValue xmi.id="XX.26.1242.6.2"><Foundation.Extension_Mechanisms.TaggedValue.tag>persistence</Foundation.Extension_Mechanisms.TaggedValue.tag><Foundation.Extension_Mechanisms.TaggedValue.value>transient</Foundation.Extension_Mechanisms.TaggedValue.value><Foundation.Extension_Mechanisms.TaggedValue.modelElement><Foundation.Core.ModelElement xmi.idref="cap1" /></Foundation.Extension_Mechanisms.TaggedValue.modelElement></Foundation.Extension_Mechanisms.TaggedValue>

ADDITIONAL ITEMS IN ROSE RT

The additional items in Rose RT such as elements in the Use Case View, Component view [38] anddeployment view are also exported in XMI using the corresponding syntax as under [7]. Since these donot fall under Real-Time criteria or under basic relationship criteria such as association, generalizationetc , their syntax in XMI is not interpreted in this report.

The Working of the XMI Script:

The XMI script works with the various modules as depicted in Figure 31, Figure 32, Figure 33, Figure34, Figure 35 and Figure 36. The working of the script will also be handling the additional elementswhich are non real time such as the elements in Use Case View and Component view but are notdiscussed under the working of the script since they are non real time elements.

The script could be also modified in terms of its working and export of elements. For example, thehandling of the state machines could be done totally separately rather than exporting it within theCapsule or Classes or Protocols.

Further, in the following illustrations of the working of the script through various artifacts, the handlingof the state machines inside Classes or Protocols are not deal with since they are of least significance.However, they are exported in the similar fashion as that of the export of Capsules.

54

3.8.1.1.3 Export of Model Information:

Figure 31: The Initial Control flow in the script

3.8.1.1.4 Branching through different artifacts:

Figure 32: The Branching of Control through different sections

The artifacts are then checkedfor the number of Classes,Capsules and Protocols and theexecution is carried out inseparate steps for each ofthem.

It initially starts with checkingthe number of classes and endswith the Protocols.

The Rose RT model is fed in to the toolwhich is developed as a script insideRose RT. The Model Information isread in and a default name is given ifthe model is unnamed. The LogicalPackages are checked for existence.The Model is accessed by the APIRoseApp.Current.ModelName

55

3.8.1.1.5 Export of Classes in XMI

The Classes in XMI are the first elements which are exported into XMI. Each item such as Class,attribute etc are stored in a separate array after declaring a type for such items.

Example:Type xmiClass

id As Integeruuid As StringtheName As StringisSpecification As StringisRoot As StringisLeaf As Stringtag As Stringabstract As Booleanstereotype As Stringvisibility As Stringinvariants As String

EndType

Figure 33: Export of Classes in XMI

Every element is declared with a type declared byType in Basic. The Extensibility InterfaceManual [35] from Rose RT has the variouscommands and APIs required for accessingdifferent elements in the model.

56

3.8.1.1.6 Export of Capsules in XMI

The Capsules are the most important artifact in a Rose Real Time Model and they also contain statemachines. The process executed in exporting the capsules starts manipulating the ports, storing them inseparate arrays, then working on capsule roles, attributes, operations , state machines and is later printedlooping through the number of items in the array. The items in a capsule which is printed outside itsstructure are its state machines, port roles and capsule roles. However, the capsule id is referenced. Theattributes, operations are printed inside the structure of the capsule itself. The port when printed outsidethe capsule structure bears a composition relationship with the capsule and is technically instantiated bya protocol role though practically by protocol since protocol roles exists only during generation of code.

Figure 34: Export of Capsules in XMI

57

3.8.1.1.7 Export of Protocols in XMI

The Protocols are exported in XMI as classes with the stereotype Protocol. They have in and out signalsand they are represented as attributes with stereotypes of “insignal” and “outsignal”. The Protocoldefines the port and hence will be referenced by many ports that use them.

The Export of Protocols in XMI script is handled similar to that of a Capsule thereby, howeverProtocols do not have any ports that they own but define them.

Figure 35:Export of Protocols in XMI

58

3.8.1.1.8 Export of Tags in XMI

Figure 36: Export of Tags in XMI

3.8.2 STAGE 2: Generation of Metamodel

The resultant XMI 1.0 which is compliant with RTP UML 1.4 is fed into the XMI reader calledNSUML XMI reader which is present as a plug-in in the code generator. This generates the MOF (MetaObject Facility) back and is used for metamodeling and mapping new elements. The XMI therebyproduced has all the information of UML RT model though vital information like the generated codeand some state machine specific elements like choice points are in the form of Tags. The usage of tagscould be standardized by choosing a higher XMI version such as XMI 2.0 or 2.1 which define thepossibility of export of many elements in a standard syntax. The reader for such an XMI version as anopen source was found and is Ecore XMI Reader as described under 2.5.1.3: Ecore XMI reader andwriter for EMF . Though this reader is not used in the project due to the choice of XMI 1.0 at a veryearly stage, the XMI produced is recommended to be changed to syntax of XMI 2.0 for maximuminteroperability. This follows the principle as depicted in the figure is shown in Figure 21:Creation of an UML Profile and this entire process is described in Figure 37:Generation of RTP UML1.4

Tags are the key concepts used in the exportof additional information from the metamodel of the UML RT model. The tags canbe used to export any information in themodel which is not supported in the syntax ofthe XMI to handle.

The XMI 1.0 syntax does not support tags.Hence, the model information such as theComposition and conditions of guards orchoice points for example are handled astags.

59

Code Generator

NSUML XMIReader

used by

Stereotypes Tags

Extensibility Mechanisms of UML

Constraints

UML

UML RT Specific Requirements

Transformation ruleswith

realized through

translated as

RTP UML 1.4

fed into

produces

Figure 37:Generation of RTP UML 1.4

3.8.3 STAGE 3: Proposal for mapping to RTP UML 2.0

After the metamodel is generated the model has to be mapped to RTP UML 2.0. Though we try toadhere to UML 2.0 as much as possible, not all the concepts of UML 2.0 can be supported. This is aproposal as the decision to support UML 2.0 according to the proposal has to be initiated by the otherproject “XMI-based Code Generation for Real-Time Systems” [24]. Hence the standard ultimatelychosen will be again a clone of most standards of UML 2.0 and Real Time and should be adhering to acertain extent to Schedulability, Performance and Time Standard of UML from OMG[14] with slightvariations and hence its called here as RTP UML 2.07 and its advantages are flexibility andinteroperability between tools and platforms. Better standardization of models is facilitated.

The Mapping of the RTP UML 1.4 to RTP UML 2.0 is tabulated as in the table below. Some of theconcepts remain the same while mapping from RTP UML 1.4 to RTP UML 2.0. Such concepts whichare not mentioned in Table 32: Mapping RTP UML 1.4 to RT UML 2.0 are shown below. The list of allconcepts for mapping can be found under the Section 3.8: Implementation

7 RTP UML 2.0 is not an OMG standard but has close resemblance to UML 2.0 and [14]

60

UML RTRepresentation

RTP UML 1.4Representation

RTP UML 2.0 Representation

Classes Classes Classes

CapsulesClasses with Capsulestereotype

Structured Classes with the artifacts of Capsules with all elementsinside them.

ProtocolsClasses with Protocol

stereotypeInterfaces with provided (aka supplied) and required constraints onthem. They are thus called Provided and Required Interfaces. Theyshould have a composite relationship to the Interface. This can becompared to the base and conjugate protocols having a compositerelationship with the Protocol.

Statemachine

State machine withreference toCapsule/Class/protocol.

State machine with reference to Structured Class/Class/protocol.All the elements of the state machine remains the same asrepresented in RTP UML 1.4 as under Table 19: RT Elements ofState machine mapping to RTP UML 1.4

PortsPorts with “Port”Stereotype. Relay andEnd ports are specifiedwith their associationrelationships accordingto Table 4.

Relay port become delegate port and. End Port becomes port withthe either public/protected visibility s with/without associationswith other ports in the beginning.

Table 32: Mapping RTP UML 1.4 to RT UML 2.0

Potential Problems to face moving to RTP UML 2.0 and counteraction:

The RT Library does not support RTP UML 2.0 while generation of code if the Protocols becomeinterfaces; Capsules are called as Structured Classes etc. There might be confusion regarding thedifferent classification and nomenclature as the artifacts will be called by the names supported by UML2.0.However, this problem can be encountered successfully if an XMI version supporting UML 2.0 ischosen and the UML 2.0 concepts are exported with Extensibility mechanisms as under Section 2.2.1.1:OMG UML 2.0 and Extensibility Mechanism and this process is shown under Figure 38: Methodologyfor RTP UML 2.0 Mapping as follows.

Figure 38: Methodology for RTP UML 2.0 Mapping

Here, the UML 2.0 concepts are implemented using XMI 2.0 or XMI 2.1 syntax and the extensibilitymechanisms for UML are used. Hence the Capsules can still be called as Structured Classes in the XMI.When the UML 2.0 concepts are mapped with the Extensibility mechanisms, they combine the Real-Time Profile of UML 1.4 with the pure UML 2.0 concepts to produce a Real Time Profile of UML 2.0.

61

3.9 What about Diagram Information of the models?Exporting diagram information must be undertaken. It must be noted that the Unisys Plugin for Rational exportsdiagram information through XMI [DI] (XMI Diagram Interchange). The geometric information is appended atthe end of the file when the diagram information generation is selected in the exporter. Sequence Diagrams mustbe given the top priority along with state machine diagrams while the export is being done on diagrams. UMLSemantics defines the metaclass information while UML Notation defines the diagram information. This UMLNotation is used in Unisys JCR exporter for Rational Rose and could be the best way to follow it for exportingdiagram information and interchange since it has been tested by importing it back into XMI reader and is foundto generate the diagram information back. The tool used for importing the XMI DI is MagicDraw 7.1. TheUnisys JCR exporter uses syntax for exporting geometric information in the models. Apart from Unisys JCR,Coral 0.8.2 exports XMI Diagram Interchange format. While Unisys JCR has been tested, Coral 0.8.2 has notbeen tested in this project. Thus Unisys JCR could be used along with Eclipse EMF which to generate XMI 2.0.This could be an excellent combination to export models with XMI 2.0 format with Diagram Interchange format.The Rose RT API [35] provides the method that could be used for accessing the diagram information and thiscould be used for printing out sequence, class, use case, component, deployment and other diagrams. This couldbe illustrated with the following example. Consider a model with a simple class diagram containing dependencyas in Figure 28 : Dependency relationship example. The diagram information of this simple class diagram can beinterpreted as follows

Construct Meaning

<Diagramming.Diagramxmi.id="S.177.2145.14.1">

This is the start of the diagram interchange representation.

<Diagramming.Diagram.name> This is the name of the diagram . This represents if this is the main diagram in themodel (under Main in Logical View) or a diagram whose name is specified.

<Diagramming.Diagram.toolName> This represents the name of the tool exporting the diagram information.

<Diagramming.Diagram.diagramType> This represents the type of the diagram. The diagram could be a Class diagram,Component Diagram, A State Diagram etc. Valid values are correspondingly“ClassDiagram”,”ComponentDiagram” etc.

<Diagramming.Diagram.style /> This represents id the diagram itself has a style. The style refers to the Font size,the colors, the elements and attributes that are visible, the transparency, theautomatic resizable ability etc. are the possible parameters and they are allBooleans with their values specified.

Diagramming.Diagram.owner><Foundation.Core.ModelElement xmi.idref="G.0"/> </Diagramming.Diagram.owner>

This represents the owner of the diagram is the package in this case with its xmi:idref and here it is referenced as “G.0”

<Diagramming.Diagram.element><Diagramming.DiagramElementxmi.id="XX.27.2145.14.4">

This is the element of the diagram in this case it is the dependency relationshipbetween the elements.

<Diagramming.DiagramElement.geometry>

This represents the geometrical placing of the element and possible format of thevalues are the coordinates of the starting and the ending points of the elementitself.

<Foundation.Core.PresentationElement.subject>

This is responsible for the representation of the end of the dependency whichpoints to the second model element. In this case it is the Controller Capsule.

Table 33:Export of Diagram Information of elements

The other information in addition to Table 33:Export of Diagram Information of elements is theinformation of the “Controller” Capsule on the other end which has the same parameters as mentionedin the table above

62

4 ResultsThe results were based on the verification of the XMI produced and by the developed script. Thisverification was carried out, by feeding the XMI into tools for syntax checking and correctness of themodel information produced.

4.1 VerificationVerifying by Proof of Concept:

Each model is checked for its correctness and integrity by feeding it into the NSUML XMI reader andthe concept is checked if all the elements of the models arrive. Though this is an “informal” method ofverification, due to strict time constraints, formal proofs are not undertaken. The models were convertedinto XMI and the model information was built back and then is verified and validated.

Syntactic checking:

A tool called Altova XMLSpy was used. A snapshot of this is present in Appendix D: SyntaxVerification

Semantic checking:

The tool CodeGenie was used to check if the model information was imported back correctly. Thesnapshot is included in Appendix D: Semantics Verification

Model Checking:

Initially, the generated XMI was also imported back into Rational Rose tool and the integrity of theitems was checked.

Alternate Method of Verification for Future:

Formal Methods:

Formal methods in Software Engineering are widely used in the area of verification and theoremproving. There is no proper refinement methodology for UML RT due to the lack of formal semantics.However OCL (Object Communication Language) of UML 2.0 can be used for verification of themapping of concepts. An attempt was made in verification using theorem proving using OCL but sinceit was time consuming. This could be done as a final check after all the mapping and concepts havebeen proven by Proof of Concept method.

63

4.2 Learning ProcessLearning is an integral part of the project. There were various possibilities of approach in the beginningand code generators and Rational Rose Real Time improvement suggestions on known problems andsuggestions of employees were aggregated and presented. This learning bar shows the amount of time ittook for reaching various levels of knowledge.

Category Days Ability

Basic Rose RT tool & UML RT standard 14 Understood the working of UML RT standardin a basic level

Intermediate UML RT and Rose RT 25 Able to work and execute Rose RT models ofmy own

Basic code generation knowledge 14 Principles of code generation and Working ofcode generators

Basics about other code generation tools,their working

14 Analyzed code generators and theirperformance

Basics in the code generator CodeGenie 3 Basic constructs to access different elementsin the model

Basic in Rose RT script API 1 Able to locate items and understand themeaning of them

Intermediate Rose RT script API 7 Can experiment based on different elements inthe API

Advanced Rose RT script API 18 Able to access all elements and work based onunderstanding examples

Basic EBS 7 Able to write code to perform basic functionsand access some elements in Rose RT

Intermediate EBS 12 Able to perform change in functioning andreorganize the working

Advanced knowledge EBS 20 Able to understand and write code based onefficient algorithms

Basic knowledge XMI 14 Able to understand few basic constructs of allclassifiers

Intermediate knowledge XMI 21 Understood the meaning of many of theconstructs in XMI 1.0

Advanced knowledge XMI 30 Analyzed different versions of XMI andunderstood differences and gained knowledgein XMI 1.0 syntax and semantics

The number of days for basic knowledge to intermediate knowledge and then to advanced knowledge underthe same category is always cumulative.

Example:

The number of days taken for Basic Rose RT and UML RT knowledge is 14 days. The number of daystaken for an Intermediate knowledge in the same UML RT and Rose RT is 25 days in which the 14 days areincluded. In other words the number of days taken for an intermediate knowledge from basic knowledge inthis case is 11 days.

64

5 Options Available and FutureWork

5.1 Evaluation of OptionsOption 1:

Continue the development of the XMI script with the XMI 1.0 standard and use the findings in thereport to implement the items left to be implemented. In Parallel, make changes to the Meta Model tosupport the new concepts. Once all the new concepts have been supported according to Rose RTstandard, change the metamodel to support UML 2.0 as much as possible.

Option 2:

Change the standard of XMI to 2.0 in the development of the XMI script. Use a tool like Ecore forEclipse Modeling Framework (recommended) or Altova UModel which supports XMI 2.0 and 2.1respectively along with UML 2.0 for exporting XMI: The XMI while being exported is concurrentlychanged into a UML 2.0 Profile XMI version. This when loaded back into the XMI 2.0 reader need notundergo any mapping as the UML 2.0 profile is already being exported. This will also enable fullsupport in other tools during import because there is not need to change the metamodel in that tool tomake it understand the XMI. The XMI Diagram Interchange (XMI-DI) should be used to exportdiagrams as discussed under Section 3.9: What about Diagram Information of the models?

Option 3:

Continue development with XMI 1.0. Export the models in current RTP UML 1.4 profile. Whileimporting it back into the code generator, make changes so that it can understand the Real TimeConcepts and build the metamodel according to it. No further change is done and the UML 2.0 standardis ignored.

Option Advantages Disadvantages

1 No time lost in transition. Export of themodels could be comparatively quick.

Mapping concepts to the Real Time profile ofUML 2.0 may take a very long time.

2 Probably the best way to proceed. Neednot worry if the tool will understandwhat is exported as XMI. Since theXMI standard is already changed tosupport UML 2.0 i.e., XMI 2.0 is chosenduring export, importing the XMI intoany tool which understands XMI 2.0will work. This process can regeneratethe metadata information without anyloss of information since only thoseitems specified in XMI 2.0 specificationswill be exported as tags.

Initially might take some time to map theconcepts in XMI 2.0 syntax. Nonetheless, therules suggested in the thesis could be used toimplement the conversion process swiftly.However, the dividend is more since there is afree interoperability through other tools.

3 Possibly the quickest procedure. The worst interoperability. The XMI is more orless locked with the tool where the metamodel ismodified. When XMI is imported to any othertool, significant vital information will be lostsince most of the items will be exported as tags.

Table 34: Options available from the current point

65

5.2 Checklist and Future Work

SNo GOAL REACHED(YES/NO) IN TERMS OFINVENTION ORFINDING

REACHED INTERMS OFSCRIPTWRITTEN

FUTURE WORK

1 Export of Nonreal timeelements in XMI

Yes Yes State machines inside classes tobe done.

2 Export ofCapsules

Yes Yes State Machines still to beimplemented and transitions to becompleted according to findings.

3 Export of Ports Yes Yes Relay and End ports to beimplemented according tofindings

4 Export ofProtocols &signals

Yes Yes Relationships to be implementedaccording to procedure describedin report.

5 State machinesand state machineelements

Yes Yes Testing of mapping to the owningcomponents to be done.

6 Relationships Yes No The results found to beimplemented inside the script

7 Research of allthe Rose RealTime Elementsand their exportinto XMI

Yes Yes All Elements except thosementioned under future workcolumn are implemented

8 Research on howRose RT codegenerator worksand how the newcode generator isexpected to work

Yes Yes

Possibly not required. If an in-depth detail is required researchof Rose RT generated code wouldbe useful.

7 Initial goal ofevaluating codegenerators

Yes NA Room for more investigation.

Table 35 : Checklist of Goals and Future Work

66

References

OMG Documents:

UML SPECIFICATIONS

Ref. No Document Name & Reference Accessed

[1] UML 1.3 Formal Specification

http://www.omg.org/cgi-bin/apps/doc?formal/00-03-01.pdf

11 Jan 2006

[2] XML for UML 1.3

http://www.omg.org/docs/ad/01-12-02.xml

14 Jan 2006


http://www.omg.org/docs/formal/01-09-67.pdf

13 March 2006

[4] UML 1.4 Interchange Metamodel in XML

http://www.omg.org/cgi-bin/apps/doc?ad/01-02-15.xml

14 March 2006



11 Jan 2006

XMI SPECIFICATIONS


[6] XMI 1.0 Formal Specification


13 March 2006

[7] XMI Document Type Definition 1.0 for UML 1.3

http://www.omg.org/cgi-bin/apps/doc?formal/02-07-01.txt

14 March 2006



14 March 2006

[9] XMI Document Type Definition 1.1 for UML 1.4

http://www.omg.org/cgi-bin/apps/doc?ad/01-02-16.dtd

11 Jan 2006



15 May 2006



15 May 2006



15 May 2006



http://www.omg.org/cgi-bin/apps/doc?ad/01-02-15.xml



http://www.omg.org/cgi-bin/apps/doc?formal/02-07-01.txt


http://www.omg.org/cgi-bin/apps/doc?ad/01-02-16.dtd

67

MOF SPECIFICATION


[13] Meta Object Facility (MOF) Specifications


19 May 2006

RT PROFILE OF UML


[14] RT Profile of UML (UML Profile for Schedulability, Performance andtime)


19 May 2006

COMMON WAREHOUSE METAMODEL (CWM)


[15] Common Warehouse Metamodel specification


19 May 2006

XMI Handlers:

Ref.No

Document Name & Reference Accessed

[16] Novosoft UML XMI 1.0 Reader

http://NSUML.sourceforge.net/

19 May 2006

[17] MDR Reader

http://mdr.netbeans.org/MDR-whitepaper.pdf

26 May 2006

[18] Eclipse Modeling Framework

http://www.eclipse.org/emf/

13 June 2006

[19] Ecore EMF APIhttp://download.eclipse.org/tools/emf/javadoc/?org/eclipse/emf/ecore/package-summary.html 13 June 2006



http://nsuml.sourceforge.net/

http://download.eclipse.org/tools/emf/javadoc/?org/eclipse/emf/ecore/package-summary.html

http://download.eclipse.org/tools/emf/javadoc/?org/eclipse/emf/ecore/package-summary.html

68

General Research Publications

Ref.No

Document Name & Reference

[20] Wolfgang Emmerich, Extension Mechanisms for UML, University College London

[21] Luigi Lavazza, Checking UML Specifications of Real Time Software, CEFRIEL, Milan

[22] Andy Evans, Robert France, Kevin Lano, and Bernhard Rumpe The UML as a FormalModeling Notation, The University of York

http://www.cs.york.ac.uk/puml/papers/evaNSUML.pdf, Accessed 10 May 2006

[23] John Hogg, An Overview of UML 2.0 and MDA

http://www.omg.org/news/meetings/workshops/UML%202003%20Manual/Tutorial7-Hogg.pdf , Accessed 4 May 2006

[24] XMI-based Code Generation for Real-Time Systems – Christofer Janstål

[25] Andrew Lyons, UML for Real Time Overview, Technical University of Berlin, April 1998The UML as a For mal Modeling N otation

IEEE Research Publications

Ref.No

Document Name & Reference

[26] Mohammad Ullah Khan, Kurt Geihs, et al. Model-Based Development of Computer-BasedSystems and Model-Based Methodologies for Pervasive and Embedded Software, 2006

[27] Bran Selic, Model Driven Development of Real- Time Software using OMG standards,2003

[28] Cristian Secchi and Cesare Fantuzzi, On the Use of UML for Modeling Systems, 2005

[29] Using XMI and MOF for Representation and Interchange of Software Processes,2003

[30] Marcus Alanen and Ivan Porres, Model Interchange Using OMG Standards,2005

http://www.cs.york.ac.uk/puml/papers/evansuml.pdf

http://www.omg.org/news/meetings/workshops/UML 2003 Manual/Tutorial7-Hogg.pdf

http://www.omg.org/news/meetings/workshops/UML 2003 Manual/Tutorial7-Hogg.pdf

69

Teaching and Projects

Ref.No


[31] Modeling SW-Architectures using UML-RT/UML 2.0, Ingolf H.Krueger, California Institute for Telecommunication and InformationTechnology

http://www-cse.ucsd.edu/~ikrueger/Teaching_Documents/Winter_2005/UML2_2005_printable.pdf

20 May 2006

[32] Andreas Roth and Peter H. Schmitt , Chalmers Institute ofTechnology

http://www.cs.chalmers.se/Cs/Grundutb/Kurser/form/Papers/keybook-5.pdf

20 May 2006

[33] Charles André, Julien Boucaron et al., High Level Modeling

http://www.inria.fr/rapportsactivite/RA2004/aoste2004/uid6.html

11 May 2006

[34] Krzysztof Czarnecki , Model Driven Architecture ---

[33] Z. Guanad, K. G. Shin, Synthesis of Real-Time Implementation fromUML-RT Models , University of Michigan

---

[34] Real Time Object Oriented Design, Nam Hee, Korea AdvancedInstitute of Science and Technology

---

[35] Rational Rose Real Time Help Manual ---

Literature

[36] Real Time UML Third Edition

Bruce Powell Douglass, Addison Wesley; ISBN 0-321-16076-2

[37] Code Generation in Action

Jack Herrington, Manning Publications; ISBN: 1-930110-97-9

[38] UML Components

Chessman, John, and Daniels, John: Addison-Wesley, 2001, 0-201-70851-5






http://www.inria.fr/rapportsactivite/RA2004/aoste2004/uid6.html

70

Miscellaneous

Ref.No


[39] OMG News on UML versions

http://www.omg.org/news/meetings/tc/Tech_Adoption/index.htm

1 June 2006

[40] IBM Rational

http://www-306.ibm.com/software/rational/

1 June 2006

[41] Introduction to diagrams of UML 2.0

http://www.agilemodeling.com/essays/umlDiagrams.htm

4 June 2006

[42] Practical UML : Hands on Introduction to UML

http://bdn.borland.com/article/0,1410,31863,00.html

4 June 2006

[43] Robert S. Seiner , Data Administration Newsletter 11 June 2006

[44] MDA Journal, David S. Frankel, Eclipse and MDA 12 June 2006

[45] An MDA Domain Specific Architecture to Provide InteroperabilityAmong Collaborative Environments

13 June 2006

[46] EMF FAQ

http://dev.eclipse.org/viewcvs/indextools.cgi/emf-home/Attic/faq.html?rev=1.3

20 June 2006

[47] SysML : Open Source Specification Project

http://www.sysml.org/

20 June 2006

http://bdn.borland.com/article/0,1410,31863,00.html



http://www.sysml.org/

71

Appendix

A: How the code generator should work with Real-Time elements?The mapping of the elements during the export into XMI should be followed by the generation of codethrough a Rose RT methodology since the code generation process would use the Real Time Library ofRose RT: The actions that would thus be required is researched along with how Rose Real Time codegenerator works [35].The behavior of the code generator will differ with the languages used as theoutput of code generation such as C ,C++, Java etc .The major Real Time elements and theirtransformation into code is discussed for C++ generation as follows:

Concept Actions Required in code generator to foster full scale

End to end conversion

Capsule

Figure 39: Generation of Capsule in C++

Capsule, its elements and state machine :

The RTActor class contains state machine processing and messaging behavior that is used by allcapsules. State machines of the capsules along with their operations and attributes are elementsin the generated RTActor class. As there can possibly be many instances of the same capsule inan application, capsule class information is dealt separately from the objects of RTActor and ishandles in a special class named RTActorClass as in Figure 40: Mapping Capsules to RT Librarybelow.

Figure 40: Mapping Capsules to RT Library

When the Capsule is generated in C++, it wouldbe generated under two different files : One theheader file and another the “.cpp” file if theimplementation language is Java. There is also a“thisPointer” which is used for referencing theCapsule roles in operation. When the CodeGenerator reads in the MOF generated backfrom the XMI, it should detect the classes withstereotype “capsule” and all these capsules mustbe generated as subclasses of RTActor as shownin Figure 40: Mapping Capsules to RT Library.

72

Capsule Roles:

Capsule roles will become attributes of type RTActorRef in the containing capsule. Theattribute name is the same as the role name and this enables referencing capsule role by name inthe C++ code of the capsule which contains it. Capsule roles, or RTActorRef class, shown asthe return type for a Capsule role named “CapsuleRole” in Figure 41: Capsule Role Generationare basically place holders for capsule instances as shown in Figure 40: Mapping Capsules to RTLibrary.

Figure 41: Capsule Role Generation

An RTActor class will have access to the current message, RTMessage that it receives throughthe port. This is shown in Figure 40: Mapping Capsules to RT Library.

Additionally each capsule instance has access to the RTController class for the thread on whichit is running. This provides options used in Capsule’s implementation.

Ports When the code generator reads the port as the nested class (owned element) of the capsule, itshould generate it as an attribute in the already generated RTActor subclass. The port attributeshould have the same name as the port in the model. The port attribute will have a return type ofRTProtocol or in other words a subclass of it. Thus Ports are generated as Protocol typeattributes.

Figure 42: Port generation in C++ Code

Protocols

Figure 43: Generation of Protocols

Figure 43: Generation of Protocols shows how the protocols are generated with respect to the Real-Time Library. The Protocols are generated as two separate classes for representing the “BaseProtocol”role and the “ConjugateProtocol” role. They are owned by the protocol which is a sub class ofRTProtocol when generated in C++. Further, the signals become Operations with the corresponding RealTime Classes as return types namely “RTInSignal” and “RTOutSignal”.

Table 36: Actions required by the code generator to work with RT Library

When a capsule role is replicated, there areplaces for holding multiple instances(objects)of compatible RTActor subclasses.

The Port is directly referenced with its namein the C++ code. Port though generated as anattribute will in effect, will behave as itsrelationship is depicted in Figure 24:Relationship between ports, Protocols,Protocol roles

73

B: Pilot Study and Empirical FindingsThe aim of the pilot study was to evaluate some tools of interest which generate code and study theirperformance.

Study on code generators and their Evaluation

The Pilot study was conducted on various code generating tools and an evaluation was made.

General Scenario of MDA based UML Code generators

There are two categories of modeling tools available for code generation.

(a) One is the called “full-boat” environment since it includes UML modeler, transformationengine and code generation [39].

Only a few tools are in this space, among them are ArcStyler from Interactive Objects SoftwareGmbH, XDE from IBM Rational and OptimalJ from Compuware Corp.

(b) The second category is those comprising the majority of the tools on the market today which donot have any UML modeler.

These are code generators that take input from existing UML modeling tools -- Rational Rose orNo Magic Inc.’s Magic Draw UML, for example -- and then generates code from those models. Toolshere include Codagen Technology Corp.’s Architect and Telelogic’s Tau.

CodeGenie; the tool that is of interest falls into the second category.

Case Study 1 : Bo UML

Key Features:

Open-source, UML 2.0, Java, C++, IDL, HTML documentation generation imports Rational Rose andhas high performance. It is fast and simple yet very effective.

Main Advantages: Does not require huge memory. BOUML is composed of the modeler itself, and a list of external programs (called plug-out)

being able to be written in C++ or Java (not in Visual Basic). Any user can write a plug-out carrying out for example its favorite design pattern; the API

provided carrying out the needed exchanges with the modeler. A plug-out is made using BOUML like any other program. The API could be changed at any

time with the parameters added to them.

Installation and usage:

The first usage of BoUML prompted to set a BoUML environment variable. This identifier is establishduring the object creation and will not change later, and it allows several users to work simultaneouslyon the same project, this object identifier contains the identifier of the user creating the object.

Since it is open source all the modifications of the API specifications and the run time configurationswas possible. The Code generation was facilitated by plug outs. The plug-outs are the externalprograms written in C++ or Java interacting with BOUML.

74

Figure 44: A relation Dialog in BoUML

Figure 45: A header file and its definition templates generated by the Generator

The code generator for C++ in UML can be initiated and run with changes to the API and thetemplates in it. Here in Fig 26, a header file and its generation with substitution is shown.Disadvantage:

State machines are handled by the Plug outs (not even a plug-in) which are developed outside BoUML.Though this might not be a direct disadvantage, integration into the tool could be a problem.

Performance:

C++ Source code can be generated by specifying parameters in the relation dialog of the objects. codegeneration in BoUML is done by changing configurations with the plug out. The run time of BoUMLcompared to other tools is good.

BoUML is under development.The Final version of BoUML is2.0 which introduce the conceptsand artifacts of UML 2.0. Theseartifacts support the use of codegeneration instead of componentbased development.

75

050

100150200250300350400450500550600650

Time inseconds

BOUML Rose AndroMDA

Tool of interest

Observed BoUML Benchmark

Reverse 39 605 112

Save 4 10 9

Load 2 17 6

BOUML Rose AndroMDA

Figure 46: Observed Benchmark of BoUML

Glossary:Java package size used 20 MB. System Specification : Intel 3.2 MHz , 1.04 GB Memory, 32 bitprocessor, 50 GB hard disk.

Reverse: To reverse the java package and sub packages with the same load

Save : To save the project

Load : Exit and to restart the tool

Case Study 2: Andro MDA

Key Features:Fully MDA Compatible code generator. Open source community with large number of users. Anymodel generates XMI conforming to a MOF 1 metamodel could be used with Andro MDA. UML 1.4support (could be seen as a disadvantage).

Main Advantages:

Modular design: all major building blocks of AndroMDA are pluggable like with BoUML. Validates the input models using OCL constraints which are related to the meta-model classes.

Can generate any kind of text output using templates (source code, database scripts, webpages, O/R mapping configuration files, etc.) - AndroMDA does it is taught which issimilar to CodeGenie tool that we are using (In fact many tools are taught through themapping of meta models from the MOF produced.)

76

Since the MoTMoT (Model driven, Template based, and Model Transformer) runs onMDR, the generated UML 2.0 XMI will conform to MOF and then it is straight forwardto generate code through building metamodels as in CodeGenie.

Installation and Usage:

1 The Java platform has to be deployed in the system and subsequently Ant (a Java based buildtool which is written in XML and portable across platforms) or Maven (a Java based high levelproject management tool which does everything Ant can do and also encapsulate the projectinformation and build process knowledge) is to be used as a Plug in.

2 Maven is a software project management and comprehension tool. Based on the concept of aproject object model (POM), Maven can manage a project's build, reporting and documentationfrom a central piece of information. Maven is considered as the right hand of AndroMDA.

3 The application thus generated could be immediately deployed using Jboss or Tomcat on theWeb if required.

Some other code generating tools in the market:

Umbrello A GPL modeling tool that looks interesting, Runs under (requires) KDEand Linux. Also supports code generation as well as reverse engineering(code to UML) for C++ and Java.

Fujaba Forward Unto Java And Back Again (FUJABA) supports both reverseengineering of and code generation for Java systems. It is a researchsystem (released under the LGPL), that supports UML class andbehavioral diagrams.

CodeGenie MDA Based code generator, flexible metamodeling and generation ofcode.

ArgoUML There is support for Java class generation, C++ and C# generation fromthe models in the form of support from separate open source ArgoUMLprojects. Produces XMI of version 1.0 and 1.1. Received the runner upaward under “Design and Analysis tools” in 2003.

Table 37: Other code generators in Market

Of the tools analyzed, AndroMDA was found to be well featured flexible MDA based codegenerator with a lively community using it and ArgoUML was found to be a powerful when usedwith the C++ project that is a separate Open source project in the ArgoUML community. None ofthe code generators were found to be developed for Real-Time Systems environment.

77

Brief improvement suggestions for Rational Rose Real Time

Initially, a very brief evaluation of Rational Rose Real Time was done and a few improvementsuggestions were made from the employees at the telecom company when a short interview wasconducted with them. A suggestion was made to 1 issue.

Requests and Suggestions for improvement made by the employees at the telecom company:

SNo Request or Suggestion

1 It would be easier for design to have a Dynamic Behavior of Rose Rt as in Rhapsody by makingthe changes in design to be immediately visible before compilation of the model.

2 Could it be made possible to view all the attributes of an entity together at the same time(example may be in an emacs editor?)

3 Is it possible to give Benchmarked examples in lieu of existing ones?

4 Could it be made possible to include breakpoints during compilation for error finding anddebugging?

5 Could Code editors be enhanced? - Intelligent code editors which give separate colors to syntaxand keywords were launched 4 years ago. It would be very useful to have them implemented inRose RT.

6 Could it be made possible to create local classes in a Capsule without Dependencies in Rose RT?

7 Could it be made possible to turn off warnings in Compiler? (Example : Broken transitions inbase classes)

Table 38: Suggestions and Requests on Rose Real Time

Suggestion to an issue in Rose Real Time

SNo

Issue Already(Known/Unknown)

IBMrecommendation

New Suggestion

1 Currently a switch statement inthe rtsBehaviour method isiterating from the currentcontaining state to the statewhere the transition is foundoutwards in the code generatorin execution of the statemachine.

KnownIssue

“Placefrequentlyexecutedtransitions onleaf states.¨

Would it be possible toimplement an Indexingmethod which will index alltransitions and which has theexact location of the trigger,so that the control candirectly go there withoutexecuting any superfluoustransition?

Table 39 : Suggestion to an issue in Rose RT

78

C: XMI Representation of Model Traffic System

Figure 47 : Traffic System Model with additional class

THE REPRESENTATION OF THE MODEL AND PACKAGE IN XMI:

The whole model under Figure 31 is not represented below since the output is huge. Only selectedelements of the model which are of prime importance are represented here.

MODEL:

<Model_Management.Model xmi.id = 'G.0' xmi.uuid = "3AC63FAA03C4" >

<Foundation.Core.ModelElement.name>TrafficSystem</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/><Foundation.Core.Namespace.ownedElement>

79

PACKAGE:

<Model_Management.Package xmi.id = 'p1' xmi.uuid = '37F129B10358' >

<Foundation.Core.ModelElement.name>RTClasses</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value = "false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value = "false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value = "false" /><Foundation.Core.ModelElement.namespace><Foundation.Core.Namespace xmi.idref = 'G.0'/><Foundation.Core.Namespace.ownedElement>

----- Elements inside the Package-----</Foundation.Core.Namespace.ownedElement></Model_Management.Package>

</Model_Management.Model>

THE REPRESENTATION OF A CLASS WITH ALL ITS ELEMENTS IN XMI:

<Foundation.Core.Class xmi.id = 'c17' xmi.uuid = '43F3639F01CA' >

<Foundation.Core.ModelElement.name>Hejsan</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value = "true" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value = "true" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value = "false" /><Foundation.Core.Class.isActive xmi.value = "false" />

<Foundation.Core.ModelElement.namespace><Foundation.Core.namespace xmi.idref='p2'/></Foundation.Core.ModelElement.namespace><Foundation.Core.Classifier.feature>

<!-The attribute appears here as a Classifier feature inside the class-!>

<Foundation.Core.Attribute xmi.id = 'atcl0' xmi.uuid = 'atcl443115320011' >

<Foundation.Core.ModelElement.name>myAttribute</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "private" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.Feature.ownerScope xmi.value= "instance"/><Foundation.Core.StructuralFeature.multiplicity><Foundation.Data_Types.Multiplicity><Foundation.Data_Types.Multiplicity.range><Foundation.Data_Types.MultiplicityRange xmi.id='mulatclid0'>

<Foundation.Data_Types.MultiplicityRange.lower>1</Foundation.Data_Types.MultiplicityRange.lower>

<Foundation.Data_Types.MultiplicityRange.upper>1</Foundation.Data_Types.MultiplicityRange.upper>

</Foundation.Data_Types.MultiplicityRange></Foundation.Data_Types.Multiplicity.range>

80

</Foundation.Data_Types.Multiplicity></Foundation.Core.StructuralFeature.multiplicity><Foundation.Core.StructuralFeature.changeability xmi.value ="1"/><Foundation.Core.StructuralFeature.targetscope xmi.value =""/><Foundation.Core.Attribute.initialValue><Foundation.Data_Types.Expression></Foundation.Data_Types.Expression></Foundation.Core.Attribute.initialValue><Foundation.Core.StructuralFeature.type><Foundation.Core.Classifier xmi.idref='dt1'/>

</Foundation.Core.StructuralFeature.type></Foundation.Core.Attribute>

</Foundation.Core.Attribute>

<!-OPERATION HERE ->

<Foundation.Core.Operation xmi.id = 'op1' xmi.uuid = '43F363CA0312' >

<Foundation.Core.ModelElement.name>main</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false"/><Foundation.Core.Feature.ownerScope xmi.value = "instance" /><Foundation.Core.BehavioralFeature.isQuery xmi.value = "false"/><Foundation.Core.Operation.concurrency xmi.value = "sequential" /><Foundation.Core.Operation.isRoot xmi.value = "false"/><Foundation.Core.Operation.isLeaf xmi.value = "false"/><Foundation.Core.Operation.isAbstract xmi.value = "false"/><Foundation.Core.Operation.specification></Foundation.Core.Operation.specification><Foundation.Core.BehavioralFeature.parameter><Foundation.Core.Parameter xmi.id = 'oppar1' xmi.uuid = '4441694D029F' >

<Foundation.Core.ModelElement.name>argc</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false"/><Foundation.Core.Parameter.defaultValue>

<Foundation.Data_Types.Expression >

<Foundation.Data_Types.Expression.language></Foundation.Data_Types.Expression.language><Foundation.Data_Types.Expression.body></Foundation.Data_Types.Expression.body>

</Foundation.Data_Types.Expression></Foundation.Core.Parameter.defaultValue><Foundation.Core.Parameter.kind xmi.value = "inout" /><Foundation.Core.Parameter.type>

<Foundation.Core.Classifier xmi.idref = 'G.2'/> </Foundation.Core.Parameter.type>

</Foundation.Core.Parameter><Foundation.Core.Parameter xmi.id = 'oppar2' xmi.uuid = '4441694D02A0' >

<Foundation.Core.ModelElement.name>argv[]</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false"/><Foundation.Core.Parameter.defaultValue>

<Foundation.Data_Types.Expression >

<Foundation.Data_Types.Expression.language></Foundation.Data_Types.Expression.language>

81

<Foundation.Data_Types.Expression.body></Foundation.Data_Types.Expression.body></Foundation.Data_Types.Expression>

</Foundation.Core.Parameter.defaultValue><Foundation.Core.Parameter.kind xmi.value = "inout" /><Foundation.Core.Parameter.type>

<Foundation.Core.Classifier xmi.idref = 'G.4'/> </Foundation.Core.Parameter.type>

</Foundation.Core.Parameter><Foundation.Core.Parameter xmi.id = 'oppar3' >

<Foundation.Core.ModelElement.name>main.Return</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false"/><Foundation.Core.Parameter.kind xmi.value = "return" /><Foundation.Core.Parameter.type>

<Foundation.Core.Classifier xmi.idref = 'G.2'/> </Foundation.Core.Parameter.type>

</Foundation.Core.Parameter></Foundation.Core.BehavioralFeature.parameter>

</Foundation.Core.Operation></Foundation.Core.Classifier.feature>

</Foundation.Core.Classifier.feature></Foundation.Core.Class>

REPRESENTATION OF A CAPSULE :

<Foundation.Core.Class xmi.id = 'ca0' xmi.uuid = '3ACFAD0703C4' >

<Foundation.Core.ModelElement.name>Controller</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value = "true" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value = "true" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value = "false" /><Foundation.Core.Class.isActive xmi.value = "false" />

<Foundation.Core.ModelElement.namespace><Foundation.Core.Namespace xmi.idref='p2'/></Foundation.Core.ModelElement.namespace>

<Foundation.Core.Namespace.ownedElement><Foundation.Core.Class xmi.id = 'pocap0' xmi.uuid = 'por0'>

<Foundation.Core.ModelElement.name>west</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/>

<Foundation.Core.ModelElement.namespace><Foundation.Core.Namespace xmi.idref='ca0'/></Foundation.Core.ModelElement.namespace>

<Foundation.Core.StructuralFeature.type><Foundation.Core.Classifier xmi.idref='pr5'/>

</Foundation.Core.StructuralFeature.type>

82

</Foundation.Core.Class>

<Foundation.Extension_Mechanisms.Stereotype xmi.id = 'empocap0'><Foundation.Core.ModelElement.name>Port</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/><Foundation.Extension_Mechanisms.Stereotype.icon />

<Foundation.Extension_Mechanisms.Stereotype.baseClass>Class</Foundation.Extension_Mechanisms.Stereotype.baseClass>

<Foundation.Extension_Mechanisms.Stereotype.extendedElement><Foundation.Core.ModelElement xmi.idref = 'pocap0'/>

</Foundation.Extension_Mechanisms.Stereotype.extendedElement></Foundation.Extension_Mechanisms.Stereotype>

‘// This is for the definition of Classifiers: i.e. Attributes and Operations

<Foundation.Core.Classifier.feature><Foundation.Core.Attribute xmi.id = 'atcap0' xmi.uuid = '3ACFB4130151' >

<Foundation.Core.ModelElement.name>greenTime</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "private" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.Feature.ownerScope xmi.value= "instance"/><Foundation.Core.StructuralFeature.multiplicity><Foundation.Data_Types.Multiplicity><Foundation.Data_Types.Multiplicity.range><Foundation.Data_Types.MultiplicityRange xmi.id='mulatcapid0'>



</Foundation.Data_Types.MultiplicityRange></Foundation.Data_Types.Multiplicity.range></Foundation.Data_Types.Multiplicity>

</Foundation.Core.StructuralFeature.multiplicity><Foundation.Core.StructuralFeature.changeability xmi.value ="1"/><Foundation.Core.StructuralFeature.targetscope xmi.value =""/><Foundation.Core.Attribute.initialValue><Foundation.Data_Types.Expression><Foundation.Data_Types.Expression.language>

</Foundation.Data_Types.Expression.language><Foundation.Data_Types.Expression.body>4, 0</Foundation.Data_Types.Expression.body>

</Foundation.Data_Types.Expression></Foundation.Core.Attribute.initialValue><Foundation.Core.StructuralFeature.type><Foundation.Core.Classifier xmi.idref='c16'/>

83


THE REPRESENTATION OF A PROTOCOL:- 

- <Foundation.Core.Class xmi.id="pr5" xmi.uuid="37E9292C018C"><Foundation.Core.ModelElement.name>Timing</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="true" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" /><Foundation.Core.Class.isActive xmi.value="false" />

- <Foundation.Core.ModelElement.namespace><Foundation.Core.namespace xmi.idref="p1" />

</Foundation.Core.ModelElement.namespace>- <Foundation.Core.Classifier.feature>

- - <Foundation.Core.Attribute xmi.id="insig10" xmi.uuid="inuuid10">

<Foundation.Core.ModelElement.name>timeout</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.Feature.ownerScope xmi.value="instance" />

- <Foundation.Core.StructuralFeature.multiplicity>- <Foundation.Data_Types.Multiplicity>- <Foundation.Data_Types.Multiplicity.range>- <Foundation.Data_Types.MultiplicityRange xmi.id="mulinsig10">

<Foundation.Data_Types.MultiplicityRange.lower>1</Foundation.Data_Types.MultiplicityRange.lower><Foundation.Data_Types.MultiplicityRange.upper>1</Foundation.Data_Types.MultiplicityRange.upper>

</Foundation.Data_Types.MultiplicityRange></Foundation.Data_Types.Multiplicity.range></Foundation.Data_Types.Multiplicity></Foundation.Core.StructuralFeature.multiplicity>

<Foundation.Core.StructuralFeature.changeability xmi.value="changeable" /><Foundation.Core.StructuralFeature.targetscope xmi.value="instance" />

- <Foundation.Core.Attribute.initialValue>- <Foundation.Data_Types.Expression>

<Foundation.Data_Types.Expression.language /><Foundation.Data_Types.Expression.body />

</Foundation.Data_Types.Expression></Foundation.Core.Attribute.initialValue>

- <Foundation.Core.StructuralFeature.type><Foundation.Core.Classifier xmi.idref="dt0" />

</Foundation.Core.StructuralFeature.type></Foundation.Core.Attribute></Foundation.Core.Classifier.feature></Foundation.Core.Class>

- <Foundation.Extension_Mechanisms.Stereotype xmi.id="empr5"><Foundation.Core.ModelElement.name>Protocol</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" />

84

<Foundation.Extension_Mechanisms.Stereotype.icon />


- <Foundation.Extension_Mechanisms.Stereotype.extendedElement><Foundation.Core.ModelElement xmi.idref="pr5" />


- <Foundation.Extension_Mechanisms.Stereotype xmi.id="eminsig10"><Foundation.Core.ModelElement.name>InSignal</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" /><Foundation.Extension_Mechanisms.Stereotype.icon />

<Foundation.Extension_Mechanisms.Stereotype.baseClass>Attribute</Foundation.Extension_Mechanisms.Stereotype.baseClass>

- <Foundation.Extension_Mechanisms.Stereotype.extendedElement><Foundation.Core.ModelElement xmi.idref="insig10" />

<Foundation.Core.Attribute xmi.id = 'outsig1' xmi.uuid = 'outuuid1' >

<Foundation.Core.ModelElement.name>yellow</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.Feature.ownerScope xmi.value= "instance"/><Foundation.Core.StructuralFeature.multiplicity><Foundation.Data_Types.Multiplicity><Foundation.Data_Types.Multiplicity.range><Foundation.Data_Types.MultiplicityRange xmi.id='muloutsig1'>




</Foundation.Core.StructuralFeature.multiplicity><Foundation.Core.StructuralFeature.targetscope xmi.value =""/><Foundation.Core.Attribute.initialValue><Foundation.Data_Types.Expression><Foundation.Data_Types.Expression.body></Foundation.Data_Types.Expression.body>

</Foundation.Data_Types.Expression></Foundation.Core.Attribute.initialValue><Foundation.Core.StructuralFeature.type><Foundation.Core.Classifier xmi.idref='dt0'/>


<Foundation.Core.Attribute xmi.id = 'outsig2' xmi.uuid = 'outuuid2' >

85

<Foundation.Core.ModelElement.name>green</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value = "public" /><Foundation.Core.ModelElement.isSpecification xmi.value = "false" /><Foundation.Core.Feature.ownerScope xmi.value= "instance"/><Foundation.Core.StructuralFeature.multiplicity><Foundation.Data_Types.Multiplicity><Foundation.Data_Types.Multiplicity.range><Foundation.Data_Types.MultiplicityRange xmi.id='muloutsig2'>




</Foundation.Core.StructuralFeature.multiplicity><Foundation.Core.StructuralFeature.targetscope xmi.value =""/><Foundation.Core.Attribute.initialValue><Foundation.Data_Types.Expression><Foundation.Data_Types.Expression.body></Foundation.Data_Types.Expression.body>

</Foundation.Data_Types.Expression></Foundation.Core.Attribute.initialValue><Foundation.Core.StructuralFeature.type><Foundation.Core.Classifier xmi.idref='dt0'/>



<Foundation.Extension_Mechanisms.Stereotype xmi.id = 'empr5'><Foundation.Core.ModelElement.name>Protocol</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/><Foundation.Extension_Mechanisms.Stereotype.icon />


<Foundation.Extension_Mechanisms.Stereotype.extendedElement><Foundation.Core.ModelElement xmi.idref = 'pr5'/>


<Foundation.Extension_Mechanisms.Stereotype xmi.id = 'emoutsig0'><Foundation.Core.ModelElement.name>Out Signal</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/><Foundation.Extension_Mechanisms.Stereotype.icon />

86


<Foundation.Extension_Mechanisms.Stereotype.extendedElement><Foundation.Core.ModelElement xmi.idref = 'outsig0'/>

</Foundation.Extension_Mechanisms.Stereotype.extendedElement></Foundation.Extension_Mechanisms.Stereotype><Foundation.Extension_Mechanisms.Stereotype xmi.id = 'emoutsig1'><Foundation.Core.ModelElement.name>Out Signal</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/><Foundation.Extension_Mechanisms.Stereotype.icon />



</Foundation.Extension_Mechanisms.Stereotype.extendedElement></Foundation.Extension_Mechanisms.Stereotype><Foundation.Extension_Mechanisms.Stereotype xmi.id = 'emoutsig2'><Foundation.Core.ModelElement.name>Out Signal</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public"/><Foundation.Core.ModelElement.isSpecification xmi.value="false"/><Foundation.Core.GeneralizableElement.isRoot xmi.value="false"/><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false"/><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false"/><Foundation.Extension_Mechanisms.Stereotype.icon />




87

REPRESENTATION OF A SAMPLE STATE MACHINE :

nsGreen

nsYellow

ewGreen

status = 1

Figure 48: Sample State Machine for the Capsule TrafficSystem

- 

- <Behavioral_Elements.State_Machines.StateMachine xmi.id="S.164.1609.21.2"xmi.uuid="4476DA4F000A">

<Foundation.Core.ModelElement.name>State/ActivityModel</Foundation.Core.ModelElement.name>

<Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />

- <Behavioral_Elements.State_Machines.StateMachine.context><Foundation.Core.ModelElement xmi.idref="cap0" /></Behavioral_Elements.State_Machines.StateMachine.context>

- <Behavioral_Elements.State_Machines.StateMachine.top>- - <Behavioral_Elements.State_Machines.CompositeState xmi.id="XX.14.169.22.3">

<Foundation.Core.ModelElement.name>{top}</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Behavioral_Elements.State_Machines.CompositeState.isConcurrent xmi.value="false" />

- <Behavioral_Elements.State_Machines.CompositeState.subvertex>- - <Behavioral_Elements.State_Machines.SimpleState xmi.id="G.1">

<Foundation.Core.ModelElement.name>nsGreen</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />

- <Behavioral_Elements.State_Machines.StateVertex.outgoing><Behavioral_Elements.State_Machines.Transition xmi.idref="G.2" /></Behavioral_Elements.State_Machines.StateVertex.outgoing>

- <Behavioral_Elements.State_Machines.StateVertex.incoming><Behavioral_Elements.State_Machines.Transition xmi.idref="G.8" />

Figure 48: Sample State Machine for the CapsuleTrafficSystem shows a state machine representation. Thisstate machine is included in the Capsule by referencing thecapsule id that it corresponds to.

88

</Behavioral_Elements.State_Machines.StateVertex.incoming></Behavioral_Elements.State_Machines.SimpleState>

- - <Behavioral_Elements.State_Machines.Pseudostate xmi.id="G.7">

<Foundation.Core.ModelElement.name /><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Behavioral_Elements.State_Machines.Pseudostate.kind xmi.value="initial" />

- <Behavioral_Elements.State_Machines.StateVertex.outgoing><Behavioral_Elements.State_Machines.Transition xmi.idref="G.8" /></Behavioral_Elements.State_Machines.StateVertex.outgoing></Behavioral_Elements.State_Machines.Pseudostate>

- - <Behavioral_Elements.State_Machines.FinalState xmi.id="G.10">

<Foundation.Core.ModelElement.name /><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />

- <Behavioral_Elements.State_Machines.StateVertex.incoming><Behavioral_Elements.State_Machines.Transition xmi.idref="G.6" /></Behavioral_Elements.State_Machines.StateVertex.incoming></Behavioral_Elements.State_Machines.FinalState></Behavioral_Elements.State_Machines.CompositeState.subvertex></Behavioral_Elements.State_Machines.CompositeState>

89

</Behavioral_Elements.State_Machines.StateMachine.top>- <Behavioral_Elements.State_Machines.StateMachine.transitions>- <Behavioral_Elements.State_Machines.Transition xmi.id="G.2">

<Foundation.Core.ModelElement.name /><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />

- <Behavioral_Elements.State_Machines.Transition.source><Behavioral_Elements.State_Machines.StateVertex xmi.idref="G.1" />

- </Behavioral_Elements.State_Machines.Transition.source>

- <Behavioral_Elements.State_Machines.Transition.target><Behavioral_Elements.State_Machines.StateVertex xmi.idref="G.3" />

- </Behavioral_Elements.State_Machines.Transition.target></Behavioral_Elements.State_Machines.Transition>

- <Behavioral_Elements.State_Machines.Transition xmi.id="G.4"><Foundation.Core.ModelElement.name /><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />


- </Behavioral_Elements.State_Machines.Transition.source>


- </Behavioral_Elements.State_Machines.Transition.target></Behavioral_Elements.State_Machines.Transition>



- </Behavioral_Elements.State_Machines.Transition.source>


- </Behavioral_Elements.State_Machines.Transition.target></Behavioral_Elements.State_Machines.Transition>


- <Behavioral_Elements.State_Machines.Transition.trigger><Behavioral_Elements.State_Machines.Event xmi.idref="S.164.1609.22.1" /></Behavioral_Elements.State_Machines.Transition.trigger>

- <Behavioral_Elements.State_Machines.Transition.source>

90

<Behavioral_Elements.State_Machines.StateVertex xmi.idref="G.7" />- </Behavioral_Elements.State_Machines.Transition.source>


- </Behavioral_Elements.State_Machines.Transition.target></Behavioral_Elements.State_Machines.Transition></Behavioral_Elements.State_Machines.StateMachine.transitions></Behavioral_Elements.State_Machines.StateMachine>

- <Behavioral_Elements.State_Machines.SignalEvent xmi.id="S.164.1609.22.1"><Foundation.Core.ModelElement.name>status = 1</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" />

- <Behavioral_Elements.State_Machines.SignalEvent.signal><Behavioral_Elements.Common_Behavior.Signal xmi.idref="S.164.1609.22.2" /></Behavioral_Elements.State_Machines.SignalEvent.signal></Behavioral_Elements.State_Machines.SignalEvent>

- <Behavioral_Elements.Common_Behavior.Signal xmi.id="S.164.1609.22.2"><Foundation.Core.ModelElement.name>status = 1</Foundation.Core.ModelElement.name><Foundation.Core.ModelElement.visibility xmi.value="public" /><Foundation.Core.ModelElement.isSpecification xmi.value="false" /><Foundation.Core.GeneralizableElement.isRoot xmi.value="false" /><Foundation.Core.GeneralizableElement.isLeaf xmi.value="false" /><Foundation.Core.GeneralizableElement.isAbstract xmi.value="false" /></Behavioral_Elements.Common_Behavior.Signal>

REPRESENTATION OF TAGGED VALUES:

- <Foundation.Extension_Mechanisms.TaggedValue xmi.id="XX.1.1038.28.18">Foundation.Extension_Mechanisms.TaggedValue.tag>RationalRosert$OT::CppTargetRTS:BackwardsC

ompatible</Foundation.Extension_Mechanisms.TaggedValue.tag><Foundation.Extension_Mechanisms.TaggedValue.value>False</Foundation.Extension_Mechanisms.Tagg

edValue.value>- <Foundation.Extension_Mechanisms.TaggedValue.modelElement>

<Foundation.Core.ModelElement xmi.idref="pr5" /></Foundation.Extension_Mechanisms.TaggedValue.modelElement></Foundation.Extension_Mechanisms.TaggedValue>

91

D: Verification

Syntax Verification

Figure 49: Verification of Syntax

Semantics Verification

Figure 50:Import into CodeGenie for Verification of metamodel

92

E: Developed Script for Export

Figure 51: Execution of the developed script on a Traffic System model

93

F: Project plan

Plan made during the start of the Project:

Figure 52: Plan during the beginning of the Project

94

Plan of working through ArgoUML - Plan Made in February:

The following plan was made when a decision to follow ArgoUML for development of Rose RT toXMI Conversion tool was undertaken. This plan was followed till March when the possibility ofwriting a script for conversion was discovered.

Figure 53: Working through both Unisys and Argo UML: Plan after the responsibilities were defined

The Plan involved in generating XMI through two sources namely ArgoUML (which produces XMI1.0 output) and Rational Rose Unisys Plugin (which can produce XMI 1.0) and trying to understand theexport of the concepts. Once the representation and working was understood, developing a Java toolwhich would parse the model and extract information was chosen. During this process, the standard ofXMI wasn’t concentrated. However, little success was achieved during this process, with the programjust being able to print out the model information after 2 weeks. The plan was abandoned at Event 8 inthe above Figure 53: Working through both Unisys and Argo UML: Plan after the responsibilities weredefined.

95

Plan of working through the Script: Latest Plan Made in March

Figure 54: Performing different tasks in Script - Plan

96

Glossary- A -

abstraction

The required characteristics of an entity that distinguish it from all other kind of entities. An abstractionsets a boundary relative to the perspective of the viewer.

aggregation

A special form of association that specifies a “part-of” relationship between the component part andaggregate (whole). See also Composition.

API: Application Program Interface

API could be a combination of various routines, protocols and tools for building software applications.At a higher level an API is a set of functionality delivered by a programming system, and as such themix of APIs in a particular system tells you what that system can do.

architecture

The organizational structure of a system. Architecture can be recursively decomposed into parts thatinteract through interfaces, relationships that connect parts, and constraints for assembling parts.

association

A relationship that describes a set of links which enables the connecting classes and

association class

A modeling element that has both association and class properties. An association class can be seen asan association that also has class properties, or as a class that also has association properties.

association role

The role that a type or class plays in an association

attribute

A named property of a type.

- B -

binary protocol

Only one role (base role) must be specified, for the other (conjugate) can be derived from the base roleby inverting the incoming and outgoing signal sets.

- C -

cardinality

The number of elements in a set. Contrast: multiplicity.

CASE - Computer-Aided Software Engineering

It involves in the usage of software tools in constructing and developing software.

class

A description of a set of objects that share the same attributes, operations, methods, relationships, andsemantics. A class is an implementation of type.

97

class diagram

A diagram that shows a collection of declarative (static) model elements, such as classes, types, andtheir contents and relationships.

collaboration diagram

A diagram that shows object interactions organized around the objects and their links to each other.Unlike a sequence diagram a collaboration diagram shows the relationships among the objects.Sequence diagrams and collaboration diagrams express similar information, but show it in differentways.

composite [class]

A class that is related to one or more classes by a composition relationship.

composition

A form of aggregation with strong ownership and coincident lifetime as part of the whole. Parts withnon-fixed multiplicity may be created after the composite itself, but once created they live and die withit (i.e., they share lifetimes). Such parts can also be explicitly removed before the death of thecomposite. Composition may be recursive. Synonym: composite aggregation.

CORBA - Common Object Request Broker Architecture

It is an architecture used for handling communication between objects in a distributed environment.

concurrency

The occurrence of two or more activities during the same time interval. Concurrency can be achievedby interleaving or simultaneously executing two or more threads.

CWM - Common Warehouse Metamodel (CWM)

It specifies the interfaces that enable interchange of warehouse metadata and model meta-informationbetween various warehouse tools, warehouse platforms and meta data repositories in a distributedframework.

- D -

dependency

A relationship between two modeling elements, in which a change to one modeling element (theindependent element) will affect the other modeling element (the dependent element).

deployment diagram

A diagram that shows the configuration of run-time processing nodes and the components, processes,and objects that live on them. Components represent run-time manifestations of code units.

- G -

generalizable element

A model element that may participate in a generalization relationship.

generalization

A taxonomic relationship between a more general element and a more specific element. The morespecific element is fully consistent with the more general element and contains additional information.An instance of the more specific element may be used where the more general element is allowed..

guard condition

A condition that must be satisfied in order to cause an associated transition to trigger.

98

- I - .

inheritance

The mechanism by which more specific elements incorporate structure and behavior of more generalelements related by behavior.

instance

An individual member described by a type or a class. Usage note: According to a strict interpretation ofthe metamodel an individual member of a type is an instance and a member of a class is an object. Inless formal usage it is acceptable to refer to a member of a class as an object or an instance.

interaction diagram

A generic term that applies to several types of diagrams that emphasize object interactions. Theseinclude: collaboration diagrams, sequence diagrams, and activity diagrams.

interface

The use of a type to describe the externally visible behavior of a class, object, or other entity. In thecase of a class or object, the interface includes the signatures of the operations.

- J -

JMI Java Metadata Interface

It enables a platform independent infrastructure for storage, creation, discovery and exchange ofmetadata.

- M -

metaclass

A class whose instances are classes. Metaclasses are typically used to construct metamodel

meta-metamodel

A model that defines the language for expressing a meta model. The relationship between a meta-metamodel and a metamodel is analogous to the relationship between a metamodel and a model.

metamodel

A model that defines the language for expressing a model . An instance of a meta-meta model’s metaobject. It is a generic term for all meta-entities in a metamodeling language. For example, metatypes,metaclasses, meta-attributes, and meta-associations.

MoTMoT Model driven, Template based, Model Transformer

It is an architecture plug-in used by AndroMDA® for model to text transformation.

- N -

namespace

A part of the model in which the names may be defined and used. Within a namespace, each name has aunique meaning.

99

- O -

operation

A service that can be requested from an object to effect behavior. An operation has a signature whichmay restrict the actual parameters that are possible.

OCL - Object Constraint Language

It is a declarative language described using pre and post conditions that apply to UML Models.

OMG - Object Management Group

It is a non-profit organization which regulates various open standards used by the industry andacademia.

OODBMS – Object Oriented DataBase Management System

It is a DBMS (Data Base Management System) which stores objects in it as opposed to tuples orrecords in a Relational DataBase Management System

- P -

PIM - Platform Independent Model

It is a model which provides an enterprise view and is devoid of the technological platformimplementing it.

PM - Platform Model

It is a model which depends on the system architecture and the model translator.

PSM - Platform Specific Model

It is a model which is linked to a specific technological platform. It is in contrast to PIM..

- R -

relationship

A semantic connection among model elements. Examples of relationships include associations andgeneralizations.

RDBMS – Relational DataBase Management System

It is a type of DBMS where the DataBase is organized and accessed according to the relationshipsbetween various data values.

ROOM - Real Time Object Oriented Modeling

It is a real time modeling architecture from Rational cooperation which is aka UML RT

RSS – Really Simple Syndication/ Rich Site Summary

It is used for syndication of site content on the internet. It is an XML based format for representation.

- S -

signal

A named event that can be explicitly invoked ("raised"). Signals may have parameters. A signal may bebroadcast or directed toward a single object or a set of objects.

state

100

A condition or situation during the life of an object during which it satisfies some condition, performssome activity, or waits for some event..

state diagram

A diagram that shows a state machine.

state machine

A behavior that specifies the sequences of states that an object or an interaction goes through during itslife in response to events, together with its responses and actions.

stereotype

A new type of modeling element that extends the semantics of the metamodel. Stereotypes must bebased on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, butnot the structure of pre-existing types and classes. Certain stereotypes are predefined in the UML,others may be user defined. Stereotypes are one of three extendibility mechanisms in the UML.

- T -

tagged value

The explicit definition of a property as a name-value pair. In a tagged value, the name is referred as thetag. Certain tags are predefined in the UML; others may be user defined. Tagged values are one of threeextendibility mechanisms in UML.

- V -

vertex

A source or a target for a transition in a state machine. A vertex can be either a state or a pseudo-state..

visibility

An attribute whose value (public, protected, private, or implementation) denotes how the modelelement to which it refers may be seen outside its enclosing name space.

- X -

XMI XML Metadata Interchange

It is an interchange format specified by OMG for interchange of models.

XML eXtensible Markup Language

It is a Markup Language which is used for representation of data and information and specified byW3C.

TRITA-CSC-E 2006:107 ISRN-KTH/CSC/E--06/107--SE

ISSN-1653-5715

www.kth.se