According to abbreviationfinder, MDA stands for Model Driven Architecture. MDA architecture. Product best practices in software engineering the Surge architecture directed by models (MDA – Model Driven Architecture).
What is MDA?
MDA is a concept promoted (but not created) by OMG, which proposes to base software development on specified models using UML, so that, from these models, transformations are carried out that generate code or another model, with characteristics of a particular technology (or with a lower level of abstraction). MDA defines a framework for processing and relating models. It is often heard that MDA is the natural evolution of UML, as it tends to increase the amount of code generated, from detailed specifications in UML.
What is not MDA?
Today MDA is one of many fashionable acronyms and, as is sometimes the case with fashions, the concept can tend to be misinterpreted. Therefore, it should be known that:
- MDA is not a development process.
- MDA is not a specification.
- MDA is not an implementation.
- MDA is not a reference implementation of any particular standard.
- MDA is not a mature concept yet.
- MDA is not simply generating code.
- MDA does not yet have a unified vision in the industry.
MDA Models
Models play a vital role in MDA. As a framework for building systems, MDA abstracts the system to be built into different layers of abstraction. Traditionally, the OOAD (Object Oriented Analysis and Design) contains, among others, an analysis view, a detailed design view and code – representing the business view of a system -, the architecture view and the implementation view. MDA adds one more abstraction layer, which represents the business context of the system.
Concrete models outnumber abstract models. As we go through the transformations, the models become more concrete, transforming the abstract model into one that is compatible with a technology or platform. The reverse situation of moving the code towards a concrete model – also known as reverse engineering – rarely occurs, except when the starting point is the code itself. This occurs because MDA promotes the strong separation between business requirements responsibilities and technology responsibilities. The advantage of this “separation of responsibilities” is that both aspects can evolve individually without generating dependencies on each other. In this way, the business logic will respond to the needs of the business and will not depend on technical vicissitudes.
CIM (Computational-Independent Model)
CIM owes its name to this focus on business over technology, which in Spanish translates as: “Independent Model of Computing”. The CIM focuses on requirements and represents the highest level of the business model. Use a non- UML language to model business processes, although this language can be derived perfectly using MOF (meta-object facility). The CIM transcends systems; each business process interacts with human workers and / or machine components. The CIM describes only those interactions that take place between the processes and the responsibilities of each worker, human or not. A fundamental objective of the CIM is that anyone who can understand the business and its processes can understand it, since it avoids all kinds of specialized knowledge or systems.
PIM (Platform-Independent Model)
The PIM, which is translated into Spanish as “Platform Independent Model”, represents the business process model to be implemented. UML or a derivative of UML is commonly used to describe PIM. The PIM models the processes and structures of the system, without making any reference to the platform on which the application will be deployed. In turn, it ignores operating systems, programming languages, hardware, and network topology. It is often the entry point for all MDA tools and even many articles that discuss MDA, leaving out the CIM.
PSM (Platform-Specific Model)
The PSM, which is translated into Spanish as “Platform Specific Model”, represents the projection of PIMs on a specific platform. A PIM can generate multiple PSMs, each for a different technology. Generally, PSMs must collaborate with each other for a complete and consistent solution. Normally, this is done in UML, creating different profiles that define a PSM for each required technology. PSMs have to explicitly deal with operating systems, programming languages, platforms (CORBA, .Net, J2EE, ETC), etc.
Code Model
The code model represents deployable code, usually in a high-level programming language, such as Java, C #, C ++, VB, JSP, etc. Ideally, the code model is ready to compile and should not require human intervention; application deployment could be automated. According to purists and some MDA fans, in a mature MDA environment, code should not be thought of as anything more than simple files, or as a mere intermediate object to generate the final executable. But because MDA is not mature, and the utopia of not having to touch any code is hardly ever reached, developers will continue to need to know the technology to complement code generation, debug the application and, above all, deal with many and varied unexpected, strange and funny mistakes.
Design decisions
MDA promotes the transformation of models that represent complex business logic (CIM), up to the executable and deployable code (Code Model). But what about design decisions, those decisions that are made when, for example, you have to develop a system where most transactions only read data, but ten of them are processor intensive? What if all the mappings were done the same way? You might think that this would degrade the final perceived quality of the application. To correct this problem, MDA promotes the use of marks (Marks), which indicate specific aspects to take into account in each transformation. A PIM generated from a PIM and Marks is called Marked PIM or Marked PIM. The use of trademarks establishes that decisions regarding technological aspects remain outside the main models. Now, to carry out the mapping between a marked PIM and, for example, a PSM, it is necessary to detail how those marks are mapped; that’s what the Mappers (mappers) are defined for. You can see the relationship between mappers, marks, and PSMs in the figure above. The mappings are done using a QVT: Query, Views, and Transformations.
Advantages of MDA
The main advantage of MDA lies in the clear and strict separation of responsibilities. On the one hand, modeling the PIMs, which represent business models, and on the other hand, the PSMs with technological concerns. This will allow both models to evolve separately. In this way, if you want, for example, to modify a technical aspect, it will be enough to modify the PSM without these having an impact on the business logic. This idea comes from a concept that, in Software Engineering, is called “Design Guides”. One of those guides in particular says that solution modeling should be business driven. This guide is based on the statement that a change in the business is likely to produce a change in the code, but not the reverse: changes in the code should not impact the business. MDA also allows: dealing with the complexity of the business, modeling it separately and allowing its analysis and improvement; reduce costs, if we have an MDA tool suitable for our needs; improve the quality of our models and processes, through their analysis and the separation of responsibilities.
Standards involved in MDA
The most important technologies involved, in order to put the underlying concepts in MDA into practice, are:
- Meta Object Facility (MOF).
- Unified Modeling Language (UML).
- XML Model Interchange (XMI).
- Common Warehouse Meta-model (CWM).
- Software Process Engineering Meta-model (SPEM).
- Action Semantics Language (ASL).
- Query-View-Transformation (QVT).
- UML profiles.
MDA tools
MDA tools should provide the ability to transform pure business models (CIMs) into complete, deployable applications capable of executing with a minimum of technical decisions. Unfortunately, we are very far from MDA or any MDA tool providing all these facilities for any business and problem to develop. There is also no leader in MDA tools, because they are so sophisticated. Some of the best known tools are:
- ATL ATLAS Transformation Language
- OptimalJ is a MDA tool for J2EE.
- ArcStyler is a MDA tool for J2EE and.NET.
- UMT UML Model Transformation
- ArgoUML
- Codagen
- Rational Architect
- MDA Transf
- Enterprise Architect
- GReAT
- AndroMDA
Importance of MDA for the developer
Today, MDA is important to the average developer. Who are blessed with the ability to use creativity to transform zeros and ones into useful applications for our clients. In the last two years, many organizations have started to pay attention to MDA as it promotes the efficient use of system models in the software development process. MDA represents a new way for developers to organize and manage business architectures, based on the use of automation tools for stages in the development and services cycle. In this way, it allows defining the models and facilitating gradual transformations between different models. In other words, from a model, another one of less abstraction can be generated.
A common example of model generation is the generation of code from the design model, using a UML modeling tool. In this case, a tool is used to transform the design model into the code “model”.