An Analysis of Model Driven Architecture MDA and Executable UML xUML

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

• The MITRE Corporation
• Tom Massie, D440
• February 19, 2004

2
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

3
The Problem Space
4
New Technologies

• Each year, new technologies are being invented
  and becoming very popular.

• C,
• Java,
• VB,
• CORBA,
• C,
• .NET,
• Eiffel,
• JDBC ,
• COBOL

• Web Services,
• ASP,
• HTML,
• JSP,
• SQL,
• UML,
• J2EE,
• Flash,
• XML

5
Technology Adoption Curve
Adoption
Laggards
Late Majority
Early Majority
Early Adopters
Innovators
6
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

7
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

8
Architecture Terminology
9
Architectural Terminologies
Java, C, C,
Programming Languages
Architectural Frameworks
Rational Rose, System Architect, CORE
DODAF, NATO C3, Zachman
architecture
Modeling Tools
RUP, Waterfall, Spiral
Methodologies
10
Model Driven Architecture Components

C, JAVA, C, ASL

Languages


DODAF
NATO C3 Zachman MDA
Rational Rose System Architect CORE
iUML

MDA
Frameworks
Tools
Methodology
RUP, Waterfall, Spiral, Agile MDA
Model Driven Engineering
11
Model Driven Architecture
12
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

13
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

14
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

15
OMG Milestones
OMG is founded
CORBA 2.0
1991
CORBA 1.0, IDL
MDA
UML, MOF, XMI, CWM
UML 1.5
UML 2.0
16
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

17
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.

18
MDA Meta Models
19
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

20
Platform Independent Model (PIM)
21
Platform Specific Model (PSM)

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

22
Platform Specific Model
23
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

24
Platform Specific Implementation (PSI)

• PSI is executable code that runs on a target
  architecture

xUML Model
account
Target Code Class data structure 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
-gt account_id cgen_get_next_unique
AC1create_account
AC6delete_account
25
MDA Framework
26
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

27
MDA Methodology
28
Software Development Methodologies
requirements
Mostly text
requirements
Mostly text
Waterfall
analysis
diagrams text
analysis design
PIM (metamodel)
design
diagrams and text
integration
PSM
coding
Code
coding
Code
MDA Agile
testing
Code
integration
PSI
deployment
testing
Code
deployment
29
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)

30
Anatomy of MDA
Functional
System
New Requirements
Domain
Operational
Sensor
Tracking
COM
Peer
PIM (Generic)
PIM (Generic)
Navigation
PIM-PSM Integration Layer
Sensor
Sensor
Tracking
COM
Peer
Tracking
COM
Peer
System X PSM
PSM Bridge
System Y PSM
Navigation
Navigation
PSI Layer
Sensor interface
Sensor interface
System Y PSI
System X PSI
Tracking
COM
Tracking
COM
Peer
Peer
Navigation interface
Navigation interface
Sys.Y
Sys.X
New Modular Component
New Modular Component
Network
31
MDA Transformation Approach
Transformation
32
Action Semantic Language (ASL)
33
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

34
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)

35
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

xUML
UML
Semantically Weak Elements
Precisely Defined Action Semantics
36
Action Semantics

• Today, UML does not prescribe an ASL
• MDA tool vendors can create their own ASL

37
Domains and Bridges

• A system is decomposed into domains, where each
  domain encapsulates the knowledge for one subject
  matter
• Examples UI, persistence, networking, and one or
  more application subject matters
• 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

38
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

39
MDA Advantages and Challenges
40
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)

41
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

42
Challenges for MDA

• How to fully integrate and leverage the growing
  abundance of OMG technologies into 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

43
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
• ATT Fixed Wireless

44
Sample Vendor List

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

45
Thank you !! Questions/Comments??