|
|
URL of the article:
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.
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:
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:
 Figure 7: MDA-based Software Development Life Cycle
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).
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
|
||
|
