In this paper we demonstrate how diagrams constructed using general-purpose drawing tools in the context of agile language development processes can be annotated and consumed by model management programs (such as simulators, model-to-model and model-to-text transformations). The aim of this work is to enable engineers to engage in programmatic model management early in the language development process, so that they can explore whether or not the languages and models constructed are fit for purpose. We demonstrate a proof-of-concept prototype developed atop the Epsilon platform and a flexible graph definition language (GraphML).
The quality and usefulness of a Domain Specific Language (DSL) depends on accurately identifying the domain concepts, their features and relationships. As such, the involvement of domain experts in the language development process is crucial. In the early stages of the language development process, domain experts often provide informal example diagrams/sketches from which engineers can infer a first version of the metamodel of the envisioned language. To obtain additional feeback, engineers then need to develop an initial version of a language-specific modelling tool that enables domain experts to further experiment with the language. This typically constitutes the first step of an iterative process during which the metamodel of the language can undergo several revisions. When 3-layer modelling frameworks such as MOF/EMF are used, for each change in the metamodel, language engineers need to update and re-deploy a new version of the modelling tool, and for non-additive changes to the metamodel they also need to provide support for automated migration of older models.
To achieve shorter and more efficient iteration cycles, several techniques that challenge this top-down metamodel-centric approach have recently been proposed. In such approaches, the early phases of the language development process involve the construction of example diagrams using flexible drawing tools, which can be used to (semi-)automatically infer a rigid metamodel only once sufficient confidence in the completeness and maturity of the language has been developed.
In this paper we argue that example diagrams constructed in the context of this process should also be processable by model management programs (such as simulators, model-to-model and model-to-text transformations) so that engineers can develop additional and early confidence that the constructed language is fit for purpose. The rest of the paper is organised as follows. In Section 2 we provide an overview of related work in the field of bottom-up and agile metamodelling. In Section 3 we illustrate an approach for enabling engineers to engage in programmatic model management activities early in the language development process, and demonstrate a proof-of-concept prototype developed atop the Epsilon platform and a flexible graph definition language (GraphML). In Section 4 we conclude and provide directions to further work. 2
In [
To our knowledge, research in this area so far has focused solely on agile model construction and automated metamodel inference. In our view, to further validate the maturity and completeness of a metamodel, it is also important for language engineers to develop some confidence that models conforming to this metamodel can support the automated model management operations involved in the envisioned MDE workflow (simulation, model-to-model and model-to-text transformation etc.) 3
In this paper we illustrate an approach for rendering diagrams constructed using general-purpose drawing tools amenable to programmatic model management. An overview of the proposed approach is illustrated in Figure 1. Consistently with previously-proposed bottom-up metamodelling techniques, in this approach language engineers and domain experts can start the language development process by drawing diagrams depicting example models, which (conceptually) conform to the envisioned language, using a general purpose diagram drawing tool.
In the next stage, engineers can augment these conceptual diagrams using a set of predefined textual annotations (discussed in Section 3.2) to specify the types and features of diagram elements of interest in an agile manner. Annotated diagrams are then automatically transformed into an intermediate representation (muddle) that can be programmatically managed using existing model management languages.
In this work we use GraphML, the conceptual metamodel of which is
illustrated in Figure 2, for diagram drawing, and languages of the Epsilon platform
[
We start by using the yEd1 GraphML-compliant tool to draw an example diagram that conceptually conforms to the envisioned flowchart language. The diagram, illustrated in Figure 3 consists of labeled rectangles which conceptually represent actions, a diamond which represents a decision, directed edges which represent transitions, a hexagon that represents the triggering event, a circle which represents a delay, and a hexagon which represents the time at which the attached event should fire for the first time.
We now take a leap and in Listing 1.1 we present the implementation of
a simple simulator for such flowcharts, expressed in the Epsilon Object
Language [
self.outgoing.at(0).target.process();
operation String toMinutes() : Integer {
var parts = self.split(":");
return parts[0].asInteger() * 60 + parts[
– Assuming that a flowchart can contain many events, in line 1 we select one event that has its entryPoint attribute set to true; – In line 3, we keep a copy of the time (converted to minutes) at which this event is fired for the first time; – In line 4, we process the target of the first outgoing transition of the event; Calls to process() operations are dynamically dispatched depending on the type of their context object, and behave as discussed below; – The Event.process() operation prints a message and processes the target of its first outgoing transition; – The Action.process() operation prints a message and then, if the action has any outgoing transition, it processes the target of the first of them; – The Decision.process() operation chooses a random outgoing transition, prints its name and processes its target; – The Delay.process() operation adds the delay time to the global time, prints a message and then processes the target of its first outgoing transition; – The toMinutes() and toHours() operations can convert HH:MM-formatted time strings to integers (number of minutes) and vice versa.
A sample execution trace of the simulator appears below. 1 Event: Alarm clock rings at 08:00 2 Action: Wake up 3 Decision: Is it too early? 4 Chose: yes 5 Action: Hit snooze 6 Waited for 10mins 7 Event: Alarm clock rings at 08:10 8 Action: Wake up 9 Decision: Is it too early? 10 Chose: no 11 Action: Get up 3.2
To facilitate the execution of model management programs such as the one illustrated in Listing 1.1, we need to annotate diagram elements with additional information. For example, we need to declare that the type of all rectangle nodes in this diagram is Action, and that the type of directed edges is Transition. As GraphML does not provide built-in support for capturing type-related information for nodes and edges, we need to use GraphML’s extensibility facilities2 to define Type extension fields for nodes and edges. 2 http://docs.yworks.com/yfiles/doc/developers-guide/graphml.
html
The value of the Type extension field of a node/edge needs to adhere to the name (> name)* pattern, where > is used to denote inheritance. For example, by setting the Type field of the Wake up node to Action > FlowchartElement, we define that the node is an instance of the Action type, and that the FlowchartElement type is a super-class of Action. All types are unique by name and are created the first time they are encountered in the diagram. For example, by subsequently setting the Type field of Hit snooze to Action, we are reusing the Action type defined in Wake up instead of creating a new one. Beyond typerelated information, we also need to capture additional information using the following GraphML extensions summarised in Table 1.
The value of the Properties field of a node/edge can contain zero or more lines of text. Each line needs to adhere to the pattern above and define the type, multiplicity, name and value of the property. For example, by setting the value of the Type field of the Alarm clock rings node to Event and the text of its Properties field to boolean startEvent = true, we define that the node has a single-valued boolean startEvent property, with a value set to true.
The value of the Default field should conform to the pattern above and define the name of the default slot of the node/edge and, optionally, its primitive type (defaults to String). For example, by setting the Default field of the Wake up node to name, the first label of the node that does not match the property descriptor pattern (in this case, the Wake up label), will be made accessible through a name property of type String.
The values of the Source role, Target role, Role in source, and Role in target fields of an edge define the name and multiplicity of the respective roles. For example, in the yes transition we define the following values for these properties: Source role: source, Target role: target, Role in source: outgoing *, Role in target: incoming *. 3.3
The next step of the process is to parse the annotated GraphML diagram and construct an intermediate model (muddle) that conforms to the metamodel of Figure 4. This is achieved through a multi-pass transformation which is transparent to the end-user and which comprises the following steps. 1. For every typed node in the graph, it creates an empty MuddleElement in the intermediate model and its corresponding MuddleElementType (if the latter does not already exist). It also looks for nodes for which the Default field has a valid value. When this happens, the value of the Default field is used to produce a primary Feature which is added to the type of the created MuddleElement ; 2. Iterates through the created elements and creates/populates their slots, based on the descriptors provided in the Properties field of the node. Again, for each new property a Feature is created and added to the type of the element. As such, by setting the value of the Properties field of Alarm clock rings to boolean startEvent = true, all model elements of type Event obtain a single-valued startEvent boolean feature; 3. Iterates through the labeled and untyped edges of the graph (e.g. the time edge in the diagram of Figure 3). For each edge, it adds an untyped Feature to the type of its source muddle element, a respective Slot to the source muddle element, and adds the target of the edge to the values of the slot; 4. Iterates through the unlabeled and untyped edges of the graph and attempts to fit their targets into appropriate slots of the source muddle elements (i.e. slots that already contain at least one value of the same type); 5. For every typed edge of the graph it creates an empty MuddleElement and its corresponding LinkElementType, similar to what was discussed for nodes in step 1. It also attempts to create primary, role in source, role in target, source and target Features for the created LinkElementTypes; 6. Iterates through the typed edges of the graph and creates/populates their slots similar to what was discussed in step 2; 7. Adjusts the multiplicities of features based on the maximum number of values of their slots. In this process, single-valued features, slots of which contain more than one values become multi-valued (but not the opposite). 3.4
Epsilon provides an abstraction layer (Epsilon Model Connectivity – EMC3) that shields the languages of the platform from the intricacies of concrete model representations and enables them to access models conforming to a wide range of technologies. To enable Epsilon languages to access muddles, we have developed a new driver that implements the set of interfaces required by EMC. Due to space restrictions, a detailed discussion on the new driver is beyond the scope of this paper.
The driver enables all languages in Epsilon to query muddles. For example, in addition to the simulator of Listing 1.1, Listing 1.2 demonstrates an exemplar constraint written in the validation language of the platform (EVL4), and Listing 1.3 demonstrates an exemplar model-to-text transformation written in EGL5. 1 context Decision { 2 constraint HasMoreThanOneOutgoingTransitions { 3 check: self.outgoing.size() > 2 4 message: "Decision " + self.name + " needs to have at least 2 outgoing transitions" 5 6 } }
1 The flowchart has [%=Action.all.size()%] actions: 2 [%for (action in Action.all) {%] 3 - [%=action.name%] 4 [%}%]
Listing 1.3. Model-to-text transformation for flowchart models 4
In this paper we have argued for the importance of enabling engineers to engage in exploratory model management operations early on in the language development process and demonstrated an approach and a prototype that enables 3 http://www.eclipse.org/epsilon/doc/emc 4 http://www.eclipse.org/epsilon/doc/evl 5 http://www.eclipse.org/epsilon/doc/egl engineers to annotate and programmatically manage GraphML diagrams using languages of the Epsilon platform. In the future, we plan to investigate supporting additional GraphML constructs such as subgraphs and hyperedges.
In our view, while constructing diagrams using using general-purpose drawing tools can be very useful in the early phases of the language development process, it can become cumbersome and error-prone as the example diagrams and the DSL become larger and more mature - at which stage a transition to a language-specific modelling tool should be consider. To reduce the overhead of this transition, we plan to investigate inferring annotated metamodels that can then be consumed by tools such as Eugenia6 to automatically generate languagespecific model editors.
This research was part supported by the EPSRC, through the Large-Scale Complex IT Systems project (EP/F001096/1) and by the EU, through the Automated Measurement and Analysis of Open Source Software (OSSMETER) FP7 STREP project (318736). 6 http://www.eclipse.org/epsilon/doc/eugenia