Berichten met label dsl
An MDE Example: Curriculum Content Sequencing Application
Geplaatst door Andriy Levytskyy in MDD op 28 september 2011
The best way to explain MDE to someone without any model-driven experience is to involve in an MDE development. The second best, for which blog is a suitable medium, is to show examples. Today I would like to share an example of a simple MDE application and give a glimpse into work items and a process behind its development.
The application in question is an MDE implementation of a sequencing system described in [1]. The purpose of this MDE exercise was to quickly build something concrete that would help Luminis learn a new vertical domain.
Problem Domain and Demo System
Curriculum content sequencing (CCS) is an important pedagogical service. The purpose of this service is management of learning routes to help students achieve curriculum goals. An emerging trend in education is adaptive learning that is tailored to backgrounds and preferences of individual students. This is in contrast to the traditional way of content sequencing that usually prescribed a single learning route for groups of individuals. Advances in e-learning provide an excellent platform for adaptive content sequencing.
Figure 1: Use case diagram of the demo system
A use case diagram in Figure 1 shows actors and important services of a simple content sequencing system. These services are:
Capture sequencing content provides Sequencing Expert with tools to design content sequencing knowledge necessary to reach a curriculum goal.
Register learning units enables Materials Provider to connect leaning materials to nodes of content sequencing.
Suggest a learning route provides Student with a learning route tailored to the student’s curriculum competences, background and preferences. The service also suggests necessary learning units and their substitutions from other providers.
Problem Domain Ontology
Domain ontology is conceptualization of domain knowledge. Figure 2 shows an information model that captures ontology for the CCS domain. The model is created using the Object Role Modelling (ORM) methodology. Some readers may be also familiar with ORM’s close relatives from The Netherlands: NIAM and FCO-IM.
Figure 2: Ontology for the curriculum content sequencing domain
At this point a few disclaimers are due:
The model loosely conforms to ORM, namely main principles are followed, used notation is based on more popular UML and ER languages, and not all ORM tools are being employed (an example of an ORM tool in Figure 2 is relationship ‘succession’ that is objectified as an entity).
The model itself is not complete. Moreover, it cannot be claimed correct, as the model was not verified with subject matter experts. However, the model is sufficiently accurate for the purpose of the demo (see above).
Design
The system illustrated in Figure 1 is partitioned in 2 parts: a domain specific modeling environment (DSME) for Sequencing Expert and a web-based CMS for Student and Materials Provider. Both parts can import/export curriculum content sequencing designs from each other. Each part provides the actors with rich environment and enables reuse of generic services that are relevant to the application, e.g. user management, document flow, security, content search. Any application-specific functionality that changes frequently during the application’s life-cycle was engineered with models, otherwise programmed. Such points of frequent change are known as variation points.
Figure 3 shows the system parts, variation points (shown as boxes) and activities (diamonds) related to changes in the variation points. These are laid over the OMG’s four modeling layers (labeled M0-M3). Variations at level M1 are part of the normal application operation. Here Sequencing Expert and Materials Publisher define sequencing designs and learning units (LU) respectively. Variations at level M2 occur when domain definitions (see Figure 2) change, e.g. as developer’s understanding of the CCS domain evolves. These are changes to the system itself and are carried out by developers during development or consequent system updates. Grayed out shapes at M0 and M3 are system and technology related variation points that do not change once chosen.
Figure 3: System parts, modeling architecture, variation points and change processes
Changes at level M2 are expensive and (given the experimental nature of the demo) frequent. Therefore these are best reduced or avoided. The direction of development activities implies that there is a single source of M2 changes, from which all the others can be derived. MDE is applied to isolate this source of change within a model (see Metamodel in the figure) and automate related development activities by means of transformations.
The following are selected technologies:
- AToM3 ─ a language workbench. AToM3 uses Entity-Relationship (ER) and Graph Grammar (GG) as Metalanguage and Transformation definition language respectively. AToM3 is used as language workbench in (model-driven) development and as domain-specific modeling environment (DMSE) for Sequencing Expert.
- Zope ─ a web application server that is typically used as intranet and extranet server, document publishing system, portal server and platform for collaboration. In this application, Zope provides a web-based CMS for Student and Material Provider.
- ZCase ─ a model-driven software factory for code generation of Zope document types.
- Python for development other than model-driven.
With these solutions and technologies in place, the following is left to be developed:
- Metamodels for sequencing designs and learning units (see Figure 2).
- A transformation bridging the gap between AToM3 metamodels and ZCase, thus forming a complete transformation chain Model→Code.
- Import/export routine between AToM3 and Zope
- Simple web-interfaces and document search for Student and Materials Provider
The last two items were trivial to implement. Item 2, while simple, requires introduction of new material (namely ER, Class diagrams, Zope, ZCase, Python) for explanation. For these reasons items 2,3 and 4 will not be covered in the article.
Capturing Sequencing Designs
With the selected technology we can now define a DSL for capturing sequencing designs in AToM3.
Figure 4: CCS metamodel
Figure 4 shows a CCS metamodel written in ER. Note, that the screenshot shows only the abstract syntax, but the other aspects (see metamodelling quality) are defined as well. The quality of the metamodel is at level 5.
Using language workbench capabilities and the above metamodel, AToM3 configures itself into a dedicated modeling environment for curriculum expert. (This configuration is implemented by AToM3’s own transformation Generate DSME.)
Figure 5: A learning sequencing design for the first grade mathematics course
Figure 5 is a screenshot of the CCS modeling environment at work: Left vertical toolbar contains buttons for every modeling concept defined in the CCS metamodel. Top horizontal toolbar contains generic modeling tools, Edit and Connect in particular. In AToM3 modeling is performed by means of a visual editor: one selects a modeling concept, places it on the canvas and modifies its properties with the Edit tool. Further on, such created instances of modeling concepts can be coupled using the Connect tool. An example of such a visual model is a sequencing design for the first grade mathematics course, shown on the canvas of DSME.
Sequencing Designs in CMS
Given the CCS metamodel, transformation chain ER→Zope generates implementation of the corresponding document types for Zope. Figure 6 shows these document types as seen in CMS (see options in the drop down list). You may recognize the entities and relationships from the metamodel shown in Figure 4.
Figure 6: Sequencing document types available in CMS
These types allow curriculum experts to build sequencing designs in a web browser. A more convenient way is to transfer sequencing designs from the DSME part. This is achieved by executing an export transformation on a sequencing design in AToM3. The result of this transformation is a fully searchable CCS document stored as graph structure in Zope. For example, given the AToM3 model in Figure 5, export would create a Zope document of type Sequencing multigraph as shown in the figure below.
Figure 7: Sequencing expert view on a CCS document
Figure 7 shows the web-interface that represents a CCS document as graph structure, i.e. a set of edges and nodes. (A viewer which can display graph-like structures in HTML web pages would be more appropriate, but is not necessary for this demo.) Note that the structure and properties of the AToM3 model from Figure 5 are transferred without loss of information.
The document shown in Figure 7 can be changed online and downloaded (via export tab seen in the screenshot) as an AToM3 model. Consequently, the downloaded file can be loaded in AToM3 for editing, thus closing the import/export round-trip.
Learning Unit Registration
Figure 8: Learning Unit metamodel
Learning Unit is a simple and atomic Zope document type, whose AToM3 metamodel is shown in Figure 8. LU Zope type is generated and its instances are created, searched, read, and modified similar to those of the CCS document types. A simple web interface is sufficient for Material Provider.
Obtaining Learning Routes
Currently, this service has a very basic recommendation mechanism:
- Sequencing designs are searched to match query parameters.
- No account is taken of student’s curriculum competences, background and preferences (and there is no student profile).
The above screenshots illustrate the current functionality: The first is the web interface that allows students to define search parameters and displays search results. The next is the web view of the sequencing design previously shown in Figure 5. Selecting any node of the design, will display information about the sequencing node and suggest learning units and their substitutions from alternative materials providers (see the last screenshot).
Summary
In conclusion, I would like to highlight a few points about this MDE application:
The complete development of the application took about 2 man-week. The real power, however is how fast the application can be updated as the knowledge of the application domain evolves: a matter of an hour given even drastic changes in metamodels. This efficiency is possible due to application of the SSoT principle, proper abstractions and automation: Effectively, two separate PSM developments were replaced by a single PIM development, from which code is generated for two platforms (AToM3 and Zope).
In development of this application, off-the-shelf MDE frameworks were reused (namely AToM3 and ZCase) and traditional development process was interwoven with development of missing model-driven assets (metamodels, ER→ZCase transformation). The latter is a software development process too, and as a matter of fact, followed OMG’s CIM/PIM/PSM process architecture.
Naturally, development of model-driven assets has its particularities as well. For one, there is a much stronger isomorphism between objects in the world of application users and domain concepts in model-driven artifacts. Therefore, role of analysis models, such as shown in Figure 2 is more important than in the more requirements-oriented traditional development.
This demo provides extremely simplified service for learning route recommendation. Recommendation algorithm depends on the information structures and is sensitive to changes in those structures as well. The service is in fact a model interpretation, where model is a CCS design and a Student profile. A possible MDE approach to building an application-specific interpreter is described here (but be sure to read the approach’s limitations as well).
Developed metamodels reach level 5 of metamodeling quality. This topmost level means that all aspects of the language have been modeled, including its semantics. In this demo, semantics of ER was defined by using the translational approach, that is by translating ER concepts to Zope and AToM3 concepts that have precise semantics. Figure 3 shows these translations as Model→Code and Generate DSME activities. This illustrates that a language can have multiple semantics.
The demo also showed that modular transformations can be reused to form new transformation chains. Case in point is how ZCase was integrated in ER to Zope transformation by means of a relatively simple bridge. This is a counterexample to a claim that MDE solutions are inflexible.
Do you have experience with MDE applications within your organization? Can you share these experiences as well?
References
[1] Yu-Liang Chi. 2009. Ontology-based curriculum content sequencing system with semantic rules. Expert Syst. Appl. 36, 4 (May 2009), 7838-7847.
Domain Specific Languages in Groovy
Domain Specific Languages in Groovy demonstrates how Groovy shines when it comes to domain specific languages.
About Domain Specific Languages
A Domain Specific Languages[1] (DSL) is a language tailored to describe a part of a specific domain. An example of a DSL are regular expressions[2]. Regular expressions provide a language that allow a user to specify which strings are accepted. Formally the domain for regular expression are finite-state machines[3] that accept strings. A regular expression describes a finite-state machine.
A DSL can enhance productivity enormously. By providing an abstraction over a specific domain, DSL’s allow a user to be more expressive. This expressiveness can cut the development time. A DSL also bridges the communication gap between a developer and a domain expert. The book Domain-specific Languages[4] by Martin Fowler and Rebecca Parsons is a great exposition about the subject.
About Groovy
Groovy[5] is a dynamic language running on the Java Virtual Machine (JVM). It takes the power of the JVM and provides a modern programming language for it. Groovy is inspired by successful languages like Python and Ruby. It rids most of the tedious boilerplate from Java code, replacing it with powerful primitives. You can try Groovy in your browser at http://groovyconsole.appspot.com/.
DSL’s in Groovy
Groovy uses a lot of domain specific languages. A notable example is the MarkupBuilder[6]. This class provides a DSL for the creation of xml. For example, the following code
new MarkupBuilder().root {
a( a1:'one' ) {
b { mkp.yield( '3 < 5' ) }
c( a2:'two', 'blah' )
}
}
will produce
<root>
<a a1='one'>
<b>3 < 5</b>
<c a2='two'>blah</c>
</a>
</root>
Custom DSL
Groovy allows the introduction of custom DSLs. Groovy provides a BuilderSupport[7] class. By extending this class a DSL like the MarkupBuilder can be created. We will demonstrate the use of BuilderSupport with the following example.
Let’s assume that we have a Robot. The robot is controlled via the executeCommand method. The executeCommand method accepts command codes. There are three of them 0x37, 0x51 and 0x88 with the following interpretation.
| Code | Command |
| 0×37 | Move Forward |
| 0×51 | Turn Left |
| 0×88 | Turn Right |
It would be tedious to perform complex movements with this robot. Multiple calls to the executeCommand method, all strung together, are necessary to do something trivial as navigate around a room. Instead, one would rather say something like.
do(4) {
forward()
left()
}
Auxiliary classes bridging the syntactic gap
We can start bridging the syntactic gap by introducing a few auxiliary classes. The following class diagram shows the participants. It combines the composite[8] pattern with the visitor[9] pattern.
The contract of the Program interface is to execute itself with a provided visiting Robot. There are two concrete programs types. There are BasicPrograms, one for each command, i.e. ForwardProgram, LeftProgram and RightProgram. These Programs execute the corresponding command on the provided Robot. The other concrete Program is the DoProgram. The DoProgram is composed of other Programs. When a DoProgram is asked to execute with a Robot, it asks it’s component Programs in turn to execute with the Robot.
The Program interface and its implementations help to express the intention of a user of the Robot. But this convenience comes at a price. There is a lot of boilerplate code necessary to express a program to navigate the robot around a room.
DoProgram program = new DoProgram(4) program.add(new ForwardProgram()) program.add(new LeftProgram())
This is where DSL’s step in.
ProgramBuilder
We will now use the power of BuilderSupport[7] to go the extra mile and close the syntactic gap. We will use BuilderSupport to create a ProgramBuilder class.
The BuilderSupport class has five abstract methods. These methods are subdivided in two categories. On the one hand there are various createNode methods. On the other hand is the setParent method.
The createNode methods only vary in their signature. The all have a name parameter in common. The createNode methods can also sport an value parameter, an attributes parameter, both parameters or no extra parameter. We chained the various methods to a single method, so we will focus on the createNode(String name) method.
The various createNode methods are called when a method is executed which is not defined. The name parameter is set to the missing method name. For example, in the following code
new ProgramBuilder().forward()
the createNode method is called with the name parameter set to "forward". A createNode method should return an object. In this case it would return a ForwardProgram.
The setParent(Object parent, Object child) method is called when a missing method is called with a closure[10]. First the createNode method should return an object. This object will act as parent parameter for the subsequent calls to createNode from the closure. I.e. every time a createNode method is called, the returned object is the child parameter in a call to setParent.
A code example should clear things up. The call sequence of the following code is determined.
ProgramBuilder b = new ProgramBuilder()
b.do() {
b.forward()
}
The call sequence will be: createNode("do"), createNode("forward") followed by a call to setParent(parent,child) where parent is the return value of the first call to createNode and child is the return value of the second call to createNode. In this example createNode("do") would return a DoProgram, createNode("forward") would return a ForwardProgram and setParent(parent,child) would call parent.add(child).
By using the various createNode method on can imagine that the following code can be used to navigate a Robot around a room. If you would like to look into the specifics the code can be found at GitHub.
ProgramBuilder b = new ProgramBuilder()
Program program = b.do(4) {
b.forward()
b.left()
}
Robot robot = new Robot()
program.executeWith(robot)
Conclusion
Groovy offers ample opportunities to introduce domain specific languages in a project. The BuilderSupport class is a great tool to create domain specific languages with. Domain specific languages can bridge the communication gap between a domain expert and a developer.
References
- http://en.wikipedia.org/wiki/Domain-specific_language
- http://en.wikipedia.org/wiki/Regular_expression
- http://en.wikipedia.org/wiki/Finite-state_machine
- http://martinfowler.com/books.html
- http://groovy.codehaus.org/
- http://groovy.codehaus.org/api/groovy/xml/MarkupBuilder.html
- http://groovy.codehaus.org/api/groovy/util/BuilderSupport.html
- http://en.wikipedia.org/wiki/Composite_pattern
- http://en.wikipedia.org/wiki/Visitor_pattern
- http://en.wikipedia.org/wiki/Closure_(computer_science)
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.
DSL Design Tutorial at PPL2010
Geplaatst door Andriy Levytskyy in MDD op 19 november 2010
In MDD explicit knowledge of the domain is crucial for successful development of domain-specific modeling languages (DSML). Yet many starting DSL developers are missing the skill of domain knowledge conceptualization. The main symptoms are difficulty to come up with good language concepts and struggling with levels of abstractions.
While language design remains an art, there are a number of paradigms, techniques and guidelines that can make creation of DSLs easier. These helping means are the core of the DSL design tutorial developed at Luminis Software Development.
The tutorial was given for the first time during the PPL2010 conference that took place on November 17 & 18 at Océ R&D, Venlo, NL. A small group of participants learned basics of domain analysis, participated in domain definition and implemented a simple metamodel of their own. The general feedback was very positive.
The slides for the tutorial can be downloaded here from the Bits&Chips website.
Presentaties AgileMDD kennissessie – 30 maart 2010
Geplaatst door Richard van der Laan in .NET, java, social, technical op 2 april 2010
Op 30 maart organiseerde luminis samen met ArchitecIT een kennissessie over model-driven development. Aan de hand van vijf verschillende thema’s deelden sprekers van diverse organisaties hun praktijkervaringen met MDD. De volgende organisaties waren als deelnemer vertegenwoordigd: ArchitecIT, Delphino Consultancy, luminis, Ministerie van Defensie, Nedap, Nuon, PANalytical, Radboud Universiteit Nijmegen, Sogeti, Tennet en Thales.
De presentaties van deze avond zijn inmiddels online beschikbaar en kunnen hieronder worden gedownload.
In de praktijk zijn er bij softwareontwikkeling nog veel communicatie (overdrachtsmomenten) en bestaan de meeste ontwikkeltaken uit veel handwerk. Op basis van een MDD aanpak kunnen ontwikkeltaken worden geautomatiseerd en kan de onderlinge communicatie worden verbeterd. Hierbij is het echter wel belangrijk om te weten hoe MDD het beste kan worden toegepast en wat hierbij de meest voorkomende valkuilen zijn. Vanuit onze AgileMDD filosofie moet bij model-driven development een pragmatische en doelgerichte aanpak vooral centraal staan. Zo kan de bestaande ontwikkelkracht in de organisatie slimmer worden ingezet.
Programma kennissessie 30 maart:
- Agile MDD: huidige trends en ontwikkelingen – Deel 1 (Richard van der Laan)
- Agile MDD: huidige trends en ontwikkelingen – Deel 2 (Tony Sloos)
- Thales case: MDA in realtime heterogene systemen (Rene van Hees, Alexander Broekhuis)
- Defensie case: Microsoft DSL Toolkit in de praktijk (Gerrit Jan Timmermans, Erik Sanders)
- MDD en software architectuur (Angelo Hulshout)
- MDD kansen en risico’s (Andriy Levytskyy)
Wil je op de hoogte blijven van aankomende AgileMDD sessies of geïnteresseerd in advies op maat? Neem dan contact op met Inge Dokter (inge.dokter@luminis.nl) of bel 026-3653470.
  |
Meld je nu aan voor de AgileMDD kennissessie op 30 maart
Geplaatst door Richard van der Laan in Uncategorized op 10 maart 2010
Luminis Software Development en ArchitecIT nodigen je graag uit voor een kennissessie over model-driven development.
We laten deze avond graag zien waarom modellen steeds belangrijker worden en hoe je er succesvol mee kunt zijn. De hele kennissessie zal in het teken staan van praktijkervaringen.
Aan de hand van vijf verschillende thema’s delen sprekers van diverse organisaties hun ervaringen met MDD in de praktijk: Thales Hengelo, Ministerie van Defensie, ArchitecIT, Delphino Consultancy en luminis.
In onze visie is het noodzakelijk om de ontwikkelkracht slimmer in te zetten, niet in de laatste plaats door de enorme toename van complexiteit in softwareintensieve systemen. In de praktijk zijn is er nog veel communicatie (overdrachtsmomenten) en bestaan de meeste ontwikkeltaken uit veel handwerk. Op basis van een pragmatische en doelgerichte aanpak kunnen ontwikkeltaken snel worden geautomatiseerd en kan de onderlinge communicatie worden verbeterd.
Datum: dinsdag 30 maart van 16:45 tot 20:00 uur
Locatie: IJsselburcht 3, 6825 BS, Arnhem
Voor wie: Architecten, ICT Managers en belangstellenden
Aanmelden: U kunt zich aanmelden per email door contact op te nemen met Inge Dokter
Het programma:
16:45 Opening in de grote zaal
17:00 Agile MDD: huidige trends en ontwikkelingen (Tony Sloos, Richard van der Laan)
17:30 MDA in realtime heterogene systemen (Rene van Hees, Alexander Broekhuis)
18:00 Lopend buffet
18:30 Microsoft DSL Toolkit in de praktijk (Gerrit Jan Timmermans, Erik Sanders)
19:00 MDD en software architectuur (Angelo Hulshout)
19:30 MDD kansen en risico’s (Andriy Levytskyy)
20:00 Afsluiting met borrel
Graag ontvangen we je aanmelding zo snel mogelijk, maar in iedergeval voor 12 maart. Aan deelname zijn geen kosten verbonden.
Je kan je aanmelding sturen naar Inge Dokter (inge.dokter@luminis.nl)
We hopen je te zien op dinsdag 30 maart!