The Four-Layer Architecture


The three layers of Figure 4-2, which comprise objects, models, and metamodels, are universal, and the OMG has standardized a terminology to ease communication about them, as shown in Figure 4-4.

  • M0 contains the data of the application (for example, the instances populating an object-oriented system at runtime, or rows in relational database tables). (This is the top row in Figure 4-2.)

  • M1 contains the application: the classes of an object-oriented system, or the table definitions of a relational database. This is the level at which application modeling takes place (the type or model level). (This is the second row in Figure 4-2.)

  • M2 contains the metadata that captures the modeling language: UML elements such as Class, Attribute, and Operation. This is the level at which tools operate (the metamodel or architectural level). (This is the bottom row in Figure 4-2.)

Figure 4-4. Four-level metamodel hierarchy

graphics/04fig04.gif

In each case above, the M stands for "meta," unsurprisingly. As we mentioned before, the levels are relative.

There can also be models that span more than one of these levels, such as a UML model that describes both the data and the metadata of an application by means of object diagrams and class diagrams, respectively. Note the Account class and its instance depicted at the same M-level in Figure 4-4.

Despite its prominence, the UML metamodel is just another metamodel. There were many notations available in the dark days before UML, and each of them could have been (and some were) metamodeled. This fact raises the question of whether it is possible to build a metamodel of the metamodel, and the answer is Yes:

  • M3 is the metametadata that describes the properties that metadata can exhibit. This is the level at which modeling languages and metamodels operate, providing for interchange between tools.

    The fundamental idea behind this level in the hierarchy is that there are classes whose instances can be associated with instances of other classes, have attributes of some type, and perform operations. In other words, M3 describes the modeling paradigm.

    In turn, it's reasonable to ask if it's possible to build a metameta-metamodel. (Really!) The answer is both Yes and No. Yes, we could build a metamodel of M3, but the modeling language we use would itself be at M3. If there were an M4, it would look just the same as M3. So, there is nothing beyond M3, because M3 is self-describing.

    Assigning fixed numbers to the levels can be misleading at times. It's more useful to regard the relationships among the four levels in other words, the metarelations as relative. Some x can be "meta" to some y if x says something about y. At the same time, y can be "meta" to some z in the same way, and so forth. Everything is relative.

    Nonetheless, the M3 level is a model of only the simplest set of concepts required to capture models and metamodels. M3 stands out as a constant in the modeling business. That's why there have been some efforts in standardizing things at this level, which has given us the MOF.



MDA Distilled. Principles of Model-Driven Architecture
MDA Distilled. Principles of Model-Driven Architecture
ISBN: B00866PUN2
EAN: N/A
Year: 2003
Pages: 134

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