H.S. Lahman on OO and MDA

1.0 MDA overview

Blog root page
next post in category

The Model-Driven Architecture (MDA) is an initiative by the Object Management Group (OMG) to standardize infrastructures supporting migration between semantic models that represent different views of the same basic thing. This is especially important in software development where a software solution evolves through several different development stages, such as analysis, design, coding, and testing. In each stage one has a solution that represents some value added to the solution from the previous stage. Typically we can express the solution in each stage as a model. (It is a model of the final software executable because it does not capture every detail of that executable.)

The representation of the model can be fairly arbitrary. Thus the bubbles & arrows of UML and the text of Java both describe a model of the software solution in a well-defined notation. But the fundamental semantics of the solution that is described in both representations will be basically the same -- at least for those elements described in the previous development stage. (Since each stage adds intellectual value, there will be new elements in addition to those from the previous stage.) Because the underlying semantic content is the same but the descriptive notations can be quite different, it is highly desirable to have an unambiguous mapping between stages and their respective representations. Providing that mapping is what MDA is all about.

One core idea of MDA is that every model is a specific instance of some semantic meta model that captures a generic model element semantics. That meta model is much more abstract than any particular software model and it simply describes what model elements mean. Once that meaning is defined, then one can map between meta models without dealing with the details of specific application solutions:

       OOA <--------------> OOD <----------> OOPL
    meta model          meta model        meta model
        |                    |                 |
        |                    |                 |
        V                    V                 V
    application        application        application
    OOA model <-------> OOD model <------> OOP model

Once the meta models are in place and one has a mapping between them, one can apply those mappings to the individual model elements for a specific application. This allows the tools the developer uses to create each application model to communicate. Thus a tool that does OOD modeling can access the repository in a tool that does OOA modeling and transfer the the relevant elements to the OOD view. This has the potential to make the developer's life a whole lot simpler by making configuration management and requirements traceability much simpler (e.g., one can preserve the OOA model while ensuring the OOD model correctly incorporates all of its semantics).

This was the original view of MDA, a standard to enhance interoperability between different tools used during different phases of the software development. However, it has far a far more powerful application as a basis of automation through translation, which I will address in subsequent posts.

Another core idea behind MDA is the notion of transformation. The basic idea is that one can transform one model instance (e.g., an application OOA model) into another model instance (e.g., an application OOD model) provided one has access to some sort of transformation rules:

    [Input Model]               [Transformation Model]
         |                              |
         |                              |
         V                              |
    {Transformation} <------------------+
         |
         |
         V
    [Output Model]

Within MDA there are many variations on this theme, but the basic idea represented above is fundamental to MDA's role in software development. It provides the semantic standards that allow the necessary infrastructures to be built supporting the transformation process. As part of that MDA defines a number of different flavors of models that I will deal with in the next post.

The final core notion of MDA is the profile. A essentially defines a configuration for transformation. For example, in an OOA model one only deals with functional requirements. If one is using UML as the notation, then the MDA profile defines UML as the notation. But it also defines what specific elements of UML may be used in an OOA model. This sort of specification ensures consistency when there are are many different alternatives available, which is typically the case for software development.

Before leaving the MDA profile let me point out some other facets as context material in case anyone asks. The OMG has defined a number of frameworks and standards. It has also defined a hierarchy of met models. The Meta Object Facility (MOF) is top dog in the hierarchy and it is intended to have much broader application than simply software development. MDA is an instantiation of a standard within the MOF umbrella. Similarly, UML is an instantiation of OO model semantics within the MDA umbrella, along with other standards, such as XMI. UML itself has four levels abstraction for its semantics.

Blog root page
next post in category

2.0 CIM, PIM, PSM, TS, & PM

Blog root page
previous post in category
next post in category

Alas, MDA is still evovling and the specifications are still sometimes vague of the definitions of things. The basic breakdown I find useful is:

Computation Independent Model (CIM): a specification model. It is a model because it has a more rigorous semantics than things like natural language specifications. I usually think of it as a white-box specification of requirements. For example, a CIM might break down requirements from a systems engineering viewpoint for individual subsystems. The ATLAS test test specification language (IEEE Std 716) is a good example of a CIM implementation. So I see the CIM as a formal SRS.

Platform Independent Model (PIM): an abstract solution model for functional requirements expressed purely in problem space terms. Because it deals only with functional requirements there is no need for it to incorporate any sort of implementation design decisions. Traditionally this has been an OOA model, at least in the translation methodologies (some OO methodologies don't provide a fully executable solution during OOA).

Platform specific Model (PSM): a solution model that resolves both functional and nonfunctional requirements. Because it deals with nonfunctional requirements it is necessarily dependent upon specific platform technologies and mechanisms (3GL, OS, libraries, interoperability infrastructure, server resources, etc.). Traditionally this as been an OOD model that was elaborated from an OOA model by incorporating platform-dependent decisions. MDA is more flexible and includes OOP models (3GL code) and even object code in an R-T/E environment as PSM variants. (Typically translation skips the OOD equivalent PSM and goes directly to the OOP equivalent PSM.)

Transformation Specification (TS): This is a formal specification of how a transformation from one meta-model to another is mapped. MDA is quite vague at present on what can be in here; apparently anything that will help the transformation will do. However, in elaboration it is usually manifested as an interface description language used to define how two tools (e.g., an OOD modeling tool and an OOPL editor) may interact. In a translation environment it is usually manifested in the form of a rules set for optimization against nonfunctional requirements. I generally think of it in terms of describing a set of rules and policies that control the transformation.

Platform Model (PM): This is esentially a model of the specific computing environment. It characterizes technologies, infrastructures, and paradigms that control implementation for a PSM. Again, MDA is a bit vague about limiting what goes in here. However, I find it useful to think of the PM as a structural model of the computing environment that compliments the more dynamic TS view.

Blog root page
previous post in category
next post in category

4.0 What is translation?

Blog root post
previous post in category

The traditional form of software development where 3GL code is manually produced is known as elaboration. Effectively the developer directly adds intellectual content at each stage of analysis, design, and implementation by elaborating on what the previous stage produced. That elaborative progression was originally enshrined in the Waterfall model. While the Waterfall has been largely supplanted today by incremental/iterative development models, that is mostly a matter of degree. The basic progression from analysis to design to implementation survives, each is built on the previous, and the developer adds intellectual value at every step -- regardless of the size of the steps.

Originally we developed programs directly in hardware (plug boards) or in Assembly language. Then in the early '60s there was a major paradigm shift in the way software was developed as 3GLs were introduced, initially FORTRAN and COBOL. That paradigm shift represented a major increase in the level of automation in the software industry. Essentially all the mundane details of specific hardware instructions, specific memory addressing, and whatnot were completely abstracted away from the developer's view while compilers, linkers, and loaders did all the dirty work. Thus a large block of developer concerns simply disappeared in the implementation stage.

Currently the software industry is on the brink of another paradigm shift as automation of the computing space moves beyond 3GL compilers. Essentially we are moving to the era of 4GLs where one translates a 4GL solution directly into an executable. It is now possible to describe the solution to an arbitrary problem at a level of abstraction that is at least as far above 3GL programs as 3GL programs were above Assembly programs. This has already been done is specialized niches within the software industry. For example, the RAD IDEs employed for CRUD/USER* processing in applications, that are effectively pipelines between an RDB and a UI, represent essentially a 4GL environment where one thinks of the problem solution in terms of schemas and windows.

The enabling technologies for this automation in general purpose computing are UML and MDA. The addition of an action semantic meta model to v1.5 of UML allows action languages to describe dynamics that have the same level of abstraction as an OOA model. That combination represents a true 4GL. MDA introduces a formalization of transformation that is crucial to being able to implement abstract PIMs against a wide variety of implementation technologies. MDA also allows the formal separation of customer space and computing space concerns represented PIM and PSM.

In separating those concerns, the PIM represents a resolution of only functional requirements that is independent of the computing environment where the software is ultimately implemented. The nonfunctional requirements (size, performance, reliability, etc.) are all addressed by the transformation process. That is, the optimization necessary to resolve nonfunctional requirements in a particular computing environment is completely automated. Thus one skips intermediate PSMs corresponding to OOD and goes directly to the 3GL PSM without any direct developer added value. (One could go directly to Assembly or even machine code but 3GL compilers already do an excellent job on instruction level optimization so there is no point in reinventing that wheel.)

When the transformation engine bypasses the traditional OOD step in development and fully automates the resolution of nonfunctional requirements (i.e., generates 100% of the 3GL code), the process is known as translation. (When MDA is applied to round-trip tools that process individual PSMs and the developer provides the intellectual content, we still have elaboration, even though MDA allows seamless integration of the tools the developer uses.) Translation represents the major paradigm shift that we face today. While the notations and construction techniques remain largely the same and the transformation technique is fundamentally the same as described in the overview post, the crucial difference lies in automation of the computing space -- exactly as it was when 3GLs were introduced. That results in some interesting advantages for translation:

Analysis reuse. The same PIM may be implemented in quite different computing environments with out modification and with complete confidence that the application still logically functions the way the user expects. Thus every application is highly portable.

Design reuse. A transformation engine tailored to a particular computing environment will optimally implement any PIM that it eats there. Thus one obtains full reuse of all of the optimizations for nonfunctional requirements across applications. This is because the resolution of nonfunctional requirements is necessarily dependent upon the particular computing environment and that is all automated.

Productivity. Because of the reuse above, the developer does not have to reinvent the wheel for every application. In fact, an application developer isn't even concerned with inventing the wheel once. In practice this productivity boost is somewhat balanced by the need to provide quite rigorous PIM models; typically much more rigorous that the OOA models in most elaboration shops. The big productivity boost, though, comes through the use of a 4GL. Once gets the same sort of advantages over 3GLs that the 3GLs had over Assembly. That boost is especially apparent when doing maintenance. Identifying changes in a couple of dozen diagrams is orders of magnitude easier than doing so in an MLOC of code. Where I worked before retiring we did an extensive evaluation of the technology before committing to it. (Among other things we completely re-developed an existing 1 MLOC application.) We measured a 10X reduction in maintenance effort -- it was so astonishing we had difficulty getting people to believe our data. But even the Marketeers were astounded by how fast we turned around major changes.

Reliability. The most surprising result was a 50% across-the-board reduction in defects because we had no expectations of any improvement. I can't point to specific practices to make that happen, but I attribute it to the 4GL level of abstraction and separation of computing space concerns. One gets to focus on what is really important to solving the customer's problem and that tends to reduce the opportunities for inserting defects. When fewer defects are inserted, there will be fewer escapes from testing.

An obvious question is: How can one resolve all nonfunctional requirements automatically? Note that the computing space is highly deterministic. That's because everything we do in software must eventually be expressed unambiguously in the simplistic context of Turing and von Neumann computational models. That means everything we express in the computing space is defined with mathematical precision. Thus the entire computing space is amenable to at least some degree of automation. On the other hand, it is no small task to provide that automation because the computing space is vast and very complex. The optimization problems a transformation engine faces are orders of magnitude more complex than those facing the designer of a 3GL optimizing compiler. So it should be no surprise that it has taken almost half a century since the first 3GLs for the engineering problems to be resolved for general purpose computing.

Fortunately the learning curve completed with the turn of the millennium and we are poised on the brink of a major shift in the way software is developed. During a keynote address at a UML World conference a couple of years ago Ivar Jacobson made the prediction that in another decade writing 3GL code would be as rare as writing Assembly is today. I am not sure it will be quite that fast, but it is certainly inevitable now that the technologies have been validated and it only took a decade for FORTRAN and COBOL to almost completely displace Assembly coding.

* CRUD = Create, Retrieve, Update, and Delete; USER = Update, Sort, Extract, and Report.

Blog root page
previous post in category

3.0 OO mapped into MDA

Blog root page
previous post in category
next post in category

MDA is about providing common semantic meta models that can be used to create concrete models using different notations. The meta models allow one to unambiguously transfer information between those concrete models. Though MDA was inspired by OO development in general and UML in particular, this principle is widely applicable to situations where models are used -- beyond OO or even software development.

For a traditional OO development I see the correspondence as:

Domain          Analysis     Design       Language     Machine
Metamodel    -> Metamodel -> Metamodel -> Metamodel -> Meta Model
     |      *:1    |      1:*    |     1:*    |     1:*    |
     |             |             |            |            |
     |             |             |            |            |
Requirements -> OOA Model -> OOD Model -> OOP Model -> Executable
     |             |             |            |
     |             |             |            |
    CIM           PIM           PSM          PSM
                Functional   Nonfunct.     Nonfunct.
                             Strategic     Tactical

Because the various meta models are defined within a consistent semantic framework, it is possible to map corresponding notational entities between then unambiguously. Since the concrete models (CIM, PIM, PSM) are instantiations of the corresponding meta model, that makes it possible to map unambiguously between the concrete models as well.

The mapping may not be 1:1, though, because there may be multiple alternatives in one metamodel for a single artifact in another metamodel. That's because software models reduce the level of abstraction moving left to right while additional concerns are addressed at each level. In contrast, most problem spaces are quite complex compared to the computing space and a major task of OOA is map the problem domain into a single mathematically precise notation.

In an OO development context it is important to note that everything model to the left of the Executable is a specification for the stage to the immediate right. However, everything to the right of Requirements is a solution model for the specification on its immediate left. Each stage has a particular focus and the level of abstraction of the solutions decreases as one moves to the right.

In an elaboration environment the application developer provides the bulk of the intellectual content to the concrete models. In such an environment the role of MDA is to support interfaces between the tools employed for each stage so that the models can be seamlessly integrated. In a translation environment, though, the transformation engine typically goes directly from the PIM to a final PSM (3GL model) or the executable. The transformation engine provides the intellectual content for OOD/P through the use of complex transformation and platform models of the computing environment itself.

One of the crucial things that MDA provides is standardization and a byproduct of that standardization is the ability to make the PIMs and PSMs executable. Thus one can execute a PIM model to validate the solution for functional requirements. That validation will say nothing about meeting nonfunctional requirements, but one can demonstrate unequivocally that functional requirements are satisfied by the solution.

In an elaboration process a major benefit of having an executable PIM is to validate the solution for functional requirements prior to committing to the rest of the development. In a translation environment, the PIM /is/ the solution to the customer's problem and no further added value is required from the application developer, other than specifying nonfunctional requirements for the transformation engine. Translationists run the same test suite for functional requirements against the code that they run against the model; only the test harness changes.)

Note that if the PIM is not an executable solution, there is no substantive difference between the CIM and the PIM when using OO development. The PIM already expresses the functional solution purely in the customer's terms because that is what OOA is about. While the PIM is based on the same mathematics as that which prevails in the computing space, that mathematics is not limited to the computing space. Nor is it specialized mathematics for the computing space because it is chosen as a bridge that provides rigorous
mapping between both domains. (In fact, there are OOR specification techniques around that even use the same subset of UML as a PIM profile.) So the only thing that distinguishes a PIM from a CIM is that
it describes a particular resolution of functional requirements.

Blog root page
previous post in category
next post in category