Coffea Works

How AOD Can Help MDA

Weaving the Ultimate Enterprise Architecture with Aspect Oriented Design

by Soumen Chatterjee

Model Driven Architecture (MDA) is a technique for deriving a platform-independent modeling solution, which approaches the ideal of iterative, dynamically evolving, scalable and interoperable enterprise domain abstraction. Static mapping between models is not difficult, but in the real world, within an agile iterative environment, defining models for concerns and domains, maintaining the traceability matrix of all modified models and synchronizing them in actual applications is the most fundamental problem with MDA. This article discusses how the modularization and weaving concepts of Aspect-Oriented Design (AOD) can encourage the evolution of MDA-based enterprise architecture.

Introducing the Matrix Enterprise
You can imagine an enterprise as a set of interacting business processes arranged in a matrix as shown in Figure 1.


Figure 1: The Enterprise as a Matrix (Reference [CIMOSA])

In the figure, the functional operations (FO) represent sub-activities while functional entities (FE) represent technologies. Each functional operation may be executed by one or more functional entity, which means that two different FEs may share common concerns. In this model, an enterprise is a matrix of macro-level activities and micro-level functional entities.Figure 2 shows a clearer "enterprise axis" view of the matrix in isolation:


Figure 2: Enterprise Axis - the figure shows a clear view of the enterprise as a matrix

The matrix model can also be used to depict the enterprise in Unified Modeling Language (UML) as shown in Figure 3:


Figure 3: UML Depiction of an Enterprise - the figure shows enterprise participants and their inter-relationships modeled in UML

Enterprise Architecture
The enterprise includes partners, suppliers and customers, collectively working as a large collaborative autonomous unit. However, an enterprise is not limited to selling or offering services or products; sometimes a product itself may act as an enterprise.Enterprise architecture is the art of applying a set of fundamental software engineering principles to describe the vision and mission of the enterprise, design and model the use-cases of the system, design relationships between the modules, and finally, to build the organizational software foundations. These principles cover enterprise aspects ranging from the organizational structure through business processes, information systems, and infrastructure. This comprehensive nature is neatly depicted in Figure 4, which shows a modified ANSI/IEEE Std 1471-2000 conceptual model of an enterprise:


Figure 4: Conceptual Model of Enterprise Architecture: Note the comprehensive nature of enterprise architecture, spanning from vision and mission to software.

Enterprise Modeling
An enterprise model is an abstract visual representation of sets of elements (modules, that is) which describe physical or abstract structure, behaviors, and the relationships between them. A metamodel is the specification for creating the model. Figure 5 shows the relationship between models and metamodels:


Figure 5: Models and Metamodels: The figure shows how specific models could map to a platform-independent metamodel.

From a design perspective, enterprise models capture different views of the enterprise, represent possible sets of constraints within the model, and thus provides enough flexibility to choose or replace a particular model.

Model Driven Architecture
Since the beginning of the software industry, architects have faced a fundamental challenge - transforming enterprise vision, views, and opinions into appropriate model. Architects have used UML to design use cases to capture the enterprise requirements, modeling components, modules, systems, and their interactions. UML, however, provides neither model reusability, nor interoperability between different heterogeneous models.More recently, MDA has introduced a standard modeling specification, providing an efficient modeling technique to model different enterprise domains, transformation techniques to transform one type of model to another, and mapping techniques to generate implementation code from the models.

The Essence of Model Driven Architecture: Model Driven Architecture (MDA) has enjoyed high visibility since its formal announcement by the Object Management Group (OMG) in March 2001. It is no exaggeration to say that MDA has the potential to revolutionise the way we create and maintain software. In this JAX Magazine article, Wim Bast, Chief Architect Compuware, outlines the essence of MDA. The article attempts to clearly explain what MDA is, and what it is not.

MDA Layers of the MDA
MDA is built upon different types of abstraction layers known as Common Information Model (CIM), Platform Independent Model (PIM), Platform-Specific Model (PSM), and platform-specific source code. The various layers are as follows:
  • Layer 1: CIM -- Common Information Model (CIM) is the highest level of abstraction in these modeling layers. CIM describes a system-independent domain or business model. CIMs are reusable IT assets, which are reusable across the enterprise. The MDA specification enforces the traceability of system CIM requirements to the PIM and PSM constructs that implement them, and vice versa.
  • Layer 2: PIM - Platform Independent Model (PIM) is the second level of abstraction layer. PIM defines high-level technology-independent modeling concepts. Multiple levels of PIM layers may result from higher-level architectural models. PIM is a unique way to represent core business requirements in a set of layered abstractions to form platform-neutral modeling solutions.
  • Layer 3: PSM - Platform-Specific Model (PSM) is the third level of abstraction layer. PSM models are platform-specific, but they are abstracted away from technology-specific coding. A solution may require multiple levels of PSM layers to support higher-level architectural models.
  • Layers below PSM - At the lowest level, PSM transformation can generate code. These lowest layers consist of platform-specific coding.

Transformations
Transformation is a process that generates a target model from a source model. Transformation should be both bi-directional and traceable. In an MDA-based implementation scenario, conversion from one particular type of model to another type of model happens through meta-model based transformation such as CIM to PIM, PIM to PSM, and so on.Consider the banking domain, for example, which has a plethora of domain-specific logic and concerns that depend on the type of banking under consideration. In other words, the concerns for investment banking are different from those for retail banking, and so on. Table 1 briefly categorizes a few of these concerns.
In a banking scenario, security is a prime concern. An MDA-based implementation of these security requirements involves a series of layered transformation from CIM to the lowest level of Java coding as shown in Figure 6:


Figure 6: MDA Layers: Here are the MDA layers within a simplified banking domain

Banking Domain logic is a part of CIM that needs to be attached with Internet-banking logic and security concern. These PIM and PSM layers can be further refined along different concern dimensions to finally produce a transformation into a Java-based implementation.

MDA Benefits
MDA has several benefits and contributions that improve of the software development process, life cycle, and architectural mechanism, as listed below:
  • MDA based Software Development Life Cycle: MDA has changed the software development lifecycle. With MDA, the analysis phase is now mostly concerned with defining the CIM, while system design involves defining and developing the PIM and PSM layers. The system design phase requires highly-skilled architects and modelers. Coding skills are required to develop the PSM layers. But to achieve automatically generated code, (transformation, that is) you need to define the exact transformation mechanism. Unfortunately, in the current MDA road map, MDA transformation is not very mature. However, the CIM and PIM layers and transformation technologies are reusable and could be reused across the enterprise.


Figure 7: MDA-based Software Development Life Cycle

  • Reusable enterprise assets: CIM and PIM are produced as platform- and technology-neutral models. Therefore, these models are highly reusable enterprise assets.
  • Less Coding: The MDA specification introduces the concept of transforming the PIM to PSM, and then to PSM-based code. In most cases, to get the actual benefits of the MDA, these transformations should be automatic, straightforward, and tool-based. Some cases may require manual intervention as well; however, that should be minimal, requiring less coding than current software development processes.
  • Interoperability: MDA encourages interoperable modeling.
  • Traceability and Maintenance: The MDA specification enforces the concept of traceability among the existing models in different layers. In most cases, organizations use automated tools to maintain relationships between the model layers; however, such tools are still immature.

The Challenge of MDA
Despite the advantages listed in the previous section, MDA neither specifies robust model-to-model transformation techniques, nor recommends any generic or predefined model transformation rules. Moreover, maintaining traceability between transformed models is extremely challenging, because of the complexity of model synchronizations and management.In fact, these are probably the prevailing reasons behind the limited adoption of MDA. New techniques promise to make MDA more attractive though.

AOP and SOC: Helping Hands of MDA
Separation of Concern (SOC) is one of the most revolutionary concepts in the practice of state-of-the-art software engineering. Traditional component-oriented software development techniques are inadequate for coping with software complexity. They often fail to achieve desired software quality factors (such as adaptability, maintainability, extendibility and reusability) and avoid inheritance, which are the primary motivations for organizing and decomposing software into manageable and comprehensible modules. In such a scenario, MDA stands to greatly benefit from Aspect-Oriented Programming (AOP)-based modularization and weaving concepts.MDA handles the vertical decomposition of a matrix enterprise into several domains, domain-independent components, industry-specific components and technology-specific components. On the other hand, AOP handles the horizontal decomposition of each problem space domain, design space, and implementation into concern-oriented models. See Figure 8:


Figure 8: Enterprise decomposition

AOP's divide-and-conquer strategy helps to separate cross-cutting concerns of the business logics into separate aspects, modular PIMs and PSMs. At a later point of time, AOP also helps to weave those concerns to generate other PIMs and PSMs. Without AOP, it will be difficult to define suitable, mature PIM standards and transformation rules that can handle these divergent concerns across each MDA layer axis.Table 2 briefly outlines how MDA and AOP can complement each other. In conjunction with specific languages (Java and .Net, for example) the combination can be extremely useful for producing quality [ISO 9126] software:
The ISO 9126 specification recommends several quality attributes, applicable for any piece of software. The information listed in Table 2 clarifies that MDA and AOP are indeed complementary technologies, which can suitably contribute towards any object-oriented languages in order to complement them, and make them complete, modular and quality driven.

Aspect-Oriented MDA
AOP can be used in horizontal decomposition of any MDA layers into several cross-cutting concerns. In this section, we will revisit Figure 6 in the light of AOP.As shown in Figure 9, in Layer 2, the PIM layer can be further horizontally decomposed into an additional Layer 3 called Aspect Based PIM layer, which introduces security concerns. In this way, Layer 3 weaves Internet-banking logic with security concern.


Figure 9: AOP-based MDA

Thus, MDA and AOP can be combined together to realize the complete business requirements. This can be further refined using aspect weaving at different levels of the PIM/PSM hierarchy as depicted in Figure 10 [later in the article].

The Ultimate Enterprise Architecture Development
Considering all our earlier discussion, MDA and AOP seem to be dramatically changing the direction of enterprise architecture development. From Figure 7, it is clear that an MDA-based software development approach can create a major positive impact in the software development life cycle. In the following sections, I will detail a few other important influences of AOP and MDA in enterprise architecture.

Concern-Oriented Enterprise Architecture Layers
MDA delivers an excellent modeling framework that has been long awaited. The need of the moment, however, is an enterprise framework that can use MDA's potential benefits to achieve business success. Enter GERAM - a comprehensive enterprise reference architecture that helps building enterprise architecture benefited from enterprise models (see Figure 10). The documentation explains that, "GERAM is not yet-another-proposal for an enterprise reference architecture, but is meant to organize existing enterprise integration knowledge. The framework has the potential for application to all types of enterprise. Previously published reference architectures can keep their own identity, while identifying through GERAM their overlaps and complementing benefits compared to others."


Figure 10: GERAM Modelling Framework. Used with kind permission of Prof. P. Bernus

Table 3 compares MDA and GERAM:
So MDA, which is one of the best candidates for producing enterprise models, together with AOP, which can plug in the concern-oriented aspect modules, can jointly produce successful enterprise operation systems. MDA, with the help of AOP weaving could be layered and developed as depicted in Figure 11.


Figure 11: MDA based AOP weaved ultimate enterprise layers

Such an enterprise model will consist of Domain layers, PIM layers, Concerns, PSM layers, a Technology Dependent layer, a Platform Dependent layer, Aspect Library / Repository and Language Dependent layer (Language Specific Framework layer, Development time concern plug-in layer, Newly Developed component layer and Service layer).

In the true spirit of MDA, developers should have tools flexible enough to create CIM as well as develop Java/.NET/C++-based application solutions. In the current scenario, however, there aren't any such all-purpose tools that can serve all layers of MDA needs. The few tools that are around, use their own transformation languages - this will give rise to compatibility issues going forward. ML versions, type of diagram supports and UML profile supports are the other areas of concern.As of now, none of the tools available advertise AOP support. As of December 2005, only one AOP plug-in was available for MDA-based development - Parralax - which is supported online in the Eclipse platform. So the potential opportunities in this realm are vast.

Paradigm Shift toward Enterprise Architecture Bus
With the coming together of MDA and AOP, enterprise model development is moving towards the concept of an enterprise architecture bus (see Figure 12). Enterprises may import or export their enterprise model/code assets to the Enterprise Architecture Bus (EAB) using Managed Object Format (MOF)-based XMI format. EAB may maintain a common warehouse of UML models, CIM, PIM, PSM, Concern Repositories, and so on.


Figure 12: Enterprise Architecture Bus

Enterprise Architecture Framework
Under the influence of MDA and AOP, an enterprise may be represented in an 8X8 matrix. Figure 13 holds a description of this AOP and MDA-based enterprise architecture framework.


Figure 13: AOP and MDA based Enterprise Architecture Framework

Conclusion
Cross-cutting Concerns or Concern Oriented Software Development is the right fuel for MDA-based enterprise architecture state-of-the art practice. Although MDA and AOP are still not established in terms of their comprehensive and robustness, enterprises stand to benefit greatly from the confluence of these practices.On a lighter note, Albert Einstein's famous formula E = MC2 , can be used to rightly describe the ultimate equation for the enterprise:


Figure 14: Enterprise = MDA & Crosscutting Concerns

Aspect-oriented, MDA-driven enterprise architecture development will bring about a paradigm shift from traditional enterprise architecture development principles towards crosscutting concern separated enterprise. Separation of crosscutting concern is a powerful new-generation technique for deriving a modular matrix enterprise. Concern oriented modularization techniques help MDA to weave a better enterprise solution. MDA and concern oriented development are made for each other, and together they can truly weave the ultimate enterprise architecture.

Soumen Chatterjee is a Sun Certified Enterprise Architect for J2EE technologies, IBM Certified Specialist for Rational Unified Process and Microsoft Certified Professional. With expertise in architectural methodologies, process development techniques and testing strategies he was a part of the success equation of several leading edge software service organizations. Soumen is a member of American Computing Machinery (ACM) and member of World Wide Institute of Software Architects. He is currently working as a Lead Consultant with UPCO.

Acknowledgement: The author is sincerely thankful to Prof Kurt Kosanke for his valuable review comments. The author is grateful to his suggestions.

Resources & References
Standards Bibliographies
  • Aspect Oriented Software Development with Use Cases by Ivar Jacobson and Pan-Wei NG, from Addision Wesley (ISBN 0-3212-6888-1)
  • Handbook on Enterprise Architecture, by Bernus, P., Nemes, L. and G. Schmidt (eds.), from Springer (ISBN 3-5400-0343-6)
  • How to survive in the jungle of Enterprise Architecture frameworks (Second Edition), by Jaap Schekkerman, from Trafford (ISBN 1-4120-1607-X)
  • MDA Distilled: Principles of Model-Driven Architecture by Stephen Mellor, Kendall Scott, Axel Uhl, Dirk Weise, from Addison Wesley Professional (ISBN 0-201-78891-8)
  • MDA Explained: The Model Driven Architecture: Practice and Promise by Anneke Kleppe, et al, from Addison Wesley Professional (ISBN 0-3211-9442-X)
Research Papers and Publications
  • The Essence of Model Driven Architecture: Model Driven Architecture (MDA) has enjoyed high visibility since its formal announcement by the Object Management Group (OMG) in March 2001. It is no exaggeration to say that MDA has the potential to revolutionise the way we create and maintain software. Wim Bast, Chief Architect Compuware, outlines the essence of MDA. The article attempts to clearly explain what MDA is, and what it is not.
  • OptimalJ - Delivering on the Essence of MDA: Wim Bast, Chief Architect Compuware, describes OptimalJ and how it delivers on the essence of Model Driven Architecture (MDA), to allow a balance between productivity and flexibility.
  • Enterprise Modelling by Marks S. Fox and Michael Gruninger (This is a publication of The American Association for Artificial Intelligence)
  • Role of Model-Driven Architecture in Business Integration by Sundar Vaidyanathan, Business Integration Journal, September 2004
  • Architectural Manifesto: Choosing MDA tools
  • Architectural Manifesto: MDA for the enterprise
  • The Role of Aspect-Oriented Programming in OMG's Model-Driven Architecture by Dean Wampler, Aspect Programming, Inc.
  • Integrating CBSE, SoC, MDA, and AOP in a Software Development Method by Raul Silaghi and Alfred Strohmeier Software Engineering Laboratory, Swiss Federal Institute of Technology in Lausanne CH-1015 Lausanne EPFL, Switzerland
  • Five Layers of the Enterprise Fondue Process
  • Parallax API documentation
  • Model-Driven Architecture: Vision, Standards And Emerging Technologies Position Paper Submitted to ECOOP 2001 for Workshop on Metamodeling and Adaptive Object by John D. Poole, Hyperion Solutions Corporation, April 2001
  • Quantitative Analysis of Enterprise Architectures by Maria-Eugenia Iacob and Henk Jonkers
  • An Integrated Component-based approach to enterprise system specification and development by Zoran Stojanovic, Ajantha Dahanayake, Faculty of Information Technology and Systems, Delft University of Technology
  • Enterprise Modelling
  • Gregor Kiczales, John Lamping, Anurang Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier and John Irving. Aspect Oriented Programming. In Mehmet Aksit and Satoshi Matsuoka (Eds.), Proceedings of ECOOP'97
  • PERA AND GERAM--ENTERPRISE REFERENCE ARCHITECTURES IN ENTERPRISE INTEGRATION by Theodore J. Williams, Institute for Interdisciplinary Engineering Studies, Purdue University and and Hong Li, Senior Consultant, Claremont Technology Group, Inc
  • Components and Viewpoints as Integrated Separations of Concerns in System Designing by Zoran Stojanovic, Ajantha Dahanayake, ISA Department, Faculty of Information Technology and Systems, Delft University of Technology
  • Reasoning About a Classification of Crosscutting Concerns in Object-Oriented Systems by Constantinos A. Constantinides, Department of Computer Science and Information Systems, Birkbeck College, University of London and Therapon Skotiniotis, College of Computer Science, Northeastern University
  • Applying Aspect-Orient Programming Concepts to a Component-based Programming Model by Thomas Eidson, Jack Dongarra and Victor Eijkhout
  • Modeling Components and Frameworks using UML by Cris Kobryn
  • Object-Oriented Design wih UML and Java by K Barclay and J Savage
  • Concepts for Modelling Enterprise Architectures by Henk Jonkers1, Marc Lankhorst1, Ren?an Buuren, Stijn Hoppenbrouwers, Marcello Bonsangue, Leendert van der Torre


back
top
print
recommend