Javier Cánovas presents his work on the application of MDE in Small Software Enterprises. Enter Javier.
Despite their promises, MDE adoption by the industry is still limited. There are a growing number of companies that have successfully applied MDE, but “its use by the industry is still an exception rather the norm”. Indeed, the industrial adoption of software innovation is usually not immediate, but a period of time (more than two decades in the case of object technology) is required to reach the needed conditions: a stable and mature foundation, usable and robust tools, skilled professionals and companies aware of the benefits of the new technology. We believe that three main actions must be carried out for MDE to be successful: more research and development effort to overcome the technical challenges; including MDE in the University curricula; and projects of Transfer of Technology (ToT) intended to increase the awareness of industry, as well as training software developers in the model-based style of thinking.
While several experience reports about MDE adoption on large companies can be found, the number of experiences in small companies is scarce. Both large and small companies face similar software engineering challenges, but the solutions have to be adapted to the size and nature of the company. For instance, small companies are more responsive and flexible, but they do not typically have enough resources to build custom, in-house solutions. Furthermore, it is not reasonable to convert the code-centric development style of a small company into a model-centric style, since the cost is high, and the benefits have not been clearly assessed yet. Instead, a better alternative is to use MDE techniques to automate certain development problems as a means to enhance company productivity. In this way, the adoption of MDE in a small company has to be different from a large one.
In this work we report on our practical experience in two ToT projects. Unlike most experience reports, we have dealt with two small software companies: Sinergia with around 100 employees, with which we carried out a modernization project in the context of a migration of Oracle Forms applications to the Java platform, and Visualtis with 12 employees (at the time of the project) which built a generative architecture to generate CRUD (Create-Read-Update-Delete) forms using a language specially adapted to the task (i.e., they defined a Domain-Specific Language). The following figure briefly illustrates these projects:
The analysis of these experiences suggests that MDE has the potential to make small companies more competitive, because it enables them to build powerful automation tools at modest cost. By reporting on these projects, our hope is to give insights that may help other ToT projects aiming at introducing MDE to small software companies. To this end, we introduce some factors that affect the success of this kind of projects, and provide an assessment of both projects in the light of these factors. The assessment is based on qualitative data about the projects and quantitative data in the form of metrics. We also present some lessons learned. In addition, the description of each pilot project may serve as an inspiration for small companies that want to begin with MDE on their own, since they are prototypical small medium projects that can be addressed without spending much resources and pay off rapidly. We will also present our approach for training companies in MDE, and we contribute the teaching material so that it can be used or adapted by other ToT projects.
Jesús Sánchez Cuadrado, Javier Luis Cánovas Izquierdo and Jesús García Molina: Applying Model-Driven Engineering in Small Software Enterprises. Science of Computer Programming. Available online 9 May 2013 (Free access link)
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Well done! I found that an interesting and useful paper. I wish you had been able to get hard data on the increase in productivity with generation from a DSL, but even the estimate of about 2.5-3x, and up to 10x if no GUI customization was needed, is a useful indicator.
One part I would disagree with might surprise you: you say “Building a MDE tool to automate a repetitive task is necessarily more costly than writing this repetitive code manually once or twice”. In our report on four industrial cases, http://www.metacase.com/webcasts/IndustrialExperiencesOnDSM.html (the video has slides and paper link at the bottom) we found that in all three cases where we could measure this, Panasonic (slide 11), Polar (slide 22) and Elektrobit (slide 29), it was as fast or faster to build the language and generators with MetaEdit+ than to write one product’s worth of code manually. In all four cases the language and generators were built by the customer, without help from MetaCase. Most remarkable was Polar, where it was over three times faster to build the language and generators than to build one product by hand. Since building one product with models was 10 times faster than by hand, they could actually build the language, generator and 7 products faster with DSM than they could build one product by hand. The full reports are in the articles and theses referenced at the end of the slides, and of course you can buy one of the Polar GPS sports watches and wear it with pride in MDE :).
The number of hours to build the language and generators with MetaEdit+ in these cases was somewhat less than in the Circe generation case reported in your paper, e.g. 60 for Polar rather than 156 for Circe, so that may explain the difference in our expectations of the ratios. Our experience is that 2-3 man-weeks is normal (80-120 hours). It’s hard to say more without knowing the size of the respective languages and generators, but the MetaEdit+ cases weren’t small languages. There are roughly 124 elements in the Polar input metamodel’s abstract syntax (objects, relationships, attributes), as opposed to 28 in Circe. The Polar generator didn’t use an intermediate model (we rarely do). I don’t have the figures for the Polar generator, but I’d guess from similar cases that building the generator took 40 hours out of the total of 60.
We unfortunately don’t have figures for a reverse engineering case with MetaEdit+: MERL can do reverse engineering, but its main focus is generation. The only figure I have for reverse engineering with MERL is coincidentally from my blog post on Jesus Cuadrado’s earlier paper, http://www.metacase.com/blogs/stevek/blogView?entry=3385914921 , where it took a little under an hour to build reverse engineering that read the core Class Diagram elements in XMI and transformed them into MetaEdit+’s MXM format.
I guess this really depends on the type of project. As a reference, this previous post also did some measurements:
MDD pays off in the mid-term: an industrial experiment
https://modeling-languages.com/mdd-pays-mid-term-industrial-experiment/
I agree with Jordi. This really depends on the type of project.
In my experience, if the generated code has a logic that is not very complicated, but just repetitive, then you may write the generator as you devise that logic. In this case you don’t even need an existing application to use as the basis for the generator.
In contrast, we have recently finished a code generation project with a company, in which developing the generator (from UML StateMachines to C) was a pain. The reason was that it was unclear how to cover all the cases, and we needed many iterations to get the generator right. However, the developers of the company were able to obtain the code from the diagrams by hand easily because they were used to finding workarounds for certain configurations of the model. In summary, we spent a lot of time studying those workarounds they have known for years, trying to find an agreement, and then putting them in the generator.
Regards,
Jesús.