AP4 – Introduction
to Model-Driven
Interoperability (MDI)
Learn about model-driven architecture
(MDA) and its application in developing
interoperable enterprise software
systems.
© 2005-2006 The ATHENA Consortium.
Course description
• Model-driven development (MDD), and in particular
OMG’s Model Driven Architecture (MDA), is emerging as
the state-of-the-art practice for developing modern
enterprise applications and software systems.
• The MDD paradigm provides us with a better way of
addressing and solving interoperability issues when
compared to earlier non-modelling approaches.
• The course gives an overview of interoperability and
MDA, and introduces the ATHENA Model-Driven
Interoperability (MDI) Framework, which provides
guidelines on how MDD can be applied to the
development of interoperable enterprise software
systems.
© 2005-2006 The ATHENA Consortium.
2
Course objective
• The participants will learn about interoperability
and MDA and get an overview of the ATHENA
MDI Framework.
• The courses AP5 and AP6 explores the MDI
framework in more detail.
© 2005-2006 The ATHENA Consortium.
3
MDI training track
No
Topic
Presenter
A
P
4
4-1
Interoperability & Model-Driven Architecture (MDA)
<Person>, <Company>, <Country>
A
P
5
5-1
ATHENA Model-Driven Interoperability (MDI) Framework
<Person>, <Company>, <Country>
5-2
Metamodelling
• Eclipse Modeling Framework (EMF) Tutorial / Exercise
<Person>, <Company>, <Country>
5-3
UML Profiles and Domain-Specific Languages (DSLs)
• Eclipse Graphical Modeling Framework (GMF) Tutorial
/ Exercise
<Person>, <Company>, <Country>
5-4
Method Engineering
• Eclipse Process Framework (EPF) Tutorial / Exercise
<Person>, <Company>, <Country>
5-1
Model Mappings and Transformations
• ATL Tutorial (optional)
• MOFScript Tutorial (optional)
<Person>, <Company>, <Country>
5-2
Model-Driven Development with PIM4SOA
<Person>, <Company>, <Country>
5-3
From PIM4SOA to Web Services
• PIM4SOA to XSD ATL Tutorial / Exercise
<Person>, <Company>, <Country>
5-4
From PIM4SOA to Agents
<Person>, <Company>, <Country>
5-5
From PIM4SOA to Peer-2-Peer (P2P)
<Person>, <Company>, <Country>
A
P
6
© 2005-2006 The ATHENA Consortium.
4
MDI website
http://www.modelbased.net/mdi
© 2005-2006 The ATHENA Consortium.
5
4-1. Interoperability
& Model-Driven
Architecture (MDA)
<Presenter>
<Company>, <Country>
<E-mail>
© 2005-2006 The ATHENA Consortium.
Outline
• Interoperability
• What is MDA?
• Standards and technologies
– OMG MDA standards
– Eclipse technologies
• MDA and interoperability
• Conclusive remarks
• References
© 2005-2006 The ATHENA Consortium.
7
Interoperability
© 2005-2006 The ATHENA Consortium.
8
Definition
Interoperability (def.) is “the ability of
two or more systems or components to
exchange information and to use the
information that has been exchanged”
– IEEE Standard Computer Dictionary
© 2005-2006 The ATHENA Consortium.
9
Rationale for interoperability
• Interoperability is the key to increase competitiveness of enterprises.
• “Enterprise systems and applications need to be interoperable to achieve
seamless operational and business interaction, and create networked
organizations” – European Group for Research on Interoperability, 2002
Application integration license revenue
System implementation budget
Misc.
20%
B$
Integration
40%
Hardware
10%
Imp.
Services
20%
Software
10%
The cost of non-interoperability are estimated to
(Source: the Yankee Group 2001)
© 2005-2006 The ATHENA Consortium.
40% of enterprises IT budget.
10
Knowledge integration
The originality of the ATHENA project is to take a multidisciplinary
approach by merging three research areas supporting the
development of Interoperability of Enterprise Applications and
Software.
– Architecture & Platforms: to
provide implementation
frameworks,
– Enterprise Modelling: to
define interoperability
requirements and to support
solution implementation,
– Ontology: to identify
interoperability semantics in
the enterprise.
© 2005-2006 The ATHENA Consortium.
Architecture
& Platforms
ATHENA
Enterprise
Modelling
Ontology
11
4-layered view of an enterprise
Business Operational Architecture
Operations
Strategy
Governance
Laws, rules,
principles
Agreed norms
and practices
Procedures
and routines
Business terms
Enterprise
methodology
Enterprise
models
Enterprise
templates
Metamodels
and languages
Product
models
Reference
architectures
Semantics
Enterprise Knowledge Architecture (EKA)
Dictionaries
Ontologies
Nomenclatures
Classifications
Information and Communication Technology (ICT) Architecture
Business and
user services
Infrastructure
services
EKA services
Ontology
tools
Software
platforms
Modeling
tools
Management
tools
Ontology
services
© 2005-2006 The ATHENA Consortium.
12
Holistic approach to interoperability
Enterprise A
Enterprise B
Application
ICT
Knowledge
Application
Data
Data
Semantics
Knowledge
Business
Semantics
Business
Interoperability (def.) is “the
ability of two or more systems
or components to exchange
information and to use the
information that has been
exchanged” – IEEE Standard
Computer Dictionary
Communication
To achieve meaningful interoperability between enterprises, interoperability must be achieved on
all layers:
– Business layer: business environment and business processes
– Knowledge layer: organisational roles, skills and competencies of employees and
knowledge assets
– ICT layer: applications, data and communication components
– Semantics: support mutual understanding on all layers
© 2005-2006 The ATHENA Consortium.
13
Interoperability challenges
Enterprise
model
Platform
independent
Model (PIM)
Platform
Specific
Model
Enterprise
model
AKM ii - EM
execution
platform
PIM execution platform
PSM execution platform
Enterprise model
interoperability
(UEML)
Ontology-.based
semantic
interoperability?
Web services
(Uddi, Soap)
Bpml, Bpel, Xpdl?
AKM ii - EM
execution
platform
Interoperability objective
Platform
independent
Model (PIM)
PIM execution platform
Platform
Specific
Model
PSM execution platform
Integrate enterprise models
across companies and EM
tools
Exchange information despite
semantic and syntactical
incompatibility
Enable enterprises to invoke
services (and processes
packaged as services) from
each other, and include remote
services in local processes
Network protocols
© 2005-2006 The ATHENA Consortium.
14
What is MDA?
© 2005-2006 The ATHENA Consortium.
15
Model-driven development (MDD)
CIM
Business
Context
Models
Model
transformation
PIM
Software
Specification
Models
Model
transformation
PSM
Software
Realisation
Models
© 2005-2006 The ATHENA Consortium.
Model-driven approach to system
engineering where models are used in
• understanding
• design
• construction
• deployment
• operation
• maintenance
• modification
Model transformation tools and services are
used to align the different models.
Business-driven approach to system
engineering where models are refined from
business needs to software solutions
• Computation independent model (CIM)
capturing business context and business
requirements
• Platform independent model (PIM)
focusing on software services
independent of IT technology
• Platform specific model (PSM) focusing on
the IT technology realisation of the software
services
16
OMG MDA
.
The current state of the art in ModelDriven Engineering (MDE) is much
influenced by the ongoing
standardisation activities around the
OMG Model Driven Architecture®
(MDA®).
•
•
MDA is a framework which defines a model-driven approach to software
systems development.
MDA encapsulates many important ideas - most notably the notion that
real benefits can be obtained by using visual modelling languages to
integrate the huge diversity of technologies used in the development of
software systems.
© 2005-2006 The ATHENA Consortium.
17
MDA from 30.000 feet (1)
• Use of platform independent models (PIMs) as
specification
• Transformation into platform specific models (PSMs)
using tools
© 2005-2006 The ATHENA Consortium.
18
MDA from 30.000 feet (2)
J2EE
.Net
• A PIM can be retargeted to different platforms
• Not the only reason why MDA might be of interest to
you…
© 2005-2006 The ATHENA Consortium.
19
Automation in software development
Requirements
Manually
implement
Requirements
Manually
implement
Requirements
Manually
implement
High-level spec
(functional and
nonfunctional)
Source in
domain-specific
language (DSL)
Compile
Source in a
general-purpose
language, e.g.,
Java or C++
Compile
Implementation
© 2005-2006 The ATHENA Consortium.
(may generate
code in
Java or C++)
Compile
Implementation
Source in
domain-specific
language (DSL)
Implement
with
Interactive,
automated
support
Compile
(may generate
code in
Java or C++)
Compile
Implementation
20
Goals
• The three primary goals of MDA are portability,
interoperability and reusability.
• The MDA starts with the well-known and long established
idea of separating the specification of the operation of the
system from the details of the way the system uses the
capabilities of its software execution platform (e.g. J2EE,
CORBA, Microsoft .NET and Web services).
• MDA provides an approach for:
– specifying a system independently of the software execution
platform that supports it;
– specifying software execution platforms;
– choosing a particular software execution platform for the system;
– transforming the system specification into one for a particular
software execution platform;
© 2005-2006 The ATHENA Consortium.
21
Basic concepts
•
System
–
–
•
Model
–
–
•
–
A viewpoint on a system is a technique for abstraction using a selected set of architectural
concepts and structuring rules, in order to focus on particular concerns within that system.
View
–
•
The architecture of a system is a specification of the parts and connectors of the system and
the rules for the interactions of the parts using the connectors.
MDA prescribes certain kinds of models to be used, how those models may be prepared and
the relationships of the different kinds of models.
Viewpoint
–
•
A model of a system is a description or specification of that system and its environment for
some certain purpose.
A model is often presented as a combination of drawings and text.
Architecture
–
•
Existing or planned system.
System may include anything: a program, a single computer system, some combination of
parts of different systems
A viewpoint model or view of a system is a representation of that system from the perspective
of a chosen viewpoint.
Platform
–
A platform is a set of subsystems and technologies that provide a coherent set of functionality
through interfaces and specified usage patterns, which any application supported by that
platform can use without concern for the details of how the functionality provided by the
platform is implemented.
© 2005-2006 The ATHENA Consortium.
22
Model-driven – a definition
• A system development process is model-driven if
– the development is mainly carried out using conceptual
models at different levels of abstraction and using
various viewpoints
– it distinguishes clearly between platform independent
and platform specific models
– models play a fundamental role, not only in the initial
development phase, but also in maintenance, reuse
and further development
– models document the relations between various
models, thereby providing a precise foundation for
refinement as well as transformation
© 2005-2006 The ATHENA Consortium.
23
MDA – Three main abstraction levels
•
Computation independent model (CIM)
– The computational independent viewpoint is focused on the environment of the
system and on the specific requirements of the system.
– A CIM represents the computational independent viewpoint.
– The CIM hides the structural details and, of course, the details related to the
targeted platform.
•
Platform independent model (PIM)
– A platform independent model is a view of the system from a platform independent
viewpoint.
– The platform independent viewpoint is focused on the operation of the system,
hiding the platform specific details.
– A PIM exhibits platform independence and is suitable for use with a number of
different platforms of similar types.
– The PIM gathers all the information needed to describe the behaviour of the
system in a platform independent way.
•
Platform specific model (PSM)
– A platform specific model is a view of the system from the platform specific
viewpoint.
– A PSM combines the specifications in the PIM with the details that specify how the
system uses a particular type of platform.
– The PSM represents the PIM taking into account the specific platform
characteristics.
© 2005-2006 The ATHENA Consortium.
24
Different abstraction levels and multiple PSMs
Business Modelling
language
Domain Model
Technology patterns
Application Modelling
Languages
Application
models
Coding patterns
Coding
languages
© 2005-2006 The ATHENA Consortium.
Application
25
PIM and PSMs
PIM: Platform Independent Model
PSM: Platform Specific Model
PSM: Platform Specific Model
PSM: Platform Specific Model
PSM: Platform Specific Model
UML
UML
and/or
platform
specific
notation
Platforms: Web Services, ebXML, J2EE/EJB, CORBA, MS .Net, …
© 2005-2006 The ATHENA Consortium.
26
Model-Driven Architecture
conformsTo
meta
Metametamodel
MOF
Metametamodel element
M3
meta
conformsTo
Metamodel element
M2
Metamodel
meta
System
M1
© 2005-2006 The ATHENA Consortium.
…
UML
metamodel
conformsTo
Model element
repOf
Relational
metamodel
…
…
Model
27
Model-Driven Architecture: Example
conformsTo
MOF Metametamodel
source
Association
Class
destination
conformsTo
Relational Metamodel
Table
Column
+ col
name: String + owner
*
{ordered}
name: String
+ key
+ keyOf 1..*
*
Type
+ type
name: String
*
conformsTo
Relational Model
System
repOf
BookId
Title
PagesNb
AuthorId
…
…
…
…
…
…
…
…
Book
© 2005-2006 The ATHENA Consortium.
28
Standards and technologies – OMG
MDA standards
© 2005-2006 The ATHENA Consortium.
29
MDA overview
Platform
Independent
Model
Model
composition
OMG domain models
Enterprise models
<<realize>>
Platform
Specific
Model
configuration
Enterprise
Deployment
Model
Versioned
repository
© 2005-2006 The ATHENA Consortium.
map
Platform-specific
artifacts
Non-normative
map
Enterprise and
supplier specific
configuration
Evolution management:
• Business, model, technology, deployment
30
MDA technology standards
•
Unified Modeling Language (UML)
–
–
•
Meta Object Facility (MOF)
–
–
–
•
XMI is a format to represent models in a structured text form.
In this way UML models and MOF metamodels may be interchanged between different
modelling tools.
Common Warehouse Metamodel (CWM)
–
–
•
MOF provides the standard modelling and interchange constructs that are used in MDA.
These constructs are a subset of the UML modelling constructs.
This common foundation provides the basis for model/metadata interchange and
interoperability.
XML Metadata Interchange (XMI)
–
–
•
UML is the de-facto standard industry language for specifying and designing software systems.
UML addresses the modelling of architecture and design aspects of software systems by
providing language constructs for describing, software components, objects, data, interfaces,
interactions, activities etc.
CWM is the OMG data warehouse standard.
It covers the full life cycle of designing, building and managing data warehouse applications
and supports management of the life cycle.
MOF Queries/View/Transformations (QVT)
–
The goals of the QVT are to provide a standard specification of a language suitable for
querying and transforming models which are represented according to a MOF metamodel.
© 2005-2006 The ATHENA Consortium.
31
Current MDA Architecture
Enterprise
modeling
expert
System
modeling
expert
System
realisation
installation
expert
© 2005-2006 The ATHENA Consortium.
OrgMM
CIM
models
ADM
QVT
BPDM
OWL
PIM
System
models
QVT
BSVR
Ontology
UML2.0
ODM
ADM
PSM
System
models
MOF2Txt
MOF2.0
ADM
System
XMI2.0
ATL
QVT MOFScript
(MOF2Txt) EMF Java API
MTF (IBM)
32
MDA products
•
Adaptive, Inc.Interactive Objects Software; ArcStylerAonix's AmeosKabira
Technologies, IncARTiSAN's Real-Time StudioKnowGravity's CASSANDRA b+m
ArchitectureWare Kennedy Carter Ltd: iUML and iCCGBITPlan GmbH
smartGeneratorLIANTIS XCoderThe Borland Approach to MDAM2VP's MDA
Consulting ServicesCalKey Technologies' CaboomMASTER Project Calytrix
Technologies' SIMplicityMetaMatrix CommitmentCodagen Technologies; Codagen
Architect 3.2Metamaxim's modelscopeCodeless Technology's CodelessMID's
InnovatorConsortium for Business Object PromotionThe MOD Group's MDA
ServicesConsyst's REP ++ StudioNeosight Technologies' BoldExpress
StudioCompuware OptimalJOCI's MDA Services Data Access Technologies (DAT)
Provides MDA ServicesObjectFrontier's FrontierSuite David Frankel Consulting Outline
Systems Inc.'s PowerRADDomain Solutions' CodeGeniePathfinder Solutions
PathMATEDot Net Builders' ConstructorPlastic Software's Agora Plastic
2005EDCubed's TETProject Technology's BridgePoint and DesignPointE2E
BridgerealMethods FrameworkGentastic's e-GENSelect Business Solutions' Select
Component FactoryM1 Global Solutions' MDEMia-Software's Model-In-ActionHendryx
& AssociatesSoftaris Pty. Ltd.: MetaBossHerzum SoftwareSoftMetaWare's Generative
Model Transformer project IBM's Rational Software ArchitectSofteam and
Objecteering/UML
An MDA CASE ToolIKV++ GmbH; m2c(tm)CARE Technologies S.A. / SOSY Inc's
OlivaNova Model Execution SystemI-Logix' RhapsodyTata Consultancy Services:
MasterCraftinnoQ's iQgenTelelogic's TAU Generation2 TechOne's ACE
•
See http://www.omg.org/mda/committed-products.htm
© 2005-2006 The ATHENA Consortium.
33
MDA success stories
• Looking Glass NetworksABB Research CenterLockheed MartinU.S.
Government Intelligence Agencyff-eCommerceSwedish
ParliamentThe Open System Architecture for Condition Based
Monitoring (OSA-CBM) ProjectSwisslog Software AGDeutsche Bank
Bauspar AGCGIUNextCarter Ground Fueling Ltd.BankHOSTPostgirot
Bank ABGothaer VersicherungenE-SoftSysAustrian RailwaysDanzas
Group Magnet Communications, Inc.National Services IndustriesHow
CodeGenie worked for AMSCredit SuisseM1 Global
SolutionsDaimlerChrysler
• See http://www.omg.org/mda/products_success.htm
© 2005-2006 The ATHENA Consortium.
34
Standards and technologies –
Eclipse technologies
© 2005-2006 The ATHENA Consortium.
35
MDA-compliant Eclipse technologies
•
Eclipse Modeling Framework (EMF)
–
–
•
Eclipse Graphical Editing Framework (GEF)
–
–
•
http://www.eclipse.org/gmf/
The Eclipse Graphical Modeling Framework (GMF) provides a generative component and
runtime infrastructure for developing graphical editors based on EMF and GEF.
Atlas Transformation Language
–
–
•
http://www.eclipse.org/gef/
The Graphical Editing Framework (GEF) allows developers to take an existing application
model and quickly create a rich graphical editor.
Eclipse Graphical Modeling Framework (GMF)
–
–
•
http://www.eclipse.org/emf/
EMF is a modeling framework and code generation facility for building tools and other
applications based on a structured data model.
http://www.eclipse.org/gmt/atl/
The ATL project aims at providing a set of transformation tools for GMT. These include some
sample ATL transformations, an ATL transformation engine, and an IDE for ATL (ADT: ATL
Development Tools).
Eclipse Process Framework (EPF)
–
–
http://www.eclipse.org/epf/
To provide an extensible framework and exemplary tools for software process engineering method and process authoring, library management, configuring and publishing a process.
© 2005-2006 The ATHENA Consortium.
36
Technology overview
OMG MDA specification Eclipse technology Comments
MOF
EMF
UML
UML
UML profile/DSL
GEF
GMF
QVT
ATL
SPEM
EPF
XMI
EMF
CWM
© 2005-2006 The ATHENA Consortium.
37
MDA and interoperability
© 2005-2006 The ATHENA Consortium.
38
MDA and interoperability (1)
• Interoperability from models point of view.
– MDA approach tries to build a interoperable model, from
enterprise models and processes to apply MDA mechanisms.
Arquitectura lógica: componentes e
interfaces (diagr. clases)
Capture user requirements
Diseñar la arquitectura lógica:
componentes e interfaces
PIM Context Definition
PIM Requirements Specification
PIM Analysis
ProcessPerformer
Enterprise B
model
Casos de uso implementados
(diagrama de casos de uso)
Interfaces ofrecidas por el componente
(diagrama de clases)
Diseño de la arquitectura
Especificar los componentes
y sus interfaces
Comportamiento de interfaces del
componente (diagrama de secuencia)
Design
Coding & Integation
Diseñar la arquitectura física
Especificación funcional de interfaces
(diagrama de actividad)
Enterprise
B external
model
Capture user requirements
PIM Context Definition
PIM Requirements Specification
Testing
Diagrama de despliegue
Deployment
PIM Analysis
Proceso de despliegue (diagrama de
actividad)
ProcessPerformer
Enterprise A
model
Design
Coding & Integation
Testing
Deployment
Model exchange
Arquitectura lógica: componentes e
interfaces (diagr. clases)
Capture user requirements
Diseñar la arquitectura lógica:
componentes e interfaces
PIM Context Definition
PIM Requirements Specification
PIM Analysis
ProcessPerformer
Enterprise A
model
Casos de uso implementados
(diagrama de casos de uso)
Interfaces ofrecidas por el componente
(diagrama de clases)
Diseño de la arquitectura
Especificar los componentes
y sus interfaces
Comportamiento de interfaces del
componente (diagrama de secuencia)
Design
Coding & Integation
Diseñar la arquitectura física
Especificación funcional de interfaces
(diagrama de actividad)
Enterprise
A external
model
Testing
Diagrama de despliegue
Deployment
Proceso de despliegue (diagrama de
actividad)
© 2005-2006 The ATHENA Consortium.
39
MDA and interoperability (2)
• Using transformations to get interoperability
– It allows document transformations on the fly.
– It can contribute to new approaches for semantic interpretations
on information exchanges.
Semantic repository
Enterprise A
Enterprise B
Document XA
Document XB
Transformation
© 2005-2006 The ATHENA Consortium.
40
MDA and interoperability (3)
• Interoperability as a quality of enterprise software
systems
• “Assure” to carry forward of interoperability
achieved/agreed on higher level down to infrastructure
(lower level).
• Verify higher level interoperability through simulation
• Alignment of models is enabled through common
metamodel
• Model-driven development is more flexible and adaptive.
© 2005-2006 The ATHENA Consortium.
41
Conclusive remarks
© 2005-2006 The ATHENA Consortium.
42
Conclusive remarks (1)
• The MDA approach promises to deliver portable,
interoperable and reusable software solutions.
• MDA pushes the goal of using visual modelling languages
to manage all aspects of systems development.
• It provides modelling and metamodelling technologies
which can be used to align different models.
• We see evidence that interoperability can be supported
by model transformations and metamodel alignment using
MDA technologies and standards.
• While success stories have been posted
(http://www.omg.org/mda/products_success.htm) and a
wide range of tools are available, one can still debate
whether MDA has really delivered on its promise.
© 2005-2006 The ATHENA Consortium.
43
Conclusive remarks (2)
• In our opinion, MDA is still immature and needs to be
improved in several areas:
– Key technologies such as the MOF Query/View/Transformation
(QVT) are still under finalization
(http://www.zurich.ibm.com/pdf/ebizz/gardner-etal.pdf).
– The “CIM”, “PIM” and “PSM” defined by MDA are causing
confusion. If we regard MDA as a conceptual framework that can
be used to develop concrete software development approaches
the terms make sense.
– Pushing UML as a “platform independent” way of doing modeldriven development. UML was not really designed for such a task
and needs to position itself amongst the emerging domain-specific
languages. A MOF-based metamodel approach could be taken
here to align models expressed in different modelling formalisms.
– Blind focus on generating implementations from higher-level
models. MDA needs to address the use of models and metadata
across the whole software lifecycle.
© 2005-2006 The ATHENA Consortium.
44
Approach to developing (1)
• The CIM, PIM and PSM models as defined by the OMG
MDA provide three coarse-grained abstraction levels for
describing and discussing the model-driven approach on
a conceptual level.
• For instance a model transformation is described as a
refinement from a PIM model to a PSM model.
• When we apply the MDA approach and develop a
concrete model-driven methodology the “CIM”, “PIM” and
“PSM” models are replaced by actual models.
• Furthermore, the methodology may define more than
three abstraction levels, as well as multiple and
overlapping model views.
© 2005-2006 The ATHENA Consortium.
45
Approach to developing (2)
• While the OMG MDA promotes UML as the visual “universal” glue
suitable for modelling everything, we are also seeing a trend towards
development and co-existence of several domain-specific modelling
languages, e.g. supported by the Microsoft Domain-Specific
Language (DSL) tools
(http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.
aspx).
• Such approaches are now also being discussed in various OMG
forums.
• UML is seen as a “general-purpose” language while DSLs may be
more expressive for most purposes.
• A model-driven framework needs to acknowledge the existence of
different models and views expressed in different modelling
languages.
• The MDA technologies can help us to align these models through a
common metamodelling language on which model transformations
and model mappings can be defined.
© 2005-2006 The ATHENA Consortium.
46
References
© 2005-2006 The ATHENA Consortium.
47
References (1)
[ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST507849). http://www.athena-ip.org/
[OMG] OMG, "OMG Model Driven Architecture", Object Management Group (OMG).
http://www.omg.org/mda
[OMG] OMG, "Unified Modeling Language (UML)", Object Management Group (OMG).
http://www.uml.org
[OMG] OMG, "Business Modeling & Integration DTF", Object Management Group (OMG).
http://bmi.omg.org/
[OMG] OMG, "Healthcare DTF", Object Management Group (OMG).
http://healthcare.omg.org/
[OMG 2001] OMG, "OMG Unified Modeling Language Specification Version 1.4", Object
Management Group (OMG), Document formal/01-09-67, September 2001.
http://www.omg.org/docs/formal/01-09-67.pdf
[OMG 2001] OMG, "Model Driven Architecture (MDA)", Object Management Group
(OMG), Document ormsc/01-07-01, July 2001. http://www.omg.org/docs/ormsc/01-0701.pdf
[OMG 2001] OMG, "UML Profile for Enterprise Distributed Components", IONA
Technologies, Inc., Rational Software Corp., SINTEF, ad/01-02-26, 2001.
© 2005-2006 The ATHENA Consortium.
48
References (2)
[OMG 2002] OMG, "Request for Proposal: MOF 2.0 Query / Views / Transformations
RFP", Object Management Group (OMG), Document ad/02-04-10, April 2002.
http://www.omg.org/docs/ad/02-04-10.pdf
[OMG 2002] OMG, "UML Profile for Enterprise Distributed Object Computing
Specification", Object Management Group (OMG), Document ptc/02-02-05, 2002.
http://www.omg.org/technology/documents/formal/edoc.htm
[OMG 2002] OMG, "UML Profile for CORBA Specification, Version 1.0", Object
Management Group (OMG), Document formal/02-04-01, April 2002.
http://www.omg.org/docs/formal/02-04-01.pdf
[OMG 2003] OMG, "MDA Guide Version 1.0.1", Object Management Group (OMG),
Document omg/03-06-01, June 2003. http://www.omg.org/docs/omg/03-06-01.pdf
[OMG 2003] OMG, "UML 2.0 Superstructure Specification", Object Management Group
(OMG), Document ptc/03-08-02, August 2003. http://www.omg.org/docs/ptc/03-0802.pdf
[OMG 2003] OMG, "Business Process Definition Metamodel - Request for Proposal",
Object Management Group (OMG), Document bei/03-01-06, January 2003.
http://www.omg.org/docs/bei/03-01-06.pdf
[OMG 2003] OMG, "UML 2.0 OCL Specification", Object Management Group (OMG),
Document ptc/03-10-14, October 2003. http://www.omg.org/docs/ptc/03-10-14.pdf
© 2005-2006 The ATHENA Consortium.
49
References (3)
[OMG 2003] OMG, "Meta Object Facility", Object Management Group (OMG), Document
ptc/03-10-04, 2003. http://www.omg.org/docs/ptc/03-10-04.pdf
[OMG 2003] OMG, "XML Metadata Interchange", Object Management Group (OMG),
Document formal/03-05-02, May 2003. http://www.omg.org/docs/formal/03-05-02.pdf
[OMG 2003] OMG, "UML 2.0 Infrastructure Specification", Object Management Group
(OMG), Document ptc/03-09-15, December 2003. http://www.omg.org/docs/ptc/03-0915.pdf
[OMG 2003] OMG, "Common Warehouse Metamodel (CWM), Version 1.1", Object
Management Group (OMG), Document formal/03-03-02, 2003.
http://www.omg.org/docs/formal/03-03-02.pdf
[OMG 2004] OMG, "Enterprise Collaboration Architecture (ECA) Specification, Version
1.0", Object Management Group (OMG), Document formal/04-02-01, February 2004.
http://www.omg.org/docs/formal/04-02-01.pdf
[OMG 2004] OMG, "MOF Model to Text Transformation Language Request for Proposal",
Object Management Group (OMG), Document ad/04-04-07, May 2004.
http://www.omg.org/docs/ad/04-04-07.pdf
[OMG 2004] OMG, "UML Profile for Modeling Quality of Service and Fault Tolerance
Characteristics and Mechanisms", Object Management Group (OMG), Document
ptc/04-09-01, September 2004. http://www.omg.org/docs/ptc/04-09-01.pdf
© 2005-2006 The ATHENA Consortium.
50
References (4)
[OMG 2004] OMG, "Meta Object Facility (MOF) 2.0 Core Specification", Object
Management Group (OMG), Document ptc/04-10-15, October 2004.
http://www.omg.org/docs/ptc/04-10-15.pdf
[OMG 2005] OMG, "Software Process Engineering Metamodel Specification, Version 1.1",
Object Management Group (OMG), Document formal/05-01-06, January 2005.
http://www.omg.org/docs/formal/05-01-06.pdf
[OMG 2005] OMG, "Meta Object Facility (MOF) 2.0 Query/View/Transformation
Specification", Object Management Group (OMG), Document ptc/05-11-01, November
2005. http://www.omg.org/docs/ptc/05-11-01.pdf
[OMG 2005] OMG, "MOF 2.0/XMI Mapping Specification, v2.1", Object Management
Group (OMG), Document formal/05-09-01, September 2005.
http://www.omg.org/docs/formal/05-09-01.pdf
© 2005-2006 The ATHENA Consortium.
51
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification
is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at rg@uninova.pt. In other cases please,
contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported
in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright
holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
© 2005-2006 The ATHENA Consortium.
52