Model Driven Development Future or Failure of Software Development?

Model Driven Development Future or Failure of Software Development? Ruben Picek, Vjeran Strahonja University of Zagreb, Faculty of Organization and Informatics, Varaždin ruben.picek@foi.hr, vjeran.strahonja@foi.hr Abstract. This article discusses some issues of the software development paradigm called Model Driven Development (MDD). Its basic idea is to move software development to a higher level of abstraction by using models as primary artifacts, and to transform models into the source code, with the aid of tools. Currently, there are several approaches to the realization of MDD paradigm which should bring a lot of benefits. However there are still problems to be solved, which will be discussed here. The authors are also going to analyze developers pros and cons, and give their own opinion about today's open question: Will MDD become a failure in trying to deal with software crisis, like the idea of CASE tools in 80's or will it become the future of software development? Keywords. MDD, MDD approaches, MDA, Software Factories, Software Development 1. Model Driven Development Paradigm In the last few years, software development has been faced with many challenges. Requirements of new and/or existing systems are growing, systems are complex and it is hard to build them on time and on budget. As an answer to these challenges, a wide spectrum of new approaches occurred, varying from buzzwords to comprehensive methodologies. One of the most prominent paradigms is Model Driven Development (MDD). MDD represents a set of approaches, theories and methodological frameworks for industrialized software development, based on the systematic use of models as primary artifacts throughout the software development cycle. It targets two roots of software crisis complexity and ability to change. First of all, let us start with definition of MDD paradigm? The basic idea of this paradigm is to move the development efforts from programming to the higher level of abstraction, by using models as primary artifacts and by transforming models into source code or other artifacts The ultimate objective is the automated development (fully or partly). According to [13], MDD is a style of software development where models are primary software artifacts. Other artifacts and code are generated from them, according to best practices In [7], MDD is defined as software engineering approach consisting of the application of models and model technology to raise the level of abstraction at which developers create and evolve software, with the goal of both simplifying and formalizing the various activities and tasks that comprise the software life cycle. According to [2], MDD refers to a set of approaches in which code is automatically or semi automatically generated from more abstract models, and which employs standard specification languages for describing those models and the transformations between them. These definitions make clear that the focus of the MDD is a shift from the programming to the modeling. Models are the key artifacts. Currently, models are mostly used as sketches that informally convey some aspects of a system or they can be used as blueprints to describe a detailed design that is then manually implemented [13]. Use of models as documentation and specification is valuable, but it requires strict discipline to ensure that models are kept up to date as implementation progresses. Time constraints mainly cause that the initial models are not updated during the design and implementation, and inaccurate models are harmful. In MDD, models are used not just as sketches or blueprints, but as primary artifacts from which efficient implementations are generated, transforming models into programming code or other artifacts characteristic to domain. As described above, MDD shifts the emphasis of application development away from the platform, enabling developers to design applications independent of the platform-level concerns. Platform is the province of developers with the platform specific expertise. Platform expertise is involved as late as possible, it means at transformations, rather than, being rediscovered many times during a project. Likewise, decisions about the implementation architecture are directly encoded in the transformation engine rather than documented as architectural decisions [13]. According to Selic [10], the essence of model driven development is about two things. One is abstraction, in terms of how we think about the problem and then how we specify our solutions. Second thing that often gets forgotten is the introduction of more and more automation into the software development, specifically by using computer based tools and integrated environments. MDD-style should enable automation to go much further. A software development project needs to produce many non-code artifacts; some of these are

completely or partially derivable from models. The following list gives some common examples of artifacts that are generated from models, but you can probably think of others [13]: Documentation: In organizations that follow a formal development approach, producing documentation takes a significant amount of development effort. Keeping documentation in line with the implementation is notoriously difficult. When using MDD, documentation is generated from models, ensuring consistency and making information available and navigable to developers. Test artifacts: It is possible to generate basic test harnesses, such as using JUnit, from the information contained in software models. If additional testspecific modeling is carried out, for example using the UML Profile for Testing, then complete test cases are generated. Build and deployment scripts: Using their expertise, infrastructure architects can create transformations to generate, build and deploy scripts. Other models: A system involves many interdependent models at different levels of abstraction (analysis, design, implementation), representing different parts of the system (UI, database, business logic, system administration), different concerns (security, performance, and resilience), or different tasks (testing, deployment modeling). To the certain extent, it is possible to generate one model from another, for example moving from an analysis model to a design model, or from an application model to a test model. Pattern application: Patterns capture best practice solutions to recurring problems. Patterns specify characteristics of model elements and relationships between those elements. Generally, a pattern comprises a model together with its implementation. Vice versa, pattern can be used as an element of the model. According to the above mentioned definitions, the heart of MDD paradigm makes: - models, - modeling and - model transformation. Modeling and models are the central point of contemporary software development. But, one fact related to models has to be emphasized. There is a big difference of what models represent and how there are used. Traditional models are just sketches, and blueprints for design. In order to be suitable for the MDD, models must satisfy additional criteria they must be machine readable. Machine-readability of models is a prerequisite for being able to generate artifacts. There are two types of transformations: model to model (M2M) and model to code (M2C). Automated model transformations are the key for realization of the MDD idea. 2. MDD pros and cons In this part of the article, the benefits of MDD will be discussed, as well as the problems which arise in their realization. 2.1. Benefits of the MDD According to [13], [12], MDD has the potential to greatly improve current practices in software development. This potential manifests in overcoming the current challenges reducing the cost of development and increasing the consistency and quality of software. Some advantages of an MDD paradigm are [13], [12]: Increased developer productivity: The aim is the speed-up and cost reduction of the software development, by generating code and artifacts from models. Very important activities are factoring the cost of developing (or buying) transformations and careful planning. Maintainability: Many legacy software applications still run on platforms in which the organization no longer has expertise. MDD leads to a maintainable architecture where changes are made rapidly and consistently, enabling more efficient migration of components onto new technologies. High-level models are kept free of irrelevant implementation detail, making it easier to handle changes in the underlying platform technology and its technical architecture. Ideally, the change of the technical architecture means the new transformation. The transformation is reapplied to the original models to produce implementation artifacts for the new platform. Reuse of legacy: If somewhere are many components implemented on the same legacy platform, reverse transformations from the components to UML is needed. A solution may be a migration of components to the new platform, wrappers for access to the legacy component and integration of technologies such as Web services. Adaptability: Adding or modifying a business function is straightforward since the investment in automation was already made. When adding the new business function, you only develop the behavior specific to that capability. The remaining information needed to generate implementation artifacts was captured in transformations. Consistency: Manual application of coding practices and architectural decisions is error prone. MDD ensures that artifacts are generated consistently. Repeatability: MDD is especially powerful when applied at a program or organization level; the return on investment from developing the transformations increases each time they are reused. Use of proofed and tested transformations also increases the predictability of developing new functions, and reduces risk because architectural and technical issues were already resolved.

Improved stakeholder communication: Models omit implementation details that are not relevant to understand the logical behavior of a system. They are much closer to the problem domain and reduce the semantic gap between the concepts understandable by stakeholders and the language in which the solution is expressed. It facilitates the delivery of solutions that are better aligned to business objectives. Improved design communication: Models help understanding of the systems at the design level and improve discussion and communication about the system. Because models are part of the system definition rather than documentation, they are reliable and up to date. Capture of domain knowledge: Projects or organizations often depend on key experts who repeatedly make best practice decisions. Their expertise is captured in patterns and transformations, so they don't need to be present for other members of a project. If sufficient documentation accompanies the transformations, the knowledge of an organization is maintained in the patterns and transformations even when experts leave. Models as long-term assets: Models are important assets that capture of what the information system of an organization is and does. High-level models are resilient to changes at the state-of-the-art platform level. They change only when the business requirements change. Ability to delay technology decisions: Early phases of an application development are focused on logical issues. You can delay the choice of a specific technology platform or product until the further information is available. In domains with extremely long development cycles (such as air traffic control systems), this is crucial. The target platforms may not even exist when development finishes. 2.2. Current problems The primary goal in MDD paradigm is to raise the level of abstraction at which developers operate. It should reduce both the amount of developer's efforts and the complexity of the software artifacts that the developers use [7], [6]. Of course, there is always a trade-off between simplification by raising the level of abstraction and oversimplification, where details for any useful transformation are missing. As you can assume, problems are bound to model abstractions at different stages of the software life cycle. The open issue is how to transform a model at one level of abstraction, into a model or code at a lower level? In trying to answer this question, new ones arise. How to use models? Some developers use models only for sketching, others for blueprinting while MDD community presumed models as programming language. Which notation and modeling language should be used in order to provide automation? The standardization of modeling notations is unquestionably an important step for achieving MDD. Standardization provides developers with uniform modeling notations for a wide range of modeling activities. In SW industry today, the Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. The UML represents a collection of best engineering practices which have been proven in the modeling of large and complex systems. Although UML is widely recognized and used as modeling standard, it provoked a lot of criticism. Here are some of our critic opinions: - To be able to address so many needs, UML 2.0 becomes enormous, ambiguous and unwieldy. It contains some diagrams and constructs that are redundant or infrequently used. - UML 2.0 lacks a reference implementation and a human-readable semantic account to provide an operational semantics, so it's difficult to interpret and correctly implement UML model transformation tools. - The lack of semantics precision makes the production of automated MDD tools difficult because the semantics carries the meaning that is essential to enable automation. - Problems in learning and adopting. Is UML suitable as model programming language? The notion of UML 2.0 as a model programming language is predicated on the belief that the use of higher levels of abstraction will make developers more productive than current programming languages. Fowler [4], discusses whether this opinion is true. He doesn't believe that graphical programming will succeed just because it is graphical. Indeed he has seen several graphical programming environments that failed - primarily because it was slower to use them than writing code. (Compare coding an algorithm to drawing a flow chart for it.). Even if UML is more productive than programming languages, it will take the time to become accepted. Most of the people for many reasons are not using programming language they consider to be the most productive. Furthermore Greenfield et al. [5] argue that although UML 2.0 is a useful modeling language, it is not an appropriate language for MDD, because UML is designed for documenting and not for programming. They promote use of special-purpose, domain-specific languages (DSLs). Clearly, UML or any other MDD language faces significant hurdles to demonstrate sufficient value to satisfy the needs of all the different kinds of MDD users. According to [7], MDD creates other problems, like: redundancy, rampant round-trip problems, moving complexity rather than reducing it and more expertise that is required.

3. MDD approaches Two leading realizations of MDD paradigm are: The Object Managements Group (OMG) approach called Model Driven Architecture (MDA) and Microsoft's Software Factories (SF). Basic ideas of these approaches will be briefly presented below in this paper. According to [7] it is too early to predict which, if any, of the current MDD approaches will be accepted as an industrial standard. 3.1. Model Driven Architecture (MDA) MDA represents one view of MDD paradigm. It is not a new OMG specification, but an approach to software development which is enabled by existing OMG specifications, such as UML, MOF and CWM, with ability to address the complete development lifecycle. Model Driven Architecture is an approach that separates system's desired functions from their implementation on the specific technology platform. The result is an architecture that is not tied to any language, platform, or vendor [8]. MDA provides an approach for [1]: - specifying a system independently of the platform that supports it - specifying platforms - choosing a particular platform for the system - transforming the system specification into one particular platform. 3.1.1. Principles and Benefits of MDA Brown [3] highlights four principles underlying the OMG's view of MDA: - Models expressed in a well-defined notation are a cornerstone for enterprise-scale solutions. - The building of systems can be organized around a set of models by imposing a series of transformations between models, organized into an architectural framework of layers and transformations. - A formal underpinning for describing models is a set of metamodels, which facilitates meaningful integration and transformation among models, and is the basis for automation through tools. - Acceptance and broad adoption of the modelbased approach requires industry standards to provide openness to consumers, and foster competition among vendors. The three primary benefits of MDA are portability, interoperability and reusability through architectural separation of concerns [1], [12]. Further benefits are [8]: productivity, quality, rapid inclusion of new technology, reduced cost and development time. 3.1.2. Basic MDA Concepts Concepts that make the core of MDA are [1]: System - The context of MDA is the software system, either existing or under construction. Model A model is a formal specification of the function, structure and behavior of the system within a given context, and from a specific point of view. A model is often represented by the combination of drawings and text, typically using a formal notation such as UML, augmented with natural language expressions where appropriate. Model driven This term describes an approach to software development whereby models are used as the primary source for documenting, analyzing, designing, constructing, deploying and maintaining a system. Architecture - The architecture of a system is a specification of parts and connectors of the system, together with rules for the interaction among them. Within the context of MDA, these parts, connectors and rules are expressed via a set of interrelated models. Viewpoint - A viewpoint is an abstraction technique for focusing on a particular set of concerns within a system while suppressing all irrelevant details. A viewpoint can be represented via one or more models. MDA viewpoints - MDA specifies three default viewpoints of the system: computation independent, platform independent and platform specific: The computation independent viewpoint focuses on the context and requirements of the system without consideration for its structure or processing. The platform independent viewpoint focuses on the operational capabilities of the system, outside the context of a specific platform, by showing only those parts of the complete specification that can be abstracted out of that platform. The platform specific viewpoint augments a platform independent viewpoint with details relating to the use of a specific platform. Platform - A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and usage patterns. Clients of a platform make use of it without concern for its implementation details. Examples of platforms include operating systems, programming languages, databases, user interfaces, middleware solutions etc. Platform independence - Platform independence is a quality that a model may exhibit when it is expressed independently of the features of another platform. Independence is a relative indicator in terms of measuring the degree of abstraction, which separates one platform from another (i.e. where one platform is either more or less abstract compared to the other). Platform Model - A platform model describes a set of technical concepts representing its constituent elements and the services it provides. It also specifies constraints on the use of these elements and services by other parts of the system. Model Transformation - Model transformation is the process of converting one model to another within the same system. The transformation combines the

platform independent model with additional information to produce a platform specific model. Implementation - An implementation is a specification that provides all the information required to construct a system and to put it into operation. It must provide all of the information needed to create an object, and to allow the object to participate in providing an appropriate set of services as part of the system. 3.1.3. MDA Models Corresponding to the three MDA viewpoints defined above, MDA specifies three default models of the system. These models can perhaps be described more precisely as layers of abstraction, because a set of models can be constructed within any of these three layers, each one corresponding to some viewpoint of the system. Computation Independent Model CIM) is a model of the system from the computation independent viewpoint. CIM is also often referred to as a business or domain model because it uses a vocabulary that is familiar to the subject matter experts (SMEs). It presents exactly what the system is expected to do, but hides all information technology related specifications to remain independent of how that system will be (or currently is) implemented. CIM plays an important role in bridging the gap between domain experts, users and designers. Platform Independent Model (PIM) is a model of the system from the platform independent viewpoint. A PIM should exhibit a sufficient degree of independence to enable its mapping to one or more platforms. This is commonly achieved by defining a set of services in a way that abstracts out technical details. Platform Specific Model (PSM) is a model of a system from the platform dependent viewpoint. A PSM combines the specifications in the PIM with the details required to stipulate how a system uses a particular type of platform. If the PSM does not include all of the details necessary to produce an implementation of that platform, it is considered abstract (meaning that it relies on other explicit or implicit models which do contain the necessary details). 3.1.4. Model Transformations Form a key part of MDA. The real value of MDA lies in the fact that the CIM can be translated to a PIM by a simple mapping. Likewise, the PIM can be translated to a PSM (by a mapping), and the PSM can be translated to code. The key elements are the mappings and the MDA tool or tools that do the translation [8]. Figure 1. shows how the different models are connected to each other. CIM is in the upper part of the image where everything starts. CIM is translated to PIM and the architect or designer creates the rest of the model. Finally, PIM is translated to one or more PSMs. Before the translation, the models need to be marked for the translation tool. Figure 1. MDA models are connected using model mappings According to [9], there are two different interpretations of how the MDA vision might be achieved. These two schools are called the elaborationist and the translationist. In the elaborationist approach once the PIM is created, the tool generates a skeleton of PSM. The developer then elaborates it by adding further detail. Similarly, the tool generates the final code from PSM, and this should also be further elaborated. In the translationist approach, PIM is translated directly into the final code of the system by code generation. 3.2. Software Factories (SF) Software Factory (SF) combines the MDD approach with the idea of industrial software development. SF is a software product line that configures extensible tools (like Microsoft Visual Studio Team System - VSTS), processes, and content by using a software factory template based on a software factory schema, to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework based components [5]. A key characteristic of a software factory is that architects and developers can customize, extend, and adjust it to address the unique needs of a project team or an organization. A software factory comprises three central elements: - software factory schema - software factory template - extensible development environment. Software factory schema enables categorizing and summarizing of development artifacts. According to [6], we can imagine the software factory schema as a recipe. It lists ingredients, like projects, source code directories, SQL files and configuration files, and explains how they should be combined to create the product. It specifies which DSLs should be used and describes how models based on these DSLs can be transformed into code and other artifacts, or into other models. It describes the product line architecture, and key relationships between components and

frameworks of which it is comprised. So, the software factory schema describes the artifacts that must be developed to produce a software product. Software factory template in a software factory schema describes necessary but still missing assets at the project. We must implement the software factory schema, defining the DSL's, patterns, frameworks, samples, scripts and so on, and make them available to software developers. According to [6] software factory template is like a bag of groceries containing the ingredients listed in the recipe. Extensible development environment, also called Integrated Development Environment (IDE), defines the place where the assets of software factory template can be loaded. According to [6], IDE is like the kitchen where the meal is cooked. When configured with the software factory template, IDE becomes a software factory for the family of products. This analogy can go further, the products are like meals served by a restaurant. Software factory stakeholders are like customers who order meals from the menu. A product specification is like a specific meal order. The product developers are like cooks who prepare the meals described by the orders, and who may modify meal definitions, or prepare meals outside the menu. The product line developers are like chefs who decide what will appear on the menu, and what ingredients, processes, and kitchen equipment will be used to prepare them. Software factory are based on the convergence of key ideas in systematic reuse, development by assembly, model driven development and process frameworks. Many of those ideas are not new. What is new is their synthesis into integrated and increasingly automated approach [5]. Software factory represents an attempt to learn from other industries facing similar problems, and apply patterns of automation to existing manual development tasks [6]. The author's opinion is that the SF vision will be realized over the next few years in the form of software development environments. 4. Critical Overview of MDD MDD is not the first attempt to solve the problems which arise during the software development cycle. It is well known that during the 1980s Computer Aided Software Engineering (CASE) was promised panacea for solving world's software development problems [7]. Traditional CASE tools based on the structural methodologies failed [5]. So, the logical questions are: What is different now? Is the model-driven development likely to gain widespread adoption as a future way of developing software? Will it make building software faster, better, and cheaper? Or, will MDD have the same ignoble end like CASE? Danner [10] says that this might be déjà vu all over again. He claims that the models are too difficult to create and maintain and resulting code requires extensive modifications to work properly. Or maybe it is just that the culture isn't ready for the paradigm shift. Other open issues are: Will this new technology require special skills that still don't exist in the SW industry? Will developers treat models as a new kind of development language, or the model-driven development will be limited to some closed community of willing and able to master it? Will these models be first-class artifacts throughout the entire life-cycle of an application, or the fancy code generators all will be abandoned as soon as the developers start tweaking the code directly? Some authors [7] believe that MDD has a chance to succeed in today's software industry, but still it is far from a sure bet. They base their opinion on the fact that the use of UML-based tools is growing, many standards are defined and technology has involve since CASE era. Greenfield [10], one of the authors of SF, thinks that the pragmatism is the primary factor that will determine the success or failure of model-driven development in the industry. There is a strong contrast in terms of pragmatism between the two leading approaches, SF and MDA. With MDA, you have two levels of model, the platform-independent model (PIM) and the platform-specific model (PSM) They are based on UML, which is a general-purpose modeling language, and they are related by transformation, since PSMs are generated from PIMs. With SF, by contrast, you have an arbitrary number of viewpoints such as user interaction, business work-flow, or logical database design etc. In fact, you can define as many viewpoints as necessary to describe the business requirements in the software under development. Each viewpoint is potentially based on a DSL but is tailor-made to address a set of unique concerns for that viewpoint. What is, from his perspective different as compared with the CASE tools era? He thinks it is precisely the pragmatic bottom-up approach which is taken with SF. Unlike MDA, which optimistically assumes like CASE did that most or all of the software can be generated from models, SF blend modeling with other software development practices to meet the needs of developers in the real world [10]. Kelly [10], a modeling tool developer, says that CASE tools failed because they tried to impose three things on the users, a way of working, a way of modeling, and a way of coding. He claims that perhaps the worst of all the problems is the gap between the generated and the handwritten code. Because the vendors should make one tool work for as many people as possible, the generated code can't be tuned to the specific needs of all users. To generate full production code from models, you need both the modeling language and the code generator to be domain specific. The big question then is what's the cost of building your own modeling language, modeling tools to support it and your own code generator? For a long time that cost was measurable

in tens of man years, way to high to make domainspecific modeling practicable for all but the largest projects. However, now there are tools that make building such support much faster. Selic [10] doesn't believe that CASE actually failed. He thinks that CASE tools were simply an early step in the right direction towards more automation and higher levels of development. So he is quite an optimist when it comes to the future of model driven development. He says that something is standing in the way and perhaps the biggest impediment is cultural change that is prerequisite of the shift of paradigm. Almost all of the vendors admitted the MDD's goals of seamless interoperability of model transformations haven't been fully realized [11]. This is partly due to standards that leave specific implementation details up to commercial vendors who must release their products into market to fund product development as the standards evolve. As the standards are put into real-world practice, additional needs and limitations are identified, and extensions or whole new categories are added to the standards family to address those concerns. Even as these standards continue to evolve, the consolidation and disappearance of some offerings have prompted cynical software industry pundits to conclude that MDD is CASE 2.0 [11]. 5. Conclusion The modest intent of MDD is to improve software quality, reduce complexity, and improve reuse by enabling developers to work at reasonably higher levels of abstraction and to ignore unnecessary details. In practice, however, MDD raises a number of significant issues which have been discussed in the article. MDD is still evolving so it is too early to talk about failure or success of MDD. Significant ideas for improvements are present, some of them are realized and some are currently immature and need to be solved in the near future. So it is too early to answer the question: is MDD failure or future of software development? [5] Greenfield, J., Short, K., Cook, S., Kent, S.: Software Factories - Assembling Application with Patterns, Models, Frameworks and Tools, Wiley Publishing, 2004. [6] Greenfield, J., Short, K.: Moving to Software Factories, 2004., http://blogs.msdn.com/askburton/archive/2004/09 /20/232065.aspx, (25.05.2007.) [7] Hailpern, B., Tarr, P.: Model-driven development: The good, the bad, and the ugly, IBM System Yournal, Vol 45, No 3. 2006., p. 451-461., http://www.research.ibm.com/journal/ sj/453/hailpern.html, (05.01.2007.) [8] Kontio, M.: Architectural manifesto: MDA for the entrprise, 2005., <http://www- 128.ibm.com/developerworks/library/wiarch16/>, (05.01.2007.) [9] M.: Mc Neile: The Vision with the Hole?, Metamaxim, 2003., http://www.metamaxim. com/download/documents/mdav1.pdf, (03.10.2006.) [10] Pierson, H.: ARCast #5, 2007. http://channel9. msdn.com/ Showpost.aspx?postid=132943, (09.02.2007.) [11] Riley, M.: A Special Guide-MDA and UML Tools: CASE 2.0 or the Developer's Dream, 2006., http://www.ddj.com/dept/ architect/184415500, (03.05.2007.) [12] Swithinbank, P., Chessell, M., Gardner, T., Griffin, C., Man, J., Wylie, H., Yusuf, L.: Patterns: Model-Driven Development Using IBM Rational Software Architect, IBM Redbooks, 2005. [13] Yusuf, L., Chessel, M., Gardner,T.: Implement model-driven development to increase the business value of your IT system, http://www- 128.ibm.com/developerworks/library/ar-mdd1/, (14.04.2006.) 6. References [1] *** MDA Guide Verison 1.0.1, OMG, 2003. [2] Brown, A. W., Iyengar, S., Johnston, S.: A Rational approach to model-driven development, IBM System Yournal, Vol 45, No 3. 2006., p. 463-480., http://www.research.ibm.com/journal /sj/453/brown.html, (05.01.2007.) [3] Brown, A: An introduction to Model Driven Architecture Part I, 2004., http://www- 128.ibm.com/developerworks/rational/library/310 0.html (05.12.2005.) [4] Fowler, M.: UML As Programming Language, http://martinfowler.com/bliki/umlasprogrammin glanguage.html, (25.02.2007.)