Any model-driven solution should avoid new, specialized tools. In the ideal case, the model can be constructed visually or in a way that makes it look like other development code. This makes it comparatively simple to deal with more complex challenges such as the merging of model changes. It also makes it easier to move models between tools without needing to rely on approaches like XMI.
Allowing models to be tool-agnostic is another way to reduce the learning curve and costs required for MDE adoption.
The AXIOM Approach
Both agile and model-driven development approaches offer considerable benefits in im-proving the productivity of software development processes and/or the quality of soft-ware products. However, each also has its own limitations. It would be beneficial to integrate the two approaches so that they complement each other and offer the best of both approaches. The challenges lie in a number of apparent incompatibilities and gaps between the two approaches:
• The style of languages. Agile software development embraces dynamic and scripting languages with little emphasis on static typing and analysis, while model-driven development is based on modeling notations that are visual, declarative, and amenable to a variety of techniques for ensuring qualities, such as static anal-ysis and design by contract.
• The role of software architecture. Model-driven development is often charac-terized as architecture-centric and design-first, while agile software development is often code-centric with architecture as an emergent property resulting from iterative refactoring.
• The trade-off between productivity and extra-functional qualities. Agile soft-ware development generally emphasizes developer productivity over extra-functional qualities, while model-driven development prioritizes the extra-functional quali-ties and counts on the modeling aspects of MDD to achieve gains in developer
35
productivity. Agile development focuses on quality needs in the short term, whereas model-driven development attempts to address long term quality needs up front.
Despite these differences, there are also critical similarities between agile and MDD practices:
• The focus on a single deliverable. Agile practices tend to focus on working ap-plication code as their single deliverable, since that is what is ultimately required.
MDD, too, focuses on a single deliverable: the model.
• End-user involvement. In agile practices such as XP, the user is an indispens-able part of the software development process. They provide key insights into business functionality as well as held define the most appropriate interaction with the software. It is no different for MDD projects since the models must capture the business rules and UI design.
The ultimate goal of AXIOM is to emphasize the similarities while de-emphasizing the differences between these two approaches.
4.1 An Outline of the Approach
Our approach is called AXIOM (Agile eXecutable and Incremental Object-oriented Modeling). The AXIOM approach aims to combine MDD techniques with agile ap-proaches to provide true agile MDE. AXIOM consists of the following key technical areas:
• A dynamic language based modeling notation. One of the novel aspects of the AXIOM approach is to use a dynamic language, Groovy [72], as the basis of the modeling notation. The Groovy language is augmented with a state ma-chine mechanism based on the UML state diagram. The state mama-chine is defined as a domain specific language (DSL) in Groovy. The specifics of the modeling notation is further elaborated in chapter6.
• Model transformation. One of the trade-offs for using dynamic languages is the substantial degradation of performance of the resulting applications as compared to those developed using statically type languages. We will develop frameworks and techniques to transform the PIMs to PSMs with the goal of minimizing the performance degradation of dynamic languages and attaining the same level of performance and qualities as applications developed using the native tools and languages of the target platforms. The model transformation mechanism is further elaborated in chapter5.
While we do not intend for AXIOM to directly support one particular style of agile development, such as XP or Scrum, we do intend that it complement the overarching principles of agile methodologies such as those espoused in the Agile Manifesto [64].
In particular, we believe that AXIOM supports agile methodologies in the following key areas:
• Working software is the primary measure of success. By allowing developers to focus on a model of the software rather than its implementation details, AXIOM employs MDA transformations to realize the final application.
• Agile processes promote constant, sustainable development. By encouraging de-velopers to work on models, rather than on application code, we believe that AXIOM allows development teams to more rapidly produce working software at regular intervals. While we will see that AXIOM’s DSML allows for less code to be written, and our analysis of AXIOM’s impact on productivity supports this assertion, further work is necessary to truly gauge AXIOM’s impact on agile de-velopment teams.
• Changing requirements are embraced, even late in development. Because the models are at a higher level of abstraction than the equivalent application code, we believe that AXIOM provides development teams more opportunities to spot and address risky changes, thus making it easier to incorporate those changes. In-tuitively this is because we expect the AXIOM models to be significantly smaller than the required native code, thus making the evaluation of a change to be an
intellectually simpler task. From an empirical perspective, this assertion deserves more investigation and is not explored further in this research.
Similarly, while AXIOM does not directly support a particular MDD methodology, it does support the key tenets of MDD, which is that we should raise the level of ab-straction and make models, rather than code, the focus of software development. By incorporating both a dynamically typed language, we believe that AXIOM raises the level of abstraction while still supporting lower degrees of abstraction when needed.
Because AXIOM is model-centric, it retains the key properties of MDD such as the use of platform-independent models and the generation of appropriate platform-specific models by way of targeted model transformations.
Although we expect AXIOM to be applicable across many different application do-mains, this research focuses exclusively on mobile applications. Such applications pro-vide fertile ground for experimentation because they allow us to immediately test the cross-platform capabilities of AXIOM. Such applications have not yet become as com-plex as many enterprise applications, which also allows us to scale up AXIOM’s ability to deal with more and more complex applications while still reaping benefits during the development of comparatively simpler applications.