Софийски университет „Св. Климент Охридски”
Факултет по Математика и Информатика
Катедра „Софтуерни технологии”
Специалност „Информатика”
Специализация „Софтуерни технологии”
ДИПЛОМНА РАБОТА
Тема:
Разработване на графичен редактор за модела
REMES
Дипломант:
Иво Лазаринов Петков, Ф№ М21874
Научен ръководител: доц. Силвия Илиева,
катедра „Софтуерни технологии”, ФМИ
Консултант:
Анета Вулгаракис, университет
„Малардален”, Швеция
Master of Science Thesis
Ivo Lazarinov Petkov
GUI for component behavior – based on REMES
Mälardalen Research and Technology Centre
Thesis supervisor: Aneta Vulgarakis
Thesis examiner: Cristina Seceleanu
{
aneta.vulgarakis
,
cristina.seceleanu}@mdh.se
Abstract
Models and components have become an indispensable part in the development of embedded systems. They reduce the complexity of embedded systems and provide a formal ground on which analysis and synthesis are performed. ProCom is a component model intended for embedded systems design. It has been developed within PROGRESS, a large research project aiming to provide component-based techniques for the development of embedded systems. The behavior of ProCom components is specified in the REMES modeling language. REMES is used for specification for both functional and extra-functional behavior of the components (timing, resource usage, reliability etc.). Without proper tool support, the use of models and components is very difficult. Such tool support is typically integrated in an Integrated Development Environment (IDE), which is simply a framework containing a programming environment. This thesis provides an implementation of a GUI for component behavior modeling based on REMES as a plug-in for the Progress IDE.
Keywords
Component behavior, Embedded Systems, Resource usage, PROGRESS, IDE, Eclipse RCP, GUI, Models
Table of Contents
Definitions and acronyms ... 8
1. Introduction ... 9
1.1. Purpose ... 9
1.2. Benefits of the implementation ... 10
1.3. Outline of the thesis ... 10
2. Background ... 11
2.1. Eclipse ... 11
2.1.1. Rich Client Platform ... 11
2.2. Eclipse Modeling Framework ... 12
2.2.1. EMF ecore Model ... 13
2.2.2. EMF genmodel Model ... 13
2.2.3. EMF generated plugins ... 14
2.3. Graphical Editing Framework... 14
2.4. Graphical Modeling Framework ... 15
2.4.1. GMF Introduction ... 15
2.4.2. GMF Dashboard ... 16
2.4.3. Domain and Domain Gen Models ... 16
2.4.4. Graphical Definition Model ... 16
2.4.5. Tooling Definition Model ... 17
2.4.6. Mapping Model ... 17
2.4.7. Diagram Editor Generator Model ... 18
3. Introduction to REMES ... 19 3.1. Introducing REMES... 19 3.2. Classes of Resources ... 19 3.3. REMES Elements ... 20 3.3.1. Modes ... 20 3.3.2. Edges ... 22 3.4. Mode execution. ... 23
4. REMES Editor Design analysis ... 24
4.1. REMES EMF Ecore meta-model ... 24
4.2. REMES Tooling Definition Model ... 26
4.3. REMES Graphical Definition Model... 27
4.4. REMES Mapping Model ... 27
4.5. REMES Diagram Editor Generation Model ... 27
4.6. REMES Views functionality... 27
4.7. REMES Diagram Editor Code customizations ... 27
5. REMES GUI Technical Realization ... 29
5.1. REMES EMF Model definition ... 29
5.2. REMES GUI Icons and color conventions. ... 40
5.3. REMES Tooling Definition Model implementation... 42
5.4. REMES Graphical Definition model implementation ... 44
5.4.1. Edge Figures graphical definition. ... 44
5.4.2. Modes Figures graphical definition. ... 47
5.5. REMES Mapping model implementation ... 50
5.5.2. Link Mappings ... 52
5.5.3. OCL Constraints for the Link Mappings ... 53
5.6. REMES Diagram Editor Generation Model ... 55
5.7. REMES Diagram plug-in code generation ... 56
5.8. REMES Diagram generated plug-in problems and customizations ... 56
5.8.1. Edges starting point decorations are huge circles ... 57
5.8.2. Labels representing Mode’s properties must the right icons ... 58
5.8.3. Multi-line properties are not viewed as multi-line labels ... 58
5.8.4. Edges starting and ending points are with random positions ... 60
5.9. REMES Diagram Views implementation ... 64
6. REMES GUI Preview ... 68
6.1. REMES GUI Installation ... 68
6.2. REMES GUI Overview ... 68
6.3. REMES GUI Usage Guide lines ... 69
6.3.1. Create new REMES Diagram ... 69
6.3.2. Create REMES Diagram Modes and Edges ... 70
7. Conclusions and future work ... 72
8. References ... 73 Appendix 1: User’s guide ... Error! Bookmark not defined.
List of Figures and Tables
Figure 2-1 Eclipse RCP ... 11
Figure 2-2 GMF Dashboard ... 16
Table 3-1 Composite Mode Node element ... 20
Figure 3-2 Composite Mode Node element ... 21
Table 4-1 REMES Containment Definition ... 24
Table 4-2 REMES Edges Definition ... 26
Figure 5-1 RemesDiagram annotated interface ... 30
Figure 5-2 Mode annotated interface ... 30
Figure 5-3 Edge annotated interface ... 32
Figure 5-4 InitEdge interface ... 32
Table 5-5 Edge interfaces matrix ... 33
Figure 5-6 ExitConditionalSubEdge interface definition ... 33
Figure 5-7 CompositeMode interface ... 34
Figure 5-8 SubMode interface ... 35
Figure 5-9 ConditionalConnector interface ... 36
Figure 5-10 FromCompositeMode interface ... 36
Figure 5-11 ToCompositeMode interface ... 37
Figure 5-12 REMES ecore model ... 37
Figure 5-13 SubMode’s resourceClassC field properties in the genmodel ... 38
Figure 5-14 EMF Code generation ... 39
Figure 5-15 EMF generated plug-ins structure ... 40
Table 5-16 REMES GUI icons ... 41
Figure 5-17 REMES Tooling Model definition ... 43
Figure 5-18 REMES Palette in the GUI ... 44
Figure 5-19 EntryEdge figure and its properties in the Grahpical model ... 46
Figure 5-20 CompositeMode figure and its properties in the Graphical model ... 48
Figure 5-21 Composite Mode Compartment definition ... 49
Figure 5-22 Composite Mode Node element ... 49
Figure 5-23 Conditional Connector Grid Layout definition ... 50
Figure 5-24 CompositeMode Top Reference Node Mapping definition ... 51
Figure 5-25 Composite Mode Node mapping element ... 51
Figure 5-26 CompositeMode Name Label Mapping definition ... 52
Figure 5-27 CompositeMode Compartment Mapping definition ... 52
Figure 5-28 InternalEdge Mapping definiton ... 53
Table 5-29 Definitions and descriptions of Edge’s constraints. ... 55
Figure 5-30 REMES Diagram generated code structure ... 56
Figure 5-31 Edge source decoration code modifications ... 58
Figure 5-32 Setting Label’s icon code modification ... 58
Figure 5-33 Setting Label’s text wrap property code modifications ... 59
Figure 5-34 Multi-line label text editor code modification ... 59
Figure 5-35 FixedConnectionAnchor class ... 61
Figure 5-36 CompositeMode’s getConnectionAnchor helper method ... 62
Figure 5-37 CompositeMode’s refreshConnections helper method ... 62 Figure 5-38 CompositeMode’s code modifications for using FixedConnectionAnchors 63
Figure 5-39 CompositeMode’s code modifications for refreshing connections ... 64
Figure 5-40 Remes.diagram plug-in extensions definition in XML format ... 66
Figure 5-41 IRemesViewsFilter interface ... 66
Figure 5-42 RemesViewAllFilter class implementation ... 66
Figure 5-43 RemesViewTimingFilter class implementation ... 67
Figure 5-44 REMES Views’s processEditParts method implementation... 67
Figure 6-1 REMES GUI Runtime... 69
Figure 6-2 REMES GUI Runtime... 70
Figure 6-3 REMES GUI Runtime... 70
Definitions and acronyms
REMES REsource Model for Embedded System GUI Graphical User Interface
IDE Integrated Development Environment XML eXtensible Markup Language GMF Graphical Modeling Framework
EMF Eclipse Modeling Framework GEF Graphical Editing Framework
1. Introduction
The importance of resource awareness in embedded systems is growing. The limited availability of computing resources is preventing the introduction of new product features and applications, especially in areas where high-performance and reliable embedded systems are required. Resources include energy, computational power, memory, and hardware components such as buses, input/output ports, etc. The systematic analysis of the resource consumption of an embedded system must include ways of semantic representation of various types of resources, be they of continuous, monotonic type (like energy), of non-monotonic type (like memory), or of discrete nature (e.g. I/O ports). A representative analysis goal is to answer the feasibility question: does the composition of the worst-case resource requirements of components stay within the available resources provided by the implementation platform? In practice, it may often be necessary to replace a component with another one having the same functionality; yet using a more sophisticated control algorithm that requires bigger memory resources. Alternatively, if we assume a repository of models, the designer might need, at some point, a refined component model, with modified behavior or more efficiently implementable data structures.
The model, called REMES, is tailored for embedded systems, but it is also suitable for reactive systems. It provides support for discrete and continuous abstract resources characterized further by the way in which they are consumed and released, and by whether they can be referred to, or not. A number of generic resources can be modeled in this way, including memory, ports, power, CPU, and buses. As such, the characterized and classified abstract resource types are not tied to any particular formal semantical interpretation.
The main purpose of REMES is to narrow the gap between architectural modeling (e.g., architecture description languages (ADLs)) and formal analysis models (such as priced timed automata) and to provide predictable design of embedded systems.
The main goal of the master thesis is to build a GUI for component behavior based on REMES:
- Design an easy-to-use graphical user interface (GUI) that allows designing the REMES modes.
- The GUI should contain:
o Palette with REMES elements from which the user can drag and drop the elements into the mode editor;
o Project explorer (file system) where you store the designed modes in XML format ;
o Some way for the user to click on the modes and edit their properties (such as name of invariants and their values);
o Possibility for the user to see different views (Functional, Timing or Resources usage)
- Expected outcome:
o Design a prototype of the GUI, implemented in Eclipse as a plug-in for the Progress IDE;
o Thesis report describing the work;
1.2. Benefits of the implementation
This thesis contains information about the structure, semantic and usage of REMES and implementation of an easy to use visual editor for REMES diagrams. This editor will be of great use for anyone interested in modeling embedded systems. It forms the basis for future development of analyzing, emulation or documentation tools.
1.3. Outline of the thesis
The first part of this document elaborates a theoretical background of the problematic area. Section 2 presents the Eclipse platform and related technologies for model based graphical editors building. Section 3 explains the essence of REMES model. The analysis of the design for the GUI editor is presented in section 4.
The second part of the document provides the technical realization of the REMES GUI in a step by step way – Section 5. Section 6 presents the ready to use product.
To emphasize source code elements italic font style will be used.
2. Background
This chapter presents the basic concepts and notions used in the thesis. It gives a brief definition of the Eclipse technologies, on which in based the PROGRESS IDE. It also presents the tools, which the Eclipse platform provides for development of Graphical editors for models.
2.1. Eclipse
Eclipse is an open source software development project, started with the aim to provide a highly integrated tool platform. It consists of a core project, which includes a generic framework for tool integration, and a Java development environment. Other projects extend the core framework to support specific kinds of tools and development environments. Everything in Eclipse, besides a small portion of the runtime library (kernel), is realized as plug-ins. The plug-in design makes Eclipse extensible and provides very easy way for adding new features which can work together.
2.1.1. Rich Client Platform
The minimal set of plug-ins needed to build a rich client application is collectively known as the Rich Client Platform [2].
Figure 2-1 Eclipse RCP
• The Platform runtime provides support for plug-in development through extension points and extensions.
• The Standard Widget Toolkit (SWT) is a widget toolkit which provides a portable API and tight integration with the native OS GUI.
• JFace is a UI toolkit that provides helper classes for developing common UI features on top of the SWT library.
• The Workbench, based on the Runtime, SWT and JFace, provides contribution-based UI extensibility, defining a powerful UI paradigm with windows, perspectives, views, editors, and actions.
• The Workspace provides a good base for keeping projects organized.
2.2. Eclipse Modeling Framework
EMF is a Java framework and code generation facility for building tools and other applications based on a structured model. EMF provides an easy way in turning models into efficient, correct, and easily customizable Java code at a very low cost of entry. EMF is part of the Tools project of Eclipse [4].
EMF consists of two fundamental frameworks:
• The Core framework - provides basic generation and runtime support to create Java implementation classes for a model.
• EMF.Edit - extends and builds on the core framework, adding support for generating adapter classes that enable viewing and command-based (undoable) editing of a model, and even a basic working model editor.
Some of the benefits which EMF provides are:
• Code generation. The code required for creating fully working data model is auto-generated, based on the model definition. The code EMF generates is easy to read and support as it allows changes to be made without loosing them after any following regeneration.
• Metadata. The metadata of the model allows defining additional calls to the model for additional data or runtime bases information. EMF also
provides interfaces for runtime modifications of the metadata of the model.
• Persistence support. Serialization to XML and XML Schema Validation allows saving, loading and validating the model data by default.
• Model change notifications, so if required additional actions to be taken on model modifications.
• Editors. There are two generated editors for the mode. The one is for the model data itself and the second is for the model metadata.
• EMF provides the foundation for interoperability with other EMF-based tools and applications.
2.2.1. EMF ecore Model
EMF model, called ecore, is a small subset of the things that can be modeled in UML and more specifically simple definitions of the classes and their attributes and relations, for which a full-scale graphical modeling tool is unnecessary [5]. The canonical form of models definition in EMF is XMI (XML Metadata Interchange), but there are several other ways to get a model to this form:
• Exporting XMI from any modeling tool. This approach is most desirable if there are already in use full-scale modeling tools
• Annotating Java interfaces with model properties. This approach provides pure Java programmers a low-cost way to get the benefits of EMF and its code generator using just a basic Java development environment.
• Using XML Schema to describe the form of a serialization of the model. • Reflective API which allows working with the model more generically.
2.2.2. EMF genmodel Model
In addition to the ecore model, there is the genmodel. It adds platform specific information to the ecore model, which contains only domain specific information. The genmodel is mandatory for the code generation. It allows modifying the default generation options.
2.2.3. EMF generated plugins
The EMF produces the following plugins:
• EMF.model – provides full implementation of the ecore model as well as its persistence functionality.
• EMF.editor – provides implementation of an Eclipse based UI editor for the domain ecore model.
• EMF.edit - provides independent layer for communication between the EMF.model and EMF.editor i.e. between the model and the editor. This layer behaves as adapter, label provider, tree view model provider, supports commands etc.
2.3. Graphical Editing Framework
The Graphical Editing Framework provides the functionality to easily develop rich graphical representations and editors for existing models. All graphical visualization is based on the Draw2D framework, which is a standard 2D drawing framework based on SWT. The editing possibilities of the GEF allow to be built graphical editors for nearly every model. With these editors, it is possible to do simple modifications to the model, like changing element properties or complex operations like changing the structure of the model. All these modifications can be handled in a graphical editor using very common functions like drag and drop, copy and paste, and actions invoked from menus or toolbars [6]. As GEF is based on MVC architecture, every GEF-based application uses a model to represent the state of the diagrams being created and edited. GEF allows usage of any objects as model objects within the application; however, using an EMF model provides some advantages over using arbitrary objects:
1. EMF code generation facilities produce consistent, efficient and easily customizable implementations of the model objects.
2. The MVC architecture used by GEF relies on controllers that listen for model changes and update the view in response. If an EMF model is used, notification of model change is already in place, as EMF provides notification framework by default.
3. The state of the model implementation is always consistent – all references are updated on change.
The editors based on EMF.edit are one-to-one TreeViewer representation of the model and in some cases it is required to create an editor which is more loosely coupled with the model. This is often the case when it is required to use a graphical notation that may hide some details of the underlying model, or may need to introduce different structure of the model, for visualization purposes. This makes using EMF in GEF applications very common scenario.
2.4. Graphical Modeling Framework
2.4.1. GMF Introduction
The use of EMF and GEF together for building Eclipse based editors is quite common, but it has its drawbacks as: its time consuming, editors do not have extensible features, editors need to be designed manually from scratch and also such editors do not provide extensive support for entire EMF framework. That is why GMF comes in place. GMF combines both GEF and EMF for designing powerful graphical editors on fly. GMF is based on GEF and utilizes all the features of EMF and also provides an editor with many re-usable components like zoom, print, print preview, fonts, colors, etc., so the main efforts can be focused on the business logic [7].
GMF consists of two main components:
• Generation framework - allows defining custom diagram structure based on few definition models. Domain Model definition is the EMF designed model. Graphical definition defines how exactly the diagrams of their respective models look on canvas. Tooling definition defines the tools on the palette. Domain Mapping unites all these three definition models. After the Mapping is over, GMF provides user with a Generator model that allows implementation details to be defined for generation phase. • Runtime framework – provides on runtime the bridge between the diagram
model and the domain models. It also provides for the persistence and synchronization of both. The runtime not only allows easier integration between EMF and GEF, but provides additional services like: transactions
support, extended meta-modeling facilities, notation meta-model, variability points used for runtime extensibility of generated code, etc.
2.4.2. GMF Dashboard
GMF Dashboard is a view which guides the user through the flow of creating a GMF based editors (Figure 2-2).
Figure 2-2 GMF Dashboard 2.4.3. Domain and Domain Gen Models
The Domain and Domain Gen Models are the ones produced by EMF (ecore and genmodel).
2.4.4. Graphical Definition Model
The Graphical Definition model is used to define visual parts of the editor i.e. the GEF figures for Nodes, Connections, Compartments, Labels and other. Editor element figures can be composed from standard GEF figures and from custom figures. All custom figures must implement the IFigure interface. Either standard GEF layouts or custom layouts are available to arrange nested figures in accordance with attached layout data. The information defined in this model is enough for the generation of the code for the described composite figures. Generated figures are later instantiated by the diagram editor and are used for visualizing diagram elements. The graphical definition model can
fully describe composite figure structures, but if there is a requirement for some specific behavior, it can be accomplished by implementing it for the custom figures or by customizing the generated code. Graphical Definition model defines only graphical elements and has no clue about the domain-model.
2.4.5. Tooling Definition Model
Tooling definition model is important part of the diagram editor description. It is similar to the graphical definition model and it is also independent of the domain model. In the tooling definition model are created the definitions of diagram palette items, additional main menu items, popup menus and other UI actions. By default the palette contains standard tools like Selection Tool, Zoom Tool and Creation Tool. The tools can be organized into groups and custom icons can be attached to them. The PaletteFactory code is generated based on the information defined in this model.
2.4.6. Mapping Model
The Mapping Model comes into place in order to bind the two domain model independent Graphical and Tooling definitions with the underlying EMF model. In this model elements like CanvasMapping, NodeMapping and LinksMapping can be created. These mappings are used to fully describe the diagram surface, diagram nodes, and diagram links, respectively. Each mapping binds the domain model element from EMF model with its corresponding visual representation from Graphical Definition model, and to a necessary set of tools in the Tooling model.
LabelMappings can be defined for LinkMappings and NodeMappings in order some attributes of the domain model to be visualized as diagram labels. The LabelMapping binds a Label element to an attribute from the domain model.
NodeMappings define CompartmentMappings, which are used to logically group a set of child nodes inside compartment figure.
In Node and LinkMappings is stored all the necessary information to present some particular semantic model element as a diagram link or a node with labels and compartments. This information is not enough to embed one diagram node into another. ChildReference comes into place to solve this problem. Each Canvas or NodeMapping can contain arbitrary number of ChildReferences. A ChildReference used to point to
another NodeMapping which could be located in the Canvas or NodeMapping. Additionally, a ChildReference stores the necessary information for getting corresponding semantic children and storing a newly created one. Every Mapping model contains complete diagram description while Tooling and Graphical models only describe some particular aspects of diagram definition.
2.4.7. Diagram Editor Generator Model
The high-level models - Graphical, Tooling definition and Mapping along with EMF domain model completely determine diagram structure. These models organize a kind of specific language for diagram definition. But these high level descriptions are not well-suited for code generation. Code generation requires some more generation-specific details like class/package names for some particular generated classes, and some implementation-specific parameters to allow fine tuning of the generated code.
The Generator model operates as an intermediary between code level and design level with elements like:
• GenPlugin - used to hold necessary parameters for generating Eclipse plug-in.
• GenDiagram - used to generate diagram editor.
• GenClass - used to generate GEF EditParts and EditPolicies.
The aim of this model is to reflect all of the necessary details and to make easier the code generation process as much as possible by moving some parts of code generator logic to the process of transformation from high-level GMF models to the Generator model.
GMF changes the diagram description while creating Generator model. The transformation from high-level GMF models to Generator model is not one-to-one transformation. GMF uses an internal, transparent transformation from the map model to the Generator model.
Most of the diagram code can be generated without any modifications to the Generator model that is created by automatic transformation process, or with only few fine tuning modifications like changing diagramming plug-in name, ID, package statements and so on.
3. Introduction to REMES
This chapter presents the model REMES and defines the resources of interest for modeling and analysis embedded systems. It gives a definition of what REMES is and how it is used for modeling the behavior of embedded systems. This knowledge puts the grounds in the problematic area of this thesis.
3.1. Introducing REMES
REMES is intended to describe the resource-wise behavior of interacting embedded components. REMES relies heavily on the modeling language CHARON [1], used for specifying embedded systems as communicating agents. The main contribution of REMES is the addition of resource consumption and utilization information, as well as introducing other constructs for modeling both functional and extra-functional behavior of real-time component-based systems.
3.2. Classes of Resources
The resources in embedded systems are considered as global quantities of finite size. The consumption of a resource is referred as c and means resource usage that occurs instantaneous in time. The utilization of a resource is the rate of consumption over time, i.e. the first derivate of consumption denoted ċ. Both consumption and utilization can be of monotonic or non- monotonic nature. Resource consumption can be further considered as discrete or continuous. Resources are also classified as referable or non-referable, for example – the memory is referable resource. It can be dynamically allocated, deallocated, addressed and manipulated during runtime.
Resource Class Characteristics A
(Memory, Ports)
c = discrete, ċ = 0
consumption non-monotonically increasing referable
B (Power)
c = continuous ċ = n, where n is N \{0}
Non-referable C
(CPU, Bandwidth)
c = continuous ċ = n, where n is N \{0}
utilization non-monotonically increasing Non-referable
Table 3-1 Composite Mode Node element
Taking all these characteristics of the resources, three resource classes are identified (class A, class B and class C). As it can be seen in Table 3-1, resource consumption for resources that belong to class B or C is continuous, which is in opposition to the discrete resource consumption nature for the resources from class A. The consumption for the resources from class A (memory, ports) and the utilization for the resources that make class C (CPU, bus bandwidth) is a non-monotonically increasing function, meaning that, e.g., memory or CPU may be released. In contrary, the resource power of class B, can not be recovered or released, hence its consumption is monotonically increasing. Only the resources from class A are referable and can be dynamically manipulated.
3.3. REMES Elements
3.3.1. Modes
In REMES, the behavior of a component is described by a mode. A mode is called atomic if it does not contain any submode and composite if it contains a number of submodes (see Figure 3-2). The data is transferred between modes via a well-defined data interface, that is, typed global variables, whereas the (discrete) control is passed through a well-defined control interface consisting of entry and exit points. The variables of a mode are partitioned into local variables and global variables, and can be of types Boolean, natural, integer, array, or of an extra type clock that specifies continues variables evolving at rate 1.
Figure 3-2 Composite Mode Node element
The atomic modes Submode1 and Submode n (Figure 2.3-1) are annotated with their respective resource-wise continuous behavior, assuming that the corresponding component is utilizing resources (r1, r2) belonging to class B or C. Such utilization is expressed by the first derivatives of the typed resource variables r1:TB, r2:TC,
respectively, which give the rates at which the composite mode consumes the resources in time, depending on the executing submode.
The execution for a composite mode consists of a sequence of actions. For example (Figure 2.3-1) the parent mode fires the action labeled A0, in order to execute Submode 1 after initialization, and similarly, actions A1,A2, . . . ,An, to further execute Submode 1, Submode 2, . . ., Submode n, respectively.
There are two types of actions supported in REMES – delay and discrete actions. A delay action describes the continuous behavior of the mode, and its execution does not change the mode and on the other hand, executing a discrete action results in a mode change, via the exit point. Discrete actions are instantaneous actions, and they are
represented as annotations of the directed lines, called edges, which connect the control points of the submodes, or of the top mode and its submodes. Mode decorated with U is called urgent, because such a mode exits right away after its activation, without any delay.
A discrete action A = (g, S) is a statement list prefixed by a boolean expression, with g called the action guard, and S the action body, that is, the statement (sequence of statements) that must be executed once the corresponding edge has been taken. Discrete action A is enabled (it can be executed), if it’s corresponding guard g evaluates to TRUE at some point in time. The time which specifies how long a mode is executed is called invariant, e.g., Inv 1, ... , Inv n. Once the invariant stops to hold, the mode is exited by taking one of the outgoing edges.
REMES also provides a conditional connector (depicted by C in Figure 2.3-1), which allows the selection of an outgoing edge, out of two or more possible ones, via the guarding boolean conditions (guards g1, g2, . . . , gn) of the discrete actions that correspond to the edges exiting the conditional connector. For a discrete action to be possibly executed the component must be in the right mode and the corresponding guard must evaluate to TRUE. If none of the guards evaluates to TRUE, then no discrete action is executed and the component remains in its current mode, performing delay actions. If more than one action guards are TRUE, then one of the enabled discrete actions could be executed non-deterministically.
3.3.2. Edges
The connecting edges of REMES modes are classified as follows:
• Entry Edge (Entry Init Edge). Connects an entry point (init point) of a composite mode with an entry point (init point) of a submode.
• Entry Conditional Top Edge (Entry Conditional Top Init Edge). Connects an entry point (init point) of a composite mode with an entry point (init point) of a conditional connector.
• Exit Edge. Connects an exit point of a submode with an exit point of a composite mode.
• Internal Edge. Connects an exit point of a submode with an entry point of another submode.
• Entry Conditional Sub Edge. Connects an exit point of a conditional connector with an entry point of a submode.
• Exit Conditional Sub Edge. Connects an exit point of a submode with an entry point of a conditional connector.
• The edges connecting all modes must not form any cycles in order to ensure terminating internal behavior of a composite mode.
3.4. Mode execution
The top-level mode, which is activated when a corresponding event is received, enters execution for the first time through the special Init entry point, while initializing the global variables, accordingly. After that, the mode is re-entered through control point Entry. A mode can execute either a discrete step, by taking a discrete action, or a continuous step, via a delay action, with such steps alternating as dictated by the urgency of the mode. When executing a continuous step, the mode follows a continuous path that satisfies the resource constraints. When the mode invariant is violated, the mode must execute an outgoing discrete step. A discrete step of a mode is a finite sequence of discrete steps of the submodes, that is, a sequence of executing discrete actions. A discrete step begins in the current mode and ends either at the entry point of a submode, or when it reaches the current mode’s exit point, meaning that the current mode has passed control to some other mode. The fact that a mode can pass control is ensured by the closure construction: each exit point of a submode is either connected to the exit point of the top-level mode, or deterministically connected to an entry point of another mode that eventually leads to the top-level mode’s exit.
4. REMES Editor Design analysis
This chapter revises in more detail the requirements for the future work based on the used technologies and the REMES specification. As the editor must be PROGRESS IDE plug-in, its implementation will be based on the Eclipse GMF following the GMF Dashboard workflow. Having good design for all required models in GMF, guarantees that the generated editor code won’t require much customization.
4.1. REMES EMF Ecore meta-model
The main goal when designing the EMF Ecore meta-model for REMES is to find the best way to represent the model. In this section will be described the EMF model requirements based on the REMES specification.
The main container for the editor is the REMES Diagram (Table 4-1). It can contain Composite Modes and standalone Sub Modes. The Composite Modes themselves can contain Sub Modes and Conditional Connectors.
Container Childs
REMES Diagram Standalone Sub Modes
Composite Modes
Composite Mode Sub Modes
Conditional Connectors Table 4-1 REMES Containment Definition The Composite Mode should have the following properties:
• Name – the mode name.
• Initialization – all the initialization data for the first time accessing the mode.
• Communication points – predefined points:
o Init point – first time accessing the mode will enter the mode through this init point.
o Exit point – all paths of execution for the mode has its last point, the exit point of the mode.
The Sub Mode should have the following properties: • Name – the mode name.
• Initialization – all the initialization data for the first time accessing the mode.
• Communication points – predefined points:
o Entry point – the starting point for execution.
o Exit point – the point at which the mode ends its execution. • Resources of Class A
• Resources of Class B • Resources of Class C
• Invariant – contains the information about timing behavior of the mode. • Is Urgent – Boolean property indicating if the mode is urgent.
The Conditional Connector properties are:
• Name – the name of the Conditional Connector. • Communication points – predefined points:
o Entry point – the starting point for execution.
o Exit point – the point at which the connector passes the execution to the next item based on informative decisions.
The execution of a mode is defined by connecting the mode’s and connector’s communication points with links called Edges. Table 4-2 shows the Edges that can be defined within a Composite Mode, their source and target points.
Edge Name Source Point Target Point
EntryInitEdge Composite Mode Init point Sub Mode Entry Point EntryConditionalInitEdge Composite Mode Init Point Conditional Connector
Entry point
Point
EntryConditionalTopEdge Composite Mode Entry Point
Conditional Connector Entry Point
InternalEdge Sub Mode Exit Point Sub Mode Entry Point EntryConditionalSubEdge Conditional Connector
Exit Point
Sub Mode Entry Point
ExitConditionalSubEdge Sub Mode Exit Point Conditional Connector Entry Point
ExitEdge Sub Mode Exit Point Composite Mode Exit
Point ExitConditionalTopEdge Conditional Connector
Exit Point
Composite Mode Exit Point
Table 4-2 REMES Edges Definition
The two initialization edges – EntryInitEdge and EntryConditionalInitEdge have only one property: Initialization, which contains all the required initialization data.
All other seven edges have the following properties:
• Action Guard – contains the condition with should be fulfilled in order the edge to be executed.
• Action Body – contains the information for the edge execution.
The EMF ecore model must be designed to best match all these requirements along with the following problems solved:
• Find the best hierarchy for the objects in order to be sure that no data will be lost on saving/loading the model.
• Constrain the model, so creating valid diagrams is forced.
• The design should allow easy extending in future – adding new edges or properties.
4.2. REMES Tooling Definition Model
In the Tooling definition model are defined the creation tools which show up into the Palette. For the REMES GUI Editor, for each diagram object (Mode, Connector or
Edge), a creation tool with appropriate icon must be created. They should be organized in visual groups for better usability and navigation.
4.3. REMES Graphical Definition Model
In the Graphical definition model must be defined the visual figures, connections, labels and compartments for the REMES GUI editor. All these will be further mapped to the model elements in the GMF Mapping model. In order to have better looking editor, colors, decorations and appropriate layouts must be defined.
4.4. REMES Mapping Model
In the Mapping model all pieces – domain model, tooling model and graphical definition are put together. Composite and Standalone Sub Modes must be set for REMES diagram root elements. All figures, labels and connections must be mapped to the domain model elements.
In this model, additional link constraints must be defined to prevent creating invalid edges, for example: one InternalEdge connects two Sub Modes, but it shouldn’t be allowed to connect one Sub Mode with itself. In GMF, Object Constrained Language is available and provides such functionality to define constraint rules in link mappings.
4.5. REMES Diagram Editor Generation Model
Final touches, such as defining diagram editor plug-in name, version, file extensions etc., have to be made in this model before the code generation.
4.6. REMES Views functionality
For the ability to have additional menu for the required different view of the REMES diagrams – Functional, Timing and Resource Usage, additional plug-in contributions and functionality must be added. There must be designed flexible and extendable filtering mechanism for defining the required filters. This will allow in future, if required, to add new views in a seamless manner.
GMF Diagram Editor generated plug-in in most cases behaves almost as it is expected, but to have met all the requirements, the auto-generated code must be modified at some places. There are also unresolved problems in the GMF generating framework which must be also fixed for the REMES Diagram Editor generated code.
5. REMES GUI Technical Realization
This chapter describes in details how the REMES GUI is implemented, step by step models definitions, code customization and additional menu contributions to have the REMES Diagram Editor plug-in functional and satisfying its requirements.
5.1. REMES EMF Model definition
It is very important to have a good design for the EMF model as this is the base for all further steps in the implementation of the REMES GUI. The approach chosen for creating the ecore model is by creating Java interfaces with EMF annotations. The package for these interfaces is named “remes”.
For the REMES EMF model, it is very important to decide where each component will be persisted. The mechanism for this is the containment property – it states that the annotated element will be persisted in the object instance of the interface in which it is defined.
The REMES Diagram root element is defined in the RemesDiagram interface. Its only purpose is to contain the top REMES modes – Composite Mode and standalone Sub Modes, which has common base interface, called Mode. On Figure 5-1 can be seen the REMES interface and its getter method – getModes, annotated with containment=”true” model tag. Such way, the diagram can contain a list of one or more modes, which base interface is the Mode interface.
Figure 5-1 RemesDiagram annotated interface
Each REMES Diagram mode must have name and initialization and as these are common properties, they are defined in the Mode interface as can be seen in Figure 5-2. The Mode interface is tagged as abstract, because it is not actual part of the REMES EMF model, but only as an abstract part on which other parts will be extended.
Figure 5-2 Mode annotated interface
Before proceeding to the definitions of the Modes, it must be decided, how the connection mechanism for the Edges will be designed. Each edge has an element from which starts and an element to which it points – let’s call these connectFrom and connectTo respectively. Each edge should also be contained somewhere in the diagram. The approach chosen for the REMES EMF models is to store an edge in its connectFrom element, this way each mode will hold reference to its connectFrom element and each element will store the edges starting from it. The connectTo element reference is stored in the edge and the referenced element holds reference to the edges which point to it. Based on this mechanism, easy extendable and flexible interfaces for the REMES EMF model can be created. Having in mind that all connectTo and connectFrom elements are Composite Mode, Sub Mode and Conditional Connector, the following interfaces are created:
• For defining the starting point element (connectFrom) of an edge, one of the following interfaces must be extended in the concrete edge interface:
o FromCompositeModeEdge – states that the edge starts from a Composite Mode and is stored in it.
o FromCompositeModeInitEdge - states that the edge is initialization edge which starts from a Composite Mode and is stored in it. o FromConditionalConnectorEdge - states that the edge starts from a
Conditional Connector and is stored in it.
o FromSubModeEdge - states that the edge starts from a composite mode and is stored in it.
• For defining the target element (connectTo) of an edge, one of the following interfaces must be extended in the concrete edge interface:
o ToCompositeModeEdge - states that the edge points to a Composite Mode and stores the reference to it.
o ToConditionalConnectorEdge - states that the edge points to a Conditional Connector and stores the reference to it.
o ToSubModeEdge - states that the edge points to a Sub Mode and stores the reference to it.
The other edge common feature is based on its type – if it is an initialization edge or it is a regular edge. For these two edge types, the following two interfaces are created:
• Edge – defines a regular edge common properties – action body and action guard (Figure 5-3)
• InitEdge – defines an initialization edge common property – the initialization string. (Figure 5-4)
Figure 5-3 Edge annotated interface
Figure 5-4 InitEdge interface
Having these 3 sets of interfaces is enough to fully define the concrete interfaces for the nine REMES edges – one such interface is defined by extending three base interfaces – one from each set (FromXXXEdge interface, ToXXXEdge interface, “Edge Type” interface”. Table 5-5 shows the full matrix for REMES Edges interfaces and Figure shows sample interface. Figure 5-6 show the ExitConditionalSubEdge interface.
Edge Type From element interface To element interface Edg e Init Edge Fr omComposi teModeEdge Fr omComposi teModeIni tEdge Fr omConditiona lC onne ctordge Fr omSubMod eE dg e ToC omposi teModeEd ge ToC ondi ti on alC onn ec tor E dg e ToSu bModeEdge EntryInitEdge x x x EntryConditionalTopInitEdge x x x EntryEdge x x x EntryConditionalTopEdge x x x InternalEdge x x x EntryConditionalSubEdge x x x ExitConditionalSubEdge x x x ExitEdge x x x ExitConditionalTopEdge x x x
Table 5-5 Edge interfaces matrix
Figure 5-6 ExitConditionalSubEdge interface definition
The Composite Mode interface has to define the following properties (except the ones defined it the Mode interface – Figure 5-7):
• InitEdge – as previously mentioned, the Composite Mode must contain the edges starting from it. There can be only one init edge. The opposite reference from the edge is “connectFrom”.
• EntryEdge – the entry edge for the Composite Mode. The can be only one entry edge. The opposite reference from the edge is “connectFrom”. • ExitEdges – a list of all edges which target is the Composite Mode. These
edges are not contained in the Composite Mode and there must be at least one exit edge. The opposite reference from the edge is “connectTo”. • SubModes – a list of all Sub Modes which are contained in the Composite
Mode. There must be at least one Sub Mode.
• ConditionalConnectors - a list of all Conditional Connectors which are contained in the Composite Mode. This list may be empty.
Figure 5-7 CompositeMode interface
The analogous interfaces for a Sub Mode and Conditional Connector can be seen in Figure 5-8 and Figure 5-9. The common thing in these two interfaces is that they
introduce a parent reference to a Composite Mode. This reference does not work for standalone Sub Modes
Figure 5-9 ConditionalConnector interface
After all Modes and the Conditional Connector interfaces are present, the FromXXXEdge and ToXXXEdge sample interfaces can be seen in Figure 5-10 and Figure 5-11 respectively. For each connectFrom and connectTo references, the opposite reference name is defined for bi-directional completeness.
Figure 5-11 ToCompositeModeEdge interface
Once all the interfaces are created, the new EMF model wizard must be invoked using the option to create the model from Annotated Java interfaces from the remes package. This way, the “remes.ecore” (Figure 5-12) and “remes.genmodel” EMF models are created.
For the “remes.ecore” model, no modifications are required. For the “remes.genmodel” it is required only few minor modifications to be made like – setting the following fields to be multi-line properties: Mode.initialization, SubMode.resourceClassA, SubMode.resourceClassB and SubMode.resourceClassC (Figure 5-13).
Figure 5-13 SubMode’s resourceClassC field properties in the genmodel
Having defined the EMF models for the REMES model, what is left is to call the EMF generation framework to generate the “Model Code”, “Edit Code” and “Editor Code” (Figure 5-14). The generated code does not require any modifications. The structure of the generated code and corresponding plug-ins can be seen on Figure 5-15
Figure 5-15 EMF generated plug-ins structure
5.2. REMES GUI Icons and color conventions.
For the further work on the REMES Diagram editor, a set of icons must be created in order to have best visual presentation and usability for the GUI. In Table 5-16 are presented all the icons created for this project:
Icon Description REMES Diagram Wizard icon.
REMES Diagram files icon. REMES Views icon. Composite Mode icon.
Sub Mode icon
Conditional Connector icon. Initialization icon.
Invariant icon. Urgent icon.
Class A resource icon. Class B resource icon. Class C resource icon. EntryEdge icon. EntryInitEdge icon. EntryConditionalTopEdge icon. EntryConditionalTopInitEdge icon. InternalEdge icon. EntryConditionalSubEdge icon. ExitConditionalSubEdge icon. ExitEdge icon. ExitConditionalTopEdge icon. Table 5-16 REMES GUI icons
The following color conventions are used in the REMES GUI: • Green – Entry point color.
• Orange – Init point color. • Red – Exit point color.
5.3. REMES Tooling Definition Model implementation
The REMES Tooling Definition model implementation begins with invoking the Derive link in the GMF Dashboard which invokes a wizard, where the name of the model is defined - “remes.gmftool”, the Domain model is set to “remes.ecore” model with Diagram Element set to RemesDiagram. At the last step of the wizard, for each Mode or Connector, the Node checkbox is selected and for every Edge – the connection checkbox is selected. After the wizard is finished and the tooling model is created, the main items to be made are:
• Set Title and Description for each creation tools and the REMES Palette. • Organize the creation tools into two groups – one for the nodes and one
for the edges.
• Set appropriate icons for each creation tool. See Table 5-16 for the icons created for the REMES GUI elements.
The Tooling definition model structure can be seen in Figure 5-17 and the resulting REMES Palette in the REMES GUI Editor can be seen in Figure 5-18.
Figure 5-18 REMES Palette in the GUI
5.4. REMES Graphical Definition model implementation
This section is presented the implementation of the REMES GMF Graphical Definition model. This model is very important because here is defined how the REMES GUI will be visualized to its users.
The model is created using the Derive link in the GMF Dashboard. The name is “remes.gmfgraph”, the Domain model is “remes.ecore” with Diagram Element – RemesDiagram. In the last step of the wizard, for each visual element of the diagram, its type must be set to one of the set – Node, Connection or Label. After the wizard is finished and the Graphical model is created, the modifications can start.
5.4.1. Edge Figures graphical definition.
In this section will be presented the graphical definition for the Entry Edge, so all other edges definitions can be made in a similar fashion.
In the Figure Gallery of the “remes.gmfgraph” model there must be a figure for the EntryEdge with Figure Descriptor called EntryEdgeFigure (Figure 5-19). It has a child of type Polyline Connection which will represent the EntryEdge line connecting the Composite Mode entry point with the entry point of a Sub Mode.
It is required for the EntryEdge line to have direction and to have visual representation for the type of the point which it connects. This is achieved by the Source and Target Decorations. For the EntryEdge, the Source Decoration must be a green circle and the Target Decoration must be a green arrow and for these properties, the “Polygon Decoration CircleDecoration” and “Polyline Decoration EntryPoint” are set respectively. The creation of these decorations will be described later in this sub section. The EntryEdge line itself must be a solid black line and this is achieved by the property “Line Kind” set to LINE_SOLID and the Foreground Color child element, set to black.
For the EntryEdge is required to be shown the Action Guard text. This is achieved by creating a child Label element called EntryEdgeActionGuardFigure with default text set to “<…>”. For this label, there must be defined a Child Access element for the parent EntryEdgeFigure Figure Descriptor. This Child Access Accessor property value is “getFigureEntryEdgeActionGuardFigure” and its figure property is set to the Label EntryEdgeActionGuardFigure.
To complete the Figure Gallery Definitions, the Decorations definitions have to be created:
• For the Source Decoration of the EntryEdge a circle decoration has to be set, but there is no such by default in GEF, so a custom one is created. In the Figure Gallery, a Polygon Decoration is created with the name “CircleDecoration”. For is, multiple child elements of type Template Point must be created – each of them representing a point of a circle. For the CircleDecoration, 44 points are defined to represent a circle. This will create a bigger circle than expected for the REMES GUI, so there must be made code modifications to fix this problem [8]. These modifications will be presented later in the thesis document.
• For the Target Decoration of the the EntryEdge a green arrow must be set. In GEF, an empty Polyline Decoration represents an arrow [9], so in the Figure Gallery is created a decoration of this type and is called EntryPoint. For better
visual presentation its Line Width is set to 2 and for its green color, foreground and background color child elements are created.
Figure 5-19 EntryEdge figure and its properties in the Graphical model The rest of the EntryEdge graphical definition under the “remes” Canvas is:
• The Connection definition element with Name “EntryEdge” and Figure = “Figure Descriptor EntryEdgeFigure”.
• The Diagram label element with Name “EntryEdgeActionGuard” and properties:
o Accessor = Child Access getFigureEntryEdgeActionGuardFigure o Figure = Figure Descriptor EntryEdgeFigure.
5.4.2. Modes Figures graphical definition.
In this section the graphical definition for the Composite Mode is presented. The Sub Mode and Conditional Connector definitions can be created in a similar way.
In the Figure Gallery of the “remes.gmfgraph” model there must be a figure for the CompositeMode with Figure Descriptor called CompositeModeFigure. Its type is defined with the child element of type Rounded Rectangle which will represent the CompositeMode with a rectangle with rounded edges. As can be seen in Figure 5-20 the child elements of the rectangle are the Name and Initialization Labels, along with the corresponding Child Access elements. For both labels, in the corresponding Diagram Label elements, the Element Icon property must be set to true in order the appropriate icons to be viewed in the diagram.
Figure 5-20 CompositeMode figure and its properties in the Graphical model
The composite mode must be able to contain other elements (Sub Modes and Conditional Connectors). This is achieved with Compartments. For the Composite Mode, a Compartment element must be created with Name “CompositeModeCompartment” and Figure = Figure Descriptor CompositeModeFigure (Figure 5-21).
Figure 5-21 Composite Mode Compartment definition
The rest of the Composite Mode graphical definition is the Node element for it (Figure 5-22).
Figure 5-22 Composite Mode Node element
For the Conditional Connector there is a little more specific work. As the figure of this element is Ellipse, it will be good to have its label in the center of the ellipse. This is achieved by setting GridLayout for the Ellipse Figure. The Grid is defined to have only one column and the GridLayoutData set for the Name label have both vertical and horizontal alignment set to center (Figure 5-23).
Figure 5-23 Conditional Connector Grid Layout definition
5.5. REMES Mapping model implementation
In this section, the three base models – Domain, Tooling and Graphical are combined in the GMF Mapping model.
The Mapping model is created using the Combine link in the GMF Dashboard. The name is “remes.gmfmap”, the Domain model is “remes.ecore”, the Diagram Palette is “remes.gmftool” and the Diagram is “remes.gmfgraph”. The last step of the wizard in the case of REMES project is not offering much value, so the wizard can be finished and all the work to be made in the Mapping model editor.
5.5.1. Composite Mode Mapping
In this section, the mapping definition for the Composite Mode is presented. The mapping model for the other top-reference mode – the standalone Sub Mode can be defined in a similar way. The whole tree of the Composite Mode mapping definition is shown in Figure 5-24.
Figure 5-24 CompositeMode Top Reference Node Mapping definition
The Top Node Reference Definition for the Composite Mode defines the Containment feature property and must be set to RemesDiagram.modes, meaning that the Composite Mode is stored in the RemesDiagram’s modes field.
The child, Node Mapping links the Composite Mode representations in the Domain, Graphical and Tooling models (Figure 5-25).
Figure 5-25 Composite Mode Node mapping element
The Composite Mode has two labels – Name and Initialization. There are two Feature Label Mappings for these labels. In the Label Mapping, the graphical representation (Diagram Label) is linked to a domain feature. For example, the Composite Mode Name mapping is linking the Diagram Label CompositeModeName with Mode.name: String (Figure 5-26).
Figure 5-26 CompositeMode Name Label Mapping definition
Sub Modes and Conditional Connectors are child nodes for the Composite Mode and there are defined two Child References for them. These definition are absolutely the same as the Top Node Reference with the difference that they are nested into the Composite Mode Mapping definition.
Note that the Sub Mode has two definitions in the mapping model – one as a top reference node and one as a child node in the Composite Mode. In GMF these definitions of Sub Mode are treated as different nodes and the generated code is duplicated, although that in the domain model there is no such difference.
What is left for the Composite Mode mapping definition is the Compartment Mapping. The visual representation is the Compartment CompositeModeCompartment (CompositeModeFigure). It is mapped with two Child References: for Sub Modes and for Conditional Connectors (Figure 5-27).
Figure 5-27 CompositeMode Compartment Mapping definition
5.5.2. Link Mappings
In this section, the mapping definition for the InternalEdge is presented. The mapping models for the other edges are defined in a similar way. The InternalEdge Link Mapping part of the tree is shown in Figure 5-28.
Figure 5-28 InternalEdge Mapping definition
The Domain model information for the InternalEdge: InternalEdge interface, Containment Feature – SubMode.exitEdges, the Source Feature defined in the FromSubModeEdge.connectFrom and the Target Feature defined in ToSubModeEdge.connectTo are mapped to the Diagram Link – Connection InternalEdge and the Tooling definition – Creation Tool InternalEdge.
The additional Link Constraints definition is discussed in the next sub section.
5.5.3. OCL Constraints for the Link Mappings
In order to defend the user of the REMES GUI editor from creating invalid diagrams, additional constraints must be defined. For each Link Mapping can be defined Source End and Target End Constraints described in the OCL [10].
In the following Table are described all the defined constraints for the REMES:
Edge Constraint and description
EntryEdge and EntryInitEdge
Target End Constraint:
OCL: “oppositeEnd.subModes->exists(s | s = self)”
This means that this edge can connect only a Composite Mode with a Sub Mode which it contains and cannot
connect to standalone Sub Modes or the Sub Modes of another Composite Mode.
EntryConditionalTopEdge and
EntryConditionaTopInitEdge
Target End Constraint:
OCL: “oppositeEnd.conditionalConnectors->exists(c | c = self)”
This means that this edge can connect only a Composite Mode with a Conditional Connector which it contains and cannot connect to the Conditional Connectors of another Composite Mode.
InternalEdge Source End Constraint:
OCL: “self <> oppositeEnd and
self.parent.oclIsTypeOf(CompositeMode)”
This means that this type of edge cannot connect one Sub Mode with itself and that only Sub Modes which are contained in a Composite Mode can be end of such edge. Target End Constraint:
OCL: “self.parent.subModes->exists(sm | sm = oppositeEnd)”
This means that this type of edge can connect only Sub Modes which are both contained in one and the same Composite Mode.
ExitConditionalSubEdge Source End Constraint:
OCL: “self.parent.oclIsTypeOf(CompositeMode)”
This means that this type of edge can begin only from a Sub Mode contained in a Composite Mode, but not from standalone Sub Modes.
Target End Constraint:
OCL: “self.parent.subModes->exists(sm| sm = oppositeEnd)”
This means that this edge can connect a Sub Mode with a Conditional Connector only if both of them are contained in
one and the same Composite Mode. EntryConditionalSubEdge Target End Constraint:
OCL: “self.parent.conditionalConnectors->exists(cc| cc = oppositeEnd)”
This means that this edge can only connect a Conditional Connector with a Sub Mode only if both of them are contained in one and the same CompositeMode.
ExitEdge Source End Constraint:
OCL: “self.parent.oclIsTypeOf(CompositeMode)”
This means that this edge can start only from Sub Modes contained in a Composite Mode.
Target End Constraint:
OCL: “self.subModes->exists(s|s = oppositeEnd)”
This means that this edge can connect a Sub Mode only with the Composite Mode in which it is contained.
ExitConditionalTopEdge Target End Constraint:
OCL: “self.conditionalConnectors->exists(c| c = oppositeEnd)”
This means that this edge can connect a Conditional Connector only with the Composite Mode in which it is contained.
Table 5-29 Definitions and descriptions of Edge’s constraints
5.6. REMES Diagram Editor Generation Model
The final model is the Diagram Editor Gen Model. It is created by using the Transform link in the GMF Dashboard. It is named “remes.genmodel” and requires almost no customizations. The only thing which is change is the “Same File For Diagram And Model” property of the Gen Editor Generator to true. This means that both the model data and its graphical information are stored both in one and the same file. This
is useful because supporting two connected files separately is more difficult than having one file for both things.
5.7. REMES Diagram plug-in code generation
After all steps from the GMF Dashboard workflow are complete and all additional touches are done, the code for the REMES GUI plug-in can be generated. This is done via the “Generate diagram editor” link in the “Diagram Editor Gen Model” box in the GMF Dashboard. After the code generation is complete, there is a new project in the tree, named “remes.diagram” and its structure can be seen in Figure 5-30.
Figure 5-30 REMES Diagram generated code structure
5.8. REMES Diagram generated plug-in problems and customizations
In this section are presented the problems of the generated diagram editor plug-in and the fixes for them. All code modifications must be marked as “@generated NOT” so if the code is re-generated, the changes won’t be lost.
5.8.1. Edges starting point decorations are huge circles
In the Graphical Definition model, the source decoration for all edges was set to the custom Circle decoration. This was achieved by defining a set of point which being connected one by one, forms a circle. When drawing the resulting figure, it is required to have a small circle, so it is best looking in the diagram [8].
The fix for this problem is to draw the circle figure with lower scale. This is achieved by modifying the createSourceDecoration method (Figure 5-31) for each edge EditPart class, for the corresponding EdgeFigure, to set the appropriate color of the PolygonDecoration and to set the scale to (0.4, 0,4) which is empirically discovered to be the best looking scale.
Figure 5-31 Edge source decoration code modifications
5.8.2. Labels representing Mode’s properties must the right icons
For each property of REMES modes, the corresponding label must show the icon created for it. This is achieved by modifying the getLabelIcon method for each label EditPart class to point to the appropriate icon [11]. The modification for the Conditional Connector name label icon can be seen in Figure 5-32.
Figure 5-32 Setting Label’s icon code modification
5.8.3. Multi-line properties are not viewed as multi-line labels
For a few properties, for example the initialization of Modes, were set to be multi-line properties in the “remes.genmodel” and it is expected to see them in the diagram as such, but this is not the case with the auto-generated plug-in.
This problem is caused because the TextWrap property of the WrappingLabel figure is not set to true.
The fix for the initialization label of the Composite Mode figure is done in CompositeModeEditPart class changing the CompositeModeFigure’s createContents method. The actual part of the fix is to call the setTextWrap method of the fFigureCompositeModeInitializationFigure with parameter true [12] (Figure 5-33).
Figure 5-33 Setting Label’s text wrap property code modifications
But having this change does not solve the whole problem. When the user tries to edit the label directly on the diagram, the default editor doesn’t allow having new lines. This is caused because the default TextCellEditor for a label of type WrappingLabel is TextCellEditorEx, but not the expected WrapTextCellEditor.
The fix for this problem is to modify the getManager method in CompositeModeInitializationEditPart (Figure 5-34) to pass to the TextDirectEditManager constructor directly the class of the WrapTextCellEditor. This allows the user to have new lines when editing the label directly on the diagram by pressing the key combination Ctrl+Enter.
Figure 5-34 Multi-line label text editor code modification
These modifications must be made for all similar problems for Sub Mode multi-line labels.
