Using%20MDA

1
Using MDA for designing and implementing
Web-based applications
ICWE'04

• Nathalie Moreno and Antonio Vallecillo
• Universidad de Málaga
• Dept. Lenguajes y Ciencias de la Computación
• vergara,av_at_lcc.uma.es
• http//www.lcc.uma.es/av/

http//www.lcc.uma.es/av/misConfs/ICWE2004/
2
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

3
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

4
Models and meta-models
5
What is a Model?

• A description of (part of) a system written in a
  well-defined language. (Equivalent to
  specification.) Kleppe, 2003
• A representation of a part of the function,
  structure and/or behaviour of a system MDA,
  2001
• A description or specification of the system and
  its environment for some certain purpose. A model
  is often presented as a combination of drawings
  and text. MDA Guide, 2003
• A set of statements about the system. Seidewitz,
  2003
• (Statement expression about the system that can
  be considered true or false.)

6
Examples of models

• Newtonian models of objects movements in space
• City models
• Underground and bus maps, commuting models,...
• Building/house maps
• floor plans, electric wiring, water conductions,
  central heating pipes, etc.
• Software system models
• Requirements (use cases)
• Structure (class diagrams)
• Behavioural models
• Choreography models
• Load balancing and Deployment models, ...

7
Characteristics of models Selic, 2003

• Abstract
• Emphasize important aspects, hide irrelevant
  ones
• Understandable
• Expressed in a form readily understood by users
• Accurate
• Faithfully represents the modelled system
• Predictive
• Can be used to derive correct conclusions about
  the system
• Inexpensive
• Cheaper to construct and study than the system

8
Usefulness of models

• Specify the system
• Structure, behaviour, ...
• Separate concepts at different conceptual levels
• Communicate with stakeholders
• Understand the system
• If existing (legacy applications)
• Validate the model
• Detect errors and omissions in design ASAP
• Mistakes are cheaper at this stage
• Prototype the system (execution of the model)
• Formal analysis of system properties
• Drive implementation
• Code skeleton and templates, complete programs (?)

9
Current limitations of (SE) models

• Models are used only as documentation
• Gap between the model and the implementation of
  the system
• Semantic gap between the respective languages
• Changes in the model do not reflect in the code
• Changes in the code do not reflect in the model
  (the model is thrown away after the first
  implementation, and never updated or used again)
• No merge of models
• Unrelated views of a system (horizontal)
• Unrelated towers of models (vertical)
• No model transformations
• Few defined transformation languages
• No tools
• We are still far behind more mature engineering
  industries, such as aerospace, automotive and
  electrical engineering.... ...Even hardware
  design is ahead of software design!

10
What is a Metamodel?

• A model of a well-defined language Kleppe, 2003
• A model of models MDA, 2001
• A model that defines the language for expressing
  a model MOF, 2000
• A meta-metamodel is a model that defines the
  language for expressing a metamodel. The
  relationship between a meta-metamodel and a
  metamodel is analogous to the relationship
  between a metamodel and a model.
• A model of a modelling language Seidewitz, 2003
• That is, a metamodel makes statements about what
  can be expressed in the valid models of a certain
  modelling language.

11
OMGs Four-layer metamodel architecture

• As with Magrittes picture of the pipe, we need
  to separate
• the thing
• from the model of the thing (I cannot smoke a
  picture)
• from the language(s) in which the model is
  written (Ceci is not a pipe)

12
Four-layers metamodel hierarchy
13
Four-layers metamodel hierarchy (example)
14
MOF Metamodel (simplified)
15
CORBA IDL for the MOF

• interface ClassClass ClassifierClass
• readonly attribute ClassUList all_of_class_class
  
• Class create_class (
• / from ModelElement / in
  ModelNameType name,
• / from ModelElement / in
  ModelAnnotationType annotation,
• / from GeneralizableElement / in
  boolean is_root,
• / from GeneralizableElement / in
  boolean is_leaf,
• / from GeneralizableElement / in
  boolean is_abstract,
• / from GeneralizableElement / in
  ModelVisibilityKind visibility,
• / from Class / in boolean
  is_singleton
• ) raises (ReflectiveMofError)
• // end of interface ClassClass
• interface Class ClassClass, Classifier
• boolean is_singleton () raises
  (ReflectiveMofError)
• void set_is_singleton (in boolean new_value)
  raises (ReflectiveMofError)

16
UML 2.0 Infrastructure
UML extension mechanisms
Boolean, Integer, ...
Namespace, Classifier, Relationship,
Generalization...
Basic definition of Class ...
Extended notion of Class, Association,...
17
New (improved) alignments in 2.0
18
Language definition mechanisms
19
UML 2.0 Profiles

• Profiles specialize UML for specific domains
• When there is no need to change UML 2.0 metamodel
  and semantics, just to extend or customize them
• Metamodel concept
• Defined on metamodel
• Used on model
• Excellent mechanism for defining MDA Platforms
• Examples
• OMG standards
• EAI Enterprise Application Integration
• EDOC Enterprise Distributed Object Computing
• CORBA, CCM
• Schedulability, Performance and Time
• Proprietary
• UML-RT UML for Real Time

20
UML 2.0 Profile Example
21
UML 2.0 Profile Example EJB Platform
22
MOF/ QVT (Query-View-Transformations)

• Query Expression evaluated over a model
• Results in one or more instances of types (either
  defined in the source model, or in the query
  language)
• Example 1 List all packages that do not contain
  child packages
• Example 2 Does attribute A of source model have
  public visibility?
• View A model completely derived from other model
• Views are usually read-only
• Views are generated by transformations
• A query is a restricted kind of view
• Transformation Generates a target model from a
  source model
• Relations and Mappings
• Relations specify transformations
• Mappings implement transformations
• A relation can be refined by one or more mappings

23
QVT Transformation Requirements

• Configurable
• Parametrizable
• Traceable
• Incrementally consistent
• Bidirectional
• Source-driven, Target-driven, Arbitrary
• One-2-One, One-2-Many, Many-2-One, Many-2-Many
• Declarative, Imperative, or Hybrid definition
• Simple
• Scalable
• Tool supported (fully or partially)

OMG, 2003
24
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

25
Beyond technology...

• Too many platforms and technologies
• Distributed Objects, Components, Web services,
  ...
• Not really interoperable!
• Which technology is the best (today)?
• Too fast evolution
• Technologies evolve... and get obsolete very soon
• Which technology will be out tomorrow?
• And how long will it last?
• How to protect my investment in business logic?
• I want my business logic (processes, rules) to be
  as independent as possible from the supporting
  technologies
• So they can separately evolve........ Without
  having to start from scratch each time.... And
  protecting the investment in each one

26
MDA a New Kid in Town

• New orientation for OMG activities
• New step beyond the OMA
• A framework for a set of standards in support of
  MDD
• Models are centric!
• Target middleware is not important!
• Focus on Platform Independent Models (PIM)
• Without middleware details
• Abstract Platform Specific Models (PSM)
• Including all middleware details
• Define PIM to PSM transformations

27
MDA principles

• Inspired by
• The widespread public acceptance of UML
• OMG moving beyond middleware (CORBA)
• The availability of mature MDD technologies
• Purpose
• Enable inter-working between complementary tools
• Foster specialization of tools and methods
• Provide guidance for MDD
• MDA overview papers and resources
• http//www.omg.org/mda

28
MDA (expected) benefits

• Protects software investment from technological
  changes and evolutions
• preserves PIMs when new middleware appears!
• Allows to handle larger and more complex systems
• Through separation of conceptual levels/concerns
• Allows the integration of separate aspects from
  the start, and in a uniform way
• security, reliability, performance, ...
• Allows legacy systems to be integrated into the
  MDA chain
• Allows simulation and automatic implementation
  of models

29
MDA Concepts (1/2)

• Architecture
• 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
• Viewpoint
• 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
• A viewpoint model or view of a system is a
  representation of that system from the
  perspective of a chosen viewpoint
• Implementation
• An implementation is a specification, which
  provides all the information needed to construct
  a system and to put it into operation

30
MDA Concepts (2/2)

• Platform
• A set of subsystems/technologies that provide a
  coherent set of functionality through interfaces
  and specified usage patterns that any subsystem
  that depends on the platform can use without
  concern for the details of how the functionality
  provided by the platform is implemented.
• Platform Independent Model (PIM)
• A model of a subsystem that contains no
  information specific to the platform, or the
  technology that is used to realize it.
• Platform Specific Model (PSM)
• A model of a subsystem that includes information
  about the specific technology that is used in the
  realization of it on a specific platform, and
  hence possibly contains elements that are
  specific to the platform.

31
MDA models (1/2)

• Computation Independent Model (CIM)
• A view from a system from the Computational
  Independent Viewpoint.
• A CIM Focuses on the system and its environment
  the details of the structure of the system are
  hidden or as yet undetermined.
• A CIM is sometimes called a domain model or a
  business model, and is specified using a
  vocabulary that is familiar to the practitioners
  of the domain in question
• It may hide much or all information about the use
  of automated data processing systems.
• Platform Independent Model (PIM)
• A platform independent model is a view of a
  system from the platform independent viewpoint. A
  PIM exhibits platform independence and is
  suitable for use with a number of different
  platforms of similar type.

32
MDA models (2/2)

• Platform Specific Model (PSM)
• A platform specific model is a view of a system
  from the platform specific viewpoint.
• A PSM combines the specifications in the PIM with
  the details that specify how that system uses a
  particular type of platform.
• Platform Model (PM)
• A platform model provides a set of technical
  concepts, representing the different kinds of
  parts that make up a platform and the services
  provided by that platform.
• It also provides, for use in a platform specific
  model, concepts representing the different kinds
  of elements to be used in specifying the use of
  the platform by an application.

33
Examples of MDA models

• CIM
• Priority must be given to shipping the oldest
  deliverables
• PIM
• The Deliverables are ordered according to date
  for shipment
• PSM/OOD
• Deliverables are sorted for shipment() in
  increasing order, using their attribute date
• PSM/OOP
• Use quicksort() to sort Deliverables, using
  Deliverable.date as sorting key, before passing
  them to shipment()

34
Model transformations MDA Pattern

• Model transformation is the process of converting
  one model to another model of the same system
• The MDA pattern includes (at least)
• a PIM,
• a Platform Model,
• a Transformation, and
• a PSM

35
Examples of MDA transformations
36
Applying the MDA pattern 1) Marking
UML Profiles can be used to define the marks and
for marking PIMs
MOF QVT languages will define the mappings
37
Model mappings and marks

• Mappings
• An MDA mapping provides specifications for
  transformation of a PIM into a PSM for a
  particular platform. The platform model will
  determine the nature of the mapping
• Marks
• Model instance mappings define marks
• A mark represents a concept in the PSM, which can
  applied to an element of the PIM to indicate how
  that element is to be transformed
• Templates
• A mapping may also include templates, which are
  parameterised models that specify particular
  kinds of transformations
• These templates are like design patterns, but may
  include much more specific specifications to
  guide the transformation

38
Example of the result of a mapping

• interface MyClass
• int getAttributeOne()
• void setAttributeOne(int v)
• int oneOperation()

39
Result of a transformation template using a
Security Profile (example)
40
Marks

• Marks distinguish multiple possible targets
• Kinds of marks
• Discriminators and enumerators
• isRemote isBoolean
• Quantities
• ( if ( numInstances lt Q and frequency lt F)
  LinkedList HashTable )
• Inputs
• ( append db_ to all operation names )
• ...

Local Invocation
Invocation
ltltisLocalgtgt
ltltisRemotegtgt
PIM
PSM
Remote Invocation
Mellor, 2003
41
Applying the MDA pattern 2) Metamodel
transformation
MOF QVT languages define the transformations
42
MDA Transformations detailed
Bezivin, 2004
43
Example of transformation
UML
Attribute name String type String
AtoX
44
The relation and the mapping
relation AtoX domain (UML.Attribute) name
n, type t domain (XML.Element)
name "Attribute", attrs
(XML.Attribute) name "name", value n,
(XML.Attribute) name "type", value t
mapping MAtoX refines AtoX domain
(UML.Attribute) name n, type t body
(XML.Element) name "Attribute",
attrs (XML.Attribute) name "name",
value n, (XML.Attribute) name
"type", value t
45
A transformation rule (1/2)

• Transformation ClassToClass (UML, UML)
• source c1 UMLClass
• target c2 UMLClass
• source condition -- none
• target condition -- none
• mapping try PublicToPrivateAttribute on
  c1.features ltgt c2.features
• -- everything else remains the same
• Transformation PublicToPrivateAttribute (UML,
  UML) source sourceAttribute
  UMLAttribute target targetAttribute
  UMLAttribute getter UMLOperation
  setter UMLOperation source condition
  sourceAttribute.visibility VisibilityKindpub
  lic

46
Transformation rule (2/2)

• target condition targetAttribute.visibility
  VisibilityKindprivate and -- define the set
  operation setter.name 'set'.concat(targetAttrib
  ute.name) andsetter.parameters-gtexists( p
  p.name 'new'.concat(targetAttribute.name)
  and p.type targetAttribute.type ) and
  setter.type OclVoid and -- define the get
  operation getter.name 'get'.concat(targetAttrib
  ute.name) and getter.parameters-gtisEmpty() and
  getter.returntype targetAttribute.type
• mapping try StringToString on sourceAttribute.n
  ame ltgt targetAttribute.name try
  ClassifierToClassifier on sourceAttribute.type
  ltgt targetAttribute.type

Kleppe, 2003
47
Applying a transformation template
48
Applying the MDA pattern 3) Model merging
49
Applying the MDA pattern 4) Additional
information

• Example. A particular architectural style may be
  specified information may be added to
  connectors to specify quality of service.

50
Applying the MDA Pattern several times

• The MDA pattern can be has to be
  usuallyapplied several times in succession
• What is a PSM resulting from one application of
  the pattern, will be a PIM in the next
  application

51
Example A Multimedia Application
Fuentes et al., 2003
52
Multi-platform systems

• Many systems are can be built on more than one
  platform
• An MDA transformation can use marks from several
  Platform Models to transform a PIM into a PSM
  with parts of the system on several different
  Platforms

53
Alternative implementations
Fuentes et al., 2003
54
Advantages

• Each model is independent from the rest
• Separately defined
• Each model defines its own entities, and
  resides at a well-defined level of abstraction
• Software development becomes model transformation
• Each step transforms (one or more) PIM at one
  level into (one or more) PSM at the next level
• ...Until a final system implementation (PSM) is
  reached
• Transformations can be automated
• We gain modularity, flexibility, and facilitate
  evolution
• Application models capturing business logic and
  IP become corporate assets, independent from the
  final implementation technologies

55
The MDA Process Summary (1/2)

• A CIM of a system is prepared showing the system
  in the environment in which it will operate
• That model will help understand exactly what the
  system is to do, independently of how the system
  is implemented
• A PIM is built
• It describes the system, but does not show
  details of its implementation in any platform
• The architect will then choose a Platform (or
  several)
• They enable implementation of the system with the
  desired architectural qualities
• Then,
• a) In model instance mapping, the PIM is marked
  the architect marks elements of the PIM to
  indicate the mappings to be used to transform
  that PIM into a PSM or
• b) In Metamodel transformations, a transformation
  engine is used

56
The MDA Process Summary (2/2)

• Transform the (marked) PIM into a PSM
• This can be done manually, with computer
  assistance, or automatically
• The input to the transformation is the marked
  PIM, and the mapping
• The result is the PSM, and the record of
  transformation
• A PSM may provide more or less detail, depending
  on its purpose
• A PSM will be an implementation, if it provides
  all the information needed to construct a system
  and to put it into operation
• A PSM can be the PIM of the next iteration of the
  MDA process, until a suitable implementation is
  reached

57
MDA components
Code Text Generators
Transfor- Mations Editors
Model Editors
Transform.Tools
Code Files
MDA bus Model Interchange (XMI, IDL o JMI)
Transform.Repository
Model Validators
Models Repository
Model Weavers
IDE
58
Current MDA technologies

• Meta Object Facility (MOF)
• Unified Modelling Language (UML)
• XML Model Interchange (XMI)
• Common Warehouse Meta-model (CWM)
• Software Process Engineering Meta-model (SPEM)
• Action Semantics Language (ASL)
• Query-View-Transformation (QVT)
• Various UML profiles
• EDOC (ECA, CCA),
• UML-RT,
• EJB,
• CCM, ...

.NET
BPML
XLANG
EDOC
59
MDA Tools

• ATL ATLAS Transformation Language is language for
  general transformation within the MDA framework
• MIA Model-in-Action is a tool that implements
  the concepts of MDA.
• OptimalJ is a MDA tool for J2EE.
• ArcStyler is a MDA tool for J2EE and .NET.
• UMT UML Model Transformation is a tool for model
  transformation and code generation of UML/XMI
  models
• MTL Model transformation at Inria ModelWare
• ModFact is an Open Source project for the MDA at
  LIP6
• AndroMDA is an open source code generation
  framework that follows the MDA paradigm
• Middlegen is a free general-purpose
  database-driven code generation engine based on
  JDBC , Velocity , Ant and XDoclet
• OpenModel is a java-based framework for
  generating executable applications from UML
  models and it complements ArgoUML
• MCC is a MDA tool supporting J2EE and .NET(in the
  works).
• Codagen Architect is MDA tool for J2EE and .NET.
• UMLX is an experimental graphical transformation
  language.
• MDA Transf is a MDA transformation engine
• GMT (Generative Model Transformer) is a project
  to build MDA tools such as UMLX
• JAMDA (Java Model Driven Architecture) is an
  open-source framework for building applications
  generators which create Java code from a model of
  the business domain
• PathMATE Model Automation Transformation
  Environment is an industry's MDA environment
  providing tools for analysis, and model
  transformation engine
• GReAT is a metamodel based graph transformation
  language useful for the specification and
  implementation of model-to-model transformation

60
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

61
Web Engineering and Applications

• Web Engineering
• The systematic, disciplined, quantifiable
  approach to the development, operation and
  maintenance of Web applications.
• Web Application
• An Information System which uses Web-based
  technologies and platforms, and which supports
  interaction through Web-based interfaces.

62
Web-based Applications

• Web-based Applications Architectural Patterns
• Thin Web Client
• Minimal client-side functionalities (web browser)
• Business logic resides in the server side
• Thick Web Client
• Client-side scripting and custom objects
  (controls, applets,...)
• A significant amount of business logic resides in
  the client
• Web Delivery
• Clients participate in a distributed object
  systems

Conallen, 2000
63
Web-based Enterprise Layers
64
Web-based Enterprise Architecture
Applets, Applications
Web Services clients
Browsers
Client Tier
servlets
JSPs
Server Tier
External Web Services
EJBs
DB
J2EE Container
CORBA ORB/CORBA Services
Middleware
Back-end Systems
Application servers
External Web Services
DB
65
From three to a six layer architecture
Three layers model Six layers model
(Refined)
66
Example A Travel Agent
Bezivin, 2004 many others
67
Conceptual model
68
Web-Apps Development proposals

• Currently, Web applications can be generated from
  models
• They are good code generators (i.e., ad-hoc
  model compilers)
• Web-Apps Modelling (pre-Web Engineering)
• Example Jim Conallens proposal
• Model Web entities (web pages, servers, forms,
  etc)
• MDD Web Engineering (pre-MDA)
• Examples UWE (ArgoUWE), OO-H (VisualWADE),
  OOHDM, OOWS, WSDM, WebML
• Model the presentation and navigation aspects
• Their conceptual models capture and successfully
  handle the applications structure

69
Jim Conallens Model (excerpt)
70
OO-H (Object-Oriented Hypermedia)
Object-Oriented Hypermedia Method
71
OO-H Domain (Conceptual) Model
72
OO-H Navigation Model
73
OO-H Presentation Model
74
OO-H Final result
75
UWE (UML-based Web Engineering)
Koch et al., 2001
76
UWE Metamodel (1/2)
77
UWE Metamodel (2/2)
78
UWE Conceptual model
79
UWE Navigational Model
80
UWE Presentation model Structural view
81
UWE Presentation model User Interface
82
Web-Apps Development proposalsSummary

• Web-Apps Modelling (pre-Web Engineering)
• Example Jim Conallens proposal
• Model Web entities (web pages, servers, forms,
  etc)
• Too low level (basically, useful to model the PSM
  only)
• MDD Web Engineering (pre-MDA)
• Examples UWE (ArgoUWE), OO-H (VisualWADE) ,
  OOHDM, OOWS, WSDM
• Model the presentation and navigation aspects
• Their conceptual models capture and successfully
  handle the applications structure
• Do not address (properly) other aspects business
  processes, choreography, distribution, etc.
• Ad-hoc code generation (i.e., model compilation)

83
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

84
MDA for Web Applications

• MDA is suitable for developing distributed
  systems that are made up of components running on
  different platforms/tiers. For example, there
  may be web tier implemented on ASP.Net, but which
  talks to a middle-tier using EJBs, with a
  back-end being a Sybase RDBMS. MDA can generate
  the software for the tiers, plus the code to glue
  it all together.
• Haywood, 2004

85
Is MDA a right option for you?

• Are models important for you?
• i.e., does your business care about models?
• Are your platforms that unstable?
• Could your development process cope?
• Including your development team... New skills are
  required!
• Would your business buy it?
• Isnt having two different flavours (Schools) of
  MDA somewhat worrying?
• Elaborationalists (e.g. Optimal/J, ArcStyler) 70
  executable annotated PIMs
• Translationists (e.g. Executable UML) 100
  executable PIMs
• Down at the coal-face, do you honestly
  believe it would work?
• Will be able to generate code from models, even
  when we do not yet agree on how to represent
  behaviour?

Dan Haywood, 2004
86
The two current MDA approaches

• Models do not contain all the information (e.g.
  behaviour)
• Missing information is added as refinement in the
  PSM or code
• Round-trip engineering is sometimes possible

• Models are a complete, executable statement of a
  solution
• Model compilers translate these models into a
  running system
• ASL are used to model behaviour
• No manual intervention required

87
The MDA way

• Define the system PIMs (structure, behaviour,
  navigation, presentation, components,
  distribution, ...)
• Select the target platform(s)
• Web pages (navigation), Java (Travel Agency),
  WSDL and JWSDP (external services banks,
  airlines, ...),...
• Define the transformations
• Either using transformation rules between the PIM
  metamodels (the PIM languages) and the target
  platforms metamodels
• Or by marking the PIM elements using the marks
  defined by the mappings
• Apply the mappings to the PIM elements
• Using a transformation engine, or manually
• This will produce a set of elements of different
  PSM
• Bridges (e.g., calls) between elements in
  heterogeneous target PSMs should be defined!

88
The Travel Agent Example
Bezivin, 2004 many others
89
PIM of the system (structure)
90
PIM of the system (Processes excerpt)
(EDOC)
Bezivin, 2004
91
Transforming the PIM (structure)

• Metamodel transformations
• An alternative approach to using marks (taken
  from the UML Profile that defines the Platform)
• More powerful
• More general
• The basis of the QVT proposals
• Currently, the preferred option
• Let us see how to transform the PIM of the system
  structure to Java, WSDL, and JWSDP
  implementations
• Transformations between the different metamodels
  should be defined
• UMLltgtJava, UMLltgtWSDL, UMLltgtJWSDP,

92
UML Metamodel (over-simplified)
93
Java Metamodel (simplified)
94
UML to Java transformation (ATL)
95
WSDL Metamodel
96
UML to WSDL transformation (ATL)
97
JWSDP Metamodel
98
PSM using Java, WS, and JWSDP
99
Transforming the PIM (behaviour)

• Metamodel transformations seem to be appropriate
  for behaviour as well
• No agreed notation for describing behaviour
• State-based approaches (state machines, ASL, SDL)
• Declarative approaches (pre-post, contracts)
• Protocol-based approaches (sequence and
  interaction diagrams)
• They do not share a common behavioural model
• Either vanilla UML or some UML dialects and
  Profiles are commonly used (UML Profile for EDOC,
  UML-RT,...)

100
PIM of the system (Processes excerpt)
(EDOC)
Bezivin, 2004
101
EDOC Process Components to Java
Bezivin, 2004
102
MDA-based proposals Summary

• MDA-based (model transformations) ATLASs,
  Optimal/J, ArcStyler
• Structured model compilation, according to MDA
  approach and disciplines
• Very good treatment of the business structure
  (Conceptual Model) modularity, platform
  independence, separation of concerns, ....
• Very simplistic treatment of navigation and
  presentation
• Lack of consensus to model behaviour and
  choreography
• Optimal/J and ArcStyler are very much focused on
  particular technologies (J2EE, .NET)

103
And now?

• Define all system PIMs
• Analyse each proposals coverage
• Play with current tools, see how far it can go,
  and how much you can integrate it within you
  development processes
• Try to use each proposal and tool wherever it
  shows its strength and benefits
• Identify gaps not covered by any of the current
  proposals
• Research and development activities
• Adapt current proposals to make them conformant
  to MDA (and thus make them interoperable, with
  modular design, etc.)
• Develop new proposals that fill the gaps
• Work on more tools

104
Models (PIMs) of a Web Application
105
Models covered by Conallen
106
Models covered by UWE
107
Models covered by OO-H
108
Models covered by Optimal/J
109
Models covered by ATLAS works
110
Lets try to do it right!

• Define all system PIMs
• Use/adapt each proposal to model the aspects it
  is more suitable, e.g.
• OO-H or UWE can model navigation and presentation
• But adapt them so they do not generate code in an
  ad-hoc manner, but according to the MDA
  principles
• ATL can be used for metamodel transformations
  (between the models generated by each proposal)
• Optimal/J and ArcStyler can generate the EJB or
  .NET code
• But adapt them so they can generate other
  platforms code more naturally
• Conallens proposal can model the PSM
• ...And the gaps?

111
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

112
Next steps
MDA is still in its infancy...

• Define and implement MDA components
• Model Editors and Builders
• Model Compilers
• Model Transformers and Weavers
• Transformation Languages and Engines (QVT)
• Sort out the Behaviour, Choreography,
  Distribution, Transactions,...
• Agree on a set of behavioural notations with
  well-defined semantics
• Agree on notations for expressing choreography
• Be able to deal with the aspects at different
  conceptual levels (CIM, PIM, PSM)
• Deal with COTS and legacy applications
• MDA seems to imply a top-down development
  process. What do we do with re-use?
• Extra functional requirements? ....
• Architecture and Architectural styles? ...

113
Agenda

1. Introduction Models and Metamodels
2. MDA primer
3. Web-based Applications
4. Applying MDA to Web-based Applications
5. What is left, and what is next
6. Conclusions

114
Conclusions

• MDA seems to be the right way to go
• Conceptually clean and well defined
• Protect investment and IP by separating the
  business model from the supporting technologies
• Model centric!
• But there is still a long way ahead
• (see previous slides)
• and MDA is not the panacea
• Many sceptical positions and critiques
• No manual coding is not 100 achievable in
  general
• We need to identify the domains in which MDA can
  be effectively used, and develop tools for it
  (e.g., Web-based systems)
• Research is required!

115
Bottom line Ideas to take home with you

• Capture each system concern (subject matter) in
  an independent model
• Presentation, navegation, business processes,
  business rules, functionality, ...
• Each models deals with an independent subject
  matter, each one is platform independent
• Decomposition should aim at modular separation
  of concerns (changes in one subject matter do
  not need to imply changes in models of other
  concerns)
• Use mappings between the models representing
  each concern
• Refinements, abstractions, representations,
  migrations,...
• Models and Mappings become your CORPORATE
  ASSETS
• Use tools to automate the mappings

116
Basic References Models and MDA

• J. Bézivin. In Search of a Basic Principle for
  Model Driven Engineering. Upgrade 5(2)21-24,
  2004.
• D. Frankel. Model Driven Architecture Applying
  MDA to Enterprise Computing. J.W. Sons, 2003.
• L. Fuentes, A. Vallecillo. An Introduction to
  UML Profiles. Upgrade 5(2)6-13, 2004.
• L. Fuentes, M. Pinto, A. Vallecillo. "How MDA
  Can Help Designing Component- and Aspect-based
  Applications". In Proc. of EDOC 2003, Brisbane,
  Australia, Sept. 2003.
• T. Gardner et al. A review of OMG MOF 2.0
  Query/Views/Transformations Submissions and
  Recommendations towards the Final Standard. July
  2003. www.omg.org/docs/ad/03-08-02.pdf
• D. Haywood. MDA in a nutshell. May 2004.
  http//theserverside.com/articles/
• A. Kleppe, J. Warmer, W. Bast. MDA Explained
  The Model Driven Architecture, Practice and
  Promise. Addison-Wesley, 2003.
• A. McNeile. MDA The Vision with the Hole?,
  2003. http//www.metamaxim.com/download/documents/
  MDAv1.pdf
• A. McNeile, N. Simmons. Methods of behaviour
  modelling, 2004. www.metamaxim.com
• S. Mellor, M. Balcer. Executable UML A
  Foundation for Model Driven Architecture.
  Addison-Wesley, 2002.
• S. Mellor, MDA Distilled. www.projtech.com
• OMG. MDA Guide. OMG doc. ab/2003-05-01.
• OMG. Model Driven Architecture. OMG doc.
  ormsc/2001-07-01.
• Ed Seidewitz. What Models Mean. IEEE Software
  20(5)26-32, Sep/Oct 2003.
• B. Selic. The Pragmatics of Model-Driven
  Development. IEEE Software 20(5)19-25, Sep/Oct
  2003.
• D. Thomas. MDA Revenge of the Modellers or UML
  Utopia? IEEE Software 21(4)15-17, May2004.
• J. Warmer, A. Kleppe. The Object Constraint
  Language Getting Your Models Ready for MDA,
  Second Edition, Addison-Wesley, 2003.

117
Basic References Models Web Eng.

• L. Baresi, F. Garzotto, P. Paolini. Extending
  UML for Modelling Web Applications. In Proc. of
  34th HICSS, 2001.
• J. Bézivin et al. An Experiment in Mapping Web
  Services to Implementation Platforms. Research
  Report04.01, Univ. Nantes, March 2004.
• S. Ceri, P. Fraternali, A. Bongio. Web Modelling
  Language (WebML) A modelling language for
  designing Web sites. In Proc. of the 9th WWW
  Conference, May 2000.
• J. Conallen. Building Web Applications with
  UML. Addison-Wesley, 2000.
• J. Gomez, C. Cachero, O. Pastor. On Conceptual
  Modelling of Device-independent Web Applications
  Towards a Web Engineering Approach. IEEE
  Multimedia 8(2)20-32, 2001.
• N. Koch, A. Kraus, R. Hennicker. The Authoring
  Process of the UML-based Web Engineering
  Approach. In Proc. of IWWOST 2001, Valencia,
  Spain, 2001.
• N. Koch, A. Kraus. Towards a Common Metamodel
  for the Development of Web Applications. In
  Proc. of ICWE 2003, LNCS 2722, pp. 497-506, 2003.
• N. Koch et al. Modelling Web Business Processes
  in Web Application Models. In Journal of Web
  Engineering 3(1)22-49, 2004.
• P-A. Muller, P. Studer, J. Bézivin. Platform
  Independent Web Application Modelling. In Proc.
  of UML 2003, LNCS 2863, pp. 220-233, 2003.
• D. Schwabe, L. Esmeraldo, G. Rossi, F. Lyardet.
  Engineering Web Applications for Reuse. IEEE
  Multimedia, Special issue on Web Engineering,
  1(3)20-31, 2001.
• D. Schwabe, G. Rossi. Designing Hypermedia
  Applications using OOHDM. In Proc. of Workshop
  on Hypermedia Development Processes, Methods and
  Models (Hypertext98), 1998.
• D. Schwabe, O. Pastor (eds.). Proc. of IWWOST
  2001. http//www.dsic.upv.es/west/iwwost01
• O. de Troyer, S. Casteleyn. WSDM A user-centred
  design method for Web sites. In Proc. of the 7th
  WWW Conference, May 1998.

118
End of Presentation
ICWE'04
http//www.lcc.uma.es/av/misConfs/ICWE2004/