Model Driven Architecture (MDA) Partha Kuchana

Agenda What is MDA Modeling Approaches MDA in a NutShell MDA Models SDLC MDA Models (an Example) MDA - Advantages MDA - Reality Check

What is MDA ? Model Driven Architecture What is Model abstraction of something that exists in reality description of a (business) system in a [formal way]

What is MDA ? Software Modeling Approaches OMG framework for software development, which is top-down and driven by the business

Modeling Approaches Code Only No formal model exists Modeling is done in the form of programming abstractions e.g., packages and modules Might work for small scale efforts Makes maintenance difficult Code is Model Pictorial representation of the code base No real high level model Developers can alter model elements through code

Modeling Approaches Code and Model Co-exist (RTE) High level model exists Transformation from model to code is manual Automated tools could be used to generate stubs Code and model evolve through iterations Code or model may be changed for error-correction If not controlled through an effective process, gets code and model out of sync Model-centric Model exists with sufficient details Business Rules Integration Requirements

Modeling Approaches Business Requirements UI Representation Details Business Logic Transformation from model to code is automated Model only Corresponding code transformation may not occur (solution architecture in proposals and software architecture documents) Model and code are disconnected (O/N/R* shoring)

MDA in a Nutshell MDA

MDA Models MDA is a way to organize and manage enterprise architectures supported by automated tools and services for both defining the models and facilitating transformations between different model types. (OMG Definition) Platform Independent Model (PIM) Fundamental Business Function and Behavior Created using UML Platform Specific Model (PSM) Specification of the Application in terms of the Implementation Constructs Specific to a Given Target Platform Based on the PIM

MDA Models Code Model Based on PSM Implementation in a Specific Language MDD Model is used as a primary artifact to generate an efficient implementation through transformations Work carried out by developers in an MDA based implementation MDA - MDD made formal (by OMG) Example: Functionality around an insurance policy and a customer

SDLC Build/Coding Design Testing Requirements Gathering/An alysis Deployment Traditional Analysis and Requirements Specification Analysis and Requirements Specification Detailed System DesignCode MDA Design Req Gathering/Analysis Build/CodingTestingdeployment Usecases/ PIM PSMCode

MDA Models (an Example) Platform Independent Model Policy effDate: Date expDate: Date Premium: Real policyType: Integer getPremium() Customer firstName: String lastName: String Address: Address * 1 Platform Specific Model (Relational) Policy effDate: DATE expDate: DATE Premium: REAL policyType: INTEGER Customer firstName: VARCHAR(30) lastName: VARCHAR(30) Address: VARCHAR(30) Platform Specific Model (EJB Component) > Policy > Customer > and > Platform Specific Model (Web Component) > Policy > Customer > Code Model Oracle DDLEJB CodeJSP Code Infrastructure/Deployment/Plumbing Code

Advantages MN language suitable for automated interpretation Increased Productivity Automated code generation (not just stubs) Higher level of abstraction to the SD process High quality, Standards Based, Consistent Code base Helps preserve development investment Insulates business from technology evolution Requires strong collaboration between IT and Business Top down development More in alignment with the real-world empowering business users

Advantages Model (in action) validation capture requirements more effectively Suitable for modern day development approaches Portability Focus on PIMs, transform to multiple PSMs (platforms) Enables transition to newer technologies seamless to gain business value (java, xml, web services) Interoperability Bridges, for communication between PSMs Documentation Low and high level Useful/meaningful documentation Automated Automated Integration support for automated testing *

MDA – Reality Check MDA <> Math UML is not sufficient to describe complex business interactions leads to proprietary extensions Affects portability Cannot produce fully functional application One-size fits all approach Potential for inefficient code Domain experts with business knowledge may need to learn UML Built in transformations Needs customizations Complex template merging may be required Can be minimized with rich set of templates

MDA – Reality Check Provides a higher level of abstraction to the SD process Before you start using MDA Support for powerful frameworks for robust system design Limit on the number of business entities that can be modeled Support for automated testing Plug-play with testing tools Support for integration Estimate the amount of customization needed DB related customizations, not just code Estimate the template merging effort Continued vendor support for template merging for new releases Consider the efficiency of the generated code Have a process to ensure top-down development requirements must always flow from top down Eliminates the scope for technology defining business requirements

Questions