The place of Architecture in Model-Driven Engineering

Model-Driven Engineering (MDE) in its essence is constructing a model of a problem space (e.g. a business process) and transform that model into a model of a solution space (e.g. a software system). In the problem space domain-specific abstraction are used to create a model, while in the solution space implementation-oriented abstractions are used. Jean-Jacques Dubray extends this model to, what he calls, MetaModel Oriented Programming (MOP). He states:

MOP is also part of the broader Model Driven Engineering picture and intends to complement it, not change it, not replace it.

He adds the notion of metamodel to both the problem and the solution space. I like his views and triggered by them I was thinking how to fit the notion of architecture in the Model-Driven Engineering picture. So, what’s the place of architecture in MDE?

Mapping between problem space and solution space

Figure 1 – Mapping between problem space and solution space

Let’s start with a picture, Figure 1, from a previous post on the concepts of MDE. I’d like to combine this view with some of my previous articles on architecture, enterprise engineering, and the economic value of architecture. I think the place of architecture in Model-Driven Engineering is as visualized in Figure 2 (below). It’s a first concept, but I think the essence is clear. Architecture plays an important role in both the problem and the solution space.

In the problem domain enterprise architecture guides the design of an enterprise based on the strategy of the enterprise. Enterprise architecture is prescriptive and is formulated using principles [1]. Enterprise architecture principles are based on the goals and policies of an organization and guide the design of the organization/enterprise. A design of an enterprise can be formulated using enterprise ontology, which provides a conceptual model of the enterprise that is coherent, comprehensive, consistent, and concise, and that only shows the essence of the operation of an enterprise [2].

Based on the design of the enterprise business components can be identified. Business components ‘directly model and implement the business logic, rules and constraints that are typical, recurrent and comprehensive notions characterizing a domain or business area’ [3]. I see a business components as an implementation of a part of the enterprise design, specified in terms of the problem domain (i.e. functional models / models of the problem space, specified in domain-specific abstractions).

Architecture and Model Driven Engineering

Figure 2 – Architecture and MDE

Besides playing an important role in the problem domain, architecture is also a key element in the solution domain. The technical architecture is closely related to the enterprise architecture. Technology is essential for supporting business, organization, information, and future enterprise developments. From this perspective the technical architecture guides or conditions how IT-systems should be designed. Following the IEEE 1471 the technical architecture also conditions the internal structure of an IT system (the quality attributes) and how IT-system are related to each other. Note that in this definition architecture also contains a descriptive notion of architecture.

The transformation from functional models (in the problem domain) to executable models (in the solution domain) should be organized in such a way that the resulting artifacts conform to the technical architecture. The technical architecture also guides the behavior of the model interpreter or the transformation of the models into source code.

From an architectural perspective Model-Driven Engineering gives a lot of opportunities. Using properly defined metamodels with additional constraints ensures that the models are guaranteed to conform to the architecture. Due to the automatic generation of source code or the direct interpretation of the models (I favor the last option, but that’s another discussion ;), the resulting system also fully conforms to the defined architecture.


————————–
[1] J. A. P. Hoogervorst. Enterprise Governance & Architectuur – Corporate, IT en enterprise governance in samenhangend perspectief. Sdu Uitgevers bv, Den Haag, 2007.

[2] Jan L. G. Dietz. Enterprise Ontology. Springer-Verlag, Berlin Heidelberg, 2006.

[3] F. Barbier and C Atkinson. Business Component-Based Software Engineering, chapter Business Components, pages 1-26. Kluwer Academic Publishers Group, 2003.

Leave a Reply