-Agile software development and Model-Driven Development (MDD) are two software engineering paradigms that contribute to enabling the rapid development of applications. Previous approaches have proposed the integration of Agile and MDD, however these approaches are either specific to one application domain, or fail to cover the complete development cycle, for example, to include requirements engineering. To address this problem we propose a general and comprehensive process that integrates Agile development and MDD, and that allows applications to be safely developed in an iterative and incremental manner. We also report on a case study to evaluate the application of the proposed process. Index Terms-agile development, model-driven development, agile model-driven development, process
Agile development methods have gained increasing
attention among the software development community [
Although researchers are already trying to integrate both
Agile development and MDD, this integration has not been
explored deeply so far [
The remainder of this paper is structured as follows: in Sect. II we discuss the related work while in Sect III, we present the proposed process, outlining its main phases and activities. Sect. IV reports the application of the proposed process to develop a code generator. In Sect. V, we evaluate the feasibility of the proposed process. Finally, in Sect VI we conclude the paper and discuss our future work.
Integrating Agile development and MDD (Agile MDD) is
a new discipline and research in this area just started [
Zhang and Patel in [
Kulkarni et al [
Guta [
Besides that these processes are platform-specific, they only describe the general course of the process and they don’t consider the full development lifecycle. We propose a more general process that considers the full development lifecycle activities which can be applied to different domains. III. AN AGILE MODEL-DRIVEN DEVELOPMENT PROCESS
In order to develop the process stages, we reviewed the
literature to identify what are the main practices and activities
in MDD processes. To this end, we adopted some MDD stages
from [
Product owner: is responsible for creating and maintaining the product backlog.
Modeller: is responsible for developing different components of the system.
Tester: is responsible for testing at model and implementation level.
Specification library manager: is responsible for managing and maintaining the specification library.
Tooling sub-team: is responsible for providing extension or adaptation to the tool.
The development process starts with the Initialisation phase and finishes with the Deployment phase. Throughout the development, it follows an iterative and incremental approach. The proposed process is not tied to a particular formalism, however we propose to adopt OMG standards, i.e., SysML and UML, to be open to multiple tools and promote the interoperability of the models. An overview of the process is presented in Fig. 1 while the different phases and its stages are explained in the following subsections.
The main objective of this phase is to capture the initial information about the system such as its scope, size, environment conditions and so on. At this stage, strong collaboration with the customer is crucial to gather the required information. Furthermore, the initial requirements of the system and the architecture at a high-level scale are identified. To meet agility, it is necessary to avoid capturing too complex information since detailed information will be evolved incrementally. All the requirements are prioritised and recorded in the product backlog by the product owner as a form of user stories. Based on that, the overall release plan will be established which distributes the product backlog tasks into iterations in order to predict when the product can be released. Moreover, the tools, modelling language and platform should be identified and agreed upon at this stage.
After the initialisation phase, the development process follows an iterative cycle. This means that the development process goes through repeated phases until the system meets the customer’s needs. The iterative cycle encompasses the following phases: Requirements and Specifications, Development,
Each iteration begins with an iteration planning activity to agree on the work to be accomplished in the upcoming iteration. The initial release plan performed in the initialisation phase can be used to feed directly the iteration planning. To support the agile philosophy, changes in requirements should be welcomed at any time. Therefore, any changes should be discussed and the product backlog is revised at this planning. Afterwards, the product owner agrees with the development team on the requirements to be implemented at this iteration according to their priorities. In order to communicate and manage the requirements effectively, user stories are produced to describe the requirements in one or two sentences. The requirements selected to be accomplished in the current iteration are added to the iteration backlog.
Throughout the iteration, daily stand-up meeting can be conducted in order to solve the problems encountered by the developers and to allow them to catch-up with each other’s progress. The daily meeting should be as short as possible, normally it lasts no more than 15 minutes.
The main objective of this phase is to analyse and specify the requirements of the current iteration. This phase includes two main stages: Requirements Analysis and Requirement Specifications.
In this stage, the requirements of the current iteration are
defined and structured in more detail. Both functional and
non-functional requirements should be identified clearly.
Since, non-functional requirements are ill-defined in Agile
development [
Once the requirements are identified, modellers start developing models that fulfil these requirements. The initial architecture should be revised and amended accordingly. In the context of MDD, metamodels and transformations are considered the main elements of the process and any models should conform to metamodels. As with any artifact, developers can reuse metamodel artifacts provided by standards such as UML and MOF or developed in previous common projects. Any identified reusable components should be imported from and/or added to the library by the specification library manager.
When the representation of the metamodels is not available,
developers need to define it to capture the abstract syntax
and constructs used to define models. Transformations should
also be identified, these include transformations between
different models or from models to text. Afterwards, models
are created that specify the requirements precisely. Different
perspectives of the system are identified to be modelled and
a set of models is selected accordingly e.g. use case, class
diagram, activity diagram. Pair modelling, analogue to XP’s
pair programming [
The main objective of the development phase is to produce a technical specification of the system and to produce an executable system that fulfils the functional and nonfunctional requirements. This phase includes two main stages: Design and Implementation.
The developers model the detailed structure and behaviour of the system that fulfils the functional and non-functional requirements. Although extensive customer involvement is a key factor in Agile development, in our process the customer is selectively involved in tasks such as requirements capturing and reviewing. This is due to the facts that most customers don’t have required knowledge of MDD activities such as modelling, designing and implementation. Following the Agile practice incremental design, the developers design and specify the platform-specific aspects by refining the platform-independent models which have been defined in the previous stage. These specifications describe the technical specification of the target platform (e.g., EJB, .NET) to allow generating the code and transformation can be employed to refine some artifacts. Formal verification at the specification level can be used to ensure the key properties are preserved from one iteration to the next. Following the Agile practice refactoring, developers should review the specification structure continuously to ensure the best design of the system. Since models are the intrinsic driver in development process, when change occurs or defects are discovered, the resolutions for the issues should be at the modelling level. Before and after every change, all test cases should pass.
At this stage, developers produce the software that is testable and executable. MDD differs from other software development approaches in that the code is partially or completely generated from the models. The level of automation that translates models into code can be varied from partial to complete implementation of the system. Although the code is generated from models, it is still necessary to run tests against the code to make sure the model semantics are as expected. When some part of the system cannot be generated automatically, it can be written and manually added and tested.
In parallel to the software development process, a tooling
sub-team can be employed to provide technical support
such as necessary extensions or adaptations of tools. Having
in-house team is found to be effective to help when issues
arise [
The main objective of this phase is to integrate the developed parts of the system and to make sure they behave as expected. This phase includes two main stages: Integration and Testing.
Since one of the intrinsic characteristic of agile development is to develop the system in an incremental fashion, the increments need to be integrated and tested frequently. Therefore, by adopting the agile practice of continuous integration, developers need to integrate their work as soon as it is completed.
Integrated parts such as components and subsystems are
verified by regression tests to detect errors early in the
development. Although testing is integrated frequently in all the
phases of the iteration, testing should be performed at the end
of the development process as well [
At the end of the iteration, an increment of the system is released and delivered to the customer for assessment and review. When some requirements cannot be completed during the iteration, they are carried over to the next one. To assess the development process and assess what has been done during the iteration, a review meeting is held.
When the system has been fully implemented and reaches a stable version, the system will then be deployed to the customer. The goal of the deployment is to release the system and make it ready to use by the customer without developer’s supervision. This activity takes place only once at the end of the development process.
In order to illustrate the proposed process, we applied it
to the development of code generator for mapping UML to
ANSI C for the UML-RSDS [
Besides the scope and the size of the system, the initial requirements were identified. The main functional requirement for the generator is (F1): Translate UML-RSDS designs (UML class diagram, use cases, OCL, activities) into ANSI C code. Using goal decomposition, F1 is decomposed into five sub-goals:
F1.2: Translation of class diagrams F1.3: Translation of OCL expressions F1.4: Translation of activities
F1.5: Translation of use cases Furthermore, non-functional requirements were identified such as:
NF2: Efficiency: input models with 100 classes and 100 attributes per class should be processed within 30 seconds NF3: Modularity of the transformation The dependencies and priorities of the requirements were identified and consequently the product backlog was created. Furthermore, the initial architecture was identified as a sequential decomposition of model-to-model transformation (design2C) and model-to-text transformation (genCText) (Fig. 2). In the release plan, the product owner organised the development into five iterations, each of which develops one translation. Each iteration was given a maximum duration of one month. In the following subsections, we present the iterations. Due to limited space, only the first three iterations are explained in detail.
This iteration concerns the mapping of data types such as boolean, int, long, etc. into C representations by defining the sub-transformation types2C. During the iteration planning, the development team planned to implement F1.1: Translation of types.
Detailed requirements elicitation identified the following requirements: (i) the source language, (ii) the target language, (iii) the mapping requirements, (iv) non-functional requirements NF1, NF2, NF3. The main user story for F1.1 was:
This user story was decomposed into further sub-user stories and their scenarios are presented in Table I. The requirements specification formalised these translations as UML-RSDS rules, defining the post-conditions of a transformation types2C. The corresponding part of genCtext was developed alongside types2C.
The source language for this transformation was identified as the Type class and its sub-classes in the standard UML-RSDS class diagram metamodel, while the initial target language is a simplified version of the abstract syntax of C programs, sufficient to represent UML types. The design in UML-RSDS is produced automatically from the formal specification. The formal specification for F1.1.1.1 and F1.1.1.2 are: PrimitiveType:: name = "int" => CPrimitiveType-> exists( p | p.ctypeId= typeId & p.name= "int") PrimitiveType:: name= "String" => CPointerType->exists(t | t.ctypeId= typeId & CPrimitiveType->exists(p | p.name= "char" & t.pointsTo = p )) Phase 3: Integration and Testing Test cases were manually developed to test the functionality, in addition to inspection and formal arguments for the satisfaction of the requirements. Since this was the first iteration, integration was not needed at this stage.
The goal of this iteration was to define the sub-transformation (classdiagram2C) that is concerned with mapping UML class diagram into C. During the iteration planning, given its high priority, it has been planned to implement F1.2: Translation of class diagram at this iteration.
Phase 1: Requirements and Specification During the requirement phase, the class diagram elements Entity, Operation, Property, and Generalisation were identified as the input language. Exploratory prototyping was used for further requirements elicitation.
Similar to type translation iteration, user stories for the mapping of UML class diagrams to C were informally identified. Phase 2: Development In order to translate class diagram classes, the developers design the following function to create C code getters for properties: CMember:: query getterOp(ent : String): String post: result = type + " get" + ent + "_" + name + "(struct " + ent + "* self) { return self->" + name + "; }\n"
Similar functions were defined to express other aspects of UML classes in C.
Phase 3: Integration and Testing Phase Testing, inspection, and formal arguments were used for validating and verifying the requirements. Both iteration 1 and 2 have been integrated and grouped as one executable jar file. Integration testing was conducted to make sure the integration behaved correctly.
This iteration concerns the mapping of OCL expressions to C. During the iteration planning, the development team planned to implement F1.3: Translation of OCL expressions. There are many cases to consider with OCL expressions mapping, thus this functionality was divided into four subcategories: (i) translation of basic expressions, (ii) translation of logical expressions, (iii) translation of comparator, numeric and string expressions, and (iv) translation of collection expressions. Due to its large size, it was not possible to complete it in one month.
Phase 1: Requirements and Specification Detailed requirements elicitation identified the mapping scenarios of the above mentioned subgroups of OCL expressions. For brevity, only the mapping scenarios for the basic expressions are presented in Table II. Phase 3: Integration and Testing Testing and inspection were used for validation and verification. Testing of these operations revealed some errors regarding the metamodels such as error in the value of the multiplicity. The generation of model.txt by the UML-RSDS tools needed to be adjusted in several cases to ensure that appropriate information was available for UML2C. It was decided that the integration of iteration 3 will be conducted later with iterations 4 and 5.
Translation of activities, and use case were implemented in iterations 4 and 5 respectively.
The code generator was deployed and delivered as Java jar executables: iteration 1 and 2 were grouped in one executable (uml2Ca.jar) and iterations 3, 4, and 5 in (uml2Cb.jar). The complete translator was referred to as (UML2C) and it can be found via the link in the footnote 1 .
Several code generators have been developed previously for UMLRSDS using Agile development with manual coding in Java (i.e, non-MDD approach) such as Java 4, Java 7, C#, and C++. Table III shows the approximate effort in person-months expended for each of these to date including our C code generator. An overall development effort reduction has been noticed for the C code generator using Agile MDD process. The benefits of this effort reduction are mainly due to the use of specifications instead of code, and to the use of executable modelling. The decomposition of the transformation into semi-independent phases formed a natural basis for the definition of the top-level work items in the product backlog, and this in turn led to the definition of iterations. The use of short iterations and backlogs enabled incremental development of the translator and helped organise the development. Partial specifications were defined for each separate iteration of the system, and incrementally refined. Refactoring was extensively used to improve the specification, in particular the removal of duplicated functionality. The agile emphasis on simplicity helped to reduce the specification complexity: in particular only class diagrams and OCL constraints are used to define the translator, without activities or other UML models. Also, we found it effective in handling changing requirements to translate static operations. Overall, we consider the combination of agile and MDD to be effective in improving system quality and reducing development time. Further techniques, such as model-based testing and pair modelling, will be investigated in future work.
In this paper, we presented a systematic process for integrating Agile development and MDD, describing its stages and activities. To illustrate the process, the development of a UML to C code generator was conducted and evaluated. In future work we will target evaluating the process more comprehensively. To this end, four case studies, developing the same system, will be conducted by four different teams implementing different approaches: “traditional approach” (i.e, a hand-coded non-agile approach); “MDD only” approach; “Agile only” approach; and “Agile MDD” approach. Comparing the results of these case studies should provide a clear understanding of the impact of integrating Agile and MDD on the development process.