Model-Driven Architecture (MDA)?

What is MDA?

Model-Driven Architecture (MDA) is a software design approach that focuses on creating and using technology agnostic models to drive the development of software systems, making it easier to develop and maintain software across different platforms and technologies.

Key Concepts of MDA:

1. Models as First-Class Artifacts: MDA emphasizes using high-level models to represent various aspects of a system (such as business processes, application structure, or data). These models serve as the primary means of communication and design.

2. Platform Independence: The core idea is to separate business logic and application design from platform-specific details. The idea is that the same model can be adapted to different target platforms (e.g., different operating systems, databases, or hardware).

3. Transformation: MDA uses model transformations to automatically convert a high-level model into lower-level models or executable code, based on a specific target platform or technology. This ensures that the high-level design remains consistent even if the platform changes.

History of MDA

MDA was developed by OMG (Object Management Group). OMG is a consortium dedicated to the development and promotion of object-oriented technologies and standards. It is a non-profit organization that creates standards for building interoperable, platform-independent enterprise-level applications.

Founded in 1989 by eleven companies (including Hewlett Packard, Sun Microsystems, Canon, IBM, and Apple), OMG’s standards were initially met with skepticism in some circles. However, the consortium now includes around 800 companies, including both software producers and users.

In late 2000, OMG members first reviewed a document titled "Model Driven Architecture" and decided to form an architecture group to create a more formal statement of MDA. This formal, albeit incomplete, definition of MDA was presented in the 2001 document “Model Driven Architecture - A Technical Perspective” by the MDA Development Team of the OMG Architecture Board. Approved by members in September 2001 as a baseline architecture, MDA was promptly adopted by many domain task forces for defining and establishing standards across various middleware platforms.

In mid-2014, OMG members approved a revised version, the "MDA Guide Revision 2.0," as a more comprehensive definition of the architecture. This document is based on the separate MDA Foundation Model.

MDA Layers and Models

CIM (Computation Independent Model)

CIM is the first and most abstract model in the architecture. Its main purpose is to describe the business requirements and goals of the system without delving into technical details.

CIM answers the following questions:

• What should the system do?
• What business processes should it support?
• How will users interact with the system?

CIM includes the following:

1. Description of business processes: CIM explains what tasks the business performs and how the system should support these tasks. For example, if it’s an e-commerce system, CIM might describe processes like searching for products, adding items to the cart, placing orders, and making payments.
2. Description of users and their interactions: CIM outlines who will use the system and how they will interact with it. For example, in an e-commerce system, there might be several user types:
   • A customer, who browses and purchases products.
   • An administrator, who adds new products and manages orders.
3. System requirements: CIM may include a list of features and capabilities the system should have. For instance, an e-commerce platform should allow users to create accounts, search for products by category, pay for orders, and track deliveries.

It’s important to note that CIM does not describe how this will be implemented technically. At this stage, there’s no discussion of whether the system will be built using Java, Python, or PHP, or which database will be used. CIM focuses solely on how the system should function from a business or end-user perspective.

Why is CIM Important?

• Business focus: CIM allows for a focus on what the business actually needs without technical distractions. This helps in understanding customer needs and business processes more clearly.
• Simplified communication: Since CIM describes requirements and processes from a business perspective, it facilitates communication with stakeholders (such as managers and users) who don’t necessarily need to understand technical details.
• Foundation for further design: CIM is the first point from which system development begins. After creating CIM, developers can move to the next stage, where technologies and architectural solutions (PIM and PSM) are discussed.

PIM (Platform Independent Model)

PIM is the second stage in the Model-Driven Architecture (MDA) approach, focusing on the logic and structure of the system without tying it to a specific technology or platform (such as programming language, database, or operating system). This model describes how the system should work in terms of functionality and architecture without delving into technical details.

PIM addresses questions such as:

• How will the system operate?
• What components and functions should it contain?
• How will these components interact with each other?

PIM elaborates and expands on the CIM (Computation Independent Model). While CIM focuses on business requirements and processes, PIM describes application logic while remaining independent of specific platforms or technologies.

What Does PIM Include?

1. System Structure:
   • PIM describes the components of the system and their relationships. These components may include modules, classes, or functions that work together to complete required tasks.
   • For example, in an e-commerce system, components might include “Product Catalog,” “Shopping Cart,” “Payment,” and “Order Management.” PIM defines how these components are interconnected but does not specify their implementation details.
2. Interaction Logic:
   • PIM also describes business rules and logic governing interactions between components. For example, in an e-commerce application, the logic might be: if a product is in stock, it can be added to the cart; once an order is placed, a notification email must be sent to the user.
   • Data flows between various modules may also be described here, without linking to a specific technology.
3. Abstract Data Description:
   • PIM outlines the data the system must handle and its structure without specifying the database. For instance, it may define that the system should store information about users (name, email, orders) and products (name, price, stock level), without indicating the data storage format (relational database or NoSQL).
4. Description of Processes and Behaviors:
   • PIM can describe dynamic behavior within the system, such as scenarios that show how components interact during certain operations. This can include sequences of actions, states, and events. For example, when a user clicks “Place Order,” which components activate and what data is transferred between them?

Why is PIM Important?

1. Separation of Logic and Technology:
   • PIM allows developers to concentrate on application logic and structure without focusing on technology choices. This simplifies design, making it more universal, as the logic can be implemented on any platform.
2. Flexibility and Portability:
   • Since PIM is technology-independent, it can be used to transfer the system’s logic to any platform. For instance, if you decide to change programming languages or databases, PIM remains relevant.
3. Platform Independence:
   • The PIM model outlines general operational principles for the system, applicable across various environments (e.g., cloud, on-premise servers, or mobile apps). This makes it useful for adapting to different technologies.

After creating PIM, the model serves as the foundation for the next step — building the PSM (Platform Specific Model), where developers choose specific technologies (such as programming language, databases, frameworks) to implement the system. PIM acts as a "bridge" between business logic and technical implementation.

PSM (Platform Specific Model)

PSM (Platform Specific Model) is the third and final stage of development in Model-Driven Architecture (MDA), focusing on the concrete implementation of the system using specific technologies and platforms. Unlike the PIM (Platform Independent Model), which remains abstract and technology-agnostic, PSM describes how the logic and components defined in PIM will be realized on the selected technological platform.

PSM answers questions such as:

• Which specific technologies and tools will be used to implement the system?
• How will the abstract components from PIM be brought to life using specific programming languages, databases, frameworks, and other tools?

What Does PSM Include?

1. Selection of Specific Technologies:
   • PSM specifies the particular programming languages, databases, frameworks, and other tools that will be used to implement the system.
   • For example, if the "Shopping Cart" component is defined in PIM for an e-commerce site, PSM might specify that it will be implemented in Python using the Django framework, and order data will be stored in a PostgreSQL database.
2. Mapping Components to Technology:
   • PSM defines how the abstract system components from PIM will be realized using the selected platform. This might include classes, functions, databases, APIs, and other technology-dependent details.
   • For instance, the interaction between the "Product Catalog" and "Shopping Cart" components might be implemented through a REST API using Flask in Python.
3. Technical Implementation Details:
   • PSM includes all technical aspects of the system’s implementation, which may include server configuration specifications, database setup, API parameters, and other application requirements.
   • For example, PSM might define database deployment parameters (such as replication settings), server configurations, and other resources.
4. Optimization for the Chosen Platform:
   • PSM also considers platform-specific features and applies optimizations to fully leverage the platform’s capabilities.
   • For instance, if the system is being developed for cloud services, PSM might include settings for automatic scaling, load balancing, or cloud database optimization.

Why is PSM Important?

1. Concretizing Abstractions:
   • PSM is the next step after PIM, where the abstract components and logic of the system are translated into specific technological solutions. This helps to clarify and formalize the development process.
2. Support for the Chosen Platform:
   • PSM allows the system’s architecture to be tailored to the capabilities and limitations of the chosen platform. This consideration helps address infrastructure and technology-specific factors that could impact performance, security, and scalability.
3. Implementation and Deployment Guidance:
   • PSM provides developers and DevOps engineers with clear instructions on how to deploy the system on the specified platform, including all necessary configurations and settings.

Relationship between PIM and PSM

PIM and PSM are closely connected. PIM describes the system’s logic without a technology tie, while PSM translates this logic into a specific implementation using defined technologies. The transition from PIM to PSM can be partially automated, where abstract models generate code or configurations for specific platforms.

Example

To better understand this system, let’s look at the process of creating an online store following the MDA approach.

Starting with the first model:

CIM

A product manager approaches the developers and says, "We need to create an online store system where customers can search for products, add them to the cart, and pay with a credit card." This is CIM. At this stage, developers understand what needs to be done but are not yet deciding how to do it.

• User process: The customer visits the website, selects a product, adds it to the cart, places the order, and completes payment.
• Business process: The system should support product search, cart functionality, and order placement. Interaction with the payment system is also part of this process.
• System requirements: The system should have a product catalog with filtering capabilities, a shopping cart, and integration with a payment system.

PIM

Once the team has developed CIM and identified that the online store needs a product catalog, cart, and payment features, they move to PIM. At this stage, they describe how these functions will interact. For example, they decide that after a product is selected, it should be sent to the cart, and order data should be processed by the payment component. They create detailed diagrams showing interactions without specifying the platform it will be implemented on (e.g., whether it will be done in Java, Python, or another technology).

• System components: The online store can be divided into components like "Product Catalog," "Shopping Cart," "Payment," and "Order Management." These components are described in PIM, including their interactions. For example, the "Product Catalog" component should send data to the "Cart" when a product is selected.
• Interactions: When the user adds a product to the cart, the system should check availability and update the cart. After placing the order, the system passes the data to the "Payment" component, which processes the payment.
• Data: PIM can describe data structure: products have a name, description, price, and stock quantity, while users have accounts, orders, and purchase history.

PSM

After creating PIM and describing how the components of the online store (catalog, cart, payment system) interact, developers move to PSM. In PSM, they decide that the system will be implemented in Python using the Django framework, with data stored in a PostgreSQL database. They also specify that the application will be deployed on AWS with configurations for automatic server scaling.

• Technology selection: PSM specifies that the online store will be built in Python using the Django framework. Product and order data will be stored in a PostgreSQL database, and the payment system will be integrated using the Stripe API.
• Component implementation: The "Product Catalog" component defined in PIM will be implemented as a Django model, with database queries handled through ORM. Interaction between "Product Catalog" and "Shopping Cart" will be carried out via REST API.
• Server configuration: PSM might also include server settings for deploying the online store on AWS, with parameters for automatic scaling and load balancing.

What’s Next?

After developing all three models, what comes next? At this stage, the system implementation begins based on the defined models.

1. Automatic Code Generation

There are tools available that automatically generate code based on the models, particularly from PSM, which is already tied to specific technologies.

For this, special code generators or platforms convert the PIM and PSM models into working code in the chosen programming language (e.g., Java, Python, C#). This significantly accelerates the development process and reduces errors, as much of the routine code is generated automatically.

1. Manual Code Refinement

While many parts of the system can be generated automatically, some areas still require manual refinement.

Developers can manually add extra features, integrations, or components that cannot be automatically generated (such as complex algorithms or non-standard API integrations).

At this stage, specific business logic that requires careful configuration may also be added.

1. System Testing

After writing and generating code, testing begins. It’s necessary to verify that the system functions correctly according to business requirements (CIM) and technical specifications (PSM).

1. System Deployment

After successful testing, the system proceeds to deployment on real servers or within a cloud infrastructure.

PSM already defines specific deployment settings (e.g., AWS, Azure, or local servers), so DevOps engineers use these models to configure the environment and deploy the application. This stage includes tasks like server setup, database configuration, network settings, and other infrastructure aspects.

1. Monitoring and Support

Once the system is live, real-time monitoring begins. It’s essential to track performance, ensure correct operation, and detect any errors.

1. System Adaptation and Evolution

After deployment, the system continues evolving to meet new business requirements. When new business goals arise, or market conditions change, developers can return to CIM and update business requirements. These changes then carry over to PIM and PSM, which lead to updates in the system’s implementation. In this way, the system can adapt to changes, staying flexible and maintainable thanks to the MDA approach.

1. Reusability

PIM and CIM remain valuable if the system needs to be ported to another platform or programming language. For instance, the PIM can be reused to implement the system on a different platform by simply modifying the PSM.

UML and XMI

Reading through this article, you may be wondering how to define models, transfer them to code generation tools, or share them with project participants. To standardize this process across platforms, OMG has provided tools that are universally compatible.

This is a broad topic, which we’ll only cover briefly here to give you a solid understanding of how MDA functions.

UML (Unified Modeling Language)

UML is a visual modeling language used to represent a system as diagrams and schematics. UML is essential for creating visual models at every development stage (CIM, PIM, and PSM), making it easy to describe how the system should function.

UML enables:

1. System visualization: Displaying system components in diagrams simplifies understanding the structure and behavior of the system.
2. System documentation: UML helps create documentation detailing system functionality, which is crucial for support, scaling, and modernization.
3. System architecture design: It aids in the design phase, where models of component structure and interactions are developed.
4. Standardized communication: UML provides a common language that developers, analysts, and managers can understand, simplifying system discussions.

UML includes diagrams and models to describe different system aspects, grouped into three main categories: structural, behavioral, and interaction diagrams. There are 14 UML diagrams in total, but we won’t cover them all here.

XMI (XML Metadata Interchange)

XMI is an XML-based standard for exchanging models and metadata created according to MDA. XMI allows models created in one system to be transferred and read by another system or tool, ensuring a unified representation of model information in XML format, making it compatible with a broad range of tools.

Key features of XMI:

• Since XMI is XML-based, it’s both easy to read and compatible with most modern systems.
• XMI supports models of any complexity and can expand to include new concepts.
• OMG standardizes XMI, ensuring it’s interoperable and supported by many MDA-compatible tools.

In the context of MDA, XMI is used for the following tasks:

• XMI allows models to be exported from one tool and imported into another. For instance, you can create a model in one UML editor and then import it into another system for code generation.
• XMI facilitates integration between different MDA-supporting tools. For example, a modeling tool can export models to XMI, while another tool analyzes them, maintaining their semantics.
• XMI serves as a format for storing models, allowing developers to save them for further use or documentation.
• XMI files can be used for model transformations. In MDA, transforming a model from PIM to PSM is often necessary, and XMI files provide the needed data structure.

Example of Using XMI in MDA

Let’s look at how XMI is used in a typical MDA process:

1. A PIM is created in a modeling tool (e.g., a UML model of a business process) that describes the system’s logic without binding to a specific platform.
2. The created PIM is exported in XMI format, creating an XML file with all model metadata.
3. The XMI file is then passed to a tool that transforms the PIM into a PSM, adapting the model for a specific platform (e.g., transforming it into a model for a web application).
4. Based on the PSM, source code is generated, completing the process.

These two tools complement each other for an efficient workflow.

Conclusion

MDA is a powerful tool with a steep learning curve, but mastering it can enable long-term support for your application, updating legacy systems, and adding new features while maintaining your application’s structure. New team members can quickly get up to speed by studying the documented models.