Archives for posts with tag: CHARTER

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


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?


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

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.


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!


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 at this blog 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.

CHARTER is an ARTEMIS JU project that 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 increasingly 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.