A Process for Integrating Agile Software Development and Model-Driven Development Hessa Alfraihi Kevin Lano dept. of informatics dept. of informatics King’s College London King’s College London London, UK London, UK hessa.alfraihi@kcl.ac.uk kevin.lano@kcl.ac.uk Abstract—Agile software development and Model-Driven De- However, there exist some approaches that attempt to integrate velopment (MDD) are two software engineering paradigms that Agile and MDD in the areas of finance, web applications, and contribute to enabling the rapid development of applications. telecommunications. Previous approaches have proposed the integration of Agile and MDD, however these approaches are either specific to one Zhang and Patel in [7] apply Agile MDD process to application domain, or fail to cover the complete development develop a project for telecommunication by integrating two cycle, for example, to include requirements engineering. To existing processes: System-Level Agile Process (SLAP) and address this problem we propose a general and comprehensive process that integrates Agile development and MDD, and that MDD process. SLAP is Scrum-based process that contains allows applications to be safely developed in an iterative and three phases: requirements and architecture, development, and incremental manner. We also report on a case study to evaluate system integration feature testing (SIFT). On the other hand, the application of the proposed process. MDD process follows a V-model process which includes Index Terms—agile development, model-driven development, the following activities: application requirements specification agile model-driven development, process and architecture, requirements analysis and high-level design, detailed design, code generation and UML unit and integration I. I NTRODUCTION testing, subsystem testing and system testing. In order to Agile development methods have gained increasing atten- achieve Agile MDD they establish a simple correspondences tion among the software development community [6]. They are between MDD activities and SLAP sprints to end up with centred around some values, practices and principles proposed three phases: application requirements and architecture, de- by the Agile Manifesto [3]. These values are related to a velopment, SIFT. tight communication with the customer, the frequent delivery Kulkarni et al [9] propose a method for integrating Agile of the application, response to changes in requirements, and method and MDD. They argue that Agile development contra- so forth. Model-Driven Development (MDD) [14] is another dicts with MDD as some activities are not suitable to be done software development paradigm that is distinguished from during short iterations. Therefore, they introduce “meta-sprint” other approaches by the fact that models are not only used for in addition to normal sprints in their Scrum process. This meta- analysis and design aspects, but also for producing artifacts sprint is dedicated for tasks that require longer duration such semi-automatically. as detailed exploration or research. Although researchers are already trying to integrate both Agile development and MDD, this integration has not been Guta [8] proposes MDD process that follows a traditional explored deeply so far [1], [5]. The goal of this paper is to iterative and incremental process. The development process is address this problem by proposing a process that integrates based on parallel collaboration between three different teams both approaches effectively. Then, we evaluate the feasibility namely; Agile development team, business analyst team, and of the proposed process by a case study. MDD team. It encompasses initial phase and development The remainder of this paper is structured as follows: in Sect. phase. Initial phase contains domain model extraction, archi- II we discuss the related work while in Sect III, we present tecture elaboration, and code generator set up. On the other the proposed process, outlining its main phases and activities. hand, development phase is an iterative process where the Sect. IV reports the application of the proposed process to domain model is extended and the other artifacts are generated. develop a code generator. In Sect. V, we evaluate the feasibility In this approach, MDD process is only applied on a subset of of the proposed process. Finally, in Sect VI we conclude the the system while the other features are hand-crafted. paper and discuss our future work. Besides that these processes are platform-specific, they only describe the general course of the process and they don’t II. R ELATED W ORK consider the full development lifecycle. We propose a more Integrating Agile development and MDD (Agile MDD) is general process that considers the full development lifecycle a new discipline and research in this area just started [1], [5]. activities which can be applied to different domains. III. A N AGILE M ODEL -D RIVEN D EVELOPMENT P ROCESS 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 [11] and [17] . Similarly, to integrate Agile practices, we analysed three different Agile methods: Scrum [13], Extreme Programming (XP) [4], and Agile modelling [2]. Generally, we used Scrum as the backbone process since it provides a management framework for managing and controlling iterative work at the project level. Some other practices such as pair programming, refactoring, active stakeholder participation and architecture envisioning were utilised from XP and Agile modelling. In our Agile MDD, we adopted the three phases from [17] and the parallel tooling sub-team from [8]. The activities of our process are assigned to a limited number of roles, and one developer can play multiple roles. We Fig. 1: An Overview of Agile MDD Process identified the following role and responsibilities: • Product owner: is responsible for creating and maintain- After the initialisation phase, the development process fol- ing the product backlog. lows an iterative cycle. This means that the development • Modeller: is responsible for developing different compo- process goes through repeated phases until the system meets nents of the system. the customer’s needs. The iterative cycle encompasses the fol- • Tester: is responsible for testing at model and implemen- lowing phases: Requirements and Specifications, Development, tation level. Integration and Testing. • Specification library manager: is responsible for man- Each iteration begins with an iteration planning activity aging and maintaining the specification library. to agree on the work to be accomplished in the upcoming • Tooling sub-team: is responsible for providing extension iteration. The initial release plan performed in the initialisation or adaptation to the tool. phase can be used to feed directly the iteration planning. To The development process starts with the Initialisation phase support the agile philosophy, changes in requirements should and finishes with the Deployment phase. Throughout the be welcomed at any time. Therefore, any changes should be development, it follows an iterative and incremental approach. discussed and the product backlog is revised at this planning. The proposed process is not tied to a particular formalism, Afterwards, the product owner agrees with the development however we propose to adopt OMG standards, i.e., SysML team on the requirements to be implemented at this iteration and UML, to be open to multiple tools and promote the according to their priorities. In order to communicate and interoperability of the models. An overview of the process is manage the requirements effectively, user stories are produced presented in Fig. 1 while the different phases and its stages to describe the requirements in one or two sentences. The re- are explained in the following subsections. quirements 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 A. Phase 0: Initialisation developers and to allow them to catch-up with each other’s The main objective of this phase is to capture the initial progress. The daily meeting should be as short as possible, information about the system such as its scope, size, environ- normally it lasts no more than 15 minutes. ment conditions and so on. At this stage, strong collaboration with the customer is crucial to gather the required information. B. Phase 1: Requirements and Specifications Furthermore, the initial requirements of the system and the The main objective of this phase is to analyse and specify architecture at a high-level scale are identified. To meet agility, the requirements of the current iteration. This phase includes it is necessary to avoid capturing too complex information two main stages: Requirements Analysis and Requirement since detailed information will be evolved incrementally. All Specifications. the requirements are prioritised and recorded in the product backlog by the product owner as a form of user stories. Based 1.1 Requirements Analysis on that, the overall release plan will be established which In this stage, the requirements of the current iteration are distributes the product backlog tasks into iterations in order defined and structured in more detail. Both functional and to predict when the product can be released. Moreover, the non-functional requirements should be identified clearly. tools, modelling language and platform should be identified Since, non-functional requirements are ill-defined in Agile and agreed upon at this stage. development [12], more attention should be paid to identifying them early at the development stage. Some requirements previous stage. These specifications describe the technical mechanisms such as prototypes and scenario analysis can be specification of the target platform (e.g., EJB, .NET) to allow used to agree and clarify the meaning of requirements with generating the code and transformation can be employed to the customer. During this stage, any existing components refine some artifacts. Formal verification at the specification that can be used to support new requirements should level can be used to ensure the key properties are preserved be identified. Furthermore, any components which have from one iteration to the next. Following the Agile practice potential for future reuse should be identified where possible. refactoring, developers should review the specification The recognition of reusable components within a product structure continuously to ensure the best design of the line may result in the establishment of a substantial library system. Since models are the intrinsic driver in development of components to support the development of related products. process, when change occurs or defects are discovered, the resolutions for the issues should be at the modelling 1.2 Requirements Specification level. Before and after every change, all test cases should pass. Once the requirements are identified, modellers start develop- ing models that fulfil these requirements. The initial architec- 2.2 Implementation ture should be revised and amended accordingly. In the context At this stage, developers produce the software that is testable of MDD, metamodels and transformations are considered the and executable. MDD differs from other software development main elements of the process and any models should conform approaches in that the code is partially or completely generated to metamodels. As with any artifact, developers can reuse from the models. The level of automation that translates metamodel artifacts provided by standards such as UML and models into code can be varied from partial to complete MOF or developed in previous common projects. Any iden- implementation of the system. Although the code is generated tified reusable components should be imported from and/or from models, it is still necessary to run tests against the code added to the library by the specification library manager. to make sure the model semantics are as expected. When some When the representation of the metamodels is not available, part of the system cannot be generated automatically, it can developers need to define it to capture the abstract syntax be written and manually added and tested. and constructs used to define models. Transformations should In parallel to the software development process, a tooling also be identified, these include transformations between sub-team can be employed to provide technical support different models or from models to text. Afterwards, models such as necessary extensions or adaptations of tools. Having are created that specify the requirements precisely. Different in-house team is found to be effective to help when issues perspectives of the system are identified to be modelled and arise [16]. The same proposed Agile MDD process can be a set of models is selected accordingly e.g. use case, class used by the tooling team considering the development team as diagram, activity diagram. Pair modelling, analogue to XP’s the customer who issues requirements for tools. The sub-team pair programming [4], can be followed during modelling is optionally employed when needed. where two developers work together. This should help detecting and resolving modelling issues instantly [7]. At this stage, any technical specification should be avoided. D. Phase 3: Integration and Testing The main objective of this phase is to integrate the C. Phase 2: Development developed parts of the system and to make sure they behave The main objective of the development phase is to produce as expected. This phase includes two main stages: Integration a technical specification of the system and to produce and Testing. an executable system that fulfils the functional and non- functional requirements. This phase includes two main stages: 3.1 Integration Design and Implementation. Since one of the intrinsic characteristic of agile development is to develop the system in an incremental fashion, the 2.1 Design increments need to be integrated and tested frequently. The developers model the detailed structure and behaviour Therefore, by adopting the agile practice of continuous of the system that fulfils the functional and non-functional integration, developers need to integrate their work as soon requirements. Although extensive customer involvement is a as it is completed. key factor in Agile development, in our process the customer is selectively involved in tasks such as requirements capturing 3.2 Testing and reviewing. This is due to the facts that most customers Integrated parts such as components and subsystems are don’t have required knowledge of MDD activities such as verified by regression tests to detect errors early in the de- modelling, designing and implementation. Following the velopment. Although testing is integrated frequently in all the Agile practice incremental design, the developers design phases of the iteration, testing should be performed at the end and specify the platform-specific aspects by refining the of the development process as well [15]. In the context of platform-independent models which have been defined in the MDD, automatic testing (model-based testing) can be carried out. However, manual testing according to various levels of testing activities can be used. 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 Fig. 2: C Code Generator Architecture the development process and assess what has been done during the iteration, a review meeting is held. TABLE I: User Stories of Informal Scenarios for types2C. ID User Story E. Phase 4: Deployment F1.1.1.1 Translate String type to char* When the system has been fully implemented and reaches Translate int, long, double types F1.1.1.2 to same-named C types a stable version, the system will then be deployed to the Translate boolean type to unsigned customer. The goal of the deployment is to release the system F1.1.1.3 char and make it ready to use by the customer without developer’s Translate Enumeration type to F1.1.2 supervision. This activity takes place only once at the end of C enum the development process. Translate Entity type E to F1.1.3 struct E* type IV. C ASE S TUDY: UML TO C CODE G ENERATOR Translate Set(E) type to F1.1.4.1 struct E** (array of E’, without In order to illustrate the proposed process, we applied it duplicates) to the development of code generator for mapping UML to Translate Sequence(E) type to ANSI C for the UML-RSDS [10]. UML-RSDS is a MDD F1.1.4.2 struct E** (array of E’, possibly tool that uses a subset of UML as an input language. At the with duplicates) specification level, UML-RSDS models application by UML 2 class diagrams and use cases. Optionally state machines and interactions can be used. At the design level, UML activities release plan, the product owner organised the development using pseudo-code notations are used. For this case study, into five iterations, each of which develops one translation. the stakeholders are: customers who needed to develop this Each iteration was given a maximum duration of one month. system, the UML-RSDS development team, and end users In the following subsections, we present the iterations. Due to who use such a system. limited space, only the first three iterations are explained in detail. A. Phase 0: Initialisation B. Iteration 1: Translation of Types Besides the scope and the size of the system, the initial This iteration concerns the mapping of data types such as requirements were identified. The main functional requirement boolean, int, long, etc. into C representations by defining the for the generator is (F1): Translate UML-RSDS designs (UML sub-transformation types2C. During the iteration planning, the class diagram, use cases, OCL, activities) into ANSI C code. development team planned to implement F1.1: Translation of Using goal decomposition, F1 is decomposed into five types. sub-goals: Phase 1: Requirements and Specification Detailed requirements elicitation identified the following • F1.1: Translation of types requirements: (i) the source language, (ii) the target • F1.2: Translation of class diagrams language, (iii) the mapping requirements, (iv) non-functional • F1.3: Translation of OCL expressions requirements NF1, NF2, NF3. The main user story for F1.1 • F1.4: Translation of activities was: • F1.5: Translation of use cases As a developer, I want to translate a UML type to its Furthermore, non-functional requirements were identified such corresponding C type. as: • NF1: Termination, given correct input This user story was decomposed into further sub-user • NF2: Efficiency: input models with 100 classes and 100 stories and their scenarios are presented in Table I. attributes per class should be processed within 30 seconds The requirements specification formalised these translations • NF3: Modularity of the transformation as UML-RSDS rules, defining the post-conditions of a The dependencies and priorities of the requirements were iden- transformation types2C. The corresponding part of genCtext tified and consequently the product backlog was created. Fur- was developed alongside types2C. thermore, the initial architecture was identified as a sequential decomposition of model-to-model transformation (design2C) Phase 2: Development and model-to-text transformation (genCText) (Fig. 2). In the The source language for this transformation was identified as the Type class and its sub-classes in the standard UML-RSDS possible to complete it in one month. class diagram metamodel, while the initial target language is a simplified version of the abstract syntax of C programs, Phase 1: Requirements and Specification Detailed requirements elicitation identified the mapping scenarios of sufficient to represent UML types. The design in UML-RSDS the above mentioned subgroups of OCL expressions. For brevity, is produced automatically from the formal specification. The only the mapping scenarios for the basic expressions are presented formal specification for F1.1.1.1 and F1.1.1.2 are: in Table II. PrimitiveType:: name = "int" => CPrimitiveType-> TABLE II: User Stories of Informal Scenarios for Basic exists( p | p.ctypeId= typeId & p.name= "int") Expressions. PrimitiveType:: name= "String" => ID User Story CPointerType->exists(t | t.ctypeId= typeId & Translate self in OCL expression CPrimitiveType->exists(p | p.name= "char" & F1.3.1.1 to self as an operation parameter in t.pointsTo = p )) C representation Translate variable v or v[ind] to v F1.3.1.2 or v[ind’-1] in C representation Phase 3: Integration and Testing Translate data feature f of context E with Test cases were manually developed to test the functionality, in no objectRef to F1.3.1.3 addition to inspection and formal arguments for the satisfaction of self → f (E is root) the requirements. Since this was the first iteration, integration was or getE f(self) (otherwise) not needed at this stage. Translate operation call op(e1,...,en) F1.3.1.4 or obj.op(e1,...,en) of instance entity scope op of E to C. Iteration 2: Translation of Class Diagram Translate call op(e1,...en) of The goal of this iteration was to define the sub-transformation F1.3.1.5 static/application (classdiagram2C) that is concerned with mapping UML class scope op to op(e1’,...,en’) diagram into C. During the iteration planning, given its high priority, Translate col[ind] ordered collection col to F1.3.1.6 it has been planned to implement F1.2: Translation of class diagram (col’)[ind’-1] F1.3.1.7 Translate E.allInstances to e-instances at this iteration. Translate value of enumerated type, F1.3.1.8 numeric or string value to value Phase 1: Requirements and Specification Translate boolean true, false to During the requirement phase, the class diagram elements Entity, F1.3.1.9 TRUE,FALSE Operation, Property, and Generalisation were identified as the input language. Exploratory prototyping was used for further requirements elicitation. Phase 2: Development Similar to type translation iteration, user stories for the mapping during design activity, for each category of expressions the developers of UML class diagrams to C were informally identified. modelled the detailed specifications, for example: BasicExpression:: Phase 2: Development query mapBasicExpression(ob : In order to translate class diagram classes, the developers design the Set(CExpression),aind : Set(CExpression), following function to create C code getters for properties: pars : Sequence(CExpression)) : CExpression CMember:: query getterOp(ent : String): String pre: post: result = type + " get" + ent + "_" + ob= CExpression[objectRef.expId] & name + "(struct " + ent + "* self) { return aind= CExpression[arrayIndex.expId] & self->" + name + "; }\n" pars= CExpression[parameters.expId] post: Similar functions were defined to express other aspects of UML (umlKind= value => classes in C. result= mapValueExpression(ob,aind,pars)) & (umlKind = variable => Phase 3: Integration and Testing Phase result= mapVariableExpression(ob,aind,pars)) Testing, inspection, and formal arguments were used for validating & (umlKind = attribute => and verifying the requirements. Both iteration 1 and 2 have result= mapAttributeExpression(ob,aind,pars)) been integrated and grouped as one executable jar file. Integration & (umlKind = role => testing was conducted to make sure the integration behaved correctly. resul= mapRoleExpression(ob,aind,pars)) & (umlKind = operation => result= mapOperationExpression(ob,aind,pars)) D. Iteration 3: Translation of Expressions & (umlKind = classid => result= mapClassExpression(ob,aind,pars)) & This iteration concerns the mapping of OCL expressions to (umlKind= function => C. During the iteration planning, the development team planned result= mapFunctionExpression(ob,aind,pars)) 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 Phase 3: Integration and Testing of basic expressions, (ii) translation of logical expressions, (iii) Testing and inspection were used for validation and verification. translation of comparator, numeric and string expressions, and (iv) Testing of these operations revealed some errors regarding the meta- translation of collection expressions. Due to its large size, it was not models such as error in the value of the multiplicity. The generation TABLE III: Development effort for UML-RSDS code gener- R EFERENCES ators (person-month). [1] Hessa Alfraihi and Kevin Lano. The integration of agile development Java 4 Java 7 C# C++ C and model driven development: A systematic literature review. In Proceedings of the 5th International Conference on Model-Driven Requirements Analysis 6 2 3 6 4.5 Engineering and Software Development, MODELSWARD, 2017. Implementation 12 4 4 6 1 [2] Scott Ambler. Agile modeling: effective practices for extreme program- Testing 6 1 1 2 0.5 ming and the unified process. John Wiley & Sons, 2002. Maintenance 6 1 1 3 0 [3] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, Total 30 8 9 17 6 M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mallor, Ken Shwaber, and Jeff Sutherland. The Agile Manifesto. Technical report, The Agile Alliance, 2001. of model.txt by the UML-RSDS tools needed to be adjusted in [4] Kent Beck. Extreme programming explained: embrace change. addison- several cases to ensure that appropriate information was available wesley professional, 2000. for UML2C. It was decided that the integration of iteration 3 will be [5] Håkan Burden, Sebastian Hansson, and Yu Zhao. How MAD are conducted later with iterations 4 and 5. we? Empirical Evidence for Model-driven Agile Development. In Translation of activities, and use case were implemented in itera- Proceedings of XM 2014, 3rd Extreme Modeling Workshop, volume tions 4 and 5 respectively. 1239, pages 2–11, Valencia, Spain, September 2014. CEUR. [6] Widia Resti Fitriani, Puji Rahayu, and Dana Indra Sensuse. Challenges E. Phase 4: Deployment in agile software development: A systematic literature review. In Advanced Computer Science and Information Systems (ICACSIS), 2016 The code generator was deployed and delivered as Java jar executa- International Conference on, pages 155–164. IEEE, 2016. bles: iteration 1 and 2 were grouped in one executable (uml2Ca.jar) [7] Gábor Guta, Wolfgang Schreiner, and Dirk Draheim. A lightweight and iterations 3, 4, and 5 in (uml2Cb.jar). The complete translator mdsd process applied in small projects. In Software Engineering and was referred to as (UML2C) and it can be found via the link in the Advanced Applications, 2009. SEAA’09. 35th Euromicro Conference on, footnote 1 . pages 255–258. IEEE, 2009. [8] Gábor Guta, Wolfgang Schreiner, and Dirk Draheim. A lightweight mdsd process applied in small projects. In Software Engineering and V. E VALUATION Advanced Applications, 2009. SEAA’09. 35th Euromicro Conference on, Several code generators have been developed previously for UML- pages 255–258. IEEE, 2009. RSDS using Agile development with manual coding in Java (i.e, [9] Vinay Kulkarni, Souvik Barat, and Uday Ramteerthkar. Early experience non-MDD approach) such as Java 4, Java 7, C#, and C++. Table III with agile methodology in a model-driven approach. In Model Driven shows the approximate effort in person-months expended for each of Engineering Languages and Systems, pages 578–590. Springer, 2011. these to date including our C code generator. An overall development [10] Kevin Lano. Uml-reactive system design support. Technical report, King’s College London, 2012. effort reduction has been noticed for the C code generator using [11] Xabier Larrucea, Ana Belen Garcı́a Dı́ez, and Jason Xabier Mansell. Agile MDD process. The benefits of this effort reduction are mainly Practical model driven development process. Computer Science at Kent, due to the use of specifications instead of code, and to the use of page 99, 2004. executable modelling. The decomposition of the transformation into [12] Balasubramaniam Ramesh, Lan Cao, and Richard Baskerville. Agile semi-independent phases formed a natural basis for the definition requirements engineering practices and challenges: an empirical study. of the top-level work items in the product backlog, and this in Information Systems Journal, 20(5):449–480, 2010. turn led to the definition of iterations. The use of short iterations [13] K. Schwaber and M. Beedle. Agile Software Development with Scrum. and backlogs enabled incremental development of the translator and Agile Software Development. Prentice Hall, 2002. helped organise the development. Partial specifications were defined [14] Bran Selic. Model-driven development: Its essence and opportunities. In Object and Component-Oriented Real-Time Distributed Computing, for each separate iteration of the system, and incrementally refined. 2006. ISORC 2006. Ninth IEEE International Symposium on, pages 7– Refactoring was extensively used to improve the specification, in pp. IEEE, 2006. particular the removal of duplicated functionality. The agile emphasis [15] Markus Völter, Thomas Stahl, Jorn Bettin, Arno Haase, and Simon on simplicity helped to reduce the specification complexity: in Helsen. Model-driven software development: technology, engineering, particular only class diagrams and OCL constraints are used to define management. John Wiley & Sons, 2013. the translator, without activities or other UML models. Also, we [16] Jon Whittle, John Hutchinson, Mark Rouncefield, Håkan Burden, and found it effective in handling changing requirements to translate Rogardt Heldal. A taxonomy of tool-related issues affecting the adoption static operations. Overall, we consider the combination of agile and of model-driven engineering. Software & Systems Modeling, 16(2):313– MDD to be effective in improving system quality and reducing 331, 2017. [17] Yuefeng Zhang and Shailesh Patel. Agile model-driven development in development time. Further techniques, such as model-based testing practice. IEEE software, 28(2):84, 2011. and pair modelling, will be investigated in future work. VI. C ONCLUSIONS AND F UTURE W ORK 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. 1 https://nms.kcl.ac.uk/kevin.lano/uml2web/