3.4 Development Processes

The MDA does not require a specific process to be used for software development. Processes are not standardized by the OMG, so you are free to choose your own. Of course, the central position of models and transformations in MDA should be reflected in such a process. We will take a short look at some of the more popular processes and show how they can be used for MDA development.

3.4.1 Agile Software Development

A current trend in the software development process is to minimize the amount of effort and time spent in building models that will only serve as documentation, even though they do capture some of the interesting aspects of the software to be built. The purpose is to ensure that software is delivered that works for the users. Since requirements continuously change, the software that is being developed must change accordingly . The ability for a software project to accommodate changes in a flexible and immediate way is the core aspect of Agile Software Development. According to Cockburn (2002), "Working software is valued over comprehensive documentation." Well, we couldn't agree more. At the Web site http://agilemanifesto.org you can find the Agile Manifesto describing the agile principles. On this website you may post a quote why you like this approach. The quote from one of the authors of this book is:

As co-author of the UML standard, people usually think I love large and detailed models. The contrary is true, a model is only worth building if it directly helps to achieve the final goal: building a working system. With the emergence of MDA tools, it becomes possible to directly move from model to code. This "promotes" models from being merely documentation to becoming part of the delivered software, just like the source code.

Because changing a model means changing the software, the MDA approach helps support agile software development.

3.4.2 Extreme Programming

The XP approach is a very popular way of working, where the focus lies on writing code in small increments , such that you have a working system all the time. Each new requirement must be accompanied by an explicit test case, which is used to test the software. When adding new functionality, all previous tests are run in addition to the new tests, to ensure that existing functionality is not broken.

As we explained in section 1.1.1, the focus on code only is too limited. Code must be augmented with so-called "markers" that document the code at a higher level. In extreme programming this is often seen as overhead. When we realize that these markers may take the form of MDA models that directly transform into code, creating these markers is not overhead anymore. On the contrary, the high-level models help to develop the software faster.

This means that we can bring XP to a higher abstraction level, and we might want to talk about "Extreme Modeling."

3.4.3 Rational Unified Process (RUP)

The RUP is a process that is much more elaborate, or much heavier, than the agile or extreme processes. Project managers often like these larger and more structured processes because they give a better feeling of control over the project. Especially for large projects, it is clear that a more elaborate process than extreme programming is needed. On the other hand, many people consider the RUP process as being too large and unwieldy, favoring bureaucratic development of large stacks of paper over "real" software development, i.e., writing code.

UML plays an important role within RUP. Many of the artifacts in RUP take the form of some UML model. If we are able to use these models in an MDA fashion, they can be used to generate PSMs and code. When we configure RUP for an MDA project, we need to make sure that the models that we produce fulfill the requirements that MDA puts on them.

When we do this, the models used in RUP are no longer bureaucratic overhead; they become "real" software development. The balance between writing paper documents and developing code moves more into the direction of developing code. At the same time, the artifacts that are produced will satisfy project managers in their quest for keeping control.



MDA Explained. The Model Driven Architecture(c) Practice and Promise 2003
Project Leadership (The Project Management Essential Library)
ISBN: N/A
EAN: 2147483647
Year: 2004
Pages: 118

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net