Berichten met label benefit
(cross-posted from blog.conceptworks.eu)
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 in rows of the gallery present transformation rules findRich and addPicture respectively. Figures in columns show these rules written in CHART and Java. The important Java methods are match() and update(), which are the translations of the similarly named blocks in the CHARTER rules.
Figures 1-4: Rules findRich and addPicture written in CHART and Java
In Figure 1, a match block counts 10 LOC against 41 LOC in Java (Figure 2), which constitutes a reduction of information content by 75%. In Figure 3, 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 . 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?
 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.
(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.
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!
While effort reduction and quality increase are both commonly recognized benefits of MDE, the former particularly has become its trademark, thanks to numerous generative uses in model-driven software development (MDSD). Examples include generation of code and configurations from models written in UML, DSLs and XML.
Figure: The effort in MDE approach with partial manual coding (adapted from )
The generative MDE automates well defined routine activities. An effective metric of depicting economical benefit thereof is effort. The above figure illustrates effort reduction due to automation and reuse in an MDE approach with partial manual coding. Of cause, the generative MDE improves quality as well: error reduction, enforced architecture conformance, and up-to-date documentation are common factors that have positive effect on software quality. But usually these are considered as icing on the cake that is effort reduction. In my experience this perspective on the economical value of MDE is common among both customers and MDE professionals. The perspective can be summarized as “the same with less”.
More with the same
Recently a client tasked me together with its domain experts to assess benefits of applying MDE to a difficult process within the organization. Having analyzed the before and after situations, we came up with estimated economical benefit expressed in effort savings. The estimate was hard to quantify, but “should” have been OK. Although I wanted to share this optimism, I felt that in practice the effort saving would be negligible if not even negative. This paradox was due to the fact that the largest activity in the problem domain was inherently creative and exploratory.
In the figure, the output of a single exploration in this activity is shown as intermediate result, corresponding to line ad. As the figure suggests, code generation directly from the output is not possible (this happens further downstream in development). You may have noticed that the modelling curve rises more steeply towards point a. This rise occurs because modelling requires increased level of domain understanding and more information is needed by semantically rich operations, such as simulation, verification, code generation (eventually), etc. On the other hand, the figure shows effort reduction indicated by distance cd, which is the result of providing end users with proper abstractions, faster access to right knowledge, separation of concerns, DRY modelling, maintained consistency and integrity.
While working efficiency per exploration is likely to increase (compare ab and cd), the leading concern is quality of the output. Here benefits are early detection of design errors, deep exploration of design choices, better communication and documentation, maximized reuse of domain-specific platforms in further development. Moreover, the domain experts noted that any saved effort would be re-invested in more alternative explorations in search of a more optimal output. This increased number of explorations, is likely to balance out any savings due to higher efficiency.
With these insights, economical benefits were expressed with quality metrics and linked to different business goals than initially thought.
The described MDE assessment targets a highly creative engineering activity that explores alternative choices. In extreme case, the main benefit is not effort reduction, but increased product and process quality. The icing on the cake is that processable models can open opportunities for generative uses as well.
In my experience, such and certainly less extreme quality-driven cases are not exotic. In recent years, quite a few MDE projects I’ve participated in, had benefits strongly linked to quality improvement. What are your MDE experiences with creative activities? What were the economical benefits and how were they conveyed?
 Thomas Stahl, Markus Voelter, Krzysztof Czarnecki. “Model-Driven Software Development: Technology, Engineering, Management”. Wiley; 1 edition (May 19, 2006)