Nathalie%20Moreno%20and%20Antonio%20Vallecillo

1
What do we do in MDA with re-use?
CIM
PIM
PSM

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

COTS component/ Legacy System
2
Agenda

1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks

1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks

3
Our background and motivation

• Component-based software development but...
• ...moving to Web-based application design and
  development
• Specific and well-defined application domain
• Model compilers current exist for Web apps
• They are successfully used in real environments
• but... ad-hoc, unstructured, non-modular, hard to
  maintain and evolve, proprietary....
• Web Service technologies are proving to be
  valuable to organizations and starting to be
  widely used
• Financial (VISA, AMEX), Travel agencies
  (TerminalA), E-shops (Amazon), Adobe, ...
• Looks like the perfect arena for MDA!

4
MDA focus

• MDA focuses on Models
• CIM (?)
• PIM
• PSM
• Platform Models
• Implementations (PSM)
• Metamodels
• MDA focuses on Transformations
• PIM to PSM
• PIM(s) to PSM
• PSM to PIM
• PIM(s) Additional Info to PSM
• Metamodel transformations

5
The basic MDA pattern

• The basic MDA pattern includes (at least)
• a PIM,
• a Transformation, and
• a PSM

PIM
PSM
6
Applying the MDA pattern
A model of a subsystem that contains no
information specific to the platform, or the
technology that is used to realize it.
TOP-DOWN
PIM
Transformation
PSM
7
Applying the MDA pattern
TOP-DOWN
PIM
Converting one model to another model of the
same system.
PSM
8
Applying the MDA pattern
TOP-DOWN
PIM
Transformation
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.
PSM
9
Agenda

1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks

10
Initial problems

• Related to the modelling of systems
• What are the contents of the model of a system?
• How is that information expressed?
• Related to COTS/legacy systems
• What are the contents of the model of a COTS?
• How is that information expressed?
• Is that information available?
• Is that information reliable?
• How can it be obtained?
• Related to matchmaking/adaptation
• How do I check whether the COTS software fulfils
  my system requirements? (Gap Analysis Problem)
• How do I evaluate the effort required to adapt
  it?
• How do I adapt it? ... Or revise my system specs?

11
COTS, legacy systems, and MDA

• COTS components and Legacy Systems are
  black-boxes
• Very few information is available about them
• Just signature information, usually in textual
  form
• Most of the available information may be outdated
• Models, if available at all, correspond to the
  original design
• Evolutions very few times reflect in the
  documentation
• Reverse engineering is not the solution
• It provides a model at the lowest possible level
  of abstraction
• Usually, just an execution model of the software
  in graphical form,
• ..but without any architectural information
• How do I match the requirements with the COTS
  information?
• Traditional rule of thumb if more than 20 needs
  to be adapted/modified, you better develop from
  scratch
• Does this rule still apply in the context of MDA?
• Can I generate adaptors that alleviate this
  problem?

12
Agenda

1. Introduction
2. The problems
3. Trying to address these issues
4. Dealing with the assumptions
5. Concluding remarks

13
BUSINESS COMPONENT
14
Based on the following assumptions

• The PIM of the application we are developing
  describes the system as a set of interacting
  parts (e.g., services)
• Each part is described by at least its structure,
  behaviour, and choreography
• We count with a model of the COTS component or
  legacy system that we need to re-use (and hence a
  PSM metamodel), described similarly
• There are MDA transformations defined between
  the PIM and the PSM metamodels
• There is a set of matchmaking operators (lt) that
  implement the sustitutability tests (AltB if A
  can replace B)
• In case of mismatches, we know how to decide
  whether an adaptor exists or not
• And if so, we know how to generate it

Sci-Fi?
15
Agenda

1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks

16
How far we are

• The PIM of the application we are developing
  describes the system as a set of interating parts
  (e.g., services)
• We are not doing too bad here!
• Each part is described by at least its structure,
  behaviour, and choreography
• No problems with the structure,
• But still far from reaching an agreement on how
  to model the behaviour and the choreography

17
How far we are
3. We count with a model of the COTS component or
legacy system that we need to re-use (and hence a
PSM metamodel), described similarly (i.e., with
models for its structure, behaviour and
choreography)
Software Element Structure Behavior Choreography
Web Service WSDL RDF BPELWS
CORBA object CORBA IDL SDL Message Seq. Charts
CORBA object CORBA IDL Larch-CORBA CORBA-Roles, Petris-nets
Java Class Java JML UML seq.diagrams
.NET assembly C contracts BPELWS
18
How far we are

• There are MDA transformations defined between
  the PIM and the PSM metamodels
• MOF/QVT may be of great help here!
• Some proposals already available

UML (Class Diagrams) lt................gt
Java (Interfaces) EDOC
lt................gt BPEL4WS
19
How far we are

• 5. There is a set of matchmaking operators (lt)
  that implement the sustitutability tests (A lt B
  if A can replace B)
• Situation under control at the structural
  (signature) level
• Subtyping
• Some works at the behavioural level (for pre-post
  specs, basically)
• Larch-CORBA, Larch Java, ...
• Some works at the choreography level
• Petri-nets
• The pi-calculus

20
How far we are

• 6. In case of mismatches, we know how to decide
  wether an adator exists or not....And if so, how
  to generate it
• Just preliminary results
• Resolve mismatches found by the sustitutability
  tests
• Unsolved yet
• defining distances between specifications
• Deciding about the existence of wrappers that
  resolve the mismatches
• Generating the wrappers

21
Agenda

1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks

22
Summary

• MDA and re-use
• MDA seems to imply a top-down approach to
  software development (al least, when used for
  model compilation)
• Re-use is critical in open, multivendor,
  distributed apps
• Not only for designing them
• But also for taking evolution into account
• Re-use seems to imply somehow a bottom-up
  approach
• Can we reconcile both approaches?
• We have presented a possible (partial) solution
  based on a set of (very strong) assumptions
• Some work on these assumptions is currently
  undergoing
• Frankly speaking, we see the assumptions feasible
  only in very few cases and application domains
• Web-based applications development may be one of
  them
• Could you think of others?

23
End of Presentation
Thanks!