The model-driven software development (MDSD) vision has booked signi cant advances in the past decades. MDSD was said to be very promising in tackling the \wicked" problems of software engineering in general. However, a decade later MDSD is still far from becoming widely recognized within the mainstream software development. At the same time Agile software development methodologies are widely considered as the way to go. This is counter-intuitive as MDSD seems to be the right methodology to boost Agile approaches. From Agile software development perspective, design models are a waste. In this experience report, we present Prototizer, a tool based on modeldriven software engineering that could boost the Agile vision. We present a validation of Prototizer on a recent case study and discuss the main lessons learned throughout the past years.
Given the advances in hardware technology, software development in general is
becoming an increasingly complex activity. For about a decade the model-driven
software development (MDSD) vision has seemed very promising in e ciently
tackling the essential complexities of the software development process [
As opposed to MDSD, Agile methodologies are currently considered to be the best practices within software development. The spectrum of agile methodologies is very broad. The core principles are typically focused on fast iteration cycles, responsiveness to change, early customer involvement, \good design", etc. Agile approaches aim at reducing the waste of big up-front analysis, planning and documentation. Nonetheless, even the most code-centric agile methodologies suggest the use and evolution of design models for communication and documentation purposes. From this perspective, it is our strong belief that MDSD is a necessary building block within a mature agile methodology. Introducing a lightweight MDSD within Agile methodologies could further reduce the waste, enforce a good design, aid with rapid prototyping and increase customer involvement. Indeed, if we use models for representing software design, we might as well use them as software artefacts, rather than merely a communication and documentation tool.
In this experience report, we present Prototizer, an MDSD supporting tool that could be used within any Agile software development process. Prototizer embraces only a small part of the MDSD philosophy, namely using models as rst-class citizens and generating partial code from these models. Nevertheless, this small part is the enabler of the true Agile vision. Over the course of the past ve years, we have developed more than ten di erent bespoke CRM/ERP webbased software systems using Prototizer. More importantly, we are still maintaining and expanding these software systems using Prototizer. In this paper, we present one of these systems.
The remainder of the paper is structured as follows. In section 2, we provide essential background information on agile software development and model driven software development. We also describe the problem statement in detail. In sections 3 and 4, we present our solution and its application on a recent case-study. Section 5 provides a brief evaluation of Prototizer. Finally, section 6 concludes this paper. 2
This section provides a brief overview of agile and MDSD methodologies by focussing on the key concepts that are in the core of the two paradigms. 2.1
Agile software development is a rather overloaded term and many existing
approaches claim to be agile. The most well-known approaches in literature include
eXtreme Programming (XP) [
Similar to agile, model-driven software development (MDSD) also covers a
relatively broad spectrum of ideas, techniques and tools. Despite their di erences,
we believe two key ideas are essential within most MDSD approaches.
Code generation Code generation is a central selling point behind MDSD
[
MDSD approach are no longer a mere piece of documentation, but actually an
essential software development artefact. Indeed, models have to be precise and
complete as they are fed to a code generator. As a result, models are always
up-to-date with the source code that makes them a valuable \lingua franca"
between the stakeholders. Software systems developed using MDSD are less likely
to evolve to a spaghetti-like systems where only the developers can manage to
nd their way [
It is our strong belief that there are two key obstacles that prevent MDSD from entering the mainstream software development and supporting the currently prevalent agile software development processes.
Rigid Code Generators. Typically, in a MDSD approach the code is
generated based on a template (e.g., Eclipse JET) or a script that is a programming
language on its own (e.g., Acceleo [
In the next section, as early adopter we present our toolset that we have created based on existing MDSD technologies. 3
We refer to Prototizer as the toolset that enables the model-driven and agile software development process. In this section we describe both the process we follow as well as the toolset itself. 3.1
Requirements Analysis This phase refers to both business requirements analysis as well as their translation into the technical requirements analysis. This activity is done using a more traditional approach, i.e., by using a text editor.
Requirements
Analysis Software Architecture
Design
Detailed Design
Validation (Acceptance)
Verification (Integration Tests) Verification (Unit
Tests)
Prototizer
Implementation Software Architecture Design This phase de nes the architecture of the overall software system. The software architecture is created in UML by the means of component/connector and deployment diagrams. Currently, we do not leverage the software architecture explicitly in the code generation. Detailed Design This phase describes the detailed UML class diagram that is further used for code generation.
Implementation Our rm mainly leverages the PHP Zend Framework as an underlying platform. However, virtually any programming language and platform can be used for the implementation.
on automated unit and integration tests that are an essential part of any systematic software development process. Given the PHP implementation platform, we further rely on PHPUnit and Selenium WebDriver for the unit testing and integration testing.
Validation Finally, the end customer is expected to perform the validation of the product release and o cially accept the release. This is done by using a modern web-browser.
The V-model is traditionally not considered to be agile, as it represents an
extension of the waterfall model. Thus, to improve the dynamics of this process
we leverage the Dynamic System Development Method (DSDM) Atern agile
project delivery framework used for software development [
Prototizer is an open-source tool implemented as an Eclipse plug-in and can
be downloaded from [
Resource Copier The resource copier simply copies various static resources,
such as libraries, Javascript/HTML/CSS les, into the le structure of the
project. The set of resources can be easily manipulated by the developer by
simply managing the static les within the plugin cartridge folder. These
resources are typically speci c for a certain company or even project domain.
Generation Scripts The generation scripts are used by Prototizer to
translate the UML model into code. Modifying a generation script is straightforward
as MOFScript is an imperative language syntactically similar to Java. For the
speci cs of the generation scripts we refer to the MOFScript speci cation [
The case study presented in this paper is a simpli ed version of our own enterprise resource planning system named CODIFIX. CODIFIX initially consisted of a rather primitive content management system for our website. However, we have gradually added various new modules that have introduced a substantial set of new functionalities. In this section, we will brie y describe two of the CODIFIX modules, i.e., the content management system and the issue tracking system. We focus mainly on the models from which the source code is continuously and incrementally generated. At the end of this section, we provide an overview of the artefacts that are actually generated from the design models. 4.1
CODIFIX is implemented in PHP by leveraging the Zend Framework version 2. Note that we do not use the Doctrine framework that provides a transparent database storage. Rather, the generation step creates the complete database API ready to use by the developers. We also rely on client-side functionality written by third parties in Javascript. As an underlying database we use MySQL. 4.2
Figure 3, presents the class diagram of the simple content management system (CMS) model we have designed to use for our informative website. The CMS consists of menus (Menu) denoting the pages. Each menu has a speci c language (Language) and can have a parent menu. The website information is represented as contents (Content ) where each content can belong to a menu object. The attributes of the classes and the semantics that are assigned to the model elements and used in the generation are out of scope for this paper.
Database scheme and API The complete data layer as well as the communication API is generated by Prototizer. The database scheme is generated as an .sql dump. We have developed a simple scripting mechanism to synchronise the generated database scheme with the actual running database. The database communication API is a collection of classes that allows systematic manipulation of the database entries for each of the classes within the UML models. We currently do not leverage on frameworks like Doctrine (the PHP version of Hibernate) and the database communication API represents a relatively large codebase. Typically, this part of the generated code is never modi ed manually as the UML model within the Prototizer philosophy is semantically complete. Model classes Each modelling entity (along with its relationships) is translated into a corresponding PHP Class. These classes represent the models in MVC terminology. Obviously, the classes have pre-generated list of attributes as well as getter and setter functions. In addition, we also generate validation rules for each attribute as de ned by its type. For instance, the order attribute in Menu class must be an integer. The model classes are typically manually re ned, hence, protected code sections denote the places where this can be realised. In general, the attribute information as well as their getters and setters should never be modi ed manually. On the other hand, methods like toString() and any additional methods that are added by the developer are protected by Prototizer. Controllers and views The basic features for most of our systems (including CODIFIX) are the web-based create, retrieve, update and delete (CRUD) interfaces to manipulate the database entities. These interfaces are also generated by Prototizer. In MVC terminology these are the controllers and the views. The controllers are in charge of processing the HTTP requests and constructing the HTML views that are sent back to the web-browsers by the web-server. The views are mainly HTML scripts with template parameters that are dynamically instantiated by the corresponding controllers.
Generated code percentage Overall, our currently running CODIFIX project contains 17546 lines of generated PHP/HTML code from a total codebase of 22281 lines of code (including comments and white spaces). Current best practices in Zend Framework would require one to write all this code manually. Nonetheless, the productivity increase is limited by two factors. Firstly, not all of the generated code is actually used. Given the ease of code generation we generate quite a few helper functions that are not always needed and used. Secondly, the generated code is by de nition trivial as it constitutes the repetitive part of the code. However, writing the code manually when it can be generated is a 100% waste of time. 5
In the past ve years we have iteratively developed numerous custom web-based CRM and ERP systems using Prototizer. All of these systems are still heavily used by our customers who often submit change requests. In this section, we provide an overview of the lessons learned within the context of our rm. 5.1
The process behind Prototizer is in line with agile and virtually any agile
framework can be plugged in as a concrete dynamics of the process. Prototizer is a
clear realization of the MDSD vision regarding the centrality of models,
instantaneously generated source code and the increased prototyping abilities. This saves
a substantial amount of time and allows our developers to focus on core problems
rather than spending time in typing code. The generated code is considered to
be bug-free as we assume the generation cartridges are bug free. Prototizer forces
the designers to create complete UML models of the system, hereby making the
communication between designers and developers in the context of the system
structure much more clear. Prototizer also enforces a speci c code structure that
is valuable especially for the less experienced developers within our rm. In our
experience, the long-term bene ts of Prototizer are even more critical. The
existence of a complete and up-to-date UML model increases the system longevity
and substantially reduces the maintenance cost. Within our rm, the cost of
maintenance (e.g., new features, change requests) often by far exceeds the
original cost of development. This is con rmed by various studies in the industry
(e.g., [
Virtually any code generation approach introduces additional constraints for the developers. The protected sections where developers are expected to operate sometimes lead to two problems. Firstly, inexperienced developers inevitably misplace manually written code that leads to overwritten code on subsequent iterations. While the code is not really lost (thanks to version control), such situations involve an additional overhead. Secondly, certain manual re nements could be relatively complicated to t within the protected sections. Developers are sometimes forced to duplicate code in order to achieve the desired result.
From a research point of view Prototizer is not innovative. In fact, the building blocks of Prototizer, i.e., MOFScript and EMF were stable almost a decade ago. However, from a state-of-the-practice point of view, Prototizer is a pragmatic answer to both problems presented in section 2.3. Generation cartridges can be easily modi ed and new cartridges can be quickly created by example. The resource copier requires simply moving around les and folders that are needed for a speci c project type. MOFScript is a powerful, yet very simple language for creating and modifying code generation scripts. Prototizer is a very lightweight approach, only focusing on a very small subset of UML, i.e., class diagrams. Instead of focusing on a programming language (PHP code generator), we have created generation cartridges for a speci c framework (Zend code generator). We believe that these aspects contribute to reducing the steepness of the MDSD learning curve. However, we have not validated either of these claims in a systematic fashion. 6
In this experience paper, we have presented Prototizer - a tool that enables a boosted agile software development approach. Prototizer, which is based on existing model-driven software engineering building blocks, enables the use of the design models as actual software development artefacts, rather than mere documentation.