Archives for posts with tag: example

Due to increasing use of domain specific languages (DSLs), declarative style of modeling is quetly spreading among users of MDE tools. Indeed, it is easy to find examples of declarative DSLs, e.g. at DSM Forums or this blog. There is however a group of users, among which the delarative style of modeling has not managed to spread – transformation developers. I am not sure if it has something todo with the group itself or with the fact that the majority of today’s transformation definition languages (TDL) are still more imperative in style (I am aware of QVT Relations and ATL, but these are rather exceptions than the norm).

There are quite a few good reasons why one would consider using a declarative language for transformation definition: reduction of information content in transformation definitions (and hence higher productivity of transformation developers), more agile DSL evolution, transformation definitions as models, higher compatibility with parallel computing, etc..

Today I would like to share some practical results that illustrate reduction of information content due to use of a declarative language.

CHART vs. Java

The following examples are kindly provided by Maarten de Mol and Arend Rensink from University of Twente. In CHARTER project, they are working on certifiable transformation technology for development of safety-critical embedded systems.

Before proceeding to the examples, here are a few relevant highlights of their technology:

  • Partially declarative transformation definition language (CHART): based on graph transformation and intended to be useable by Java programmers.
  • Transformation compiler (RDT): given a transformation definition written in CHART, generates its executable implementation in Java. The produced code runs against and transforms user provided data.

Figures 1 and 2 present transformation rules findRich and addPicture respectively. Each figure shows its rule written both in CHART and Java. The important Java methods are match() and update(), which are the translations of the similarly named blocks in CHARTER rules. 

Figure_1a_-_findrich_chartFigure_1b_-_findrich_java

Figure 1: Rule findRich written in CHART (a) and Java (b)

In Figure 1a, a match block counts 10 LOC against 41 LOC in Java (Figure 1b), which constitutes a reduction of information content by 75%.

Figure_2a_-_addpicture_chartFigure_2b_-_addpicture_java

Figure 2: Rule addPicture written in CHART (a) and Java (b)

In Figure 2a, an update block counts 12 LOC against 65 LOC in Java, an 80% reduction.

Both examples show significant reduction of information content in CHART rules. The reduction is even stronger if one takes into account that Java implementations also have to address technical concerns, which do not exist in CHART rules. In this case reduction is 92% (13 LOC vs. 160 LOC for rule findRich).

In experence of another CHARTER partner, who evaluates CHART/RDT in practice, a CHART transformation definition counted 1024 lines of code against 8000 in Java, an 87% reduction of information content [1]. Author’s own industrial experiences elsewhere with AToM3 GG rules (declarative) and QVT Operational (imperative) agree with the above results as well.

While exact reduction numbers are certainly arguable, the overal trend in the above experiences is that use of a declarative TDL can result in dramatic reduction of information content and manyfold increase of development productivity.

Conclusion

Despite industrial successes of MDE (which are often hidden), it is my experience that model-driven methods have hard times keeping up as organizations evolve. One factor behing this lag is slow speed of transformation development. Practical industrial experiences such as above, show that declarative languages have potential to significantly improve agility of transformation development.

What are your experiences with declarative TDLs and agile language development? Can you share concrete examples or provide references to declarative TDLs?

References

[1] de Mol, M.J. and Rensink, A. and Hunt, J.J. (2012) Graph Transforming Java Data. In: Proceedings of the 15th International Conference on Fundamental Approaches to Software Engineering (FASE 2012), 26-29 Mar 2012, Talinn, Estonia. Lecture Notes in Computer Science. Springer Verlag.

Advertisements

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.

Actors_and_services

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.

Simple_ssc_ontology

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.

Ccs_meta_application_pim

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:

  1. Metamodels for sequencing designs and learning units (see Figure 2).
  2. A transformation bridging the gap between AToM3 metamodels and ZCase, thus forming a complete transformation chain Model→Code.
  3. Import/export routine between AToM3 and Zope
  4. 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.

Sequencing_dsl_metamodel

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

A_learning_sequence_example_of_the_first_grade_mathematics_course_determined_by_curriculum_experts

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.

Cms_sequencing_document_types

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.

Author_view_on_a_sequencing_model

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

Learning_unit_model

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

Searching_for_course_sequencingReader_view_on_a_sequencing_modelSubstitutive_materials_per_sd

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.