An Analysis of Model Driven Architecture (MDA) and Executable UML (xUML)

The MITRE Corporation Tom Massie, D440 February 19, 2004

Objectives

Problem Space (Rise of MDA) Architecture Terminology MDA Defined xUML/Action Semantic Language Defined Joint SIAP Systems Engineering Organization (JSSEO) Advantages/Disadvantages of MDA MDA Tools MDA Vendors

The Problem Space

New Technologies

Each year, new technologies are being invented and becoming very popular.
Web Services, ASP, HTML, JSP, SQL, UML, J2EE, Flash, XML
4

C++, Java, VB, CORBA, C#, .NET, Eiffel, JDBC , COBOL

Technology Adoption Curve:

Java CORBA J2EE DCOM TCP/IP .NET Web Services CCM
Jini JavaSpaces

Future

Adoption

Laggards

Late Majority

Early Majority

Early Adopters

Innovators

The CIOs Challenge:

All of this constant change presents a real problem to an organizations CIO who wants to:

continue to use and integrate their existing software; employ industry standards; curtail massive integration costs; balance need for interoperability and growing trend in system-of-systems evolution
6

Rising Interoperability Gap

CIO challenges with changing technology Diverse set of platform and standards J2EE, CORBA, .NET, Web Services Oracle, SQL Server, XML Current and growing need: To unify the system model and implementation Provide an agile process to preserve the investment in a system architecture Overcome challenges with system interoperability and integration
7

Architecture Terminology

Architectural Terminologies
Programming Languages

Java, C++, C#,

Architectural Frameworks

Rational Rose, System Architect, CORE

Modeling Tools

architecture

DODAF, NATO C3, Zachman

RUP, Waterfall, Spiral

Methodologies

Model Driven Architecture Components

C#, JAVA, C++, ASL Languages Rational Rose System Architect Tools CORE iUML DODAF Frameworks NATO C3 Zachman MDA

MDA
Methodology

RUP, Waterfall, Spiral, Agile MDA

Model Driven Engineering

10

Model Driven Architecture

11

The Model Driven Architecture

A common approach for designing and building a system that remains decoupled from the eventual languages, platforms and middleware environments -Object Management Group, 2001
12

OMGs MDA Vision

Provide A Different Way to Specify and Build Systems

Provide a coarse separation of views Provide a viable strategy for system integration Motivate a new breed of modeling tools Provide support for tool integration
13

Object Management Group

The OMG Sponsors Research Committees Including: A non-profit corporation Founded in April 1989. Goal: To accelerate the introduction of standardized object software. Over 800 members, from Industry, Academia, and Government. Introduced MDA in 2001 as an evolution of OMGs CORBA architecture
14

OMG Milestones
1989
OMG is founded

1991
CORBA 1.0, IDL

CORBA 2.0

1996 1997
UML, MOF, XMI, CWM MDA

2001
UML 1.5 UML 2.0

2003
15

Model Driven Architecture [1]

MDA is a framework for software development Key to MDA is the importance of models in the software development process (PIM, PSM, PSI) Provides independence from a diverse set of IT environments operating system network topology programming language middleware independence
16

Model Driven Architecture [2]

Provides a common approach for design and building a system that remains decoupled from the:

Eventual languages, Platforms Middleware environments that will be used

The code is completely derived by the model Future Proofing

Provides a mechanism for an organization to design their systems once and then transition them over time when the next best technology comes along.

17

MDA Meta Models

18

Platform Independent Model (PIM)

High level abstraction that is independent of any implementation technology Describes a software system that supports some business and are specified using xUML System is modeled from the viewpoint of how it best supports the business Describes peer system behavior, independent of the computing environment & implementation technologies PIMs are reused across multiple platforms
19

Platform Independent Model (PIM)

PIMs

<<PIM Context.abstraction level>> Context <<refine>>

Functional Requirements

<<PIM Requirements.abstraction level>> Requirements

<<refine>>

<<PIM Analysis.abstraction level>> Analysis <<refine>> <<refine>>

Performance Requirements

<<PIM Design>> Objects Design

<<PIM Design>> Components Design

20

Platform Specific Model (PSM)

Specifies how the functionality in a PIM is realized on a computing platform. Derived from the PIM by adding platformspecific attributes to the standard components Common to have multiple PSMs with one PIM Is tailored to specify the target platform system
21

Platform Specific Model

PIMs <<PIM Context.abstraction level>> Context

<<refine>>

<<PIM Requirements.abstraction level>> Requirements <<refine>>

<<PIM Analysis.abstraction level>> Analysis

<<refine>>

<<refine>>

<<PIM Design>> Objects Design

<<PIM Design>> Components Design

PSMs

<<refine>>

<<refine>>

<<refine>>

PSM_CORBA

PSM_EJB

PSM_CCM

22

Platform Specific Implementation (PSI)

Generation of an Object Model Model repository contains all necessary information to produce a runtime specific platform Model compiler translates abstractions in the model to a specific implementation PSI is executable code that runs on a target architecture Object Model Compiler Requires for Generation

C++ file Make File IDL File XML File

23

Platform Specific Implementation (PSI)

PSI is executable code that runs on a target architecture

xUML Model
customer Customer id customer address account 1 Is owned by 1..* account id owns data opened balance

Target Code

AC1:create_account
Class data structure
Creating Account Entry/ New_account = create unique Account with \ balance = opening_balance Link owing_customer R1 new_account

AC6:delete_account
Deleting Account Entry/ owing_customer = R1 Unlink this R1 owing_customer {other_owned_accounts} = owning_customer R1 If countof {other_owned_accounts} = 0 then generate C99:delete_customer() to owing_customer endif delete this

Typedef struct D7_C3 struct { /*account Class header * / struct s_object *next_object; /linked list */ struct s_object *prev_object; /objects */ struct s_object *rel_ptr; /list of rel ns */ }D7_C3; Section of state action ASL #ifdef HARNESS SMM_At_Line (7, 3, State, 1, 1, CGEN_FUNCT, #endif new_account = cgen_create_object (7, 3, sideof(d7); new_account -> account_id = cgen_get_next_unique;

24

MDA Framework

25

MDA Framework

Construction of the PIM metamodel with class and state diagrams Integrating PIMs into one or more PSMs through auto-generation and action semantics language (ASL) Automation of PSM into a Platform Specific Implementations (PSIs) Model compilation of PSI code in simulation environment
26

MDA Methodology

27

Software Development Methodologies

Mostly text

requirements

requirements

Mostly text

Waterfall
analysis design analysis
diagrams & text

PIM
(metamodel)

design
PSM

diagrams and text

integration
coding
Code

MDA Agile

Code

coding testing integration

PSI Code

deployment
Code

testing deployment

28

Model Driven Engineering (MDE)

Somewhat similar to other software engineering methodologies (spiral, waterfall, etc) Agile process with iterative model builds that are linked together and then mapped to a single combined model, translated into code Agile MDA, Model is constructed, run, tested and modified in short incremental cycles Results are more rapidly immediate (couple of classes, state machines, etc)
29

Anatomy of MDA
Functional Operational

New Requirements

System Domain

PIM (Generic)

Sensor
Tracking Navigation
PIM-PSM Integration Layer Sensor Sensor COM Tracking Navigation PSI Layer

COM

Peer

PIM (Generic)

System Y PSM

Tracking Navigation

COM

Peer

PSM Peer Bridge

System X PSM

System Y PSI

Sensor interface Tracking Navigation interface COM Peer Peer COM Tracking

Sensor interface Navigation interface

System X PSI

New Modular Component

Sys.Y

Network

Sys.X

New Modular Component

30

MDA Transformation Approach

PIM

Marked PIM Transformation

PSM
Marked PSM
Specific Implementation

31

Action Semantic Language (ASL)

eXectuable UML (xUML)

Foundation of xUML is the Action Specification Language (ASL) Language allows platform-independent specification of state actions, operations, and corresponding relationships Provides the complete syntactic and semantic language to fully specify models Specifies the mapping rules that generate PIMs and PSMs
33

Action Semantic Language

Allows Access to Data Described by Class Diagrams Allows Access to Data Supplied by Signals initiating actions Provides the ability to generate signals Action Semantics is executed in the Context of numerous interacting state machines (UML State Diagrams)
34

Executable Unified Modeling Language (xUML)

A non-standardized, formalized subset of UML that enforces constraints on the description The only mandatory UML diagrams within xUML:

UML Class diagram UML State Chart diagram

All other diagrams or certain constructs within these diagrams are semantically weak, and therefore not a part of xUML Specifies the use of UML 2s Action Semantics for the definition of model actions
Semantically Weak Elements Precisely Defined Action Semantics 35

xUML

UML

Action Semantics

Today, UML does not prescribe an ASL MDA tool vendors can create their own ASL
Examples If then else logic ASL (KC) AL (ProjectTech) AS (Kabira)

If factor = 2 then If (factor == 2) If (factor ==2) { # Do some Action // Do some Action // Do some Action Switch factor case 1 #Do Some Action If (factor == 1) If (factor==1) { // Do Some Action // Do Some Action Elif (factor ==2) } elseif (factor ==2){
36

Multi-Way Decision

Domains and Bridges

A system is decomposed into domains, where each domain encapsulates the knowledge for one subject matter:

Domains are semantically autonomous, because you can understand one domain without understanding others Domains depend on one another without actual knowledge of one another Bridges tie together the loose ends in the domains by specifying the inter-domain dependencies Domains are pure within a subject matter and bridges is where the pollution is kept An interface is actually defined twice: once by the domain using the service and once by the domain supplying the service The bridge is the piece of logic that translates between using domain interface and the supplying domain interface

Examples: UI, persistence, networking, and one or more application subject matters

37

ASL Summary

A programmer must develop the execution process for the UML model The goal of ASL is an unambiguous, concise and readable definition of model processing The use of ASL allows the modeler to decouple from target languages Each vendor can implement the programming constructs differently thus creating different ASLs Use of ASLs allows for automatic code generation

38

MDA Advantages and Challenges

Advantages of MDA [1]

Hand coding of model behavior is bypassed Focus on modeling forces better designs Essentials of system model are behavior algorithms Model uses middleware abstractions for platform independence (PIM) Model Compiler is written once per platform

Updated for hardware or operating system changes Validate compiler with simple models exercising associations, facilities and actions Creates the Platform Specific Model (PSM)

40

Advantages of MDA [2]

Evolutionary step that raise the level of abstraction Models always reflect the current baseline Better supports inclusion of emerging technologies Help separate business rules from the diverse implementation environments

41

How to fully integrate and leverage the growing abundance of OMG technologies into MDA

Challenges for MDA

Unified Modeling Language (UML) Meta Object Facility (MOF) Common Warehouse Metamodel (CWM) XML-based Metadata Interchange (XMI)

Need for more mature MDA modeling tools

Translation between PIMs and PSMs Better coordination between mappings of different models (avoidance of hand-coding) Tools to support model driven testing (setting thresholds, touch points) Tools for version control and distributed working Model Compilers

42

MDA User Base

Thales Research and Technology (Europe) Lockheed Martin (F-16) Mission Avionics Wells Fargo (Business) Pacific DataWorks (E-Business) IBM (Web Business) U.S. Air Force (Kabria) Lucent Technologies (Kabria) Ericsson AT&T Fixed Wireless

43

Sample Vendor List

Kennedy-Carter / iUML+iCCG Project Technology/BridgePoint Telelogic Tau (IBM) Rational/XDE Interactive Objects/ArcStyler SoftTeam Objecteering/UML Codagen Architect Compuware/OptimalJ MetaMatrix/Metabase

44

Thank you !! Questions/Comments??

45