1. Goals
Model Driven Architecture (MDA) is a term that has several different meanings. When referring to MDA, it means the initial stage of standardization of OMG involving MDSD. Because MDA does not cover the entire field of MDSD, it can also be considered a special style of MDSD.
MDA was the initial standard established by OMG. Traditionally, OMG has been a platform for middleware and tool manufacturers, serving the synchronization and standardization of their fields of activity. CORBA (Common Object Request Broker Architecture) and IDL, UML, MOF, and XMI are popular results of this process. MDA is OMG's new flagship.
According to the OMG, the two fundamental motivations for MDA are software platform interoperability and portability -- the same motivations that developed CORBA. Furthermore, the OMG assumes that a system's functional specification should be independent of its functionality's implementation on any given platform. In this view, MDA strives towards the goal of providing guiding principles and standards that lead to the respective construction of specifications in the form of models.
2. Core concepts
The core component of MDA. These components are UML2.0, MOF (Meta Object Facility, meta object facility), XMI (XML Metadata Interchange, metadata exchange), three types of models (PIM/PSM/PDM), multi-stage transformation, Action Language ( Activation Language), various core models, model notation, and executable UML.
1.UML2.0
From an MDA point of view, UML is central because many tools are based on UML and profiles. To make sure this will actually work, the OMG has recently made some improvements to the UML 2.0 environment.
2. MOF--Meta Object Facility
The Meta Object Facility (MOF) forms the core of MDA. It describes the meta-metamodel on which MDA-compliant tools should be based—or should be based on. Definitions of custom DSLs or metamodels should use the mechanisms of MOF, or extend UML via configuration files, which effectively constitute lightweight metamodel extensions. UML is defined by MOF. MOF itself uses a concrete syntax of UML, which can be confusing. Implicitly use the mechanism of MOF. When extending the UML metamodel, MOF is automatically used.
MOF is important not only as a formal basis for meta-models, but also as a concrete relevance for the structure of MDA tools, including repositories, modeling tools, code generators, etc. Tools in general need a solid foundation: this can be just the meta-metamodel.
3.XMI
XMI stands for XML Metadata Interchange, and is the XML shade of MOF - not just UML's DTD/schema, since it's often not declared correctly. Currently, XMI is the basis for interoperability between different MDA tools, as MOF repositories are not yet widely used.
4.PIM/PSM/PDM
OMG has a concrete concept of what MDA should represent.
From PIM it is possible to create platform-specific models (PSMs) via the model transformation program. As the name suggests, PSM is platform-specific for J2EE, .NET or other implementation platforms.
This discussion emphasizes that both PIM and PSM are relative concepts. PSM may be J2EE specific, but still has nothing to do with a specific application server. Therefore, it forms a PIM on a specific application server platform.
There is a more important model type in MDA, Platform Description Model (PDM). This is the metamodel of the target platform.
5. Multiple Stages of Transformation
In most cases the source code for some platform is generated directly from the (PIM) model. This is done mainly for practical reasons: no model transformation tool exists yet that supports the transformation of multiple stages of large systems in a manner suitable for everyday use.
6. Action language
It is currently not possible to design a model of a complete software system through UML. This situation does exist. As long as the domain is adequately constrained, its concept thoroughly standardized, and a suitable DSL defined, the Mexico of the domain can be designed to a large extent, of course, many aspects will remain unresolved or infeasible, and in particular, remain unspecified Methods of Algorithmic Behavior.
Action semantics includes the following elements:
- variable
- Usual arithmetic and logical operations
- Typical properties of sequential programming languages
- instance creation, instance destruction
- Class scopes that can be hinted using SQL-like queries
- Signal generation, including parameters
- Definitions of functions with input and output parameters, and the methods that call them
- timer
7. Core Model
In order to be able to benefit as much as possible from MDA, as many aspects as possible must be standardized. This includes platforms -- already done, at least on a technical level -- through J2EE, .NET, CORBA or Web services -- and transformation languages, which are generated within the QVT environment. In order to allow users to design models of platform-independent application logic, it is also necessary to standardize domain-specific metamodels. Thus, not only can the transformation language be standardized, but also reusable transformation rules can be captured in a transformation library. Developers design application models through standardized UML configuration files or meta-models of their respective domains, and commercial or open-source capture modules generate platform-specific code through this model.
In the context of MDA, OMG refers to these standardized meta-models as core models.
8. Control PIM to PSM conversion
In some cases, the transformation engine cannot transform the model because the information in the source model is not particularly sufficient. For example, the target metamodel may provide different ways of identifying source metamodel constructs.
1). Model ID
MDA proposes the concept of model identification. A model ID is extra information in the transformed source model that is used to control the transformation. These annotations generally depend on the target metamodel.
2). Decision criteria in PIM
If you are ready to accept other results, there is another option that works with little to no identity, a mechanism that requires extending the metamodel in such a way that enough information exists in the model that the generator can choose between different Choose between methods.
In J2EE, the decision about which implementation alternative should be used in each case can now be delegated to the J2EE transformation. Of course, the metamodel must be extended, and this is not always possible. Then, instead of extending the metamodel with the concepts of the target metamodel, it uses general information that can be used by the transformation program, which constitutes the enrichment of the source metamodel, rather than "polluting" it with constructs specific to the target metamodel.
9. Executable UML
The term "executable UML" is often seen in the context of MDA. This is not a formal standard, but a so-called "term" that is documented to have come together as a result of all efforts to establish UML as a fully fledged programming language. Therefore, UML must be cleaned of all redundancies and ambiguities, resulting in executable UML diagrams: the smaller the metamodel of the modeling language, the easier it is to implement a compiler or interpreter for it. Regarding executable UML, another necessity The component is the action language, which must be used to define a complete implementation of a software system.