Berichten met label tool
Added value of MDE tools: a customer perspective
Geplaatst door Andriy Levytskyy in MDD op 27 februari 2012
(cross-posted from blog.conceptworks.eu)
Recently I came across an interesting article by Jordi Cabot, in which he shares a tool vendor’s experience of high customer acquisition cost for MDD tools. In my opinion the main reason for this is that MDE is still not a mainstream methodology and hence benefits of MDD tools (and what it takes to reach those benefits) are often not clear to customers. This an issue I’ve had to deal with in all MDE-projects and currently in the CHARTER project, where Luminis is involved in industrial evaluation of an MDE tool-chain. In this post I would like to look at the problem from the customer perspective.
Figure 1: Customer processes and MDE tools
Given a large number and diversity of MDE tools (actually too many, one may argue), it is impractical to list added value cited by their vendors. Moreover, added value is per definition subjective to customer’s opinion. Instead I would like to step back and place these tools in customer’s context. For this I will use a simple classification model that partitions all customer processes and tools supporting them in four quadrants (see the figure). There are two dimensions: uniqueness (core/context) and technology (problem/solution). Core represents unique processes that are specific to a customer, which is in contrast to generic processes in Context. Customer’s business processes are found in category Problem. Solution is reserved for IT or Engineering processes supporting the business processes.
The four quadrants in the figure help to reason about the value of customer processes and tools. The most important are the core quadrants as these define the customer itself. Depending on the type of the customer’s industry, critical processes are found either in the 1st (service-oriented) or the 3rd quadrant (product-oriented). The context quadrants have the least value. Here customers often seek to outsource processes or purchase generic off-the-shelf solutions.
The following is a summary of MDE value for customers, based on my personal experiences in the four quadrants:
- Q4 is the hardest to sell. The reason for this is that here MDE provides a generic solution for a solution to a business problem. In other words, an unknown (and therefore regarded risky) MDE tool has to compete against multiple possible solutions that customer is more comfortable with. These include alternative mainstream technologies, in-house frameworks and run-time platforms, and even business changes that may cut ground from under the foot a tool vendor might have in the customer’s door. Warm reception by end users that love tinkering with their own ad hoc productivity solutions, is not guaranteed (not to mention their concern of becoming unneeded). Moreover, any MDE gains achieved in Q4 are likely to be watered down by waste in customer processes elsewhere. Industrial practices show that successful MDE application results in maximum 30%-40% faster overall development. These gains are among the lowest in MDE (compare these with up to 10x acceleration reported in Q1). Moreover, these gains are further relatively reduced when contrasted against alternative solutions. Last but not least, value of the initial gains is the hardest to demonstrate (you may discover that your stakeholders are not even aware of real business problems). The same stakeholders have the weakest influence over budget. It really looks like odds are against MDE tools in this quadrant today. Still, organizations without core processes, e.g. startup customers or customers developing one of a kind systems, may be interested in MDE tools here.
- Q2: MDE tools are typically not found here.
- Q3: This is the place of unique processes and numerous stakeholders from various domains: engineering disciplines (software development being one of them), architecturing, system design to name a few examples. Here MDE tools together with process optimizations can produce dramatic overall improvements (especially in product-oriented industries), which can be measured and linked to business needs recognizable by the customer. However, processes here are often knowledge-intensive and free-form, which makes the road towards these improvements longer and more complex compared to Q1, where processes are more structured and information-intensive. Off-the-shelf fixed MDE solutions are at disadvanage here.
- Q1 is the easiest for customer acquisition. Tool vendors can produce proofs of concepts in really short sprints (typically up to two weeks), deliver never seen before results (e.g. up to 10x faster development), directly relate these results to real business needs (usually falling under the business agility umbrella, but also including the more common T2M and cost reduction benefits) and have the shortest lines to budget holders. It is no wonder that vendors in this quadrant report numerous successes and are even able to grow under currently declining economic conditions.
So what kind of MDE tools are found in these four quadrants? Figure 1 illustrates my attempt to classify the tools. (This classification provides sufficient coverage and is by no means exhaustive.) The categories are:
- CIM tools are fixed business modelers with interpretation or code generation capabilities. Modifier CIM (Computation Independent Model) stresses that these tools focus on business solutions and isolate users from developing source code. Well-known examples come from Mendix and OutSystems.
- OTS are off-the-shelf applications that support generic business processes. Examples include CRM, ERP, Office and Simulation packages.
- DSM tools are language workbenches that enable customers define their own domain-specific modeling (DSM) and transformation processes. Typical tools in this group are MetaEdit+, Obeo Designer, oAW, AToM3, etc.. Note that while application of DSL tools in quadrants 1 and 2 is not unimaginable due to adaptability of such tools, there is not much “meta-” variability and too much integration complexity to justify such application.
- PIM tools are fixed UML modeling tools with (generic) code generators for one or more software technology platforms (e.g. .NET, Java, PHP). Modifier PIM (platform-independent model) indicates that users are at best isolated from details and differences of the platforms. Numerous examples can be found be found here.
Since I’ve mentioned the CHARTER project, it would be natural to place its tool-chain (aka CTC) in Figure 1 as well, especially because it presents an exception to the above experiences. CTC provides support for Java source code verification, testing and compilation, which are generic processes, thus placing CTC among PIM tools in Q4. However, due to restrictions that safety critical systems impose on those processes, there are no alternatives currently available. This coupled with huge error costs in such systems, significantly increases the tool-chain’s value for its potential customers.
Conclusion
In conclusion, I agree with Jordi that the cost of customer acquisition is high. However the situation is not the same for all MDE tool vendors. Those behind CIM tools, enjoy impressive interest from business customers. Their successes are responsible for the current breakthrough in popularity of MDE. Life is the most difficult for PIM tool vendors as too many factors may work against their tools in customer context. Moreover, they face competition from more versatile DSM tools. Last but not least, DSM tools can provide impressive benefits in Q3 (especially in product-oriented industries), but require that customer first commits to learning its own often knowledge-intensive processes. In my opinion, this quadrant and DSM tools are the stage for the next MDE breakthrough.
A necessary disclaimer is that the above conclusions are based on my own limited experiences. If you are an MDE tool vendor, customer or MDE professional, I would love to hear your opinion!
AToM3 0.2.2 Language Workbench Evaluation
Geplaatst door Andriy Levytskyy in MDD op 28 december 2011
AToM3 is a language workbench developed at the Modelling, Simulation and Design Lab (MSDL) in the School of Computer Science of McGill University. Please note that the reviewed version is not the latest (0.3).
The focus of the review is the language workbench capabilities, that is everything related to specification of modeling languages and automated processing of models.
Freeform Multilingual Modeling
In AToM3, models (and metamodels) are visually described as graphs. There is no support for spatial relationships, such as containment or touch. While position of modeling elements may seem to imply spatial relationships among them (e.g. among a software component and a port), AToM3 does not recognize, maintain or process such relationships.
Modeling is performed by means of a visual editor: one selects a modeling concept from one of possibly multiple language toolbars (to the left of the canvas) and places (instantiates) it on the canvas. Any language toolbar can be easily removed or added by closing or opening its language-specification file. Furthermore, the toolbar itself is defined by a model in a so-called “Buttons” DSL (see Figure 1). At any time, the modeler is free to edit this model to e.g. arrange buttons in one or multiple rows, remove language concepts or specify additional buttons to launch transformations frequently used with the given language. Both language specification and toolbar files are generated by AToM3 from the language model (aka metamodel). Language independent tools like Edit, Connect, Delete form the general modeling toolbar (above the canvas).
A special feature of AToM3 is a freeform multi-language canvas. AToM3 breaks with the tradition of “strongly typed” diagrams that prevent intermixing modeling elements if not explicitly allowed by the diagram’s metamodel type. AToM3 canvas can be considered a diagram that allows any modeling elements. However, elements can only be connected if their metamodel allows this. Such canvas provides users with a high degree of modeling freedom. (As illustration of this freedom, AToM3 logo itself is a freeform model done using 5-6 DSLs). Furthermore, because models are not fragmented among islands of diagrams, information access is optimal. Another benefit is less effort on the metadeveloper’s part because a freeform model can be handled by a transformation without the prior need of metamodel integration.
Unfortunately as models grow in size and number, the single canvas does not scale well, nor does AToM3 provide the user with means to manage them.
AToM3 uses this editor and the freeform canvas in a few different contexts. The primary role is a modeling editor, however the same editor is used for metamodeling and specifying transformation definitions. Such reuse reduces the learning curve and more importantly, brings the benefits of a domain specific modeling environment and the freeform canvas to metadevelopers as well.
Language Specification
AToM3’s metalanguage is based on the Entity Relationship (ER) formalism. In order to provide complete metamodeling capabilities, concepts Entity and Relationship are extended with constraints and appearance properties (see Figure 2). Property constraints is used to define static semantics. Appearance defines visual presentation or concrete syntax of a language concept.
AToM3 provides overall excellent metamodeling capabilities that enable metadevelopers produce level 5 quality metamodels. The following details these capabilities.
Abstract Syntax
For this task metadevelopers are equipped with the ER-based metalanguage, which is very close to conceptual modeling techniques, such as ORM. This means that there is a minimum gap between conceptual, business world-oriented models and AToM3 metamodels. In fact, AToM3 abstract syntax models are surprisingly simple and void of technical details typical for metamodels, which makes the models very readable by subject experts. Figures 2 and 4 of the Curriculum Content Sequencing (CCS) demo illustrate this point.
Concrete Syntax
A simple but sufficient editor allows to define a vector presentation for a language concept. Figure 2 shows all that the editor has to offer.
Static Semantics
The constraints property contains rules that control how a modeling element can be connected to another element to form a meaningful composition. Such rules can be defined per language concept or a model and triggered by editor events (e.g. edit, save, transformation start) or on demand by user, thus covering all imaginable ways to invoke model checking.
AToM3 constraint language is Python, which is an unusual choice. Indeed, Python is not a constraint language, not formal (in the model-driven sense), and has side effects (AToM3 is written in Python too). However, my experience with AToM3 showed that none of those are real disadvantages in practice: Python is known for a concise and easy to read syntax and as constraint language, is intended for metadevelopers (who know how to deal with side-effects). In this role, Python proved to be powerful, flexible and efficient.
Dynamic Semantics
AToM3 uses a common approach to define DSL semantics by translating language concepts to concepts in another target domain with predefined dynamic semantics (e.g, C++, Java). This approach is known as translational.
Another less common approach supported by AToM3, is by modeling the operational behavior of language concepts [1]. The operational semantics approach specifies how models can be directly executed, typically by an interpreter. Such specifications are expressed in terms of operations on the language itself, which is in contrast to translating the language into another form. The advantage is that operational semantics are easier to understand and write. The disadvantage is that interpreters are normally not available for DSLs due to the very specific nature of the latter. (For an AToM3 illustration of how to build a custom interpreter in a model-driven way, please refer to this article.)
In AToM3 translational and operational approaches are implemented as transformations.
Transformation
AToM3 employes the graph rewriting approach to transform models. Transformations themselves are declaratively expressed as graph-grammar models. My experience with transformation models written in imperative languages (e.g. QVT Operational, MERL) is that more time is spent figuring out how to navigate host model structure to access right information than actually specifying what to do with this information. Declarative approach like that of AToM3, frees the metadeveloper from having to specify navigation, thus drastically reducing complexity of transformation modeling.
To define a transformation in AToM3, one needs to create a graph grammar and specify one of more GG rules. Figure 3 shows a GG model for the export transformation in the CCS demo. Each rule specifies how a (sub)graph of a so-called host graph can be replaced by another (sub)graph. These (sub)graphs are respectively called the left-hand side (LHS) and the right-hand side (RHS). A rule is assigned an order (priority), a condition and an action. In AToM3, conditions and actions are programmed in Python. As in the case with the constraint language, Python performs very well in these roles too.
A special feature of AToM3 is that both LHS and RHS can be modeled with the DSL(s) of the host graph. In fact, the (sub)graph editor is based on the above mentioned model editor, and provides the metadeveloper with the freeform multilingual canvas, customizable language toolbars and transformations. The consequence is that it is very easy to construct sub-graphs and verify them with subject experts.
An interesting feature of AToM3 transformation system is that it does not feature transformation parameters. This may seem limiting, however an equally effective alternative is to store “parameter” information in a model. The AToM3 canvas makes it extremely easy to mix such “parameter” model(s) with a host model and pass them to a transformation. Figure 4 shows a sequencing model from the CCS demo together with a repository model (top left corner of the canvas). Given both, an export transformation can access the remote model repository, pass authentication, and store the sequencing model at the repository.
Another interesting feature is that transformation input can be also an element selected by users (unfortunately multiple selection does not work in this version). A promising application thereof is user-defined in-place transformations that automate frequent and routine modeling operations. For example, decomposing a group element into constituent objects (and vice-versa) with a click of a button. Industrial users that often work with large models would really appreciate the resulting reduction of repetitive strain.
Finally, AToM3 supports nearly all transformation kinds known to the author [2, 3]. It is easier to list what is unsupported: text-to-model and text-to-text (which is a consequence of the graphical nature of the language workbench), and the more exotic synchronization and bidirectional kinds. Due to its graph rewriting system, AToM3 is very strong in model-to-model (M2M) and model-to-text (M2T) transformations. A GG-based support for the latter, very popular category, is not obvious and therefore warrants an extra explanation.
M2T Transformation
In AToM3 M2T means producing textual structures from graph structures. One way of doing this is via a transformation where the source and the target models are the same. Rules of such transformation do not perform any important rewriting, but use the graphical nature of the source language to traverse and annotate the source model with temporary information that is needed for text generation. Text itself is generated by side-effects encoded in actions of rules, which can access the annotations.
A typical M2T application is code generation. An example of a non trivial code generation made with AToM3 is ZCase, a software factory for Zope. In the CCS demo, ZCase is a part of the ER→Zope transformation chain.
Conclusion
The is no escaping the fact that AToM3 is a research tool and is not suitable for demanding industrial use. The workbench does not scale well for large models (both in terms of performance and user controls) and its tools are basic. There is no reliable support, no up-to-date exhaustive documentation, no collaborative development, no integration with version control and requirement management systems, and naturally plenty of bugs and annoyances. In short, the tool is far from being mature and ready for industrial users.
However, metadevelopers may find the above drawbacks quite tolerable, because they are better prepared to deal with technical issues and metamodels typically do not stress the tool’s scalability. On the positive side, AToM3 provides simple but optimal tools and set of features that work together to create one of the most robust and powerful language workbenches I know. Thereby AToM3 is extremely suitable for agile, responsive and timely development. Due to the maturity level of the workbench, its application is best limited to proofs of concept. To date, AToM3 is the language workbench of my choice for quick prototyping.
AToM3 is recommended to MDE students, analysts in need of quick prototyping and tool vendors seeking to improve their language workbenches. In my opinion, AToM3’s metamodeling and transformation technology is nearly optimal, and is still ahead of the larger and more inert commercial workbenches. While its problems are numerous, they are run-of-the-mill and knowledge and technologies to address them are commonly available. If these problems could have been removed, then AToM3 would have been the tool I could have easily recommended to industrial customers too.
References
[1] Tony Clark, Andy Evans, Paul Sammut, and James Willans. Applied Metamodelling: A foundation for Language Driven Development. Version 0.1. Xactium Ltd., 2004.
[2] Krzysztof Czarnecki and Simon Helsen. Classification of model transformation ap- proaches. In Jorn Bettin, Ghica van Emde Boas, Aditya Agrawal, Ed Willink, and Jean Bezivin, editors, 2nd OOPSLA Workshop on Generative Techniques in the Context of Model-Driven Architecture, Anaheim, CA, October 2003. ACM Press.
[3] Tom Mens, Krzysztof Czarnecki, and Pieter Van Gorp. Discussion – a taxonomy of model transformations. In Jean Bezivin and Reiko Heckel, editors, Language Engineering for Model-Driven Software Development, volume 04101 of Dagstuhl Seminar Proceedings, Dagstuhl, Germany, 2005. Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany.
CHARTER Surveillance Use Case – Industrial Evaluation
Geplaatst door Andriy Levytskyy in MDD, Uncategorized, java op 10 oktober 2011
This month, Luminis has started development of a surveillance use case. The purpose of the case is industrial assessment and validation of tools and technologies developed in the “Critical and High Assurance Requirements Transformed through Engineering Rigor” project (CHARTER). The ultimate goal of CHARTER is to ease, accelerate, and cost-reduce the certification of embedded systems. The CHARTER tool-suite employs real-time Java, Model Driven Development (MDD), rule-based compilation and formal verification. The coming series of articles will describe evaluation experiences in the surveillance use case.
The CHARTER project includes user partners from four key industries: aerospace, automotive, surveillance and medical, each of which develops embedded systems that require high assurance or formal certification in order to meet business or governmental requirements. The four user partners will each validate the CHARTER tools and methodology using industrial applications and actual development scenarios, which will provide feedback for the project and ensure the tools and technologies perform as expected, and deliver the expected improvements in embedded systems development. As part of the evaluation process, metrics will be used to quantify industrial experiences in terms of development effort, cost savings, verification time, etc., to document for others the benefits achieved.
The CHARTER project was established to improve the software development process for developing critical embedded systems. Critical embedded software systems assist, accelerate, and control various aspects of society and are common in cars, aircraft, medical instruments and major industrial and utility plants. These systems are critical to human life and need to be held to the highest standards of performance through formal certification procedures. Improving the quality and robustness of these systems is paramount to their widespread adoption.
Measuring Quailty of a Metamodel
Geplaatst door Andriy Levytskyy in MDD op 31 juli 2011
Nowadays DSLs seem to be everywhere. If 5 years ago DSL was an exotic word in the UML dominated model driven world, today it has established a strong following. A recent research on how MDE is used in industry [1], indicated that nearly 40% of respondents use in-house DSLs (alongside of other languages). The in-house qualifier is important, as these DSLs are very likely to be developed with metamodels. In such cases, a quality benchmark may help language development. Yet, it is not easy to find such a benchmark, let alone one that is widely accepted.
Five levels of Metamodelling
One quality benchmark that I found useful is described by Tony Clarks et. al in [2]. The authors define 5 levels of quality. These briefly are:
- The lowest level: a simple abstract syntax is defined, but not implemented yet in a tool. The static and dynamic semantics of the language is informal and incomplete. There is no specific tool support: an existing language is repurposed, compliance with the DSL is manually maintained and models are mostly interpreted by users.
- At this level, the abstract syntax and static semantics have been largely defined, implemented in a tool and validated. The dynamic semantics is still informally defined.
- The abstract syntax is completely implemented and tested. Concrete syntax has been defined for the language, but not implemented yet. Optimization of the language architecture has started.
- The concrete syntax of the language has been implemented and tested. Users create models either visually and textually. The language architecture has been optimized for reuse and extensibility. Tool support for dynamic semantics begins to appear.
- The topmost level: all aspects of the language have been modeled, including its semantics. Models written in the language can be processed by the tool. Examples thereof include code generation, execution, simulation, verification. The language architecture is well optimized for reuse.
While the original intention of the benchmark was to assess metamodels, I found it also useful for estimating metamodelling capabilities of MD tools. If a tool is not capable of supporting development needs for a certain level, then that level will be the quality ceiling for all metamodels defined with the tool. In my experience, DSLs in traditional (fixed method) CASE Tools do not achieve level greater than 1. Metamodels in UML tools often do not reach level 4 (and often lack static semantics and concrete syntax). Language workbenches can typically produce level 5 metamodels.
Conclusion
The referenced benchmark provides a first order approximation of quality of metamodels. Furthermore, these 5 levels provide those looking for MDx technology, with a simple framework at least to question the marketing information by tool vendors. In my opinion this benchmark may be a useful ingredient in an answer to a more general question of comparing MD technologies.
What are your experiences with measuring quality of metamodels or comparing metamodelling capabilities of MDx tools? Which aspects are you interested in and how do you measure them?
References
[1] John Hutchinson, Mark Rouncefield, Jon Whittle, and Steinar Kristoffersen. Empirical Assessment of MDE in Industry. ICSE 2011.
[2] Tony Clark, Andy Evans, Paul Sammut, and James Willans. Applied Metamodelling: A foundation for Language Driven Development. Version 0.1. Xactium Ltd., 2004.
Image by Aqua
How to build a custom model interpreter in a model-driven way
Geplaatst door Andriy Levytskyy in MDD, Uncategorized op 20 juli 2011
Blogs by Johan den Haan, Stefano Butti and Jordi Cabot raised interesting discussions about code generation (CG) and model interpretation (MI). One observation I took from these discussions is that MI is still little known. Previously I demonstrated operation of a custom-made model interpreter for a so-called weighbridge domain. Today I would like to share my experience of building this interpreter in a model-driven way.
MDE Approach
Two main choices underpin the process and technology used to develop the interpreter:
- Execution semantics of the interpreter is defined within the problem domain itself (weighbridge in this case), without translating it to another domain (e.g. .Net or Java) as it is the case with CG. Such definition of semantics is also known as operational semantics. The advantage is reduction of development complexity: out of at least 2 domains needed for CG, only one and the more abstract domain is sufficient.
- Operational semantics is defined within an MDE framework. This enables customization of modeling language for problem domains besides that of the weighbridge example. Moreover, transformation capabilities are used to define operational semantics.
Figure 1: Domain-specific, nested interpretation (DSNI) MDE framework
Figure 1 shows the MDA framework [1] after it has been adapted to reflect the above mentioned choices. (If you are confused between MDA and MDE, you might find this article useful.) In contrast to MDA, there is no PIM or PSM model, but single computational independent model (CIM) written in DSL. CIM is both source and target of Transformation Tool. Transformation Tool carries out transformation classified as same language, same model. Transformation Definition defines operational semantics. It is not important if Transformation Definition Language (TDL), extends the Metalanguage as in MDA or is customizable by means of meta-specification. Therefore TDL is omitted from the framework and TDL selection criteria are defined instead (see below). Finally, new concept System Context is connected to Transformation Tool. This is due to the fact that interpretation as system exhibits external behavior through communication with other systems.
This approach can be described as nested interpretation, where a domain-specific interpreter is executed (nested) by a generic interpreter. From this perspective, Transformation Tool assumes the role of a generic interpreter and execution of Transformation Definition fills in the role of the domain-specific interpreter.
TDL Selection Criteria
Selection criteria for transformation definition language are:
- declarative modeling
- support for domain-specific notation
These criteria help to reduce development complexity and improve communication with problem domain experts.
Selected MD Technology
AToM3 is a free language workbench written in Python and under development at the Modelling, Simulation and Design Lab (MSDL) in the School of Computer Science of McGill University. The workbench closely matches the DSNI framework and meets the TDL selection criteria.
In AToM3, DSLs and models are described as graphs. From a language specification written in the metalanguage (ER formalism), AToM3 generates a tool to visually manipulate (create and edit) models written in the specified DSL. Model transformations are performed by graph rewriting. The transformations themselves can thus be declaratively expressed as graph-grammar models. However, AToM3 provides no communication infrastructure as needed by the framework.
Proof of Concept
As demonstration, a language specification for the weighbridge domain was defined (see sections domain and weighbridge DSL here) and graph rewriting was used to model operational semantics (see below). Source code of AToM3 itself, being written in Python, was extended to support web services for the communication purpose.
Operational Semantics
As blueprint for operational semantics of the interpreter, we took πDemos [2], a small process-oriented discrete event simulation language. There is a number of πDemos events that change state of a weighbridge system. For each such event, [2] defined the transitions induced on system state. While the original used functional programming language, this work uses graph rewriting and a graph grammar (GG) rule is defined per event.
| Priority | GG Rule | Description |
|---|---|---|
| 50 | importProcess | Adds an external vehicle to EL |
| 25 | removeProcess | Deletes a vehicle that has completed its todos (events) |
| 40 | newR | Creates a new weighbridge |
| 40 | decP | Creates a new vehicle class |
| 40 | newP | Creates a vehicle from a vehicle class |
| 40 | getR | Acquires a non-busy weighbridge |
| 40 | blockProcess | Blocks a vehicle acquiring a busy weighbridge |
| 40 | promoteProcess | Unblocks a delayed vehicle |
| 40 | useR | Moves a vehicle on a weighbridge until service is complete |
| 30 | releaseResource | Moves a served vehicle from a weighbridge to EL |
| 41 | putR | Releases an occupied weighbridge |
Table 1: Graph grammar rules of weighbridge events
Table 1 lists the minimum set of required events and their corresponding GG rules. Execution of such rules needs to be globally orchestrated through proper sequencing. The rules, together with execution sequencing, form an operational semantics model of the interpreter.
For complete description of the model, please refer to [3]. In the following, we present a detailed description of an example rule, followed by the execution sequencing model.
Example GG Rule
a) Left-hand side (LHS)
b) Right-hand side (RHS)
Figure 2: Subgraphs of the promoteProcess rule
Rule promoteProcess releases a busy weighbridge (bluish box in Figure 2a) that delays at least one vehicle (yellow box labelled 5). In the new state, the weighbridge remains busy and the blocked vehicle (5) is removed from the head of queue Delay and inserted in waiting queue EL.
The rule is executed if:
- The left-hand side (LHS) shown in Figure 2a is matched in the host graph (the CIM model).
- Associated condition is true: the weighbridge in LHS is the one referred to in the imminent event putR (a todo) in the body (a todo list) of the first vehicle (label 21) in queue EL.
If the above holds, the matched part of the CIM model is substituted with the right-hand side (RHS) shown in Figure 2b. Note new objects are labelled 10, 11, 13. The entities and relationships in RHS are initialized as follows:
- Objects copied from LHS keep all their properties.
- Imminent event putR (a todo) of the current vehicle (21) is completed.
- All properties of blocked vehicle (5) are copied to vehicle (10).
Execution Sequencing
The execution sequencing is based on the next-event approach: Next event to execute is always the imminent event in the body of the current vehicle. Informally, the operational semantics of execution sequencing is as follows: if EL is empty, interpreter idles until at least one vehicle is inserted in EL. Such vehicle becomes current. If the body of the current vehicle is empty then it is removed from EL and EL is examined again. Otherwise, interpreter executes a GG rule corresponding to the imminent event of the current and EL is examined again. Note that whenever interpreter is idle, EL is being updated with new vehicles that meanwhile might have arrived from system context.
The execution sequencing is implemented by organizing GG rules into groups, each group having its own base priority. These groups, in the descending order of priority are: vehicle removal, weighing activities and vehicle arrival. Within a group, each rule is assigned a relative priority. If pattern matching of two and more rules within a group is deterministic on the basis of LHSs and conditions, then these rules can share the same priority level. Example rule priorities are given in Table 1.
Conclusion
The demonstrated development approach is characterized by a very high level of abstraction, direct involvement of problem domain experts and absence of software development. All these factors contribute to fast development times: The lead time of this one man project including research and development was 3 weeks. Admittedly, tests of the produced model interpreter showed noticeable performance penalty due to 1) repurposing of MD technology that was not designed for use as interpreter and 2) the overhead introduced by nested interpretation. In my opinion there is much room for performance improvement and I am wondering if MDE can prove useful again. An important message from this experience is that model interpretation does not have to be prerogative of big commercial tools and can get closer to code generation in terms of accessibility.
References
[1] Anneke G. Kleppe, Jos Warmer and Wim Bast. “MDA Explained: The Model Driven Architecture: Practice and Promise”. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, April 2003.
[2] Graham Birtwistle and Chris Tofts. “An operational semantics of process-oriented simulation languages: Part 1 πDemos”. ACM Transactions on Modeling and Com- puter Simulation, 10(4):299–333, December 1994.
[3] Andriy Levytskyy. “Model Driven Construction and Customization of Modeling & Simulation Web Applications”. PhD thesis, Delft University of Technology, Delft, The Netherlands, January 2009.
MetaEdit+ 4.5 Review
Geplaatst door Andriy Levytskyy in MDD, Uncategorized op 6 december 2010
MetaEdit+ DSM Environment by company MetaCase is a commercial language workbench that in contrast to inflexible CASE tools, enables users to build their own modeling and code generation tools (aka DSM tools). It comes in two main product components:
- MetaEdit+ Modeler provides customizable DSM functionality for multiple users, multiple projects, running on all major platforms.
- MetaEdit+ Workbench i) allows building custom modeling languages (DSLs), and text generators and 2) includes the functionality of MetaEdit+ Modeler and MetaEdit+ API (the latter is not reviewed in this document).
This review is written from the MDE perspective and will cover major MDE functionally related to specification of modeling languages. For a complete picture of MetaEdit+, readers are advised to consider other aspects (e.g. collaboration, versioning, etc…) as well.
This review covers MetaEdit+ Workbench version 4.5.
Language Specification
MetaEdit+ supports graph-like visual languages represented as diagrams, matrixes or tables. There is a limited support for spatial languages: touch and containment relationships are derived from canvas coordinates of modeling elements. There is no actual tool support to preserve these relationships: for example, as a modeller moves a “container” element, contained elements do not move along as expected, but remain at old coordinates.
In MetaEdit+, languages are specified with a set of specialized tools. In the following, we describe the tools per each aspect of the visual language definition: abstract syntax, concrete syntax, static and dynamic semantics.
Abstract Syntax
This aspect is defined with GOPPRR metatypes. GOPPRR is an acronym for metatypes Graph, Object, Property, Port, Role and Relationship. For each metatype, there is a form-based tool, e.g. Object tool allows specification of object types and Graph tool allows assembling types produced with the other tools into a specification of abstract syntax. GOPPRR tools support single inheritance.
Graph tool also allows linking DSL objects to graphs of other DSLs through decomposition and explosion structures. Furthermore, through sharing language concepts (of any OPPRR metatype) among graphs, DSLs can be integrated so that changes in one model can be automatically reflected in models based on different languages.
An alternative to these form-based tools for abstract syntax specification is a visual metamodeling DSL. However, this functionality is best used as easy start-up leading to automated generation of barebone GOPPRR metamodels. Once a language developer changes a GOPPRR metamodel (which is inevitable), visual metamodeling is best discontinued to avoid manual round-trip between the two metamodels.
Concrete Syntax
By default, MetaEdit+ provides generic symbols. However, language developers are free to specify custom symbols for objects, roles and relationships. These symbols are either defined with a WYSIWYG vector drawing tool or imported from vector graphics (SVG) or bitmap files. Symbols can display text, property values and dynamic outputs produced by text generators (more on generators in section M2T Transformation). Moreover, symbols or their parts can be conditionally displayed. Finally, symbols can be reused among different DSLs via a symbol library.
MetaEdit+ does not directly support multiple concrete syntaxes per language, which (the lack of such support) is still a common practice among language workbenches. However, its capability to display symbols based on conditions allows to work around this limitation.
Static Semantics
This aspect covers constraints and business rules. The purpose of these rules is to ensure a consistent and valid model.
In general, DSM tools should verify a model against the static semantics of its DSL at different times. These times can be classified as ‘live’ (i.e. when a user is modelling) and ‘batch’ (i.e. invoked on events caused by actions such as user demand, model saving or transformation). Furthermore, tool actions following violation of a constraint can be classified as prevention (i.e. a violating action is canceled and a warning message is displayed) or merely informative (i.e. a violating action is allowed, but model will display clues about invalid constructions until the effect of the action is corrected).
MetaEdit’s Constraint tool (available from the Graph tool) allows ‘live’ checks against constraints and preventive protection of models (‘live’ and ‘preventive’ in the terms of the above classifications). The tool is very expressive and easy to use, but covers only limited number of types of constraints, namely:
- object connectivity in a relationship
- object occurrence in a model
- ports involved in a relationship
- property uniqueness
More advanced constraints have to rely on MERL generator (see section M2T Transformation), which can inform users about invalid constructions during modeling (‘live’ and ‘informative’ in the terms of the above classifications). MERL generator can also be used for ‘batch informative’ and ‘batch preventive’ checks: a checking report can be run on demand or included as preventive check before any other transformation is carried out.
Dynamic Semantics
MetaEdit+ can define dynamic semantics through a process of translating DSL concepts to concepts in another target domain with defined dynamic semantics. Examples of target domains in code generation applications are e.g. C++ or Java. A major benefit of language workbenches is that they are capable of automating this and other useful kinds of processes.
PROCESS AUTOMATION
MDE applications need capabilities to automate processes in which models are inputs and outputs. MetaEdit+ provides various levels of support for model-to-model (M2M), model-to-text (M2T) (e.g. in code generation applications) and text-to-model (T2M) (import of legacy code, data type definitions, etc. into models) types of transformations. (The latter transformation type is not reviewed.)
M2T Transformation
Text (and more specifically code) generation is accomplished with Generator tool that can efficiently navigate models, filter and access information, and output text into external files, Generator Output tool and DSL symbols. All these tasks are specified with imperative language MERL. While MERL is very concise and efficient for most of these tasks, I think that navigation and access tasks are better accomplished in a declarative way.
MERL generators are defined per graph type (i.e. per DSL) and can be acquired from supertypes of a given graph type via an inheritance hierarchy. If a generator has to be used for different graph types, then the generator should be defined for the common parent graph type. On the other hand, DSL developer can define new or redefine generators already provided by parent graph types.
Finally, MERL provides support for modularization by allowing includes of generators in other generators. Making modular generators pays off well, as there are many reuse opportunities in MetaEdit+: generators can be reused not only for text generation but also in concrete syntax (symbols) and validation/reporting purposes (symbols, generator output tool).
M2M Transformation
Models can be transformed 1) programmatically via the SOAP and WebServices-based API of MetaEdit+ (this option requires product component MetaEdit+ API) or 2) through code generation of an intermediate external representation (in the XML format) and consequent import thereof as new model.
These two options amount to a generic support at a minimum level that is commonly provided nearly by all language workbenches. Moreover, code generation of an intermediate representation cannot implement in-place M2M transformations, of which application examples are: model optimization, model layout, model interpretation, model weaving and any repeatable model manipulation in general.
OTHER
- DSL evolution: MetaEdit+ updates existing models instantly yet non-destructively to reflect changes in DSLs. The update policy ensures that models created with the older DSL versions are not broken and remain usable with existing generators. Instant update is also very useful when fine-tuning a DSL with end users.
- According to MetaCase, a MetaEdit+ project can hold over 4 billion objects. A typical project would contain about 40-100 models (graphs).
- In the multi-user version, users can simultaneously access and share all models within a Repository. Locking is made at the object-level, so several users could collaboratively work on the same model at the same time.
- Multi-user collaboration in MetaEdit+, product line analysis of commonality and variability and proper separation of concerns reduce the need for version control as it is known in software engineering. Therefore MetaEdit+ does not provide its own versioning system. Best practices for versioning with MetaEdit+ can be found here.
- Model interoperability: by default, all models and DSLs can be exported in an XML format. The schemas are very simple, which make it easy to post-process such files if needed. Moreover, the M2T transformation capabilities of MetaEdit+ enable DSL developers to easily create custom export generators.
CONCLUSION
MetaEdit+ is a versatile language workbench that enables building high quality visual DSLs for any kind of domain, be it technical or business. Another key quality of MetaEdit+ is efficient DSL/GOPPRR tools, which allow light-weight, agile and fast DSL development and evolution. A testament to this quality is the fact that MetaCase is one of few language workbench makers that routinely designs and builds DSLs in improvisation with audience at conferences, workshops, etc. In my opinion, this impressive productivity is possible because GOPPRR tools are based on paradigms that are optimum for DSL development (DSM for DSM so to speak).
Highlights of MetaEdit+ are:
- Proper level of abstraction: DSL developers are completely shielded from details of how DSM-tools are implemented. DSL development tools focus on essential abstractions for specification of languages and generators.
- High-levels of automation: DSM-tools are completely and automatically generated from abstract language specifications.
- High quality of tools: each DSL development task has its own dedicated tool.
- Numerous enhancements: high integration of tools, non-destructive evolution of languages, inheritance mechanism, reuse opportunities for types, symbols and generators, visual metamodeling, etc.
- Very cheap introductory license.
Naturally, there are a few drawbacks as well:
- No specific support for model-to-model transformation.
- Somewhat limited constraints support.
- Limited support for spatial relations.
- Uncommon user interface.
- Form-based GOPPRR tools prevent a global overview of a metamodel.
- Expensive standard licenses.
Code generation applications are the oldest tradition in MDE and this is where MetaEdit+ excels. As MDE discovers new applications, my experience is that the code generation specialization becomes restrictive. Admittedly, it is possible to implement some types of M2M transformations with code generation (via intermediate representation). However, the problem with this workaround is that it introduces accidental complexity both to MDE developers and more importantly to end users (that have to keep repeating the generate/import routine, sometimes complicated by model merge).
That said, in my opinion MetaEdit+ gets the big things right. Whether its shortcomings are little things is a subjective matter that is best evaluated in the context of a concrete problem domain.