Institutionen för datavetenskap

Transcription

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 Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping

2 Linköping University Electronic Press Upphovsrätt Copyright 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 universitet SE Linköping, Sweden Linköpings tekniska högskola Linköpings universitet Linköping

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: Handledare: Prof. Peter Fritzson ida, Linköpings universitet Dr. Mohsen Torabzadeh-Tari ida, Linköpings universitet Mr. Wladimir Schamai EADS IW, Germany Linköping, 3 March, 2011

5 Avdelning, Institution Division, Department Division of Computer System Department of Computer and Information Science Linköpings universitet SE Linköping, Sweden Datum Date Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LIU-IDA/LITH-EX-A-11/004-SE Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version 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 language 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 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 Keywords Modelica, Papyrus

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. vi

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 vii

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. viii

9 Contents 1 Background Modelica Overview OpenModelica ModelicaML Purpose of Thesis Pre-Study Phase Implementation Phase ModelicaML Papyrus MDT GUI Modeling, Validation, and Simulation ModelicaML Specific Views Model Browser Properties View Diagram Editors Palette ModelicaML Class Component tree Modelica Perspective Add ModelicaML Specific Views How to Create Model Structure How to Set the Type in ModelicaML Design of tools Papyrus Modelica ML Class Component Tree Plug-in Block Diagram Modelica Perspective Required Installations Table Model Structure Description of Stereotypes and Utilization in Model Package Modelica Class Modelica Restricted Classes ix

10 x Contents Modelica Package Operator Model Block Connector Type Record A common Constraint Constraint Stereotypes and Filtered Constraints Enumeration Function Calculation Model Requirement Annotation Variable Component Implementation Details Commands Filters Command Handler The Graphical Representation of Implementation Creating Class Components View What is a view in Eclipse? Why Do We Need Class Component Tree View? How It Works Counting the inside component Selection in outline window What if you select multiple items? Explanation with Example Source Tank1 and Tank picontinuous1 and picontinuous Implementation Details Implemented Classes Selection Process Modification Support in Class Component Tree Inheritance What does a modifier do Features of Class Component Tree View Information of component How can we modify the values

11 Contents xi 7 Conclusions and Future Work Conclusion Future Work ModelicaML Perspective Configuration OMC Communication Appendix 43 Bibliography 47

12

13 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, electrical, 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 Modelica tool will have enough information to decide that automatically. Modelica is designed such that available, specialized algorithms can be utilized to enable efficient handling of large models having more than one hundred thousand equations [1]. Modelica community contributed its efforts in an efficient way for the sequential 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, Now in March, 2010 the Modelica 3.2 has released. Modelica community is working hard to provide 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 1

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 description of time-continuous and time-discrete/event-based system dynamics. ModelicaML 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 modelling 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 introduces some new features which were not supported in the ModelicaML version 1. ModelicaML uses Papyrus UML as a modelling tool since papyrus UML introduces 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 dedicated perspective for Modelica. The context menu, pallets, and diagrams from the previous version of ModelicaML were migrated into new version and some new features were implemented. The details of these features are comprehensively explained in chapters 4, 5 and 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 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 Implementation Phase All the implementation work has done at EADS Innovation Works Hamburg Germany [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 dynamics. 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 create, 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]. 5

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 constraints 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 workflow. 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 example 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. After we switched the perspective the next step is to Create ModelicaML

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 example 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. model.di file is the diagram file. This can only be edited by Papyrus UML

20 8 ModelicaML Papyrus MDT GUI 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 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 10 ModelicaML Papyrus MDT GUI 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 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 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 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 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 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 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) 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 differ-

24 12 ModelicaML Papyrus MDT GUI Figure 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 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 Papyrus 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 explained in Chapter 3.

25 2.5 How to Set the Type in ModelicaML 13 Figure Adding views. The graphical representation is given below in a screenshot. Figure 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 Modelica Boolean

26 14 ModelicaML Papyrus MDT GUI Figure Selecting the type. We can add more diagrams like activity diagram, conditional algorithm/equation 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. 15

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 capabilities 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 Block Diagram Figure 3.2. Block diagram of Papyrus MDT and supported plug-ins.

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 Modelica Perspective The Modelica perspective is another separate plug-in providing a dedicated perspective 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. Figure 3.3. Modelica perspectives.

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 Eclipse 3.6 (Helios) Papyrus MDT Eclipse plug-in ModelicaML Eclipse plugins Acceleo Eclipse plug-in Modelica Development Tooling (MDT) Eclipse plug-in Source updates/index.php /tools/ /tools/133 Table 3.1. Required installations.

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 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 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. 19

32 20 Model Structure 4.4 Modelica Restricted Classes 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 Operator This stereotype corresponds to Modelica s restricted class Operator. The operator 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 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, algorithm, sections, connectors, input states, outputs states 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 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 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 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 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 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 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 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 22 Model Structure 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 defined in Modelica class constructs and it can be instantiated under the constraints which are defined in section 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 Annotation This stereotype is used for storing extra information about the model such as documentation, 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 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 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. Commands - One for each action as a declarative description

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, application menu of papyrus model org.eclipse.ui.menu Papyrus menu Commands A command in Eclipse is a declarative description defined in an XML file particularly in extension tab and is independent from the implementation details. Commands are defined via the extension point org.eclipse.ui.commands. 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 Filters The constraints which are described in section 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: Figure 4.1. Implementation of filters.

36 24 Model Structure 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 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 Implementation Figure 4.2. Modelica class command and handler.

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 particular 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 remembering the components it is necessary to make another view inside the Papyrus perspective to provide an ease to the modeller. 25

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 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 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 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 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 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 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 picontinuous2

40 28 Creating Class Components View 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 picontinuous1 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 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 component 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: Figure 5.2. Class Component Tree Position while Clicking on Liquid Source.

41 5.4 Explanation with an Example 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 picontinuous1 and picontinuous2 The two components -picontinuous1 and picontinuous2 are of the type PIContinuousController 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 30 Creating Class Components View 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 modification of the components with the help of the modification editor ModelicaML Xtext Modification Editor which has the code completion functionality. The modification 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 extension 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 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 organization 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. Figure 5.7. Package <com.eadsiw.modelicaml.componenttree.views>.

44 32 Creating Class Components View Content Provider: The Class ViewContentProvider implements ITreeContentProvider, 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 platform).in the Section: 5.5, we have seen how the implementation of Class Component 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 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 selection in a window is changes. To show how the selection 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 ml.componentstree"

46 34 Creating Class Components View From the Class public class ComponentsTree extends ViewPart implements I TabbedPropertySheetPage Contributor public void createpartcontrol( Composite parent ) { viewer = new TreeViewer( parent, SWT. MULTI SWT. H_SCROLL SWT. V_SCROLL ); // Content Provider & Label Provider Methods are explained in Section : \ ref{ Imp Sec} } drilldownadapter = new DrillDownAdapter( viewer ); viewer. setcontentprovider( new ViewContentProvider()); viewer. setlabelprovider( new ViewLabelProvider()); viewer. setsorter( new NameSorter()); shell = parent. getshell (); PlatformUI. getworkbench(). gethelpsystem(). sethelp ( viewer. getcorol (), " com. eadsiw. modelicaml. componentstree. view "); makeactions(); hookcontextmenu(); hookdoubleclickaction(); contributetoactionbars(); getsite (). getworkbenchwindow(). getselectionservice(). addselectionlistener( listener ); Here by giving this command the selection listener has registered. In the implementation of initialize () function the selection check is performed and the source code snippet is given below: if ( sel!= null) { if ( sel instanceof IStructuredSelection) { Object first =(( IStructuredSelection) sel). getfirstele ment(); EObject selectedelement = null; if ( first instanceof ModelElementItem) { selectedelement = (( ModelElementItem) first ). geteobject(); } else if ( first instanceof IUMLEditPart) { selectedelement = (( IUMLEditPart) first ). getumlelement (); } } } 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 display 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 modification 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 modifiers. 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 modifications can occur: Variable declarations. Short class declarations. Extends clause 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 35

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 Figure 6.1. Graphical representation of classes.

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: 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 Get information about the selected component

50 38 Modification Support in Class Component Tree Figure 6.2. Components Level 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 component 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. Figure 6.3. Information of the component.

51 6.2 Features of Class Component Tree View 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 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 ModelicaML Perspective Configuration ModelicaML is a powerful modeling language with its unique features and integration 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. 41

54 42 Conclusions and Future Work So in order to achieve this target a dedicated perspective for ModelicaML is essential. 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 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.