ModelicaML Graphical Modeling Environment Based on Eclipse MDT Papyrus

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

ModelicaML Graphical Modeling Environment

Based on Eclipse MDT Papyrus

by

Imran Hakam

LIU-IDA/LITH-EX-A—11/004—SE

2011-03-03

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

(2)

Linköping University Electronic Press

Upphovsrätt

ĞƚƚĂ ĚŽŬƵŵĞŶƚ ŚĊůůƐ ƚŝůůŐćŶŐůŝŐƚ ƉĊ /ŶƚĞƌŶĞƚ ʹ ĞůůĞƌ ĚĞƐƐ ĨƌĂŵƚŝĚĂ ĞƌƐćƚƚĂƌĞ ʹĨƌĊŶ ƉƵďůŝĐĞƌŝŶŐƐĚĂƚƵŵ ƵŶĚĞƌ ĨƂƌƵƚƐćƚƚŶŝŶŐĂƚƚŝŶŐĂĞǆƚƌĂŽƌĚŝŶćƌĂŽŵƐƚćŶĚŝŐŚĞƚĞƌƵƉƉƐƚĊƌ͘ dŝůůŐĊŶŐƚŝůůĚŽŬƵŵĞŶƚĞƚŝŶŶĞďćƌƚŝůůƐƚĊŶĚĨƂƌǀĂƌŽĐŚĞŶĂƚƚůćƐĂ͕ůĂĚĚĂŶĞƌ͕ƐŬƌŝǀĂƵƚĞŶƐƚĂŬĂŬŽƉŝŽƌĨƂƌĞŶƐŬŝůƚ ďƌƵŬ ŽĐŚ Ăƚƚ ĂŶǀćŶĚĂ ĚĞƚ ŽĨƂƌćŶĚƌĂƚ ĨƂƌ ŝĐŬĞŬŽŵŵĞƌƐŝĞůů ĨŽƌƐŬŶŝŶŐ ŽĐŚ ĨƂƌ ƵŶĚĞƌǀŝƐŶŝŶŐ͘ PǀĞƌĨƂƌŝŶŐ Ăǀ ƵƉƉŚŽǀƐƌćƚƚĞŶǀŝĚĞŶƐĞŶĂƌĞƚŝĚƉƵŶŬƚŬĂŶŝŶƚĞƵƉƉŚćǀĂĚĞƚƚĂƚŝůůƐƚĊŶĚ͘ůůĂŶŶĂŶĂŶǀćŶĚŶŝŶŐĂǀĚŽŬƵŵĞŶƚĞƚ ŬƌćǀĞƌ ƵƉƉŚŽǀƐŵĂŶŶĞŶƐ ŵĞĚŐŝǀĂŶĚĞ͘ &Ƃƌ Ăƚƚ ŐĂƌĂŶƚĞƌĂ ćŬƚŚĞƚĞŶ͕ ƐćŬĞƌŚĞƚĞŶ ŽĐŚ ƚŝůůŐćŶŐůŝŐŚĞƚĞŶ ĨŝŶŶƐ ůƂƐŶŝŶŐĂƌĂǀƚĞŬŶŝƐŬŽĐŚĂĚŵŝŶŝƐƚƌĂƚŝǀĂƌƚ͘ hƉƉŚŽǀƐŵĂŶŶĞŶƐ ŝĚĞĞůůĂ ƌćƚƚ ŝŶŶĞĨĂƚƚĂƌ ƌćƚƚ Ăƚƚ ďůŝ ŶćŵŶĚ ƐŽŵ ƵƉƉŚŽǀƐŵĂŶ ŝ ĚĞŶ ŽŵĨĂƚƚŶŝŶŐ ƐŽŵ ŐŽĚ ƐĞĚ ŬƌćǀĞƌ ǀŝĚ ĂŶǀćŶĚŶŝŶŐ Ăǀ ĚŽŬƵŵĞŶƚĞƚ ƉĊ ŽǀĂŶ ďĞƐŬƌŝǀŶĂ Ɛćƚƚ ƐĂŵƚ ƐŬǇĚĚ ŵŽƚ Ăƚƚ ĚŽŬƵŵĞŶƚĞƚ ćŶĚƌĂƐ ĞůůĞƌ ƉƌĞƐĞŶƚĞƌĂƐ ŝ ƐĊĚĂŶ ĨŽƌŵ ĞůůĞƌ ŝ ƐĊĚĂŶƚ ƐĂŵŵĂŶŚĂŶŐ ƐŽŵ ćƌ ŬƌćŶŬĂŶĚĞ ĨƂƌ ƵƉƉŚŽǀƐŵĂŶŶĞŶƐ ůŝƚƚĞƌćƌĂ ĞůůĞƌ ŬŽŶƐƚŶćƌůŝŐĂĂŶƐĞĞŶĚĞĞůůĞƌĞŐĞŶĂƌƚ͘ &Ƃƌ ǇƚƚĞƌůŝŐĂƌĞ ŝŶĨŽƌŵĂƚŝŽŶ Žŵ >ŝŶŬƂƉŝŶŐ hŶŝǀĞƌƐŝƚǇ ůĞĐƚƌŽŶŝĐ WƌĞƐƐ ƐĞ ĨƂƌůĂŐĞƚƐ ŚĞŵƐŝĚĂ ŚƚƚƉ͗ͬͬǁǁǁ͘ĞƉ͘ůŝƵ͘ƐĞͬ

Copyright

dŚĞƉƵďůŝƐŚĞƌƐǁŝůůŬĞĞƉƚŚŝƐĚŽĐƵŵĞŶƚŽŶůŝŶĞŽŶƚŚĞ/ŶƚĞƌŶĞƚʹŽƌŝƚƐƉŽƐƐŝďůĞƌĞƉůĂĐĞŵĞŶƚʹĨƌŽŵƚŚĞĚĂƚĞŽĨ ƉƵďůŝĐĂƚŝŽŶďĂƌƌŝŶŐĞǆĐĞƉƚŝŽŶĂůĐŝƌĐƵŵƐƚĂŶĐĞƐ͘ dŚĞŽŶůŝŶĞĂǀĂŝůĂďŝůŝƚǇŽĨƚŚĞĚŽĐƵŵĞŶƚŝŵƉůŝĞƐƉĞƌŵĂŶĞŶƚƉĞƌŵŝƐƐŝŽŶĨŽƌĂŶǇŽŶĞƚŽƌĞĂĚ͕ƚŽĚŽǁŶůŽĂĚ͕ŽƌƚŽ ƉƌŝŶƚ ŽƵƚ ƐŝŶŐůĞ ĐŽƉŝĞƐ ĨŽƌ ŚŝƐͬŚĞƌƐ ŽǁŶ ƵƐĞ ĂŶĚ ƚŽ ƵƐĞ ŝƚ ƵŶĐŚĂŶŐĞĚ ĨŽƌ ŶŽŶͲĐŽŵŵĞƌĐŝĂů ƌĞƐĞĂƌĐŚ ĂŶĚ ĞĚƵĐĂƚŝŽŶĂůƉƵƌƉŽƐĞ͘^ƵďƐĞƋƵĞŶƚƚƌĂŶƐĨĞƌƐŽĨĐŽƉǇƌŝŐŚƚĐĂŶŶŽƚƌĞǀŽŬĞƚŚŝƐƉĞƌŵŝƐƐŝŽŶ͘ůůŽƚŚĞƌƵƐĞƐŽĨƚŚĞ ĚŽĐƵŵĞŶƚ ĂƌĞ ĐŽŶĚŝƚŝŽŶĂů ƵƉŽŶ ƚŚĞ ĐŽŶƐĞŶƚ ŽĨ ƚŚĞ ĐŽƉǇƌŝŐŚƚ ŽǁŶĞƌ͘ dŚĞ ƉƵďůŝƐŚĞƌ ŚĂƐ ƚĂŬĞŶ ƚĞĐŚŶŝĐĂů ĂŶĚ ĂĚŵŝŶŝƐƚƌĂƚŝǀĞŵĞĂƐƵƌĞƐƚŽĂƐƐƵƌĞĂƵƚŚĞŶƚŝĐŝƚǇ͕ƐĞĐƵƌŝƚǇĂŶĚĂĐĐĞƐƐŝďŝůŝƚǇ͘ ĐĐŽƌĚŝŶŐƚŽŝŶƚĞůůĞĐƚƵĂůƉƌŽƉĞƌƚǇůĂǁƚŚĞĂƵƚŚŽƌŚĂƐƚŚĞƌŝŐŚƚƚŽďĞŵĞŶƚŝŽŶĞĚǁŚĞŶŚŝƐͬŚĞƌǁŽƌŬŝƐĂĐĐĞƐƐĞĚ ĂƐĚĞƐĐƌŝďĞĚĂďŽǀĞĂŶĚƚŽďĞƉƌŽƚĞĐƚĞĚĂŐĂŝŶƐƚŝŶĨƌŝŶŐĞŵĞŶƚ͘ &ŽƌĂĚĚŝƚŝŽŶĂůŝŶĨŽƌŵĂƚŝŽŶĂďŽƵƚƚŚĞ>ŝŶŬƂƉŝŶŐhŶŝǀĞƌƐŝƚǇůĞĐƚƌŽŶŝĐWƌĞƐƐĂŶĚŝƚƐƉƌŽĐĞĚƵƌĞƐĨŽƌƉƵďůŝĐĂƚŝŽŶ ĂŶĚĨŽƌĂƐƐƵƌĂŶĐĞŽĨĚŽĐƵŵĞŶƚŝŶƚĞŐƌŝƚǇ͕ƉůĞĂƐĞƌĞĨĞƌƚŽŝƚƐǁǁǁŚŽŵĞƉĂŐĞ͗ŚƚƚƉ͗ͬͬǁǁǁ͘ĞƉ͘ůŝƵ͘ƐĞͬ͘

© Imarn Hakam

(3)

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

ModelicaML Graphical Modeling Environment

Based on Eclipse MDT Papyrus

Examensarbete utfört i Datavetenskap vid Tekniska högskolan vid Linköpings universitet

av

Imran Hakam

LIU-IDA/LITH-EX-A-11/004-SE

Linköping 2011

Department of Computer and Information Science Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(4)

ModelicaML Graphical Modeling Environment

Based on Eclipse MDT Papyrus

Examensarbete utfört i Datavetenskap

vid Tekniska högskolan i Linköping

av

Imran Hakam

LIU-IDA/LITH-EX-A-11/004-SE

Examinator: Prof. Peter Fritzson

ida, Linköpings universitet

Handledare: Dr. Mohsen Torabzadeh-Tari

ida, Linköpings universitet

Mr. Wladimir Schamai

EADS IW, Germany

(5)

Avdelning, Institution

Division, Department

Division of Computer System

Department of Computer and Information Science Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2011-03-03 Språk Language Svenska/Swedish Engelska/English ⊠ Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ⊠

URL för elektronisk version

http://www.ida.liu.se/ http://www.ep.liu.se ISBN — ISRN LIU-IDA/LITH-EX-A-11/004-SE

Serietitel och serienummer

Title of series, numbering

ISSN

—

Titel

Title

Svensk titel

ModelicaML Graphical Modeling Environment Based on Eclipse MDT Papyrus

Författare

Author

Imran Hakam

Sammanfattning

Abstract

The ModelicaML graphical Modeling Language and Modelica/UML profile is a lan-guage for the description of continuous-time and discrete-time/event-based system dynamics. Modelica ML uses Papyrus as modelling tool implementation platform which is used for editing models. These models may be expressed in UML with optional textual statements in Modelica as action language code. For the new version ModelicaML 2.0, the need for support in the new Papyrus M1 version was essential. In this master thesis project, new plug-in functionality was devel-oped that has enhanced the existing functionality of the ModelicaML modelling environment within the Papyrus Eclipse plug-in. This includes handling Modelica modifiers as well as new views and component tree views which provides complete list of components for a selected class.

Nyckelord

(6)

Abstract

The ModelicaML graphical Modeling Language and Modelica/UML profile is alanguage for the

description of continuous-time and discrete-time/event-based system dynamics. Modelica ML

uses Papyrus as modelling tool implementation platform which is used for editing models. These

models may be expressed in UML with optional textual statements in Modelica as action

language code. For the new version ModelicaML 2.0, the need for support in the new Papyrus

M1 version was essential. In this master thesis project, new plug-in functionality was developed

that has enhanced the existing functionality of the ModelicaML modeling environment within

the Papyrus Eclipse plug-in. This includes handling Modelica modifiers as well as new views

and component tree views which provides complete list of components for a selected class.

(7)

Dedication

I would like to dedicate my thesis work to my loving parents, affectionate Taya ge,

devoted wife, considerate brother, caring sisters and other kind family members…

(8)

Acknowledgments

The special thanks go to my supervisors, Mr. Wladimir Schamai and Dr. Mohsen Torabzadeh

Tari. The supervision and support that they gave me with their helping nature truly help the

progression and smoothness of my thesis work.

I radiate a lot of confidence while working at EADS Innovation Works it was very nice

experience and I am thankful to my supervisors for providing me this opportunity.

I would like to thank my examiner Professor Peter Fritzon for his help and timely advices during

my thesis work.

My grateful thanks also go to all my friends not only for the support in curricular activities but

also for the hospitality in Linköping and Hamburg. I have spent a very good time of my life with

my friends in Sweden and Germany specially with Mr. Adnan Waheed, Mr. Muhammad Ayaz

Khan, Mr. Molana Sajid Hussain, Mr. Mansoor Munib, Mr. Mati Ullah Khan W, Mr. Muzammil

Zareen, Mr. Farhan Khan, Mr. Azam Zia, Mr. Ahsan Rasool,Mr. Kamran Zafar,Mr. Syed Zahid

Ali,Mr. Syed Yasir Imtiaz,Mr. Kamran Hakam, Mr. CH.Hassan Riaz(Late), Mr. Imran Khan and

those not listed here but listed in my mind.

(9)

Chapter 1 Background

1.1 Modelica Overview

Modelica is an object-oriented, equation based language to conveniently model the dynamic behaviour of complex physical systems containing, e.g., mechanical, elec-trical, electronic, hydraulic, thermal, control, electric power or process-oriented subcomponents as well as consisting of components from other similar domains.

Models in Modelica are mathematically described by differential, algebraic and discrete equations. No particular variable needs to be solved for manually. A Mod-elica tool will have enough information to decide that automatically. ModMod-elica is designed such that available, specialized algorithms can be utilized to enable effi-cient handling of large models having more than one hundred thousand equations [1].

Modelica community contributed its efforts in an efficient way for the sequen-tial existence of the Modelica Language. Modelica is used in industry since year 2000 but it covers a long journey from late nineties up to the end of first decade of 21st century.

The first Modelica version 1 was released in September, 1997. Now in March, 2010 the Modelica 3.2 has released. Modelica community is working hard to pro-vide new advance features on every released version.

1.2 OpenModelica

OpenModelica is an open source Modelica environment developed and supported by Linköping University and the Open Source Modelica Consortium (OSMC) - a growing group of companies, universities, institutes and individuals. The goal of this project is to create a complete Modelica modeling, compilation and simulation environment based on free software distributed in source code and executable

(14)

2 Background

form intended for research, teaching, and industrial usage. OpenModelica is freely available [2].

1.3 ModelicaML

ModelicaML graphical Modeling Language for Modelica is language for the de-scription of time-continuous and time-discrete/event-based system dynamics. Mod-elicaML is defined as an extended subset of the OMG Unified Modeling Language (UML). This subset enables the generation of executable Modelica code [3].

Modelica Modeling Language started its journey in 2007 at PELAB [4] Linköping University. Now ModelicaML is in a mature stage and can efficiently support mod-elling complex systems. The ModelicaML technology is fully explained in section 2.1. Now ModelicaML has a new version which is attuned to new version of Pypyrus UML [5].

1.4 Purpose of Thesis

In the OpenModelica Annual Workshop 2011, February 7 [6] ModelicaML intro-duces some new features which were not supported in the ModelicaML version 1. ModelicaML uses Papyrus UML as a modelling tool since papyrus UML intro-duces a new version and the previous version of ModelicaML was not compatible with this new version of Papyrus. Therefore it was reengineered with some new advanced features. The purpose of this thesis was to implement the new proposed features for the new version of the Modelica. These features include providing context menus for Modelica elements, displaying the components of a class in a User Interface (UI) view, providing modification support and providing a dedi-cated perspective for Modelica.

The context menu, pallets, and diagrams from the previous version of Modeli-caML were migrated into new version and some new features were implemented. The details of these features are comprehensively explained in chapters 4, 5 and 6.

1.4.1 Pre-Study Phase

Understanding the tools and technology is a key to achieving the aims. Before starting work at EADS Innovation Work [7], pre study work was done at PELAB Linköping [4] under the supervision of Prof. Peter Fritzson and Dr. Mohsen Torabzadeh-Tari.

This phase took three months form June 2010 to September 2010. It took some time in this period to get basic understanding of the Modelica, OpenModelica and ModelicaML technologies. For better insight into the requirement I used some modelling tools for viewing the components in a UI tree view. Getting an idea for

(15)

1.4 Purpose of Thesis 3

the implementation was a hard task and it took most of my time during working a PELAB.

1.4.2 Implementation Phase

All the implementation work has done at EADS Innovation Works Hamburg Ger-many [7] under the supervision of Mr. Wladimir Schamai. Developing the plug-in for displaying components was the initial task which was achieved and then the most time consuming and challenging part was the modification support. The details of the implementation are described from chapter 4 and onwards.

(16)

(17)

Chapter 2 ModelicaML Papyrus MDT

GUI

Modelica Modelling Language (ModelicaML) is a graphical modeling language for the description of time-continuous and time-discrete/event-based system dynam-ics. ModelicaML is defined as an extended subset of the OMG Unified Modeling Language (UML). This subset enables the generation of executable Modelica code. The main purpose of ModelicaML is to enable an efficient and effective way to cre-ate, visualize and maintain combined UML and Modelica models. ModelicaML is defined as a graphical notation that facilitates different views (e.g., composition, inheritance, behaviour) on system models. It is based on a subset of UML and reuses some concepts from SysML. ModelicaML is designed to generate Modelica code from graphical models. Since the ModelicaML profile is an extension of the UML meta-model it can be used as an extension for both UML and SysML [8].

Figure 2.1. ModelicaML prototype architecture [9].

(18)

6 ModelicaML Papyrus MDT GUI

In the figure 1 the architecture of ModelicaML prototype is shown graphically. Papyrus [5] is an Eclipse based graphical editing tool and Papyrus UML is used for modeling the objects. The modeling tool Papyrus UML has special features like dedicated toolbars and diagram selection. Models are then validated and con-straints are effectively checked through the validator plug-in which informs the user of any violation made by r.

After completion of the modeling phase, Modelica ML code generator (which is implemented using Acceleo [10]) is used for generating Modelica code from the Modelica models. Acceleo follows the model driven approach in order to generate the code.

The last step is performing simulation from the above mentioned generated Modelica code. The simulation can be performed by using either OpenModelica [12] Or Dymola [13].

Up till now the abstract working of ModelicaML has been explained, the next section contains the complete procedure for setting up the environment and work-flow.

2.1 Modeling, Validation, and Simulation

In order to know the complete technology of ModelicaML and to understand the above architecture it will be wise to explain through an example how the user can model objects using ModelicaML.

The example is taken from the book “Principles of Object-Oriented Modeling

and Simulation with Modelica”[22]. The example is precisely explained in chapter 12 “System Modeling Methodology and Continuous Model Representation”. The ex-ample describes a system containing a tank system with two water tanks, a source for liquid, and a controller which checks for the overflow of liquid.

The graphical representation is given below in figure.

In order to simulate this example we will first set Graphical User Interface (GUI), model it and then we generate the code using Acceleo [10] and finally we can simulate it by using the OpenModelica [2] or MathModelica [12] tools. The steps as well as the screenshots of the performed steps are given below. You may execute another example or model on your own system by using these steps.

We will start by opening Eclipse, when the Eclipse plat form is visible after selecting a suitable workspace we need to change the perspective. For this we will go in “Open Perspective” tab and select the Papyrus perspective.

The steps are shown in the figure: 2.3.

(19)

2.1 Modeling, Validation, and Simulation 7

Figure 2.2. Two tanks system [15].

Figure 2.3. Changing perspective.

Project”. As we are using Papyrus as a modeling tool so we need to create a Papyrus project simply go to the file → new → Papyrus Project. This step is shown in the screen short given below.

Specify a suitable name in the field Project name and click next. In the given example of the two tank system the naming convention of Eclipse is followed with a dot notation.

After specifying the name, select UML check box and on the next page select the UML class diagram. Now we are going to create a class diagram for the ex-ample of two tanks system. Click on finish and now we have created a project.

After creating a project we can find the following files inside the project explorer view.

(20)

Figure 2.4. Create new papyrus project.

Figure 2.5. Create new papyrus project.

editor.

• model.notation

• model.uml file is the model file and you can edit it by using any UML2 tool.

In the model browser (Model Explorer) there is only one file with the name “model” with out any extension. We must rename this file and set a suitable name for our system. The reason of renaming is that “model” is a keyword in the Modelica representing is a class type. So, the name must be changed, in our example we set the example system’s name. The screen short of the Eclipse platform is given below in figure 2.8.

After renaming the file we are going to apply the ModelicaML stereotype to the model. This action is described in four steps:

Step-1: Select the model which has now the name “twotankssystem”.

Step-2: Go to the properties tab and press the button as shown in figure 2.9. Step-3: A pop up window with the title “apply profile from Papyrus repository”

is now opened, and you will be able to see ModelicaML 1.1.1. Select ModelicaML and press ok. Now this window will disappear and it takes a few seconds to load

(21)

2.1 Modeling, Validation, and Simulation 9

Figure 2.6. Selecting class diagram.

Figure 2.7. File structure of ModelicaML project.

and another pop up window will be opened.

Step-4: Click to check the check box of ModelicaML and press ok to finalize.

You have successfully applied the Modelica profile. You can see that inside the properties view → profile tab the following text is visible:

• ModelicaML

• ModelicaML::ModelicaPredefinedTypes

• ModelicaML::ModelicaClassConstrucs

• ModelicaML::ModelicaBehaviorConstrucs

• And so on.

This text shows that you have successfully applied the ModelicaML stereotype. These four steps are graphically represented in one screen shot on the next page. Note that the text in profile tab will only be visible after step-4.

(22)

Figure 2.8. Renaming the Model.

Now we will configure the model explorer. For this click on the “Load browser customisation” button and select ModelicaML customisation from left panel, put it on the right side panel and also set it on top by using the up button.

2.2 ModelicaML Specific Views

2.2.1 Model Browser

When we start modeling our system in the Papyrus perspective, the model browser is a view which shows the model elements of our system.

2.2.2 Properties View

This view shows the properties of the selected element. This view has four tabs: • UML provides the name and the visibility of selected element.

• ModelicaML provides the name of model selected.

• Profile provide the applied stereotypes on model.

• Advanced tab provide a brief summary of name and other properties.

2.2.3 Diagram Editors

Diagram editors supports different UML-based diagrams. You can add a diagram by using Modelica actions and draw the diagram by using the components inside palette. Palette is described below.

(23)

2.2 ModelicaML Specific Views 11

Figure 2.9. Applying profile Step 1-4.

2.2.4 Palette

The Palette can also be customised and it is different for each diagram.

Class diagram: It provides the related contracts inside the classes, relation and

annotation sections.

Activity diagram: The palette will provide nodes, decision nodes, edges and

annotation. An activity diagram can be of the type conditional algorithm or conditional equation.

2.2.5 ModelicaML

ModelicaML code generation and validation actions can be performed from the context menu which can be visible when you right click on the model class. The code generated will be a file with the extension .mo. This file will be supplied to any simulation tool like Math Modelica for the simulation of the desired model.

2.2.6 Class Component tree

Class component tree shows the component hierarchy of the selected class as well as the modification value which is modified by user. Inheritance is supported in Modelica through instance modification and class modification. This tree follows the class modification. (Explained in detail in Chapter 6).

2.2.7 Modelica Perspective

The Modelica perspective is like the Papyrus perspective. Modelica has its own perspective in which you can configure the model browser and can also add

(24)

differ-12 ModelicaML Papyrus MDT GUI

Figure 2.10. Model browser customisation.

ent related views.

The section below will explain how we can add different Modelica related views inside the perspective.

2.3 Add ModelicaML Specific Views

To add views, inside the Eclipse platform go to windows → show view → others, a pop up window will open offering different views. You can see the folder of ModelicaML with a a drop down menu, drag it and select the class component view. This view will be added on the top of the outline window. You can place it at a suitable position inside the perspective as per you convenience. In the same way you can add the Modelica validation view.

The screen short illustrating this section is provided in figure 2.11.

2.4 How to Create Model Structure

In the above sections we have configured the various component of the platform. From this section, the description of the process for the actual modelling in Pa-pyrus will be provided. We can create packages and classes using ModelicaML menus. Right click the model class and there is a menu containing the actions that can be performed on the selected element. The detail of this plug-in is ex-plained in Chapter 3.

(25)

2.5 How to Set the Type in ModelicaML 13

Figure 2.11. Adding views.

The graphical representation is given below in a screenshot.

Figure 2.12. Adding Modelica elements.

2.5 How to Set the Type in ModelicaML

There are four primitive types in Modelica given below: • Modelica Real

• Modelica Integer

• Modelica String

(26)

Figure 2.13. Selecting the type.

We can add more diagrams like activity diagram, conditional algorithm/Equa-tion diagram to our model. The process for adding these diagrams in a model is described in a tutorial [9].

So far, we have created a basic model structure and set the types for variables and components. Creation of a model structure such as adding a Modelica element is done by developing a separate plug-in as an extension to Papyrus. The detail of this plug-in is described in section 4.7.

(27)

Chapter 3 Design of tools

The Eclipse platform is open source and it is designed in such a way that it can be extended easily. All the extensions are in the form of plug-ins. The Eclipse is surrounded by thousands of plug-ins but these plug-ins are not loaded at once. These plug-ins are dynamically loaded by the Eclipse plug-in loader at run time on demand and this is called lazy loading.

The ModelicaML extensions are implemented in Papyrus UML as contribution to the new version of ModelicaML 2.0.

The figure given below explains the general concept about the design of Eclipse based tools. The implementation detail of each plug-in is described in the later chapters.

Figure 3.1. Eclips based tools.

(28)

16 Design of tools

3.1 Papyrus

Papyrus is an open source tool which is based on the Eclipse platform and is used for modeling within UML2. Papyrus has an extendable architecture so we can add new diagrams and new code generators.

3.2 Modelica ML

ModelicaML is implemented as an Eclipse plug-in. ModelicaML is an alternative way for authoring Modelica models. It extends the graphical modeling capabili-ties of Modelica by providing more diagrams (UML diagrams for presenting the composition, connection, inheritance or behaviour of classes) for graphical model definition or documentation. Moreover, ModelicaML incorporates concepts for formalizing and evaluating textual requirements during system simulations [25].

3.3 Class Component Tree Plug-in

The class component tree is a plug-in and is described more in detail in Chapter 5.

3.4 Block Diagram

(29)

3.5 Modelica Perspective 17

In the block diagram, we can see that ModelicaML (UML profile) support the following:

• Create model structure

• Validate model

• Generate code

In Section 2.4, how to create model structure was discussed in detail. In the next chapters the implementation of this plug-in will be discussed. ModelicaML profile uses the class component tree view plug-in which is responsible for adding a view inside the Papyrus perspective and shows the components of a selected class. This plug-in is also discussed in detail in the Chapters 5 and 6.

3.5 Modelica Perspective

The Modelica perspective is another separate plug-in providing a dedicated per-spective for ModelicaML. The purpose of this plug-in is try to reduce the initial set up efforts made by the user before modeling. The perspective has dedicated views and provides the customised pallets for each diagram like class diagram, activity diagram etc.

A screenshot of the Modelica perspective is given below.

(30)

18 Design of tools

3.6 Required Installations Table

Before starting the modeling with ModelicaML, we need to install the tools that were discussed in ModelicaML architecture 2.1. The names and sources of the tools are given below in the table 3.1.

Tools Source

Eclipse 3.6 (Helios) http://www.eclipse.org Papyrus MDT Eclipse

plug-in

http://www.eclipse.org/modeling/mdt/papyrus/ updates/index.php

ModelicaML Eclipse plug-ins

http://www.openmodelica.org/index.php/developer /tools/134

Acceleo Eclipse plug-in http://www.acceleo.org/pages/download-acceleo/en Modelica Development

Tooling (MDT) Eclipse plug-in

http://www.openmodelica.org/index.php/developer /tools/133

(31)

Chapter 4 Model Structure

Modelica actions such as "add a Modelica element" and "launch of ModelicaML validator or code generator" are migrated from old version of Papyrus to new version of Papyrus because the old version of Papyrus is reengineered and now it has some extra feature in the new version. All the elements are implemented through commands and actions, the details of the implementation are described in section 4.7.

4.1 Description of Stereotypes and Utilization in

Model

In this section the detail of the stereotypes as well as the constraints is explained. The constraints represents the constraints under which another Modelica element can be added to the model. This will provide extra information to the modeller and will provide an ease while modeling. The details of stereotype are already described in [16], but in this section the detail [16] is merged with constraints that are implemented through filters. The filters are described in section 4.7.2.

4.2 Package

A package inside the menu bar is the simple UML package. It is not a stereotype and it can be added any where in the model.

4.3 Modelica Class

The “Modelica class” is a stereotype used to represent a Modelica “class”. The base class of modelica class is “UML class” Modelica class can be instantiated in the model inside an object element which is instance of a “class” or “package” and not the instance of “behaviour” with an additional constraint that the object element should not have the stereotype “function”.

(32)

20 Model Structure

4.4 Modelica Restricted Classes

4.4.1 Modelica Package

The Modelica package is Modelica restricted class “Package” and its base class property is “Class”. This stereotype is defined in “Modelica class constructs”. It can be instantiated any where in the model, inside an object element, which is an instance of a “package”.

4.4.2 Operator

This stereotype corresponds to Modelica’s restricted class “Operator”. The oper-ator is defined in “Modelica class constructs” and its base class is “Class”. An operator can be instantiated any where in the model, inside an object element, which is an instance of a “class” or “package” with the additional constraint that the object element should not have the stereotype “function”.

4.4.3 Model

This stereotype is corresponds to the Modelica restricted class model. The base class of the model is “class”. It can be instantiated under the following constraints: • Instantiated inside an object element which is instance of a “package” or “class” as well as an object element that is not an instance of a “behaviour”. Moreover the object element should not have the stereotype “function”. In a Modelica model many classes are allowed such as equation sections, algo-rithm, sections, connectors, input states, outputs states.

4.4.4 Block

A Modelica block is the same as a model but the important difference between the two is that the block must have the ports with fixed input and outputs. The ports are instances of a connector class. A Block can be instantiated inside a “package” or “class” that has the stereotype “function”.

4.4.5 Connector

The connector stereotype represents the Modelica restricted class “connector”. A connector cannot contain an equation section or an algorithm section. It can have causality and flow specification. While creating ports inside the model the type of the ports must be “connector”.

A connector can be instantiated inside an object element which is instance of a “class” or “package” and object element should not have the stereotype “function” and not an instance of “behaviour”.

(33)

4.5 A common Constraint 21

4.4.6 Type

This stereotype is used to represent the Modelica restricted class “type”. The base property of the stereotype is “primitive type” and is defined in “Modelica class constructs”. A type can be instantiated inside an object element that is instance of “class” or “package” and not an instance of “behaviour” as well as the object element that does not have the stereotype “function”.

4.4.7 Record

A Record is the stereotype which corresponds to a modelica “record” and it can contain an algorithm section and an equation section. But it can not contain causality or flow specification. A Record can be instantiated inside an object element which has the same constraints as mentioned above in Section 4.4.6.

4.5 A common Constraint

The constraint given below is very common in various Modelica elements. The implementation of these constraints is done by handler’s filters. The detail of implementation is described under section 4.7.

4.5.1 Constraint

A Modelica element can be instantiated inside an object element that is an instance of “class” or “package” and not an instance of “behaviour” as well as the object element that does not have the stereotype “function”.

4.6 Stereotypes and Filtered Constraints

4.6.1 Enumeration

Enumeration is a stereotype and its base class is “enumeration” and is defined in Modelica class constructs. It can be created in the model under the same constraints as described in section 4.5.1.

4.6.2 Function

A Modelica function with the base property “function behaviour” which is defined under Modelica class constructs. It ca be instantiated in the model under the following constraints:

• It can be created under an object element which is instance of “class” or “package” but not an instance of “behaviour”.

(34)

4.6.3 Calculation Model

A calculation model is subtype of Modelica model. The advantage of defining the calculation model is to reuse the equations. It does not represent any physical system part and it cannot have external connectors. The calculation model is de-fined in Modelica class constructs and it can be instantiated under the constraints which are defined in section 4.5.1.

4.6.4 Requirement

This stereotype is used to represent the requirement, which has textual statements or properties like id and text. The concept of textual requirement is taken and reused from Object Management Group (OMG) and System Modeling Language (SML). Requirement is defined under Modelica requirement constructs. It can be instantiated any where in the model under the common constraints which are defined in section 4.5.1.

4.6.5 Annotation

This stereotype is used for storing extra information about the model such as doc-umentation, graphics or versioning. Annotation is defined in Modelica annotation constructs. An annotation element can be instantiated inside an object element, which is an instance of “class” or “package” and not an instance of “behaviour” as well as the object element should not have stereotype “enumeration”.

4.6.6 Variable

This stereotype is used to represent the Modelica class instance of a primitive type such as real, string, boolean, integer or a subtype of modelica restricted class type. It is defined in Modelica composite constructs. A variable can be instantiated if the object element have stereotype of any one of the following classes: function, model, Modelica class, Modelica package, record, connector and operator.

4.6.7 Component

This stereotype is used to represent a Modelica component of composite type. Its base property is “property” and is defined in Modelica composite constructs. A component can be instantiated if the object element is the instance of a class and not has a stereotype function and modelica package and not an instance of behaviour.

4.7 Implementation Details

The Modelica actions are implemented by commands and handlers technique in Java.

(35)

4.7 Implementation Details 23

• Filter - When an action command should be visible

• Handler - One handler class is associated with one command as behaviour

• UI Assignment - Where should the command be included in the UI?

Contribution to Description Uri

Papyrus Application menu

Add a Modelica item, ap-plication menu of papyrus model

“org.eclipse.ui.menu” Pa-pyrus menu

4.7.1 Commands

A command in Eclipse is a declarative description defined in an XML file particu-larly in extension tab and is independent from the implementation details. Com-mands are defined via the extension point “org.eclipse.ui.comCom-mands”. One command is assigned to one action with a unique id such as the command id for the

Modelica Class action is: “com.eadsiw.modelicaml.commands.CreateModelicaClass

Command”. All 26 commands are defined in plug-in.xml in the extension tab.

4.7.2 Filters

The constraints which are described in section 4.5.1 are implemented with the help of filters. The filter takes the first object and checks the condition which is applied and then it let the action display in the menu.

The implementation of filter for the command “add a Modelica class” is given below in a screen short from the XML file:

(36)

The behaviour of each command is defined via a handler, handler is java class and all 26 java classes are in the package of: “com.eadsiw.modelicaml.handlers”.

4.7.3 Command Handler

The behaviour of each command is defined via handlers. The handler is the Java class that will be executed.

4.8 The Graphical Representation of

Implemen-tation

(37)

Chapter 5 Creating Class Components

View

5.1 What is a “view” in Eclipse?

In the Eclipse platform, the workbench can be considered as a container of many workbench windows. Inside a window there are many pages so we can consider each window as a container of pages. An editor or view is contained in these par-ticular pages. The view is used to navigate and edit information.

Some examples of most common views in Eclipse are given below:

• The Navigator view is used to display and navigate through the workspace. If you select a file in the Navigator, you can open an editor on the contents of the file.

• Once an editor is open, you can navigate the structure in the editor data using the Outline view, or edit the properties of the file contents using the properties view [18].

5.2 Why Do We Need Class Component Tree View?

When the intended user starts modeling in ModelicaML as described is section 2.4, an outline view is already created which displays information about the model browser. In complex and time continuous systems there are several classes, where some of them are inherited. Furthermore each class has a number of components and it is very hard for the modeller to remember the exact location as well as the value of every variable or component. In order to reduce this headache of remem-bering the components it is necessary to make another view inside the Papyrus perspective to provide an ease to the modeller.

(38)

26 Creating Class Components View

“Class component tree” is a view that builds the instance tree for a selected class and allows the definition of modifications in a pop up editor. Selection can be made in a diagram editor or in model browser and in the tree view all the variables and components of composite type can be viewed. The tree not only displays the values it also provide a functionality to edit these values. The editing process is called modification and it is described in chapter 5.

Class component tree view is developed as a separate plug-in which is given below: “com.eadsiw.modelicaml.classcomponentstree”. You can add this view perspective as described in figure 2.11.

5.3 How It Works

Class components tree works efficiently in the Papyrus perspective and provide an ease to the modeller while construction complex models. When a modeller clicks on the class in the model browser the class component tree shows all the components of this class in a tree view. This tree view provides a hierarchy that shows the first level components and provides a drop down menu to explore the second level components and so on until the modeller reaches the primitive type of Modelica.

In short we can say that the first level components are classes inside a model class and the leaves of this component tree are the primitive types of Modelica. A leaf can be one of the primitive types described in figure 2.13. As we know the Modelica language has 4 primitive types as well as some predefined types which are “display unit, fixed, max, min, nominal, quantity, start, state select, and unit”. In the class component tree every leaf node has a drop down menu that provides this set of predefined types.

5.3.1 Counting the inside component

Every item inside the tree display its name and after the name it shows how many components that are inside the node. This is done by implementing a special counter that counts the number of child nodes and displays it in front of the name of the parent node. The special feature of this counter is that it does not count the predefined types and hence there are no number displays in front of a leaf node. This is done because the modeller already knows that a leaf node is primitive type of the Modelica language moreover the primitive type can further be categorized in predefined Modelica types, which are mentioned above.

5.3.2 Selection in outline window

As other standard views of Eclipse platform, one of the unique features of our class component tree is that it displays the component in both cases either if you click on a model class in diagram editor or if you click on a class in a model browser.

(39)

5.4 Explanation with an Example 27

This is achieved by implementing a selection listener. The detail of the selection listener is described in the section 5.6.

5.3.3 What if you select multiple items?

If you select multiple items then the listener will neglect the previous selections and provide only the current selection to the method collecting the components from the class. This feature has two advantages; the first one is that it neglects the previous selection and fills the tree with components of the last selected and secondly it provides another feature, that is you can select either the class from model browser or diagram editor as described in section 5.3.2.

5.4 Explanation with an Example

Before going into the implementation details let us take an example in order to understand the complete working of class component tree. Let us consider figure 5.1:

Figure 5.1. Explanation of diagram editor.

This screenshot is taken from the diagram editor of Papyrus. The example of two tanks system is explained in section [19]. In the given diagram we can see that there are five major components which are:

• Source

• tank1

• tank2

• piContinuous1

(40)

The basic purpose of this diagram is to illustrate the difference between the name and type of a component. The name of the first water tank is tank1 and it is of the type tank. Type means that the modeller has already defined a special type inside the class of composite components. And same is the case with piCon-tinuous1 and piContinuous2. These are of the type connector and this connector is defined inside the class component. Up till now we have skimmed through only the first level components but each type has its own component defined in that particular class and this hierarchy is followed in depth until we reach the leaf node component which is the predefined data type of modelica language.

Let’s now go into the detail of first level components one by one.

5.4.1 Source

Source is a first level component and it has the type “Liquid source”. Now liquid source is another class that defined in package “components”. It further has three components that is a port, a variable and a function given below:

• qOut: this component has the type “Liquid Flow”

• flowLevel: This component having type Modelica Real (Primitive type) • set outgoing flow level is a function

It is very important to understand that qOut is not a primitive type compo-nent it has the type “Liquid Flow” so in out tree this will not be a leaf node it will further expand inside the Liquid Flow until we reach the primitive type. Where as in the component number 2 “flowLevel” is a primitive type variable. So in our tree it will be a leaf node. If we click on the class “Liquid Source” the output in our class component tree will show flowLevel as a primitive type and qOut as having more components inside.

This figure shows the complete picture:

(41)

5.4 Explanation with an Example 29

5.4.2 Tank1 and Tank2

The two components tank1 and tank2 have the same type “tank”. And this “tank” class is defined in the package of “components”. If we see the tank class it has 9 variables and 4 ports. The ports are even visible in figure: 5.1 but when we click on the tank class the class component tree gives he complete picture of all components inside tank. Some of them are of primitive types like flow Gain, h, maximum Volume, minimum Volume as well as some components has further components as shown in figure: 5.3.

Figure 5.3. Class Tank Components.

5.4.3 piContinuous1 and piContinuous2

The two components -piContinuous1 and piContinuous2 are of the type “PICon-tinuousController” which is defined in the package of components. If we click on the base class tree view, it will provide us all the details of its components.

In above Section: 5.5, we have seen the individual classes and this gives an idea about its implementation that a method that takes an object as a parameter and displays all the components. The recursive call of this particular method provide the functionality to just click on top level model class and then instead of checking individual classes just expand the tree drop down menu to reach the desired component. The figure 5.5 illustrates the complete hierarchy.

(42)

Figure 5.4. Class PIContinuousController Components.

Figure 5.5. Labelled Diagram with Class Component Tree View.

5.5 Implementation Details

A separate plug-in is developed for Class Component Tree which is given below:

“com.eadsiw.modelicaml.componentstree” This plug-in is also used in

mod-ification of the components with the help of the modmod-ification editor ModelicaML Xtext Modification Editor which has the code completion functionality. The mod-ification support is described in the next chapter, Chapter 5. In this chapter we focus on the implementation of the class component tree view. In the ex-tension tab of our plug-in XML file, a view has been added and for this view a class is defined. The implementation of the class id is done under the package of

“Com.eadsiw.modelicaml.componenttree.views”. The first portion of the

figure: 5.6 is a screen shot from an XML file and the lower portion is a screen shot from the source editor where the actual implementation of the class is done.

(43)

5.5 Implementation Details 31

Figure 5.6. Graphical Representation of Class Component Tree.

5.5.1 Implemented Classes

In the implementation the standard naming convention of Eclipse is used hence the package has special name starting with com and then followed by the organi-zation name after a dot sign and then the details of actual project as given below.

“com.eadsiw.modelicaml.componenttree.views”

In the figure: 5.7 all the implemented classes can be seen and the classes are pointed with a very small description of usage of the particular class. The main class that instantiates the tree uses the methods defined in other supporting classes like name sorter, content provider and view Label Provider.

(44)

32 Creating Class Components View Content Provider: The Class ViewContentProvider implements

ITreeCon-tentProvider, the purpose of ITreeContentProvider is to provide information to the viewer about the transformation of domain objects into tree items in UI tree. The tree viewer displays the child element of a parent node in UI and for this purpose it uses the following method from the content provider’s class.

• Public object getParent(object element)

Figure 5.8. Method Call

Label Provider: This class is used to provide the images and text for items

that are contained in the tree viewer. The domain object is the input argument for the label provider. The tree is initialized by tree viewer when the tree viewer calls the method: private void initialize (); // in the class component tree This method checks the selected object and if the selected element is a class then it calla another method responsible for building a tree from a class. It takes a class element as a parameter and returns an array of objects which are displayed in the form of a sorted tree items by tree viewer.

For a better understanding of these method calls please see the figure: 5.9. This figure contains the important methods calls and flow control. The names of classes are in blue and a dotted line denotes the class containing the methods. Methods are shown in white boxes.

5.6 Selection Process

In Section: 5.1, it is described what a view is (in the context of the Eclipse plat-form).In the Section: 5.5, we have seen how the implementation of Class Compo-nent Tree is done as well as the other supporting classes. The initialization of the tree is performed in such a way that first it checks the type of selection and then calls the method which generates the actual tree. It is very important to have some inside details of the selection process. That is how the selection is recognized when user clicks in the model browser or in a diagram editor?

Each workbench window has its own selection service instance. The service keeps track of the selection in the currently active part and propagates selection

(45)

5.6 Selection Process 33

Figure 5.9. Tree viewer’s Control Flow

changes to all registered listeners. Such selection events occur when the selection in the current part is changed or when a different part is activated. Both can be triggered by user interaction or programmatically [20]. This concept is used while implementing the class ComponentsTree which is the main class of the plug-in. The figure given above explains a common selection process in Eclipse platform.

Figure 5.10. Selection Service Big Picture [20]

Typically views react on selection changes in the workbench window. So we need to register an “ISelectionListener” to get notification when the current selec-tion in a window is changes. To show how the selecselec-tion listener is added in the implemented plug-in for class component tree lets have a look in the source code. This code snippet is taken from the implemented plug-in: "com.eadsiw.modelica

(46)

From the Class

public class C o m p o n e n t s T r e e extends ViewPart i m p l e m e n t s I T a b b e d P r o p e r t y S h e e t P a g e C o n t r i b u t o r

public void c r e a t e P a r t C o n t r o l( C o m p o s i t e parent ) {

viewer = new T r e e V i e w e r( parent , SWT . MULTI | SWT . H_SCROLL | SWT . V_SCROLL ); // Content Provider & Label Provider Methods are e x p l a i n e d i n Section : \ ref { Imp Sec }

d r i l l D o w n A d a p t e r = new D r i l l D o w n A d a p t e r( viewer ); viewer . s e t C o n t e n t P r o v i d e r( new V i e w C o n t e n t P r o v i d e r ()) ; viewer . s e t L a b e l P r o v i d e r( new V i e w L a b e l P r o v i d e r()); viewer . s e t S o r t e r( new N a m e S o r t e r ());

shell = parent . getShell ();

P l a t f o r m U I. g e t W o r k b e n c h(). g e t H e l p S y s t e m (). setHelp ( v iewer . getCorol () , " com . eadsiw . m o d e l i c a m l. c o m p o n e n t s t r e e. view ");

m a k e A c t i o n s (); h o o k C o n t e x t M e n u (); h o o k D o u b l e C l i c k A c t i o n (); c o n t r i b u t e T o A c t i o n B a r s (); getSite (). g e t W o r k b e n c h W i n d o w(). g e t S e l e c t i o n S e r v i c e( ). a d d S e l e c t i o n L i s t e n e r( listener ); }

Here by giving this command the selection listener has registered. In the imple-mentation of initialize () function the selection check is performed and the source code snippet is given below:

if ( sel != null ) {

if ( sel i n s t a n c e o f I S t r u c t u r e d S e l e c t i o n) {

Object first =(( I S t r u c t u r e d S e l e c t i o n) sel ). g e t F i r s t E l e m e n t (); EObject s e l e c t e d E l e m e n t = null ; if ( first i n s t a n c e o f M o d e l E l e m e n t I t e m) { s e l e c t e d E l e m e n t = (( M o d e l E l e m e n t I t e m) first ). g e t E O b j e c t (); } else if ( first i n s t a n c e o f I U M L E d i t P a r t) { s e l e c t e d E l e m e n t = (( I U M L E d i t P a r t) first ). g e t U M L E l e m e n t (); } } }

If the selection is not empty then there will be the first element of selection in the “first”. This is because we have to avoid the multiple selections and the goal of class component tree view is to show the variables of primitive as well as components of composite types when the selected element is only the class.

The entire source code can be downloaded from SVN as it will be an open source.

(47)

Chapter 6 Modification Support in

Class Component Tree

As described in Section: 5.2 the purpose of class component tree is not only dis-play the variables and components in UI, but also to provide the functionality to modify these values. The modification concept is explained in the above section. In this section we will see how the modification support is provided in the class component tree view.

In order to have a good understanding we need to take a look on the modifi-cation concept in modelica.

6.1 Inheritance

The class concept with inheritance is the key to reuse of modeling knowledge in Modelica. Modelica provides inheritance through modification via so-called mod-ifiers. This makes reuse even easier, and can be expressed very concisely. In fact, the three operations; inheritance, specialization through modifications, and object instantiation, can be expressed within a single Modelica declaration.

There are three kinds of constructs in the Modelica language in which modifi-cations can occur:

• Variable declarations.

• Short class declarations.

• Extends clause.

6.1.1 What does a modifier do

It modifies one or more declarations from an inherited class by changing some aspect(s) of the inherited declarations. The most common kind of modifier just

(48)

36 Modification Support in Class Component Tree

changes the default value or the start value in a declaration equation. Modelica provide two type of modification.

• Instance Modification

• Class Modification

In class component tree plug-in, the instance modification is supported through the concept of merging of modification. The merging of modification mean that the In order to understand the modification concept in modelica let us look at the following example which is described in [22], [23].

We have four classes

• C1 having one variable of real type • C2 having two variable of real type • C3 extends C2 and C1

• C4 extends C3

(49)

6.2 Features of Class Component Tree View 37 Variables Default Values X1 None X2 22 X3.a 33 X4.b 4 X4.c 44 X5.a X3.a a 55 b 66 c 77 Table 6.1. Object of C4.

The above example is taken from [22], [23]. Merging of Modification b=66, b=6, The Result is b=66

In the two tank example [19], we have seen that we have first level components and each component is of composite type. This means that the component is of the type of another class, that class becomes the second level component and so on. If we consider the example of “twotankssystem” [19], we can see that picountinuous1 is a component of composite type and it has the type “PIContinuousController”. If there is a variable declared or modified in the PIContinuousController and if we modify the same variable in the class “picountinuous1” then this modification value will always overwrite the first modification. This concept is same for all the components so in short we can say that first level modification value (the value modified on the first level components) will always has highest priority and this value will be the final value of that component. The previous modifications have no worth anymore in the model. The concept of first level components and modification is graphically shown in the following figure: 6.2.

6.2 Features of Class Component Tree View

The class component tree view provide a menu if you right click on a component. In the menu we can perform the following actions.

• Edit/Modify

• Delete the previous modification

• Add to class

(50)

38 Modification Support in Class Component Tree

Figure 6.2. Components Level.

6.2.1 Information of component

The information about the components gives a feasible view in a dialog box which describes about the component path, type and declaration. The path of compo-nent means its hierarchy in the tree which is denoted in dot notation. Each dot denotes the next level. Type describes that weather the components is of primitive type or a composite type. The information also includes the declaration as well as the class name in which this value has overwritten.

Figure: 6.3 shows a screen short of the information about the component ref.

(51)

6.2 Features of Class Component Tree View 39

6.2.2 How can we modify the values

Select the component from the class components tree and right click on it, then select Edit from the right click menu. The popup window let able to modify the value. For example if we want to change the value of a Variable “ref” then it can be seen in the figure below.

Figure 6.4. Modification editor.

The modification concept is implemented in the class “Modificationmanager.java” described in figure: 5.7. For a deep knowledge about the implementation you can review source code.

(52)

(53)

Chapter 7 Conclusions and Future

Work

7.1 Conclusion

A Model is the representation of a real world system. The level of understanding of a model depends upon the level of elaboration. For a good representation of a system or simply for a good Model, the modeling tool should provide adequate support like contextual interfaces, the ability to build a logical model, provide ease of selecting features/functions and other related characteristics which can represent different components of a system. The work done in this master thesis was based on providing ease to the modeller. The functionality of an existing tool is enhanced according to the requirement. Effort was made to improve overall usability, model formatting and layout. Now a modeller can easily view the class/-component hierarchy and can also modify the class/-components value. One interesting feature added is that the component of a class will only be visible in the menu items if it is related to a particular class. Although these features improved the Modelica modeling environment but this improvement in an ongoing process and there are some desired features which are not achieved yet.

7.2 Future Work

There is a lot of work I wished to do in this time slot but now it will be done as my future work.

7.2.1 ModelicaML Perspective Configuration

ModelicaML is a powerful modeling language with its unique features and integra-tion of UML and SysML. But there is still need for work on the feasibility issues of ModelicaML. This means that the initial setup should be user friendly and short.

(54)

42 Conclusions and Future Work

So in order to achieve this target a dedicated perspective for ModelicaML is es-sential.

The perspective will be automatically configured and there will be no need to perform the whole process described in chapter 2. The desired perspective should look like this.

Figure 7.1. Desired Perspective.

7.2.2 OMC Communication

The target of interactive integrated communication between ModelicaML modeling tool and OMC has not yet achieved, which means that so far there is no integrated environment has been developed that facilitates a tight communication between ModelicaML modeling tool and OMC due to shortage of time. This work will be considered as a future work.

(55)

Chapter 8 Appendix

Here is the source code for the above mentioned handler is given below as a sample for a better understanding.

package com . eadsiw . m o d e l i c a m l. handlers ; import java . util . C o l l e c t i o n s;

import java . util . List ;

import org . eclipse . core . commands . A b s t r a c t H a n d l e r; import org . eclipse . core . commands . E x e c u t i o n E v e n t; import org . eclipse . core . commands . E x e c u t i o n E x c e p t i o n; import org . eclipse . core . runtime . I A d a p t a b l e;

import org . eclipse . core . runtime . Platform ; import org . eclipse . emf . common . command . Command ;

import org . eclipse . emf . common . command . C o m p o u n d C o m m a n d; import org . eclipse . emf . common . notify . N o t i f i c a t i o n;

import org . eclipse . emf . common . notify . impl . N o t i f i c a t i o n I m p l; import org . eclipse . emf . common . util . EList ;

import org . eclipse . emf . ecore . EObject ;

import org . eclipse . emf . t r a n s a c t i o n. R e c o r d i n g C o m m a n d;

import org . eclipse . emf . t r a n s a c t i o n. T r a n s a c t i o n a l E d i t i n g D o m a i n; import org . eclipse . jface . dialogs . M e s s a g e D i a l o g;

import org . eclipse . jface . viewers . I S e l e c t i o n;

import org . eclipse . jface . viewers . I S t r u c t u r e d S e l e c t i o n; import org . eclipse . papyrus . core . utils . B u s i n e s s M o d e l R e s o l v e r; import org . eclipse . papyrus . core . utils . E d i t o r U t i l s;

import org . eclipse . papyrus . diagram . common . e d i t p a r t s. I U M L E d i t P a r t; import org . eclipse . swt . widgets . Shell ;

import org . eclipse . swt . widgets . Text ; import org . eclipse . ui . P l a t f o r m U I;

import org . eclipse . ui . handlers . H a n d l e r U t i l; import org . eclipse . uml2 . uml . Class ;

import org . eclipse . uml2 . uml . C l a s s i f i e r; import org . eclipse . uml2 . uml . Comment ; import org . eclipse . uml2 . uml . Element ; import org . eclipse . uml2 . uml . Model ; import org . eclipse . uml2 . uml . Property ; import org . eclipse . uml2 . uml . Package ; import org . eclipse . uml2 . uml . S t e r e o t y p e; import org . eclipse . uml2 . uml . U M L P a c k a g e; import com . eadsiw . m o d e l i c a m l. A c t i v a t o r;

public class C r e a t e M o d e l i c a C l a s s H a n d l e r extends A b s t r a c t H a n d l e r {

ModelicaML Graphical Modeling Environment Based on Eclipse MDT Papyrus

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

ModelicaML Graphical Modeling Environment

Based on Eclipse MDT Papyrus

by

Imran Hakam

LIU-IDA/LITH-EX-A—11/004—SE

2011-03-03

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Linköping University Electronic Press

Upphovsrätt

Copyright

© Imarn Hakam

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

ModelicaML Graphical Modeling Environment

Based on Eclipse MDT Papyrus

ModelicaML Graphical Modeling Environment

Based on Eclipse MDT Papyrus

Examensarbete utfört i Datavetenskap

vid Tekniska högskolan i Linköping

av

Abstract

The ModelicaML graphical Modeling Language and Modelica/UML profile is alanguage for the

description of continuous-time and discrete-time/event-based system dynamics. Modelica ML

uses Papyrus as modelling tool implementation platform which is used for editing models. These

models may be expressed in UML with optional textual statements in Modelica as action

language code. For the new version ModelicaML 2.0, the need for support in the new Papyrus

M1 version was essential. In this master thesis project, new plug-in functionality was developed

that has enhanced the existing functionality of the ModelicaML modeling environment within

the Papyrus Eclipse plug-in. This includes handling Modelica modifiers as well as new views

and component tree views which provides complete list of components for a selected class.

Dedication

I would like to dedicate my thesis work to my loving parents, affectionate Taya ge,

devoted wife, considerate brother, caring sisters and other kind family members…

Acknowledgments

The special thanks go to my supervisors, Mr. Wladimir Schamai and Dr. Mohsen Torabzadeh

Tari. The supervision and support that they gave me with their helping nature truly help the

progression and smoothness of my thesis work.

I radiate a lot of confidence while working at EADS Innovation Works it was very nice

experience and I am thankful to my supervisors for providing me this opportunity.

I would like to thank my examiner Professor Peter Fritzon for his help and timely advices during

my thesis work.

My grateful thanks also go to all my friends not only for the support in curricular activities but

also for the hospitality in Linköping and Hamburg. I have spent a very good time of my life with

my friends in Sweden and Germany specially with Mr. Adnan Waheed, Mr. Muhammad Ayaz

Khan, Mr. Molana Sajid Hussain, Mr. Mansoor Munib, Mr. Mati Ullah Khan W, Mr. Muzammil

Zareen, Mr. Farhan Khan, Mr. Azam Zia, Mr. Ahsan Rasool,Mr. Kamran Zafar,Mr. Syed Zahid

Ali,Mr. Syed Yasir Imtiaz,Mr. Kamran Hakam, Mr. CH.Hassan Riaz(Late), Mr. Imran Khan and

those not listed here but listed in my mind.

Contents

Chapter 1

Background

1.1

Modelica Overview

1.2

OpenModelica

1.3

ModelicaML

1.4

Purpose of Thesis

1.4.1

Pre-Study Phase

1.4.2

Implementation Phase

Chapter 2

ModelicaML Papyrus MDT

GUI

2.1

Modeling, Validation, and Simulation

2.2

ModelicaML Specific Views

2.2.1

Model Browser