The Third International Conference on Software Engineering Advances

Adapting Software Development Process towards the Model Driven Architecture

Vladimirs Nikulsins Accenture, Riga, Latvia vladimirs.nikulsins@accenture.com Abstract
Model driven architecture (MDA) is increasingly gaining the attention of both research communities and industry. MDA is a model-oriented software development paradigm, which can be applied to any software development methodology. MDA gives no guidelines in terms of the processes such as activities and phases, roles and responsibilities that are involved in the software development process. When an organization considers applying MDA-based software development process, it will face the lack of methodological guidelines. The aim of this paper is to customize typical heavyweight software development methodology (based on most widely used methodologies Rational Unified Process and Microsoft Solutions Framework) according to the MDA software development framework.

Oksana Nikiforova Riga Technical University, Riga, Latvia oksana.nikiforova@rtu.lv

The portability problem (frequent technology update or change) The interoperability problem (the complexity of the communication between systems) The maintenance and documentation problem (documentation has no influence on code and vice versa) Various approaches, methodologies, techniques and tools supporting the development of software systems exist and evolve, becoming more and more complex. They dont affect the underlying software development principle: working code will always be the ultimate goal of software development. A promising approach to resolve these problems is the Model Driven Architecture (MDA), a framework for software development defined by the Object Management Group (OMG) [1], [2]. Key to MDA is the importance of models in the software development process. Within MDA the software development process is driven by the activity of modelling the software system. Through the various automated and semi-automated transformation models are being transformed into the working code. Since MDA does not prescribe a development methodology, each MDA-based development project has to define its own methodology or apply existing ones. MDA gives no guidelines in terms of the processes such as activities and phases, roles and responsibilities that are involved in the development software development. Furthermore, the MDA technologies are not explicitly related to identifiable activities within software development processes, as these technologies are being developed to be generally applicable in combination with development processes that may already be anchored in organisations [3]. Hence, there is a potential research opportunity in applying MDA to the traditional software development. The goal of the paper is to present a general framework of the model driven development usage within the traditional iterative development process. The guidelines on the modifications of the popular

1. Introduction
Software development process complexity combined with the intricacy of software systems has increased significantly. With environment undergoing non-stop changes, businesses are challenged to adapt via business process enhancement and corresponding software systems improvement. Using any new technology involves a lot of activities that need to be done again and again. Systems are rarely based on one technology and often systems have to communicate with other systems. Code and documentation are still separated from each other. When quick changes to the software system are applied, it is typical that documentation is not updated. Through the time documentation can become useless. According to [1] the main problems of the traditional software development are: The productivity problem (developers often consider code is to be productive, writing models and documentation are not)

978-0-7695-3372-8/08 $25.00 2008 IEEE DOI 10.1109/ICSEA.2008.25

394

heavyweight methodologies, Microsoft Solutions Framework and Rational Unified Process, are provided. Overview of the current status of the research field and software production industrialization aspects is outlined in Section 2. Section 3 provides guidelines and comments on the model driven development approach application within traditional software development methodologies. Followed by this section, Section 4 describes conclusions and future work plans.

2. Using MDA to customize a solution framework

Modern heavyweight software development methodologies (like Rational Unified Process and Microsoft Solutions Framework) are quite general and can be applied to various software development projects. From the other side, MDA also does not prescribe a specific development methodology to be used. Organizations that use internal software development methodology may utilize their own development experience in this area and apply MDA to the already established process.

2.1. Existing researches

There are various researches available on the software development process usage tied with MDA. However, only few of them provide particular guidelines and recommendations on how to map MDA to the typical software development methodology which is being used in practice. OMG also proposes that MDA is not limited to be used in any software development project. Case study analysis can enrich the establishment of a methodological base. One of the results of such researches is a MASTER project (Model-driven Architecture inSTrumentation, Enhancement and Refinement) deliverable called Process Model to Engineer and Manage the MDA Approach [8]. The main part of that report describes a standard software process (SSP) for software development following a model-driven and system family engineering approach. Such SSP should be instantiated to each specific project through a derivation mechanism which is also explained. The process model described is based on SPEM (Software Process Engineering Metamodel), a metamodel and a UML profile dedicated to software process modelling. It is useful for modelling a family of related software processes using UML notation. Importance of process improvement initiatives is also covered, making the methodology compliant with CMM requirements. Integrated software development methodology, which was applied to the telecommunication domain,

was proposed in the MODA-TEL project. Through the assigning appropriate methods to the software development processes like Rational Unified Process (RUP), V-model or CMM, MDA-supported methodology will be devised [9]. However, complete and consistent software process based on MDA is beyond the scope of the MODA-TEL project. Similar to MASTER project, the phases and activities in the development process, as well as the roles and products of each activity in accordance with the Software Process Engineering Metamodel (SPEM) were identified and proposed in the new methodology [3]. However, this methodology is designed for distributed applications development only. By analyzing case studies it is possible to get an overview on how to fit MDA into the software development process when the web services based solution is being implemented [10]. The overview of the main aspects covers process roles, artefacts and deliverables, tools (by providing an example of using Codagen tool) and separation of lifecycle phases within the RUP software development process. In that way collaboration between all the interveners of the development cycle is achieved and visualized. It is possible to extend and implement this approach to other software development projects as well. Organizations developing software products should organize their process effectively and continuously enhance its maturity (e.g., reaching higher maturity levels of CMM). The automation of software production could lead to the continuous improvement inside single organization.

3. Software development methodologies and MDA

At the metamodel level, a methodology describes a set of coordinated activities realized by actors to produce defined work products [11]. The aim of any typical software development methodology is to define guidelines to be used in a development project in terms of the necessary activities, roles, work products, etc. Software development methodologies are especially valuable for large systems development like enterprise systems development. Such systems are rarely developed from scratch, line-by-line, in an IDE. Rather, they are created by extending an existing solution framework with domain-specific business logic, by connecting to (and manipulating) information from different sources, and by designing context-rich user display and interaction services [12], [13]. This approach is characterized with continual extension and refinement of an existing partial solution toward a desired goal through a set of iterations that add value to the solution. These partial solutions that form the heart of a

395

new system may come from one of the following sources: An existing set of applications A proprietary application framework used by the organization An acquired application framework A set of extensions and customizations to packaged applications According to these possibilities, the primary task is to create a clear understanding of the domain, to express that understanding in a platform-independent domain model. Such model should support various kinds of analysis to ensure its correctness and consistency, and to map that domain model to a platform-specific implementation realized by extending the solution framework. In model-to-code transformations, the solution framework plays a key role, because it constrains and guides the kinds of transformations that are meaningful.

3.1. MDA and RUP

MDA is still a new and emerging approach, which has not been widely accepted in practice yet. There still exist problems such as insufficient MDA tools support and lack of methodological frameworks proved in practice. Currently, RUP provides no specific guidance on how to integrate an MDA style of software development into the overall process. Experiences [13], [14] indicate a number of aspects in which it is possible to enhance RUP with best practices for MDA projects. The RUP fundamental, an architecture-centric and iterative development process, is highly consistent with MDA concepts. However, there are some areas where additional guidance on MDA is appropriate. The MDA software development lifecycle applied to the RUP process is the following. At the Inception phase requirements for the system are being elicited, resulting in a CIM. CIM model covers Business Modeling and Requirements disciplines. At the same time, during the Inception phase, metamodel planning for the PIM development and initial implementation are carried out. PIM covers some parts of Construction also the models should be enriched with mapping functions and appropriately marked. Models are iteratively tested for conformance. At the Construction phase, model transformation into different PSM or code takes place. PSM covers the Transition phase and Deployment discipline as well transition to some production environment can be performed with the help of separate PSM as well. Configuration and Change Management discipline is also affected by MDA these disciplines cover metamodel and metadata repository maintenance.

There are several practical and theoretical researches available on how to apply MDA to the RUP. Important aspects to consider in applying RUP to an MDA project are the following [13]. Elaboration is the main phase impacted by an MDA project. It is important to look at Elaboration activities and briefly describe MDA modifications. The Architect role is the main role in Elaboration phase that requires additional consideration. As a specialization of "Architect," the MDA Architect role is appropriate to many MDA projects. Essentially, this role defines specific MDA activities and artefacts, creates the transformations, and so on. The primary MDA artefacts from this role are mapping documents, transformations, and UML profiles. It should be noted, that [8] divides the Architects role into a Software Architect (who is in charge for PIM design) and a Deployment architect (who is in charge for PSM design). Typically, MDA automates activities within RUP. Rather than changing RUP activities, MDA enhance them with additional tasks aimed at supporting automation with a number of the primary RUP activities. The primary changes to RUP involve a more subtle change of perspective on the development process. MDA encourages architects and developers to work at higher levels of abstraction than typically expected in non-MDA projects. This is most apparent during construction where the code automation aspects of MDA significantly change the emphasis of the implementation tasks. They work less with actual implementation models and source code themselves, and more with designs for the appropriate businessfocused workflow of the solution. A smaller subset of developers will be implementing the model-to-code transformations themselves. However, the amount of work needed for transformations may vary and depends on initial availability of the transformation tools [9]. The RUP phases and workflows, enriched with the MDA specific deliverables are described in [15].

3.2. MDA and MSF

Microsoft is implementing own approach in the model-driven development area through the Visual Studio Team System (VSTS) System Definition Model (SDM), which is not compliant with OMG initiatives [16]. SDM aim is the definition of metadata requirement, which is used through Envisioning, Planning, Developing, Stabilizing and Deploying phases. SDM are described with special DomainSpecific Language (DSL) instead of UML, which allows taking into account .NET specificity.

396

Currently no theoretical base or case study research on how to map MDA to MSF exists. However, it is still possible to apply general MDA mapping rules to the MSF software development process model. At the envision phase, requirements specification with well-defined terminology should be elicited (probably, resulting in ontology) [17], [9], [15]. Structuring of captured information should be performed. This formal structured information and the terms of the ontology could later be used to refine the requirements into design-oriented models. Later, models should point back into the requirements for traceability and test specification formalisms (validating a resulting system against the requirements). The formalized outcome is CIM model. Preparations for PIM development starts at the beginning of Envision phase as well. Metamodel development is being initiated. MSF standard deliverable Risk Assessment Document should be enriched with MDA related information (transformation tools availability, metamodels facilities evaluation, mapping complexity assessment and etc.). Vision/scope Document should be enriched with Project Structure Document and conceptual model. Similar to RUP, the MDA modeling activities will affect the MSF Plan phase to a great extent, where the design of PIMs and initial planning of PSMs should be clearly identified. The metamodels or profiles of the domain analyzed should be extracted first and then models based on these models can be used to formally describe the system. This is an incremental activity each new instance of a metamodel could bring up some improvements for the metamodel. Additional constraints in the models should be defined with Object Constraint Language (OCL). Functional specification semantics, which is the standard MSF deliverable, should be captured in the models as well. At the Build phase, development or improvement of model transformation algorithms or code generators activities should be performed. Both PIM and PSM models should be marked, and mappings rules should be defined. Additional complex business rules and transaction methods, where a further structure could not be abstracted from the use cases should be implemented. Implementing runtime environments for some domain specific structures or patterns found takes place in the design process as well. MSF Build phase deliverables source code and executables, are replaced with marked PIM and PSM models. Test specifications and test cases are defined both for models and for the final solution resulted in code (in order to verify the system functionality and models conformance). Once the models are marked, it is possible to make automated (or semi-automated) PIM to PSM transformation and PSM to code (or PSM

to PSM transformation as well). The transformation process should occur at the end of Build phase, resulting in an additional deliverable executable model. PSM covers the most part of stabilize phase. Stabilize phase allows to test models conformance with test cases, which were created in the previous Build phase. As [15] outlines, one of the famous slogans of extreme programming- "tests first" can be translated in the MDA world to "verify first". The development process itself is iterative, so if any inconsistence found in the target model, source model or appropriate mapping functions should be modified. The transformation process continues until the bug convergence is reached. MSF principle about zero bug bounce can be successfully applied to the models testing in the MDA context. During the Deploy phase, the team deploys the core technology and site components, stabilizes the deployment, transitions the project to operations and support, and obtains final customer approval of the project. The result of the deployment phase is a working system, which is implemented in code and is set up in production. Most deployment information is based on some sort of metamodels or profiles (some PSMs). By using model transformation to create instances of such metamodels for deployment directly from the models and their annotations, the deployment process will become much more transparent and less dependent on certain versions of the target technology. In case requirements for the system are revised or there are changes in the target architecture, the software development lifecycle starts from the beginning. The most impressive benefits are acquired in the maintenance phase (however, this phase is out of scope in MSF process model). The more dynamic and structured the architected system is, the less complicated and time consuming development phases are necessary and the cheaper and more effective the maintenance phase will be.

3.3. MDA and universal software development process

MDA specific activities can be tailored to universal software development process, and expressed in the diagram form. Such tailoring could ease the perception of the typical software development lifecycle adaptation to MDA. Taking into account the most widely used software development processes in Latvia, universal software development process, generally applicable to heavyweight software development process, is considered as consisted of unified RUP and MSF phases and activities [5]. Figure 1 represents the highlevel phase mappings between MDA and universal

397

software development process in terms of phases and appropriate activities. It represents only static structure, without taking into account iterative process aspects. Agile software development process is not covered here due to its difference from strict and formal heavyweight process. However, agile software development aspects will be analyzed in forthcoming works. Thus it will facilitate in overall understanding of how the MDA could be utilized within software development methodologies. Such tailoring is out of scope in this paper.

Model Driven Development Lifecycle

7 8 9

information Verify models PSM identification Define verification strategies Define user interface options (with model aware aspects) PSM metamodel design Verify models Mark PIM and PSM Create additional transformations and code generation scripts for target platforms Create test scripts PIM to PSM automatic or semi-automatic transformation Verify the established meta-models Code files generation from PSM Automatic deployment (deployment profiles or PSMs can be used) Fine-tuning and repeated use of automated testing process Executable code verification to models

4. Conclusions and future work

This paper provides guidelines and instructions on MDA utilization within the typical heavyweight software development methodologies such as RUP and MSF. Analyzing existing research in this area, a lack of well formalized knowledge was identified. There are various case studies and MDA process specifications available. However, they are not general ones and are limited to specific domain (e.g., distributed applications). Future research in this area can possibly lead to universal methodology development, which could be applied both to the heavyweight and agile methodologies. It is planned to proof the outcome of such MDAbased methodology application in practice within one of the Latvian software development companies. A special attention should be given to the transition of the software development process from the traditional form into model-driven.

Figure 1. Software development lifecycle and MDA mappings According to Figure 1 appropriate activities in the phase crossings are marked with digits. Their description in more details is provided in Table 1. Table 1. MDA specific activities in the phase crossings Define possible domain specific metamodel Traceability convention from requirements to code Choose modeling tool Technology selection 1 Requirements specification development (ontology) Information structuring Initial PIM development Transformations strategy selection 2 Business process modeling role evaluation Risk assessment Refine PIM context 3 Define verification strategies PIM design Finalize metamodels Create model-capturing support (model instances, which are not easy to illustrate in 4 diagrams) Annotate PIM with platform specific

5. Acknowledgements
The research reflected in the paper is supported by the research grant of Riga Technical University Development of Conceptual Model for Transition from Traditional Software Development into MDAoriented and by the European Social Fund within the National Programme "Support for the carrying out doctoral study program's and post-doctoral researches".

398

6. References
[1] Kleppe A., Warmer J., Bast W. MDA Explained: The Model Driven Architecture: Practice and Promise. Addison Wesley, April 2003. [2] OMG Model Driven Architecture. Available at: http://www.omg.org/mda [3] Gavras A., Belaunde M., Pires L.F., Almeida J.P.: Towards an MDA-based development methodology for distributed applications [4] Kruchten P.: The Rational Unified Process An Introduction, Second Edition, Addison Wesley, 2000. [5] Nikulsins V,. Nikiforova O., Sukovskis U. Analysis of Activities Covered by Software Engineering Discipline, Databases and Information Systems, Seventh International Baltic Conference on Databases and Information Systems, Communications, Materials of Doctoral Consortium, O. Vasilecas, J. Eder, A. Caplinskas (Eds.), pp. 130-138, VGTU Press Technika scientific book No 1290, Vilnius, Lithuania, 2006 [6] Meservy T., Fenstermacher K.D. Transforming Software Development: An MDA Road Map. University of Arizona, 2005. [7] Kontio M. Architectural manifesto: MDA for the enterprise. An architect's approach to more productive development. IBM. July 2005. [8] Process Model to Engineer and Manage the MDA: Model-driven Architecture inSTrumentation, Enhancement and Refinement Approach. European Software Institute. September 2003. Available at: http://modeldrivenarchitecture.esi.es/pdf/Deliverable-D32.zip [9] Steinhau R. Model Driven Architecture Definition and Methodology. Deliverable 3.1. MODA-TEL. Interactive Objects Software GmbH, 2002. Available at: http://www.modatel.org/public/deliverables/D3.1.htm [10] Bertrand D. Model-Driven Architecture Case Study: Model-Driven Architecture with Codagen. June 12th 2003. Available at: http://www.omg.org/news/meetings/workshops/MDA_Wksp _Manual/06-1_Bertrand_Brassard.pdf. [11] Langlois B., Exertier D. MDSoFa: a Model-Driven Software Factory. Thales Research & Technology France. October 2004. Available at: www.softmetaware.com/oopsla2004/langlois.pdf [12] Belaunde M. Initial identification of issues for further research. Deliverable 2.2. MODA-TEL. Interactive Objects Software GmbH, 2002. Available at: http://www.modatel.org/~Modatel/pub/deliverables/D2.2final.pdf [13] Brown A., Conallen J. An introduction to model-driven architecture. Part III: How MDA affects the iterative

development process. May 2005. Available at: http://www.ibm.com/developerworks/rational/library/may05/ brown/index.html [14] Mansell J., Bediaga A., Vogel R., Mantell K. A Process Framework for the Successful Adoption of Model Driven Development. A. Rensink and J. Warmer (Eds.): ECMDAFA 2006, LNCS 4066, pp. 90100, 2006. [15] Steinhau R. Guidelines for the Application of MDA and the Technologies covered by it. Deliverable 3.2. MODA-TEL. Interactive Objects Software GmbH, 2003. Available at: http://www.modatel.org/~Modatel/pub/deliverables/D3.2final.pdf [16] Dubova N. Software development platforms (in Russian). Open Systems, January 2006. Available at: http://www.osp.ru/os/2006/01/380740/_p3.html [17] Microsoft. Microsoft Solutions Framework: MSF Process Model v. 3.1. White Paper, Microsoft Corporation. June 2002. [18] Brown A.W. Model driven architecture: Principles and practice. IBM Software Group, USA. Published at SpringerVerlag, 2004.

399