Model-driven architecture

from Wikipedia, the free encyclopedia

Model -driven architecture ( MDA ; model-driven architecture ) describes a model-driven software development approach based on a clear separation of functionality and technology.

Differentiation from CASE and MDSD

MDSD ( model-driven software development ) refers to the use of models and generators to improve software development. Even in the early days of computer science, models were used and generators were developed to generate schematic source code from them. MDSD is occasionally confused with the CASE approaches of the 1990s. However, MDSD and CASE differ in their basic goals.

The aim of the CASE approaches was and is to create software as fully automated as possible from technical descriptions. Since the automation also extends to the area of ​​software architecture, the CASE approaches proved to be very inflexible. This fact, in conjunction with the proprietary nature of the tools available, meant that CASE was unable to establish itself.

One possible way to implement the MDSD is the MDA described in the article.

MDA does not require a hundred percent automation, but a meaningful part. This varies between 20 and 80 percent depending on the technical requirements. Since the architecture of a system is created entirely manually, MDA is extremely flexible and, in contrast to the CASE approach, grants complete control during the development process.

aims

Increase in development speed

One goal of the MDA is to increase the speed of development. The means to achieve this is called “automation through formalization”.

Generators should automatically generate code from formally unambiguous models , the so-called Generat. This should also increase the software quality. Errors in the generator can be eliminated at one point - in the generator templates. The quality of the generated source code is constant, which should lead to a higher degree of reuse. See also generative programming .

Better manageability due to higher abstraction

Another important goal is the better manageability of complexity through abstraction. With the modeling languages, programming on a more abstract level should become possible, the clear separation of functional and technical parts aims at better maintainability by separating responsibilities. The more abstract, technology-independent description of key concepts with clear modeling languages ​​promises improved manageability of the technological change. And last but not least, improved interoperability should be achieved through standardization.

Action

The MDA idea is based on the assumption that a single model for the construction of a software system is too fuzzy and overloaded to map a larger, more complex application. In most of the "classic" ( UML ) models, business-relevant information is mixed with technical information; MDA divides the overall model into several layers:

  • Computation Independent Model (CIM) for the colloquial description
  • Platform Independent Model (PIM), platform-independent model for business processes
  • Platform Specific Model (PSM), platform-dependent model for architecture, services
  • a code model, the target platform

The separation of the models ( separation of concerns ) represents an extension of the content of the UML standard. In particular through the CIM and above all the PIM one would like to achieve not only platform independence, but also language and system independence.

In addition to the content-related separation of the models, MDA also defines the transformation of the models and distinguishes between two types:

  • The model transformation from one model to another model (see also MOF QVT )
  • The code transformation from a model to code.

The transformations generate the elements of the target model from the elements of the source model. The transformation usually takes place from the more abstract level to the more concrete level (CIM-PIM-PSM code). As a result, a more complex application can be created from simpler model elements by having experienced architects program their construction rules into such transformation processes.

MDA is a strategy of the Object Management Group (OMG). OMG creates manufacturer-neutral specifications to improve the interoperability and portability of software systems.

Advantages and disadvantages

One of the main advantages of MDA is to encourage system designers and software developers to more carefully conceptualize the programs to be created in the design phase, which is of great importance in the case of very complex software, especially in the creation of standard software .

The disadvantage is the very high level of abstraction that is required of the software developer. For smaller or less complex applications, e.g. B. in database applications as an individual solution to support typical administrative processes, the effort of an abstract definition of all objects and processes is often felt to be inappropriately high. With some alternative software technologies , the software itself can be created in the same amount of time . The formalized strict separation of the model levels also prevents the increase in productivity through the use of models with mixed specialist and technical content.

Furthermore, an automated transformation of a model often requires a much more formal description than is necessary for the transformation by a human. For example, consider a class Person with the attribute bornAm . A programmer does not need a particularly detailed description to implement the giveAgeInYears function. For an automatic transformation (to source code or to another model), however, an exact specification must be available.

It is advantageous that changes to the application are made in the model. These are transferred to the source code by a new code generation. This prevents the model and code from diverging. In particular, wild hacking , in which changes in the source code are not transferred to the originally underlying model and thus the model becomes faulty and ultimately unusable over time, is avoided. This means that the MDA approach in particular is ideally suited for an iterative-incremental process model and in no way supports or demands a waterfall approach .

When using generic modeling languages ​​such as UML, it must also be clearly defined by which elements and with which means of the modeling language technical facts are to be described so that a valid model is created in the sense of the following transformations. This mapping often introduces more new complexity than is hidden by the abstraction. The use of domain-specific languages can bring significant advantages here.

Overview of MDA concepts

model

A model is an abstract representation of the structure, function or behavior of a system .

MDA models are usually defined in UML . But classic programming languages are also suitable as modeling languages. Their programs are MDA models. These are in turn independent of the underlying platform ( bytecode , machine code and API ).

Not every collection of UML diagrams represents a model in the MDA sense. The most important difference between general UML diagrams (e.g. analysis models) and MDA models is that the meaning of MDA models is formally defined . This is ensured through the use of a formally unique modeling language that is specified in a UML profile (see below). A generator must have enough information to be able to map or transform the MDA model to another model or to source code.

platform

MDA does not (initially) say anything about the level of abstraction of platforms. Platforms can build on one another.

For example, Intel PC is a platform for Linux . CORBA , J2EE or web services are possible platforms for an eBusiness system, and C ++ is a possible platform for CORBA. A well-defined application architecture with an associated runtime system can also be a platform for applications.

UML profiles

A UML profile is the extension of the standard UML language scope to create a more specific design language using the extension mechanisms provided in UML (stereotypes, tagged values, constraints, custom icons). The meta-types specified in the UML metamodel are further specialized by using the extension mechanisms.

The more specific design languages ​​defined in UML profiles are required in particular to be able to map domain or platform-specific semantics.

While the introduction of new concepts is relatively well supported by profiles, existing concepts are difficult to hide with this mechanism, which can easily lead to misunderstandings, especially when modeling with standard UML tools.

See also

literature

  • David S. Frankel: Model Driven Architecture. Applying MDA to Enterprise Computing . John Wiley & Sons, 2003, ISBN 978-0-471-31920-7 .
  • Jim Arlow, Ila Neustadt: Enterprise Patterns and MDA. Building Better Software with Archetype Patterns and UML . Addison-Wesley Publishing Company, 2004, ISBN 978-0-321-11230-9 .
  • Stephen J. Mellor, Kendall Scott, Axel Uhl: MDA Distilled: principles of model-driven architecture . Addison-Wesley Professional, 2004, ISBN 978-81-297-0529-7 .
  • Anneke Kleppe, Jos Warmer, Wim Bast: MDA Explained. The Model Driven Architecture: Practice and Promise . Addison-Wesley Professional, 2003, ISBN 978-0-321-19442-8 .
  • Klaus Zeppenfeld, Regine Wolters: Generative software development with the Model Driven Architecture . Spectrum Academic Publishing House, 2005, ISBN 978-3-8274-1555-4 .
  • Roland Petrasch, Oliver Meimberg: Model Driven Architecture - A practice-oriented introduction to MDA . dpunkt.verlag, 2006, ISBN 978-3-89864-343-6 . ( Website for the book )
  • Thomas Stahl, Markus Völter, Sven Efftinge: Model-driven software development. Techniques, engineering, management . 2nd Edition. d.punkt Verlag, 2007, ISBN 978-3-89864-448-8 . ( Website for the book )
  • Andreas Andresen: Component-based software development with MDA, UML and XML . 2nd Edition. Hanser reference book, 2004, ISBN 978-3-446-22915-0 .
  • Volker Gruhn, Daniel Pieper, Carsten Röttgers: MDA - Effective software engineering with UML2 and Eclipse . Springer, 2006, ISBN 978-3-540-28744-5 .

Web links

Individual evidence

  1. ↑ uml.org: UML 2.0, The Current Official Version.