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
2
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
5
The CIO’s Challenge:
All of this constant change presents a real problem to an organization’s 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
8
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
9
Model Driven Architecture Components
C#, JAVA, C++, ASL Languages
Rational Rose System Architect Tools CORE iUML
MDA
Methodology
DODAF Frameworks NATO C3 Zachman MDA
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
OMG’s 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 OMG’s 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
<
> Context <>
Functional Requirements
<> Requirements
<>
<> Analysis <> <>
Performance Requirements
<> Objects 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 <> Context <>
<> Requirements <>
<> Analysis <> <>
<> Objects Design
<> Components Design
PSMs
<>
<>
<>
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 New Modular Component COM Peer Peer COM Tracking
Sensor interface Navigation interface
System X PSI
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 2’s 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 ASL (KC) AL (ProjectTech) AS (Kabira)
If then else logic
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