Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 1

Strengthening the Modeling Foundation of the MDA

Paper for Workshop in Software Model Engineering1 October 2002

Dresden, Germany

Duane Hybertson

The MITRE Corporation7515 Colshire DriveMcLean, VA 22102

dhyberts@mitre.org

Abstract. The Model Driven Architecture (MDA) represents a positive step toward a generalmodel-based approach to software engineering. The conceptualization of the MDA is not yetmature; it is still being formed. Elements of a modeling foundation are described in thispaper, including an architecture of software engineering and a multi-dimensional modelingspace that provides separation of concerns and a systematic and uniform approach to modelsthat is self-similar at all levels of each dimension. The position of the paper is that amodeling approach is the right way forward, but the MDA can be strengthened and mademore complete by incorporation of some of the concepts in the proposed modelingfoundation.

1. Purpose and content

OMG has introduced the Model Driven Architecture (MDA) as its next generation architecture and generalapproach to technology integration. Much of the work the OMG has previously done can readily beincorporated into a model-oriented approach. Furthermore, the concept of a model driven architecture ismore generally applicable to the larger software engineering community, and not limited to OMGtechnologies. Therefore, the position of this paper is strongly in support of the general thrust of the MDAtoward a broader modeling approach.

However, a key supposition of this paper is that further strengthening of the modeling foundation for theMDA would be beneficial in realizing MDA goals and the larger goals of software model engineering. Thepurpose of the paper is to describe a modeling foundation for software engineering, and to indicate how thisfoundation can strengthen the MDA. The paper proposes a general modeling space as a key element of thisapproach.

The paper has two parts. The first part, in Section 2, provides an introduction to the modeling foundation,with more details in the areas related to the MDA. The second part, in Section 3, raises certain issues in thecurrent MDA, and shows how they are addressed by the modeling foundation.

2. Introduction to modeling foundation

The artifacts of software engineering have traditional names such as requirements specification,architecture description, design description, source code, and executable code. In this foundation, all theseartifacts are regarded as models. Based on this orientation, the foundation consists of a context described asthe architecture of software engineering, followed by an introduction to a general modeling space, which isthe key focus of the architecture.

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 2

2.1 Architecture of software engineering

The architecture of software engineering consists of three interacting components: a problem space, amodeling space, and an execution space that includes computers. The full architecture includes multiplerelations among these three components, but for the purposes of this paper, we focus on three specificrelations, as illustrated in Figure 1. The problem space is the “real world” that comes up with problems thatcan be solved by computers. The problems exhibit great variation, but they are organized into morehomogeneous sets of problems called problem domains. The modeling space is an organized collection ofall software and system models. Most of this paper is focused on the structure and contents of the modelingspace. The execution space is where certain models, called executable models, are used to govern thebehavior of the computer and other related run-time resources, which interact with users and other systemsin the problem space to solve problems in a given problem domain. The models bridge the gap betweenspecific problem domains in the problem space and specific computer processor architectures in theexecution space.

Problem space

Models

Modeling space Execution space

1

3

2

1. Describe: Modeling space entities describe problem space entities and behavior2. Instruct: Models are interpreted by execution space entities as instructions and data3. Interact: Problem space entities interact with execution space entities - Interaction is governed by models and problem space data - Entities operate within their own universe of discourse: problem vs. computer

Interact

Describe Instruct

Figure 1. Architecture of software engineering

2.2 Modeling space elements

This section summarizes the contents and structure of the modeling space. The uniform approach oftreating all software artifacts and descriptions as models enables simplicity. A strong emphasis is placed onmodularity, encapsulation, and flexibility.

The first subsection gives an overview that introduces each element, and remaining subsections providemore details on certain elements that are important in understanding the MDA.

2.2.1 Overview

The modeling space contains the following key elements:

• A general interaction model of components and connectors includes component interfaces calledports that interact via connectors that define roles and protocols. This interaction model addressessystem interaction, coordination, and integration in a uniform way at all levels throughout themodeling space.

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 3

• A composition dimension represents a whole-part hierarchy ranging from the most inclusive system ofsystems to the lowest level indivisible unit. It is recursive in that a given whole can be part of a largerwhole.

• A commonization dimension represents “kind-of” (generalization) and “instance-of” (categorization)hierarchies ranging from universal models to highly specialized models, and from universal categoriesto individuals. It is recursive in that a general model can in turn be further generalized, and a categorycan be an instance of another category.

• A conceptualization dimension ranges from problem domain languages and universes of discourse tothe languages and universe of discourse of computer processors.

• A specification approach emphasizes precision, contracts, and semantics, and has two primaryspecification types or views for each component and connector: external and internal. The same kindsof specification information apply throughout the modeling space.

• A starter set of generally applicable views and viewpoints define certain basic perspectives on modelsand systems

• Mappings capture knowledge about the relations among models, specifications, and views throughoutthe modeling space – including transformation, abstraction, and satisfaction relations.

• Processors perform certain actions on models, including transform one model into another, execute amodel, and analyze a model to determine its properties or whether it matches or satisfies anothermodel. Processors can be human, software, or hardware.

Composition, commonization, and conceptualization collectively structure the modeling space into threedimensions as shown in Figure 2. They are separate dimensions because two models can be positioned atthe same point on any two dimensions but differ on the third.

Problem domain

Common

izatio

n

- Kind

s- C

atego

ries

Com

posi

tion

Universalmodel

Indivisible Unit

System of systems

Model of individualsystem or component

Conceptualization- Language/notation- Universe of discourse

Modeling space

Hardwareprocessor

domain

Views exist within and acrossthe three dimensions

Figure 2. Modeling space dimensions

The modeling space is a fractal in the sense that each dimension defines multiple levels of a spectrum inwhich the same types of entities and relations repeat in a self-similar or recursive way at each level. Thisuniformity enables the modeling space to support scale up and scale down in a natural way.

The elements of this modeling space are described in more detail in [1]. The subsections that follow presenta brief description of certain elements that are applicable to the MDA.

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 4

2.2.2 Commonization dimension

Commonization is a criterion for abstraction in which the relevant information is what is common among aset of entities. Common models are useful in multiple environments. Common models include abstractdata types, classes in class hierarchies, component and connector types, data types, metamodels, generics,templates, reference models, domain specific architectures, product line architectures, analysis patterns,architecture/design patterns, architecture styles, and programming idioms.

Two important relations in this dimension are kind-of and instance-of. These relations form two separatehierarchies that may be called generalization and classification or categorization. In object-orientedparlance, ‘kind-of’ is a class inheritance hierarchy relation—i.e., the relation of a class with its parent orsuperclass, and ‘instance-of’ is the relation of an object with the class from which it was instantiated.Figure 3 illustrates the distinction between the hierarchies, and also the intersection of the two, with anabbreviated form of the two-dimensional taxonomy of living things.

Categorization hierarchy

Biological category

Kingdom Class Species

Plant Animal Bird Mammal Fish Homo sapiens Dog Horse

{…Rover, …} {…Rover, …} {…Rover, …} {all animals} {all mammals} {all dogs}

Generalization hierarchy

Living thing

Plant Animal Fungus

Bird Mammal Fish

Homo sapiens Dog Horse

Combined hierarchies

Kingdom Animal Rover

Class Mammal Rover

Species Dog Rover

instance-of

kind-of

instance-of

kind-of

Figure 3. Intersection of kinds and instances using biological classification

A given entity can have multiple roles in these hierarchies. For example, a mammal is a kind (or subkind)of animal, a superkind of dog, a category of Rover, and an instance of class. In object oriented modeling,an OO class is a kind in the context of its class hierarchy, and it is a category in the context of itsinstantiated objects.

Kind-of is a transitive relation. In the Figure 3 generalization hierarchy, since dog is a kind of mammal andmammal is a kind of animal, then dog is a kind of animal. Instance-of is not a transitive relation. In thecategorization hierarchy, Rover is an instance of dog, and dog is an instance of species, but it is not truethat Rover is an instance of species.

In the modeling world, categorization is the relation that involves metamodels. A metamodel is a categoryof which a model is an instance. Some modeling structures define four such levels: Object is an instance ofa model, which is an instance of a metamodel, which is an instance of a metametamodel. A correspondingexample from Figure 3 is: Rover (object) is an instance of dog (model), which is an instance of species(metamodel), which is an instance of biological category (metametamodel). The Meta Object Facility has

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 5

this four layer architecture. In the modeling space, all levels are models—model is a relative term. Asdescribed above, each model is defined and distinguished by its roles in the categorization hierarchy or thecombined hierarchies.

2.2.3 Conceptualization dimension

Each model is represented in some notation or language, or combination of languages. The generalcategories of languages are textual, graphical, and mathematical. Models range from problem domainmodels (such as banking or geospatial information) to computer processor models. In addition to thelanguage differences are differences in universes of discourse—concepts, terms, and domain ontologies. Itis really the latter set of differences that establishes the large conceptual gap between problem domains andcomputer processors, and defines the range of this dimension. Example: In the banking domain used in theearlier example, key concepts are account, withdraw, deposit, balance, and transfer. In the geospatialdomain, key concepts are map, contour, elevation, feature, thematic layer, and projection. In the computerprocessor domain, key concepts are load, store, add, branch, memory address, and register (actually01011000, 0101000, etc. but we will use translated terms). The computer processor uses this basic set ofconcepts to solve problems in banking, geospatial information, and all other problem domains. Note thatwe listed the concepts in all these domains using English, but the conceptual distance between themremains large. In fact, software engineering could be defined as the discipline that designs systems thatenable successful communication two parties neither of whom has any idea what the other is talking about(the two parties being a problem domain specialist and a computer processor).

2.2.4 Specification approach

What is a specification?A specification is a precise shared understanding of an entity or set of entities, and therefore it involves anentity such as a model and at least two parties communicating about the model. Typically one party writesthe model (e.g., a programmer), and another party reads the model (e.g., a compiler). A specificationconsists of a set of rules, where ‘rule’ is used in a very general sense that includes everything from systemrequirements to code. Examples: data types; functions; performance properties; provided services;dependencies; policies; types of permitted components in a system; specific components and connectors ina system; attachment of components to connectors (ports to roles); properties or attribute values; invariants,preconditions, postconditions; exception handling; and state transitions.

An important element of component specification is design by contract, as defined by Meyer [2] butextended to include non-functional (e.g., performance, quality of service/QoS) information.

Intertwining external and internal specificationsSpecification types are derived from the interaction model and the composition dimension—specifically,the intertwining of internal and external views. An internal specification of a composite component orconnector entity is a set of propositions—including policies—about the data, components, and connectorsthat are within the composite, and their structure and interaction. An external specification of a componentor connector entity is a set of propositions about the external view of that entity. For a component, thatincludes observable data, behavior, ports, and services. The relation between the two specification types isthat an internal specification of a composite includes the external specifications of its components andconnectors. The external view corresponds to what we typically call requirements or specification, and theinternal view corresponds to what we typically call architecture, design, or implementation.

A further refinement of the concept of external specification is important. An external specification of acomponent may be one of two types. One type is the specific use made of the component in a givenenvironment, and the other is a “stand-alone” specification of the component that is not tied to any specificenvironment. The first is called a specialized external specification, and the second is called a generalizedexternal specification. This distinction is important for modularity and for the use of commercial (COTS)components and component-based systems. For example, in Figure 4, suppose component G in system E isa COTS component. The internal specification of E includes a specialized external specification of G thatshows how G is used in the E context. The vendor of G provides a generalized external specification of G

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 6

that is not aware of the E context but specifies general constraints that must be satisfied by anyenvironment or context that uses G. The G in E is a desired component, and the specialized specificationtells what E needs, while the vendor’s G is an actual component, and the generalized specification tellswhat G offers. The system developer of E matches his specialized specification of G with the vendor’sgeneralized specification of G to determine if G can be used in E.

Propagating (internal-external)

E

E

F G

H

p2 r4 p4

r6

p6

N1

N3

r3

I

p7

r7

N4

r5 p5N2

r3

r1

p2 r3

r1

r1

p6

p6

p2 Component Connector, roles Port

p = provided service; r = required service

External specification of E

Internalspecification

of E

Figure 4. Propagating services and dependencies

Service structureAn external specification of an entity such as a component has two contract types. The first specifies whatthe component provides to users (services offered). The second specifies what the component requires ofproviders (dependencies). These two contract types effectively partition the environment of a componentinto two parts: a service environment to which the component provides services, and a dependencyenvironment from which the component requires services. A dependency environment may also be viewedas a platform. Both the service environment and dependency environment can generate a chain of indefinitelength. A component can provide services to another component, which can in turn provide services toanother component, etc., thereby generating a provided services chain. Conversely, a component canrequire services from another component, which can in turn require services from another component, etc.,thereby generating one or more required services chains. Provided and required services are simply twoviews of the same chain. They are divided from the viewpoint of a given component in the chain.

Such a chain tends to bring composition into the picture, because somewhere along the chain it typicallyextends beyond the system that contains the chain of components. Suppose we have a system E withcomponents F, G, H, and I, as shown in Figure 4. F requires a service (r6) that is provided by component H(p6), which in turn requires a service (r5), which is provided by component I (p5), which in turn requires aservice (r1). But service r1 is not satisfied within system E. Therefore, E must propagate the dependency asa required service of system E. Likewise, any service offered by a component (e.g., p2 from F or p6 fromH) is a candidate for a service to be propagated and offered by the encompassing system (E).

This propagation continues up the composition hierarchy. Finally, whatever is not satisfied or consumedwithin the system of interest is exposed to its environment as an observable provided or required service.The provided service is ultimately expressed in the language and ontology of the problem space (e.g.,

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 7

“Select withdrawal or deposit”). The required service is ultimately expressed in the language and ontologyof the execution space.

The provided and required services generate two corresponding views for each model: Problem space viewand execution space view. The problem space view is characterized by the question “What problem or setof problems does this model address?” and relates to provided services. The execution space view ischaracterized by the question “What platforms can this model run on?” and relates to required services andan execution engine. The latter is closely associated with the language in which the model is expressed.These two views are largely independent of each other. Two models that address completely differentproblems may run on the same platforms, and conversely, two models that run on different platforms mayaddress the same problem.

3. Applying foundation concepts to selected MDA concepts

The MDA has much in common with the modeling space. However, the commonality is obscured to someextent by what I consider to be a lack of clarity in the description and conceptualization of some aspects ofthe MDA. In particular, certain concepts are treated in a somewhat ad hoc and inconsistent manner, and theemphasis in some areas is out of balance. The purpose of this section is to offer a few examples ofcommonality and of how the modeling space can help strengthen the MDA through more uniform andconsistent treatment and clearer separation of concerns.

3.1 Relations between models

This section shows an example of commonality between the MDA and the modeling space. An MDAexample is taken from the MDA draft specification [3] section on ‘Architecture for MDA Models’,specifically Figure 4 from page 9 of that document. It is reproduced as Figure 5 below. A mapping of thisfigure to modeling space concepts is given in Tables 1 and 2.

Business Domain Models B1, B2 (describes knowledge about the business domains, independent of specific software or business processes that might be used)

Spec of software system S1 (specifies the software independent of the various processes it may be configured for and deployed into, built using a minimal model of domain)

Business Process Models (describes business processes and includes information models; detailed versions include how some software sys tem, S1, is used as a part of some business processes; cannot violate domain knowledge in B1 and B2)

Design D1 of software sys tem S1 (a design of the software as an assembly of other software components C1 and C2)

Spec of C1

Spec of C2

Figure 5. “Structure of specification, refinement, and design” from [3]

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 8

Table 1. Mapping MDA structure to modeling space specification structure

MDA model Modeling space specification or viewBusiness domain model(B1, B2)

Data or information view of the business domain, and either a generalizedinternal view of interactions within the domain, or an external view of theenterprise

Business process model Internal view of an enterprise (including a data or information view) that isintended to satisfy the business domain model specifications. In the ‘non-detailed’ version, components are business processes. In the ‘detailed’ version,components are software systems, or more specifically, components include thesoftware system S1 and the other systems or actors (including people) withwhich S1 interacts. The detailed version therefore includes a specializedexternal specification of S1.

S1 specification Generalized external specification of S1 (assuming S1 may be used in otherenvironments)

D1 specification Internal specification of S1. Includes specialized external specification ofcomponents C1 and C2.

C1 and C2specifications

Generalized external specifications of C1 and C2 (assuming C1 and C2 may beused in other environments)

In Table 2, the business domain model from Figure 5 is referred to as BDM, and the business processmodel as BPM. Further, the assumption is that the BDM is an external view of the enterprise.

Table 2. Mapping MDA model relations to modeling space

MDA model pair Modeling space relations DimensionDecomposition (external enterprise to internalenterprise)

CompositionBDM – BPM

Possible translation (e.g., external domainterminology to internal enterprise terminology)

Conceptualization

Match (general external specification tospecific external specification)

Commonization (generalization)BPM – S1

Possible translation (e.g., internal enterpriseterminology to formal specification language)

Conceptualization

Decomposition (external system to internalsystem)

CompositionS1 – D1

Possible translation (e.g., formal spec languageto UML design diagrams)

Conceptualization

Match (general external specification of C1 tospecific external C1 specification in D1)

Commonization (generalization)D1 – C1

Possible translation (e.g., UML designdiagrams to IDL or Java interfaces)

Conceptualization

The match in Table 2 assumes a component based approach, both at the ‘system’ level (S1 is an existingcomponent that can be used in the detailed business model) and the ‘component’ level (C1 and C2 areexisting components that can be used in D1). If the system is custom built, the match does not apply.

One of the expressed goals of the MDA is to promote automation of the transformation between models.The modeling space provides a systematic basis for automation by making explicit both the specificationstructure of models and the relations between models, and by separating these relations by dimension. Inthe above example, dividing transformation into decomposition and translation allows us to workseparately on the automation of the two aspects. We can apply our extensive knowledge of compilertechnology to all translation problems, and isolate the more difficult problem of automating decompositionas a separate issue. Similarly with matching—we may have to translate before we can match. Thisseparation of relation types reduces the complexity and increases the reuse of automation, and seems to be

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 9

a more plausible approach to automation than the undifferentiated transformation approach involvingmarkings etc. presented in the MDA [3, 4].

3.2 Commonality and the generalized concept of platform

Traditionally, platforms have been defined as hardware processor, or virtual machine, or operating system,or programming language, or some combination of these. The MDA raises this to (or adds) the middlewarelevel, identifying specific middleware specifications such as CORBA or .NET as platforms.

Platform independence is an important concept in the MDA. To get a proper perspective on this issue, thesection examines some of the history of platform independence in the form of a repeating pattern ofplatform hiding.

A key goal in much of the history of platform independence has been about hiding platform variationsbehind a standard virtual platform or interface specification or API – or in modeling space terminology, anexternal specification – in order to reduce the number of different software variations to build and maintain.Efforts have included virtual machines, operating system interfaces such as POSIX, middleware such asCORBA, and now the MDA.

Based on the history of these efforts, one could roughly define a “platform hiding infinite loop” algorithmthat works something like this:

1. Problem: Software should be available to all. But multiple specific platforms exist. This makes it tooexpensive to build and maintain software because of the multiple variations needed.

2. Solution: Raise the level. Standardize or hide the platform variants behind one common platformindependent API or interface model. The models that access this interface model may be calledplatform independent models.

3. Goal: Get everyone to target this common API4. Problem: The world does not behave as we wanted. Multiple competing interfaces are defined at this

“platform independent” level. These competing interfaces now look a lot like specific platforms. Themodels that access any one of these competing interfaces are now called platform specific models.

5. Go to 1.

This loop would presumably stop (at Step 3) if everyone agreed on one API at some level. The loop relatesto the modeling space in two ways. First, at each level—or each iteration of the loop—an API is an externalview that is intended to be an external specification. Each platform that implements the API is analternative internal view or specification that satisfies the external specification. Second, the iterationsreflect the modeling space concept of spectrum. What is general and what is specific are relative points on acontinuum from most general to most specific. Platform is also a relative concept that exists at the differentpoints on this spectrum.

The foregoing discussion raises two issues with the current definition of the MDA and suggests how bothcan be addressed. The first issue is defining a common middleware API or external specification. If PIMsare intended to hide middleware differences, then we would expect, in accordance with Step 2 of thealgorithm, that a middleware analysis would be done to abstract away differences and yield a common setof services that could be used by application models or PIMs. But as it stands, no such common set or APIis contemplated in the MDA. Rather, this analysis must be done for each PIM—either reflected in the PIM,or applied to the transformation of the PIM to a PSM. The definition of UML profiles may mitigate theeffort of transforming to a PSM, but the profiles do not mitigate the basic problem, which is the lack ofdefined common services for PIMs to access.

The second issue is the relative nature of PIMs versus PSMs. Much of the MDA literature defines PIM andPSM as inherent or absolute model types, but the loop described above illustrates the relative nature ofthese designations. The claim that the middleware layer is now the platform is too narrowly focused. Thisclaim does not adequately address the lower layers that represent the more traditional concept of platform.

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 10

Do PSMs extend several layers, with a different PSM type at each layer? A more extensible notion ofplatform is needed, as embodied in the spectrum concept of the modeling space. The draft MDA guide [4]has in fact begun to reflect this relative nature of PIM versus PSM, but the dominant conceptualization ofthe MDA has not yet been reconciled with this concept, and the PIM/PSM terminology itself suggests adichotomy rather than a spectrum or a relative positioning.

3.3 Adding the problem space view from the OMA

The service structure presented in Section 2.2.4 described a problem space view and execution space viewof a model, distinguished by what problem a model solves versus what platform it runs on. If we overlaythe MDA on this structure, it seems fairly clear that the MDA is focused the execution space view and noton the problem space view. This issue of what problem a model addresses is invisible in the PIM-PSMformulation. This is a significant gap in the MDA. There is much more potential benefit from model basedsoftware engineering than the MDA focus on platform. Ironically, one of the better examples of a problemview is the OMG’s own Object Management Architecture (OMA) structure. That structure reflects aspectrum of generality of problems addressed ranging from most general to most specific: general CORBAservices, then CORBA facilities, then domain-specific models (e.g., transportation or health care), thenapplication specific models.

It is important to recognize that problem domain and platform are not different models, but different viewsof the same model. As shown in Table 3, the two views (problem and execution) are separate vectors ofgeneralization.

Table 3. Differentiating generality of problem view and platform view

Platform viewGeneral (specific

middleware)(specific operating

system)Specific

(hardware)General Common services

PIM expressed inUML

CORBAservicesPSM\PIMexpressed in IDL

CORBAservicesPSM\PIM implementedfor UNIX

CORBAservicesPSM compiled forSparcStation

Broad supportdomain services PIMexpressed in UML

CORBAfacilitiesPSM\PIMexpressed in IDL

CORBAfacilitiesPSM\PIM implementedfor UNIX

CORBAfacilitiesPSM compiled forSparcStation

Problem domainspecific services PIMexpressed in UML

Healthcare domainspecificationsPSM\PIMexpressed in IDL

Healthcare domainPSM\PIM implementedfor UNIX

Healthcare domainPSM compiled forSparcStationPr

oble

m V

iew

Specific Application specificservices PIMexpressed in UML

Applicationspecific PSM\PIMexpressed in IDL

Application specificPSM\PIM implementedfor UNIX

Application specificPSM compiled forSparcStation

A model can range from general to specific with respect to platform used, and can separately range fromgeneral to specific with respect to problem solved. The general column under platform view corresponds inthe MDA to the most general PIM, while the specific column under platform view corresponds in the MDAto the most specific PSM. In the intervening columns, the ‘PSM\PIM’ designation conveys the relativenature of “PIMs” and “PSMs.” For example, a CORBA model is a PSM relative to the most general PIM,but is a PIM relative to an operating system services PSM. An additional column for programminglanguage as a platform view could be inserted into the table—e.g., between middleware and operatingsystem.

The problem space view uses generalization to factor out common problems and solutions from morespecialized problems and solutions, i.e., the factorization of solutions into parts that are common tomultiple problems and parts that are unique to a given problem. This factorization acts like a prism that binsparts into multiple levels along a spectrum of commonality that ranges from universally applicable (thegeneral row under problem view) to unique to a single problem or application (the specific row). OMG has

Copyright (C) 2002. The MITRE Corporation. All Rights Reserved.

Hybertson 11

specifications that map nicely across this range of problem generality, as shown in the specific middlewarecolumn.

The current MDA platform focus corresponds to standing in the modeling space and analyzing its relationto the execution space. The MDA needs to turn around and also analyze its relation to the problem space.The modeling space described in this paper attempts to provide a foundation for both views and forleveraging both types of knowledge. The MDA should fully incorporate both views. From an OMGperspective, this would make the MDA a more complete instrument for integrating OMG technologies.From a larger software model engineering perspective, this would expand the MDA into a morecomprehensive framework for software modeling and software engineering.

Conclusion. In sum, the general position of this paper is that the MDA can be strengthened by thefundamental concepts expressed in the modeling space, including generalization, specification, anddependency, rather than the heavy emphasis on the PIM/PSM distinction. Incorporating these conceptswould broaden the modeling foundations of the MDA through a clearer separation of concerns, a morecomplete and balanced set of views, and a more systematic and uniform treatment of models and theirrelations in each dimension.

References

[1] Hybertson D. (2001) A uniform component modeling space. Informatica, vol 25, no 4, November2001, pp. 475-482.

[2] Meyer B. (1997) Object-Oriented Software Construction (2nd ed.) Prentice Hall.[3] Object Management Group (2001) Model Driven Architecture (MDA), 9 July 2001 draft, edited by J.

Miller and J. Mukerji, available at http://doc.omg.org/ormsc/2001-07-01[4] Object Management Group (2002) text for an MDA Guide, June 2002, available at

http://doc.omg.org/ormsc/02-06-02