Object to Model Paradigm Change with the OMGMDA Initiative' - PowerPoint PPT Presentation

Title: Object to Model Paradigm Change with the OMGMDA Initiative'


1
Object to Model Paradigm Changewith the OMG/MDA
Initiative.

• Jean Bézivin
• Université de Nantes - CRGNA
• Faculté des Sciences et Techniques
• 2, rue de la Houssinière BP 92208
• 44322 Nantes cedex 3, France
• Jean.Bezivin_at_sciences.univ-nantes.fr

2
Summary

• This presentation covers the new software
  development framework recently proposed by the
  Object Management Group. The Model-Driven
  Architecture departs from traditional
  code-centric approaches to explore new practical
  ways to separate platform-independent business
  models from platform-specific design and
  implementation models.

3
Main point of the presentation

• Objects everywhere
• The latest paradigm shift in software
  engineering
• Object technology
• to
• Model technology
• How did we arrive there so quickly?
• What are the short and medium-term consequences
  of this move?

Models
4
From object technology to model technology

• The new role of models and meta-models in the
  software lifecycle
• From Object-Oriented Programming to Ontology
  driven modelling
• From OMA to MDA
• From object composition to model transformation
• From implicit to explicit
• From contemplative to productive
• Seamlessness revisited
• Central message
• Model engineering is now ready for prime time

5
Dynamic importance of paradigms
How to deal with these evolving trends?

• Object
• Component
• Process
• Rules
• Services
• Model technology is able to subsume most of these
  paradigms (and others).

6
We lied about objects
"Because of the wonderful unifying properties of
the object paradigm, the transition from
procedural technology to object technology will
bring huge conceptual simplification to the
software engineering field. Since everything will
be considered as an object, we shall observe a
dramatic reduction in the number of necessary
concepts." All together, circa 1980
Object technology failed to achieve its
promises of simplification.
7
Models of increasing complexity
1980
1995
Procedural technology
Component technology
Object technology
Beans, Components, Containers, Packages, Interface
s, Use cases, Scenarii,Services, Frameworks, Appli
cations, Patterns, etc.
Objects, Classes, Methods
Procedures
8
Exact correspondence ?
NB What about persistance, GUI, etc. ?
NB M. Jackson who initially proposed this
principle never argued about exact
correspondence.
9
Where is the complexity of a system ?
1) inside objects ? 2) at the interfaces of
objects ? 3) elsewhere ?
(answer mainly outside objects) Pattern models
Architectural composition know-how models.
the system
10
Patterns are not objects
named relations from the GoF
11
Service or not service ?
Functional roots
Are services objects ?
Non stable architecture.
to be continued
12
AOP a well identified problem

• We have found many programming problems for which
  neither procedural nor object-oriented
  programming techniques are sufficient to clearly
  capture some of the important design decisions
  the program must implement. This forces the
  implementation of those design decisions to be
  scattered through-out the code, resulting in
  "tangled" code that is excessively difficult to
  develop and maintain. We present an analysis of
  why certain design decisions have been so
  difficult to clearly capture in actual code. We
  call the properties these decisions address
  aspects, and show that the reason they have been
  hard to capture is that they cross-cut the
  system's basic functionality. We present the
  basis for a new programming technique, called
  aspect-oriented programming, that makes it
  possible to clearly express programs involving
  such aspects, including appropriate isolation,
  composition and re-use of the aspect code.

Gregor Kiczales, John Lamping, Anurag
Mendhekar, Chris Maeda, Cristina Videira
Lopes, Jean-Marc Loingtier, John Irwin.In
proceedings of the European Conference on
Object-Oriented Programming (ECOOP), Finland.
Springer-Verlag LNCS 1241. June 1997.
but complex solutions
13
AOP the code as unique reference
Optimisation directives
Algorithms
Debugging directives
preconditions postconditions
Synchronization
Exceptions
Organization code (include, etc.)
Executable code
14
There is no unique minimal object "model"
?
The quest for the Holy Grail has stopped.
X3H7 matrix study The intersection is empty
15
Conclusion

• OT (Object Technology) has got to answer many
  difficult problems since its initial industrial
  discovery in the 80's.
• Generally OT did not succeed to find good
  internal solutions to these challenges.
• As a consequence, the proposed solutions are
  often ad-hoc, informal, and even baroque. They
  are are difficult to generalize and hard to
  combine. They often don't scale up.

Use cases
Patterns
Object Technology
Aspects
etc.
16
Conclusion

• MT (Model Technology) seems to be in a position
  to meet some of these challenges to which OT was
  not able to find an internal solution.
• Among these we may quote
• Aspect separation
• Homogeneous handling of functional and
  non-functional attributes
• Integration of different points of view (rules,
  services, processes, architecture, etc.)
• MT seems able to subsume OT and to offer a
  realistic migration path from present object and
  component solutions to more ambitious
  organizations.

MT
Services
Patterns
Use cases
OT
QoS
Applications
Rules
etc.
Aspects
Processes
17
Intro to MDA Outline

• The end of the middle-war(e)
• From OMA to MDA the new OMG vision
• Visiting the model space
• What is a model?
• What is a meta-model?
• The MOF and the four-level model stack
• Hopes and dangers of the MDA.

18
The middleware war is over
HTTP HTML
COM DCOM

• There is no clear winner nor loser
• The next battlefield will be model transformation
• The OMG's Model Driven Architecture (MDA)
  initiative is aimed at using modelling and
  meta-modelling to drive the design and
  implementation of distributed systems.

Sun's Java EJB
Microsoft C DotNet
CORBA IIOP
Sun's reaction to C DotNet ?
XML SOAP
the next wonderful Middleware platform (2005)
19
MDA The new OMG vision

• OMG is in the ideal position to provide the
  model-based standards that are necessary to
  extend integration beyond the middleware
  approachNow is the time to put this plan into
  effect. Now is the time for the Model Driven
  Architecture.
• Richard Soley and the OMG staff,
• MDA Whitepaper Draft 3.2
• November 27, 2000

20
Angry end-users
We don't want anymore to pay such a high price
for simply moving our information system to a
new middleware platform (COM, CORBA, Java, HTML,
XML, DotNet, etc.) when our business system stays
stable. We are prepared to pay a last price for
building the abstract models of our business and
services that will guarantee us against
technological obsolescence. From there, any
platform provider will also have to provide the
mapping solutions from standard business models
before we buy.
21
The sequence has no end

• It's difficult -- in fact, next to impossible --
  for a large enterprise to standardize on a single
  middleware platform. Some enterprises found
  themselves with more than one because their
  different departments have different
  requirements, others because mergers or
  acquisitions created a mix. Even the lucky
  enterprise with a single middleware choice still
  has to use other technologies to interoperate
  with other enterprises and B2B markets.
• The middleware environments that are most visible
  today are CORBA, Enterprise JavaBeans,
  messageoriented middleware, XML/SOAP, COM and
  .NET. However, over the past decade or so, the
  middleware landscape has continually shifted. For
  years we've assumed that a clear winner will
  emerge and stabilize this state of flux, but it's
  time to admit what we've all suspected The
  sequence has no end! And, in spite of the
  advantages (sometimes real, sometimes imagined)
  of the latest middleware platform, migration is
  expensive and disruptive. (We know an industry
  standards group that, having migrated their
  standard infrastructure twice already, is now
  moving from their latest platform du jour to
  XML.)
• from Richard Soley and the OMG staff,
• MDA Whitepaper Draft 3.2, November 27, 2000

22
Mapping to multiple and evolutive platforms

• MOF along with UML is a core technology for MDA.
• Technology neutral models of systems can be
  mapped to implementations that use a variety of
  middleware technologies.

UML and MOF compliant platform independant models
COM DCOM
Java EJB
HTTP HTML
C DotNet
CORBA
XML SOAP
23
The next steps

• CORBA was a powerful first step, but we have more
  steps to take.
• Fred Waskiewicz,
• OMG Director of Standards

24
Some of the OMG successes

• 1. CORBA
• 2. IDL
• 3. IIOP
• 4. UML
• 5. MOF
• 6. XMI
• 7. CWM
• 8. UPM/SPEM

yesterday
OMA
today
?
tomorrow
MDA
25
OMG is very good at creating consensus
Academic cycle 1 m/y (e.g. ECOOP) Industrial
cycle 5 m/y (e.g. OMG)
Board Approval
DTC or PTC Recommendation
Final AB Review
Evaluation
RFI
RFP
AB Review (Architecture Board)
(IDL is the consensus definition language)
DTC Domain Technical committee. PTC Platform
Technical committee.
Task Force
26
Compare code-centric and model-centric approaches
MDA OMA
IDL --gt UML
27
From OMA to MDA
2000
1980
1995
Procedure technology
Component technology
Object technology
Model technology
Objects, Classes, Smalltalk, C, ...
Procedures, Pascal, C, ...
Packages, Frameworks, Patterns,
Models, Meta-Models, UML, MOF, XML, XMI, XSLT,
Procedural refinement
Object composition
Model transformation
28
Models Everywhere
Business model
Business processes
Test model
Performance model
Development process model
User model
Design model
Cost model
Workflow model
Agent model
Resource model
29
The global model space

• The development software cycle is populated with
  models
• Models are of unequal importance
• The model space is structured
• Models are linked in a complex organization
  network
• The content of each model is defined
  (constrained) by a corresponding meta-model
  (ontology)
• The model space is constantly broadening starting
  from the essential models (Domain, Service,
  Resource)

30
Each model has different characteristics

• A Smalltalk coding model only offers single
  inheritance, but also explicit anonymous
  meta-classes.
• An Eiffel coding model has a different form of
  inheritance and several extensions (contracts,
  etc.). It has also specific "client" relations
  between classes.
• A Java or C coding model has two notions of
  inheritance, corresponding to the class and
  interface categories.
• A C coding model allows cross-language
  inheritance
• A workflow model is built from basic tasks.
• A usage model contains the concepts of actors,
  use-cases and several relations like
  specialization of use-cases.
• etc.

31
Consequence having to deal simultaneously with
several models of different semantics
UML model
Java model
32
UML opened the road,several roads indeed...
From Object-Oriented Programming to Model-Based
Software Engineering.
product and process models model engineering
OMT
UML/MOF
SA/RT
SADT
ERD
Merise
DFD
etc.
JSD
33
The roadmap
Procedural ADM
Method notation process tools
Unified Method impossible
OOADM e.g. OMT
11/1997
07/2001
UML
UPM SPEM
profiles other MMs
specific processes (RUP, IBM SI, etc.)
Model weaving
gt2001
Network of models
34
UML Creation of a consensus at OMG
UML 1.4
UML 2.0
november 1997
creation of UML-RTF
Industrialization
Submission of UML 1.0 to OMG for adoption
(january 1997).
UML 1.0
Standardisation
UML 0.9 0.91
(june 96 - oct. 96)
UML partners expertise
public feedback
Unification
OOPSLA95 Unified Method O.8
Booch 93
OMT-2
Fragmentation
Other methods
Booch 91
OOSE
OMT-1
35
UML a cocktail of well-known ingredients.
State Diagrams
Use cases
Class Diagrams
ERD
etc.
36
Projections
System functions, from a user view
Objects and basic relations between these objects.
Representation of behavior in term of states.
Representation of objects, of their mutual links
and potential interactions.
Physical components of an application
Schemas of component installation on hardware
devices.
Representation of operation behavior in terms of
actions.
Representation of objects and their temporal
interactions.
Class static structure and relations between
these classes.
37
Fragments of a UML meta-model
not 1.4
UML
38
Three stages in the evolution of modeling
techniques at OMG.
(a)
(c)
(b)
MOF
UML
MOF
UML
PWG
Workflow
etc.
UML
aModel
Common Warehouse Metadata Interchange
UML_FBO
aModel
Action language
aModel
39
Egyptian architecture
Inspired by IRDS, CDIF, etc.
M3
The MOF
meta-meta model
The UML meta-model and other MMs
M2
meta-model
Some UML Models and other Ms
M1
model
Various usages of these models
M0
"the real world"
40
Multiple meta-models
MOFClass
UMLClass
JavaClass
UMLParticipant
JavaParticipant
Peter Smith
Peter Smith
41
The OMG/MOF Meta-Model Stack
- One unique Meta-Meta-model (the MOF) - An
important library of compatible Meta-Models -
Each of the models is defined in the language
of its unique meta-model
42
OMG the software bus and the knowledge bus.
Java
CORBA, IDL, IIOP,...
Cobol
C
UML
CWM
MOF, UML, XML,...
Workflow
UPM
43
The on-line separate models organization
(aspect-oriented software engineering)
Usage model (Use Cases)
Test model
Domain model
Resource model
Design model
Common BUS (e.g. CORBA or DotNet UML MOF
XMI)
Execution model
Architecture model
Deployment model
First-class independent models and meta-models
44
A theory of models for the MDA?

• What are the theoretical tools that could be
  useful in model engineering?
• What help can they provide with the MDA effort?
• Main answer Ontologies (Gruber, Guarino, etc.)
• Concrete translation the four-levels OMG
  modeling stack

45
Systems and models

• A model M is a simplified representation of the
  world, as a matter of fact of only a part S of
  the world called the system.

M
M1 (the modeling space)
isRepresentedBy
M0 (the world)
S
46
Aspect-Oriented Modeling is a Pleonasm

• Obviously a given system may have plenty of
  different models.
• Each model represents a given aspect of the
  system.
• AOM (Aspect-Oriented Modeling) is a pleonasm.

Ma
Mb
Mc
M1
isRepresentedBy
M0
S
47
Limited Substituability Principle

• The purpose of a model is always to be able to
  answer some questions in place of the system,
  exactly in the same way the system itself would
  have answered similar questions.

48
Meta-Model
M
S
M
The correspondence between a model and a
system is defined by a meta-model.
49
Meta-models and ontologies

• Ontologies bring
• Abstraction
• Consensus and sharing

50
Layered ontologies
Concepts and Relations e.g. UML diagrams
terminological
assertional
pragmatical
e.g. OCL statements
e.g. How to draw a class? presentation issues,
etc.
51
Abstract Syntax Systems Compared
Technology 2 (MOF OCL)
Technology 3 (XML Meta-Language)
Technology 4 (Ontology engineering)
Technology 1 (formal grammars attribute
grammars, etc.)
M3
A XML DTD Or Schema
EBNF
Upper Level Ontologies
MOF
M2
Pascal Language Grammar
The UML meta-Model
A XML document
A XML DTD or Schema
KIF Theories
Description Logics Conceptual Graphs etc.
M1
A specific Pascal Program
A XML document
A Specific UML Model
Xpath, XSLT RDF, OIL, DAML etc.
A specific execution of a Pascal program
A Specific phenomenon corresponding to a UML Model
XMIMOFXMLOCL Model serialisation
from contemplative to productive.
52
UML/XML Convergence
UML
XML
MOF/XMI story of a convergence
53
Explicit product and process meta-models.
MOF
UML
Wfl
?

UPM

Java
CORBA
54
Growing Importance of Process Consideration

• Different sort of processes
• Business process, Workflow
• Software development processes
• Software Maintenance Processes
• Information System Migration Process
• etc.
• When the complexity of product increases, it is
  necessary to carefully consider and define the
  process aspects
• e.g. software components (EJB, COM, etc.)
• Who is in charge of the interface definition, of
  the implementation, of the adpatation, etc.
• e.g. QoS considerations (performance,
  reliability, etc)
• When should we consider these non functional
  requirements? Before or after the functional
  requirements (UML)? Mixed?

55
Back to MDA PIMs and PSMs

• MDA models
• PIM Platform Independent Models
• Formal specification of a system that abstracts
  away technical detail
• Example Billing system expressed in UML
• Platform models
• e.g. of component constructs (CCM), of Eiffel,
  C, EJB,
• PSM Platform Specific Models
• Expressed in terms of the specification model of
  the platform
• Example Billing system expressed in "UML profile
  for CORBA"

56
Back to MDA PIMs and PSMs

• OMG standards are specified in terms of a PIM and
  normally one or more PSMs, all in UML.
• The MDA defines consistent relationships across
  these models.
• It makes it easier to produce implementations on
  different platforms while conforming to the same
  essential and precise structure and behavior of
  the system.
• As a consequence, the business model may define
  business goals and policies in a computation
  independent manner.

57
Development cycle old and new
Analysis
Design
Code
4
7
PIM
PSM
Code
5
2
1
3
6
58
Write once, run everywhereModel once, Generate
everywhere
Platform-Independent Model
Multi-target code generation
PIM
etc.
data grid computing pervasive computing cluster
computing
CORBA
SMIL/Flash
Java/EJB
C/DotNet
Web/XML/SOAP
SVG, GML, Delphi, ASP, MySQL, PHP, etc.
59
Tooling the MDA Sample

• Adaptive's Framework http//www.adaptive.com/
• France-Telecom Universalis http//universalis.elib
  el.tm.fr/
• Codagen Gen-it http//www.codagen.com/
• Codigo CodigoXpress http//www.codigoxpress.com/
• DSTC dMOF http//www.dstc.edu.au/Products/CORBA/MO
  F/
• Interactive Objects ArcStyler http//www.io-softwa
  re.com/
• Kabira Business Accelerator http//www.kabira.com/
  
• Kennedy Carter iUML and iCCG http//www.kc.com/
• Metamatrix MetaBase http//metamatrix.com/
• NetBeans Meta Data Repository MDR
  http//www.netbeans.org/
• ONTOS ObjectSpark http//www.objectspark.com/
• ObjectRad Java Metadata Server http//www.objectra
  d.com/
• ObjeXion Software Netsilon http//www.netsilon.com
  /
• Project Technology BridgePoint/DesignPoint
  http//www.projtech.com/
• Secant Technologies ModelMethods
  http//www.modelmethods.com/
• Soft-Maint Scriptor Semantor http//www.sodifran
  ce.fr/
• Tata Research Development ADEX http//www.tcs.com/
  
• University of Berne MOOSE http//www.iam.unibe.ch/

and much more
60
Hopes and Dangers of the MDA

• Some hopes
• Ontology-Driven transformations
• Combining MP and MM
• Some dangers
• Confusing model of the problem and model of the
  solution
• UML executability

61
Revisiting the Y cycle
PIMs (Platform Independent Models)
Merging/binding phase
PSMs (Platform Specific Models)
PDMs (Platform Description Models)
62
A typology of models

• Product vs. Process
• Executable vs. Non Executable
• Atomic vs. Composite
• Primitive vs. Derived
• Transient vs. Essential
• Pivot models
• Functional vs. Non Functional
• PIM vs. PSM vs. PDM vs. CIM
• Architecture, Pattern, Know-how
• Legacy
• Test
• Code
• etc.

63
Examples

• Transient vs. essential models
• used as a temporary relay between a source and a
  target model
• an essential model is stored a transient model
  is disposable
• source and target models may be transient or
  essential
• Pivot model
• Similar to a transient model, but plays a
  particular role
• Backward and forward process
• Many to many correspondence

64
Examples PDM

• What is a platform model?
• model
• of the (operating) system?
• of the middleware?
• of the language?
• Java Syntax
• Byte code
• of the machine
• RISC assembler?
• Micro-machine levels?
• of the components?
• EJB
• CCM
• Generic component model
• of the technology (RM/ODP)?
• of the architecture (distributed architecture)?
• etc.

65
A typology of operations

• Ops on Models vs. Ops on Meta-models
• Monadic operations on M MM
• op(m)
• Dyadic operations on M MM
• op(p,q)
• 2 arities operations on MMM
• op(a,b,c,)
• Monadic or dyadic with result
• m3 op (inout m1, in m2)

66
TOOLS

• TOOL implementation of a generic set of
  operations
• exemples
• Rational Rose
• Microsoft VISIO 2002 Modeler
• Argo UML
• Objectering
• Together
• etc.
• Importance of precisely defining the exact
  capacity of tools in terms of the set of
  supported operations.
• Examples of supported operations
• Model navigation
• Code generation
• Model import/export

67
Monadic operations

• Display
• Serialization
• Storing
• Creation, Modification, Browsing
• Extension
• Reduction
• Measure
• Verification
• Normalization
• Rapid prototyping
• Code generation

68
Dya dic operations

• Comparison
• Confrontation
• Transformation
• Fusion
• Alignment

69
Transformation operations

• Inversible transformation (no loss)
• Optimisation
• Abstraction level
• Formalism (Maude, Prolog, XSLT, etc.)
• Reversibility Trace production
• Traceability

70
Endogeneous transformations
T
sem
sem
source
cible
71
Exogeneous transformations
T
sem
sem
source
cible
72
UML profiles

• A UML profile is a grouping construct for UML
  model elements that have been customized for a
  specific domain or purpose using extension
  mechanisms such as stereotypes, tagged values and
  constraints. For example, the UML Profile for
  CORBA RFP customizes UML for specifying CORBA
  IDL.
• A meta-model defines a domain-specific language.A
  profile is a variant of a meta-model. It allows
  to define a dialect of a given language. There
  are a dozen of UML profiles that are currently
  being defined.

73
Two main kind of tools

• Meta-Model Based
• MOFXMI
• Set of communicating specialized tools
• Incomplete coverage of various operations
• Adpatable
• Performing well on some particular problems
• Profile-Based
• UML 2.0
• Monolithic, covering the whole spectrum
• UML CASE tools

74
IBM Initiative EUM

• Eclipse Universal Modeler
• Since the introduction and wide spread use of the
  Unified Modeling Language (UML) , there has been
  increased interest in and usage of object
  oriented modeling software, such as Rational Rose
  and Together ControlCenter for general
  development projects and i-Logix Rhapsody for
  real time and embedded systems. While developers
  have found these software products helpful, their
  use has limits. One significant limiting factor
  is the necessarily generic syntax of UML. UML was
  created to be a general purpose object oriented
  modeling language, and therefore does not address
  domain-specific needs. While there are extensions
  mechanisms in UML, their power is limited, and
  tool support for the features that those
  mechanisms supply is negligible. To allow
  object-oriented modeling to become truly useful
  in complex technology domains such as transaction
  systems, messaging systems, and web services, and
  in specialized business domains, there must be
  tool support which allows for the definition of
  meta-models and diagrams which are as visually
  and logically expressive and specific as the
  domain demands, and are shareable across teams
  and organizations in a domain. Such tool support
  must be standards based to allow for easy
  transfer of intellectual assets and to encourage
  widespread adoption.

75
IBM Initiative EUM

• To meet this need, we have begun work on the
  Eclipse Universal Modeler (EUM). Using the
  Eclipse tooling platform and a number of open
  standards (XMI, MOF, and SVG), EUM allows
  individuals or organizations to define
  meta-models and diagram types which can be
  encapsulated in an Eclipse plug-in and shared
  across teams and organizations. EUM plug-ins can
  build on top of one another, and reuse and extend
  each other's meta-models, diagram definitions,
  etc.
• EUM uses XMI , the XML standard for meta-date
  interchange, as its meta-model file format, and
  the IBM implementation of the OMG's MOF standard
  at run-time to define and extend meta-models. The
  W3C's SVG (Scalable Vector Graphics) XML 2D
  graphics standard is used to define all diagrams
  and diagram members. By using accepted standards
  from end to end, we create an easy path to
  adoption and maximum interoperability with
  existing tools, and encourage others to build on
  top of our work to add value to our offering.

76
IBM Initiative EUM

• Another limiting factor in current tool use is
  inconsistencies among diagrams. Developers create
  many diagrams describing a system and
  inconsistencies often appear across the set of
  diagrams. EUM takes a significant step towards
  solving this problem by rendering diagrams
  directly from the meta-models they are based on.
  While visual diagram information (location of
  elements on the screen, what elements are present
  in the diagram, etc.) will be stored separately,
  all object information will be stored as
  instances of the classes of the meta-model being
  used, and these objects will be shared across all
  of the diagrams of a given project. Simply put,
  EUM's diagrams are meta-model based (as
  recommended in "Nine Suggestions for Improving
  UML Extensibility", Dykman et.al., LNCS 1723).
• After supporting custom meta-models and diagrams
  and stated above, EUM will be developed further
  to support artifact generation. Artifacts can be
  code, documentation, or any other thing which
  users view as a desirable output. Because of the
  open plug-in based architecture of EUM, artifact
  generation plug-ins will be reusable across
  multiple meta-modeling and diagramming plug-ins.

77
UML 2.0 not a language, but a family of
languages

• UML 2.0 Infrastructure RFP - - A UML 2.0 RFP
  issued September 15, 2000 that is primarily
  concerned with architectural alignment,
  restructuring and extension mechanisms.
• UML 2.0 Superstructure RFP - - A UML 2.0 RFP
  issued September 15, 2000 that is primarily
  concerned with the refinement and extension of
  UML 1.x semantics and notation.
• UML 2.0 OCL RFP - - A UML 2.0 RFP issued
  September 15, 2000 that is primarily concerned
  with with defining an OCL metamodel.
• UML 2.0 Diagram Interchange RFP - - A UML 2.0
  RFP issued March 2, 2001 that is primarily
  concerned with defining a metamodel for diagram
  interchange using the XMI facility.

from "Will UML 2.0 Be Agile or Awkward?" by Cris
Kobryn
78
The roadmap to model engineering

• 12 years for CORBA 3 to mature (gt2015)
• Probably more for the MDA
• Tools will be needed in the meantime
• Sort/medium/long term issues
• Manual/Automatic code generation

0
100
79
An impression of "déjà vu"

• The forms of development of model engineering in
  the 2000's are strangely similar to the forms of
  development of object engineering in the 1980's
• Many evangelists
• Few tools

80
An impression of "déjà vu"

• Arguments against
• It will not work
• It is very expensive
• It is not efficient
• It will change too much our current working
  habits
• ROI is not guaranteed
• Educational changes are huge
• Organizational opposition is likely build up
• and much more

81
An impression of "déjà vu"

• What happened to organizations that resisted the
  move to object orientation in the 1980's?
• Choosing not to move is also choosing
• There is a risk for premature change
• There is a risk for delayed change
• The reasonable solution is to apply to the
  migration to model engineering solutions that
  were found successful in the migration to object
  engineering
• Start education as soon as possible
• Select non strategic projects and find motivated
  staff to work on them
• Disseminate the results of these pilot projects
  and progressively integrate into enterprise
  culture

82
Object vs. modelsis only part of the debate
Interpretative approaches
MDA
Dist. OS Middleware
OS
Transformational approaches
compiler compiler's
1950
1975
2000
2025
83
La prose de Monsieur Jourdain

• Like in other important evolutions, many people
  will soon recognize that they were applying MDA
  ideas before MDA times
• A new idea is often an explicitation of good
  practices already applied by clever engineers.
  The explicitation will allow other engineers to
  apply these ideas as well.
• This is probably true many people were already
  moving to transformational approaches hint the
  number of lines of Java code hand-written vs.
  generated
• MDA will be successfull if it allows old good
  techniques to be integrated in a general regular
  framework.
• Example many ideas in DBMS (e.g. schema
  integration, etc.) or in VHDL, hardware/software
  co-design, etc. may be injected in MDA.

84
MDA beyond the buzzword

• Modern model engineering techniques are ready for
  prime time in software engineering.
• They are based on
• A four level architecture (31)
• A unique meta-meta-model (MOF),
• with transfer and exchange mechanisms
• with transformation mechanisms
• with standard projection mechanisms on a variety
  of middlewares (CORBA first, Java and DotNet
  next, )
• A grawing collection of specialized meta-models
  (evolutive)
• Object meta-models (Java, CLR, etc.)
• Legacy meta-models (Relational, CWM)
• Enterprise meta-models Business objects,
  Healthcare, Transportation, Process Rules, and
  much more
• Product an process meta-models (e.g. workflow,
  RUP)
• Automatic and semi-automatic generation tools,
  from high abstraction standardized models to
  various middleware platforms will progressively
  appear in the coming years.

85
Yet another silver bullet technology?

• MDA is not a new technology, but
• a way to deal with new emerging technologies like
  Web services in a smooth way,
• progressively integrating yesterday's legacy
  (Cobol, RPG, ADA, PL/1, Pascal, etc.), today's
  developments (Java, CORBA, etc) and tomorrow's
  ideas (Web services, Grid computing, Cluster
  computers, etc.) into a global consistent
  strategy for the management of constantly
  evolving information system
• MDA is about integration and evolution management

86
The challenge of complex systems

• Systems are becoming more complex
• The source of complexity is multiple
• Volume
• Data
• Code
• Evolutivity
• Business
• Platform
• Heterogeneity
• Operating systems and Middlewares
• Languages
• Paradigms (procedures, events, objects, services,
  rules, etc.)
• Network, Databases, etc.
• MDA is proposing a global management of
  complexity

87
Dimensions of variations

• MDA will provide a basic technical approach and
  basic tool and mechanisms supports to tackle the
  representation of variations.
• As explained by DSouza, MDA addresses three main
  conceptual dimensions of variations
• vertical different level of abstraction of the
  same subject of a system, from physical data,
  logical data models, middleware, applications
  specifications, component assemblies, business
  process models, business goals and strategies
• horizontal different subject areas or views
  that are not, of themselves, more or less
  abstract than others, whether business (like
  marketing, engineering, and sales, ) or
  technology (like performance, security, fault
  tolerance, )
• variant different systems, legacy, ongoing and
  upcoming, as-is, as-was and as-could-be,
  including variants that arise within a family of
  related systems configured to different needs.
  This is technically similar to horizontal
  variation, but is more concerned with
  configurations, variants, evolution and
  evolution-focused architectural rules and
  modeling standards.

88
Claims (hopes)

• MDA is (should be) able to manage
• Application genericity, extensibility,
  adaptability, etc.
• Aspect separation and weaving
• Product/process separation and weaving
• Functional/non-functional separation and weaving
• Cross paradigms interoperability (objects, rules,
  processes, ,services, roles, etc.)
• Legacies of various ages, including most extreme
• Feature interaction and dependencies
• Business description service specification
  platform definition
• Relations between requirement and implementation
• Descriptions of various contexts (user, customer,
  platform, paradigms, environment, etc.)

89
MDA helps you to move

• From implicit to explicit
• From explicit to precise
• From precise to formal
• From formal to computable
• From computable to automatizable

90
MDA good impact

• Obliges people to define precisely
• What is a platform?
• When is a platform a refinement of another
  platform? (Java, Bytecode, EJB, etc.)
• What is a design? (set of design decisions)
• What is an application, an entry point, an
  extension, a product, a product line, etc.
• etc.

91
Conclusion

• Model engineering is the future of object
  technology
• As object and classes were seen in the 80's as
  "first class entities", with libraries of several
  hundred of classes hierarchically organized,
  models and meta-models are beginning to be
  considered alike in the 2000's.
• Libraries (lattices) of hundreds of meta-models
  (ontologies) of high abstraction and low
  granularity are beginning to appear. Each such
  meta-model may contains several hundreds of
  concepts and relations.
• Tools will be needed to work with these vast
  libraries of models and meta-models.
• This will have a rapid impact on the daily work
  of the information engineer.
• More research is urgently needed to bring
  together the people involved in the theory and
  practice of model engineering (ontologists,
  methodologists, software practitioners,
  information system builders, database
  specialists, etc.).

92
Conclusion

• MDA is probably not the silver bullet for
  software engineering,
• but
• There is no reasonable alternative to MDA
• Decoupling the business part and the technical
  part of information systems is a long term trend.