Transcript Model Driven Architecture

OMG’s Model Driven
Architecture
Davide Buscaldi
D.I.S.I.
Summary





1.
2.
3.
4.
5.
Introduction
MDA Overview
Developing in MDA
MDA in the Practice
References
1. Introduction
A heterogeneous world…
 Programming languages: (see also: the DoD survey)



~3 million COBOL Programmers
~1.6 million VB Programmers
~1.1 million C/C++ Programmers
 Operating systems:


Unix, MacOS, Windows(3.1->XP),PalmOS
Embedded devices
 Networks:


Ethernet, IP, USB, FireWire
Bluetooth, 802.11b, HomeRF
Where can we agree?
 Hetereogenity hinders the development
of enterprise distributed systems
 There will not be consensus on
 Hardware
 Operating systems
 Network protocols
 Programming languages
 We can agree at an higher level
 Middleware
Middleware
 A software layer that masks
hetereogeneity
 Placed between operating systems and
application components
Middleware proliferation
 Middleware itself has proliferated:
 CORBA
 COM / DCOM / MTS
 Java / EJB
 XML / SOAP
 C# / .NET
 None of them prevails over the others
 The problem remains
The Object Management
Group (OMG)
 An open membership and no-profit
consortium
 Produces and mantains computer
industry specifications for interoperable
enterprise applications
Who are OMG?
OMG’s Milestones
OMG is
founded
1989
CORBA
2.0
1991
CORBA
1.0, IDL
1996
MDA
1997
UML, MOF,
XMI, CWM
2001
2. MDA Overview
What is the MDA?
 An approach to IT system specification
that separates the specification of
system functionality from the
specification of the implementation of
that functionality on a particular
technology platform
 “Design once, build it on any platform”
Basic concepts of MDA
 A model is a formal specification of the
function, structure and/or behaviour of a
system

Examples:
 Source code is a model
 An UML-based specification is a model
 Models of different systems are structured
explicitly into:
 Platform Independent Models (PIM)
 Platform Specific Models (PSM)
Platform Independent Model
(PIM)
 A “formal” specification of the structure
and function of a system that abstracts
away technical detail
 Expressed using UML
PIM: an example
Platform Specific Model (PSM)
 Specifies how the functionality specified
in a PIM is realized on a particular
platform
 Expressed using UML extended with
platform specific UML profiles
PSM: an example
MDA metamodel
Infrastructure
PIM Mapping
techniques
<<based on>>
Mapping from
PIM to PIM
UML
1..n
<<expressed with>>
MOF
1..n
<<described with>>
Metamodel
<<expressed with>>
1..n
<<independant of>>
1..n
1..n
Mapping from
PIM to PSM
<<expressed with>>
Other
languages
PIM
Refactoring from
PSM to PIM
<<based on>>
<<described with>>
1..n
PSM
PSM Mapping
techniques
<<depends on>>
1..n
Mapping from
PSM to PSM
MDA in a Snapshot
Vertical
Domains
Core
Technologies
Core Target
Platforms
Pervasive
Services
3. Developing in MDA
System Development Lifecycle
and the MDA approach
PIM to PIM
mappings
PSM to
PSM
mappings
UML MOF CWM
Time
PIM to PSM
mappings
(projection on a
specific platform)
Developing in MDA – Step 1:
the PIM (1/2)
 All MDA development projects start with the
creation of a PIM
 PIM at this level represents business
functionality and behaviour, undistorted by
technology details
 MDA application-modeling tools contain
representations of Pervasive Services and
Domain Facilities allowing them to be used
and/or incorporated in the application via a
menu selection
Developing in MDA – Step 1:
the PIM (2/2)
PIM
Calls
Calls
Pervasive
Services
Model
Domain
Facilities
Model
Developing in MDA – Step 2:
the PSM (1/2)
 Once the first iteration is complete, the
PIM is input to the mapping step which
will produce a PSM
 Code is partially automatic and partially
hand-written
 PIM can be mapped either to a single
platform or to multiple platforms
Developing in MDA – Step 2:
the PSM (2/2)
PIM
Maps to
CORBA
Model
Maps to
Java/EJB
Model
Maps to
…
Other
Model
Developing in MDA – Step 3:
Generating Application (1/2)
 An MDA tool generates all or most of
the implementation code for the
deployment technology selected by the
developer
 Re-integration on new platforms can be
done by reverse engineering the
existing application into a model and
redeploy
Developing in MDA – Step 3:
Generating Application (2/2)
PIM
Maps to
CORBA
Model
Maps to
CORBA
Maps to
Maps to
Java/EJB
Model
…
Maps to
Java/EJB
Other
Model
Maps to
…
Other
4. MDA in the Practice
MDA Adoption Status
 Adoption of MDA is at an early stage
 UML profiles underway:




CORBA (adopted)
EJB (adopted)
SOAP/XML (in process)
.NET (to be started)
 UML 2.0 in process
Future Trends
 “A market for MDA will be created as OO
modeling and development tool vendors
incorporate MDA into their offerings”
 “It will be two or three years before mature
MDA tools emerge”
 “This is the most exciting enterprise software
initiative I’ve seen since UML”
(Paul Harmon, Senior consultant and Market Analyst,
CUTTER consortium, 2001)
Early Adopters
 Interactive Objects Software GmbH

ArcStyler
 Kennedy Carter

iUML, iCCG
 Kabira

Adaptive Realtime Infrastructure
 Secant technologies

Model-Driven Infrastructure
Sun’s NetBeans was added to this list on
May 7th 2002
…stay tuned!
Conclusions (1/2)
 Abstracting out the structure and
behaviour of a system in the PIM makes
easier:



To validate the correctness of the model
To produce implementations on different
platforms
The application of tool supported solutions
Conclusions (2/2)
 The major drawback is that MDA does
not provide a standard for the
specification of mappings


Different implementation of mappings can
generate very different code or models
This can create dependencies between the
software and the mapping solution used
5. References
Bibliography (1/3)
 MDA Specification:

Model Driven Architecture specification, OMG
Architecture board, July 2001
 Introduction and overview of MDA:


Model Driven Architecture: An introduction, R.M.
Soley
Model Driven Architecture, Richard M.Soley (OMG
CEO), November 2000
 CWM and MOF definitions:

Model-Driven Architecture: Vision, Standards and
Emerging Technologies, John D.Poole, ECOOP
April 2001
Bibliography (2/3)
 CWM examples:

Enterprise CORBA 2001 – CWM, Pete Rivett
 System Development Lifecycle in MDA:

Developing in OMG’s Model-Driven architecture,
Jon Siegel, November 2001
 Middleware definition:

Software Engineering and Middleware: A
Roadmap, W.Emmerich
 The DoD survey on PLs:

A survey of Computer Programming Languages
Currently used in the DoD, A.Hook et al., 1995
Bibliography (3/3)
 Conclusions and future trends:


Pratical experiences in the application of
MDA, M. de Miguel et al.
MDA: An Idea whose time has come, Paul
Harmon
 Kennedy Carter’s xMDA:

F-16 Modular Mission Computer Application
Software, Lauren E.Clark et al.
Webliography
 MDA documentation:

http://www.omg.org/mda
 ArcStyler:

http://www.io-software.com/as
 Kennedy Carter’s iUML and iCCG:

http://www.kc.com
 NetBeans:

http://www.netbeans.org
The End
Platform
 Technological and engineering details
that are irrelevant to the fundamental
functionality of a software component
UML Profile
 A standardized set of extensions
(stereotypes and tagged values)
 Defines an UML environment tailored to
a particular use, such as modeling for a
specific platform

UML profile for CORBA was standardized in
2000
Common Warehouse
Metamodel (1/2)
 OMG’s data warehouse standard
 Enable easy interchange of
 warehouse and business intelligence metadata
between
 warehouse tools
 warehouse platforms and
 metadata repositories
 in distributed heterogenous environments.
 Defined using MOF
Common Warehouse
Metamodel (2/2)
 Comprised of a number of constituent
metamodels representing:




Data resources
Analysis
Warehouse management
Foundational components
of a typical data warehousing/business
intelligence environment
 Drawn using UML profile for MOF
More on CWM…
Example: the Relational
Metamodel
/constraint
/constrainedEl ement
CheckConstraint
*
deferrabi lity : DeferrabilityType
{ordered}
*
Column
*
/constrant
ColumnSet
precision : Integer
scale : Integer
/feature isNullable : NullableType
0..1
length : Integer
/owner
* col lationName : String
{ordered} characterSetName : String
/ optionScopeColumnSet : NamedColumnSet
/ referencedTableType : SQLStructuredType
*
/structuralFeature
/type
1
SQLDataType
typeNumber : Integer
NamedColumnSet
/ optionScopeColumn : Column
/ type : SQLStructuredType
/ usingTrigger : Trigger
SQLDistinctType
/constrainedEl ement
QueryColumnSet
query : QueryExpression
length : Integer
precision : Integer
scale : Integer
/ sqlSimpleType : SQLSimpleType
sqlDistinctType
*
*
SQLSimpleType
{ordered}
Table
isTemporary : Boolean
temporaryScope : String
/ trigger : Trigger
isSystem : Boolean
View
isReadOnly : Boolean
checkOption : Boolean
queryExpression : QueryExpression
characterMaximumLength : Integer
characterOctetLength : Integer
1
numericPrecision : Integer
sqlSimpleType numericPrecisionRadix : Integer
numericScale : Integer
dateTimePrecision : Integer
CWM: correspondances
between models
Area
Metadata
Data
Object
Oriented
Package
Class
Attribute
Extent
Object
Data
Value
Relational
Catalog/
Schema
Table
Column
RowSet
Row
Column
Value
RecordFile
RecordDef
Field
RecordSet
Record
Field
Value
ElementType
Attribute
Document
Element
Data
Value
Record
XML
Schema
MOF (Meta Object Facility)
 OMG’s standard for defining metamodels
 Provides standard modeling and interchange
constructs used in MDA
 UML and CWM are defined in terms of MOF
constructs
 The three main metadata modeling
constructs provided by the MOF are:
 Class
 Association
 Package
Mappings
 Mapping is defined as a set of rules and
techniques used to modify one model in
order to get another model
 Mappings are described using UML
Refining
 Makes a model less abstract
 Permits “zooming” in (and out of) a
model:
PIM to PIM mapping
 Used when models are enhanced,
refined or filtered during the
development lifecycle without needing
any platform dependant information

Example: analysis to design models
transformation
PIM to PSM mapping (1/3)
 This transformation is used when the PIM is
projected to the execution infrastructure
 Projection is based on platform characteristics
 These characteristics should be described
using a UML description (and eventually a
profile for describing common platform
concepts)
 There are multiple ways to transform a PIM
into a corresponding PSM
More on mapping
PIM to PSM mapping:
techniques (2/3)
 A human could study the PIM and:


Manually construct a platform-specific
model
Utilize models of known refinement
patterns to reduce the burden in
constructing the PSM
PIM to PSM mapping:
techniques (3/3)
 An algorithm could:


Be applied to the PIM and create a
skeleton of the PSM to be manually
enhanced by hand
Create a complete platform specific model
from a complete platform independent
model, explicitly or implicitly recording the
relation for use by other automated tools
PSM to PSM mapping
 This transformation is needed for
component realization and deployment
 Generally related to platform dependent
model refinement
PSM to PIM refactoring
 This transformation is required for abstracting
models of existing implementations in a
particular technology into a platform
independent model
 Represents a “mining” process hard to be
fully automated
 Result of this transformation will match the
corresponding PIM to PSM mapping
Infrastructure
 A set of software or hardware pieces
assumed to be already present by some
stakeholders when he/she develops a
software artifact
Core models
 The core target platforms of the MDA:
 CORBA
 Java/EJB
 C#/.NET
 XML/SOAP
 MDA provides UML profiles for these
target platforms
Pervasive Services
 Essential services for many applications
 transactions
 directory services
 security
 persistance
 others…
 OMG will define them at PIM level
OMG Domain Models
 Standardization of services in specific vertical
markets
 They will be in the form of normative PIMs
expressed using UML, augmented by
normative PSMs for at least one platform
 They are being developed by OMG’s DTFs
(Domain Task Forces)
The DoD survey of
programming languages
 Report on programming languages used in
the DoD (1995)
 In 1995 there were more than 2500 PLs
worldwide
Total SLOC by
gp third
generation
languages:
Ada 83
C 89
Fortran
CMS-2 Y
Jovial
C++
CMS-2 M
Pascal
PL/I
Basic
LISP
Cobol
Others
Some of the OMG members:










AT&T
BEA
Borland
Boeing
CA
Citigroup
Compaq
Ericsson
Ford
Fujitsu










Glaxo
HP
Hitachi
Hyperion
IBM
IONA
io Software
Kabira
KC
John Deere










Microsoft
MITRE
MSC Soft
NASA
NEC
NetGenics
NTT
OASIS
Oracle
Pfizer










Rational
SAGA
SAP
SAS
Secant
Siemens
Sprint
Sun
Unisys
Vertel
IoSoftware’s ArcStyler
ArcStyler Success Story
 Deutsche Bank Bauspar AG used
ArcStyler to embed existing COBOL
mainframe application into modern
web-based system
 A customized Cartridge was created
The KC’s xMDA approach
xMDA: eXecutable UML + MDA
xMDA Success story
 Lockheed Martin used MDA to develop
the F-16 Modular Mission Computing
software
 They used the KC’s iUML tool and more
recently iCCG (intelligent Configurable
Code Generator) to specify an Ada code
generator which can automatically
generate 100% of the implementation