What do we do
in MDA
with re-use?
BUSINESS COMPONENT
PSM
STRUCTURAL
BEHAVIORAL
CHOREOGRAPHY
Nathalie Moreno and Antonio Vallecillo
COTS component/
Legacy System
Dept. Lenguajes y Ciencias de la Computación
Universidad de Málaga
{vergara,av}@lcc.uma.es
Agenda
1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks
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!
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
The “basic” MDA pattern
• The basic MDA pattern
includes (at least):
– a PIM,
– a Transformation, and
– a PSM
PIM
Transformation
PSM
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
Applying the MDA pattern
TOP-DOWN
“Converting one model
to another model of the
same system.”
PIM
Transformation
PSM
Applying the MDA pattern
TOP-DOWN
PIM
“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.”
Transformation
PSM
Agenda
1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks
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?
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?
Agenda
1. Introduction
2. The problems
3. Trying to address these issues
4. Dealing with the assumptions
5. Concluding remarks
BUSINESS COMPONENT
STRUCTURAL MODEL
BEHAVIORAL MODEL
CHOREOGRAPHY MODEL

REVIEW

MDA
TRANSFORMATION
PIM
LANGUAGE
MDA
TRANSFORMATION
MDA
TRANSFORMATION
STRUCTURE
NO
NO
ADAPTABLE?
NO
NO
< ?
CHOREOGRAPHY
NO
< ?
PSM
LANGUAGE
ADAPTABLE?
NO
NO
< ?
BEHAVIOR
ADAPTABLE?
WORTH DEVELOPING?
YES
YES
STRUCTURE
BEHAVIOR
CHOREOGRAPHY
COMPONENT
SPECIFICATION
MDA TRANSFORMATION/
IMPLEMENTATION
GENERATED
COMPONENT
STRUCTURE
BEHAVIOR
CHOREOGRAPHY
ADAPTER
SPECIFICATION
MDA TRANSFORMATION/
IMPLEMENTATION
ADAPTER
STRUCTURE
BEHAVIOR
CHOREOGRAPHY
COTS
SPECIFICATION
DOCUMENTATION OR
MDA TRANSFORMATION/ REV. ENGINEERING
COTS
(BLACK BOX)
CODE
Based on the following assumptions
1. The PIM of the application we are developing describes the
system as a set of interacting parts (e.g., services)
2. Each part is described by at least its structure, behaviour, and
choreography
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
4. There are MDA transformations defined between the PIM and
the PSM metamodels
5. There is a set of matchmaking operators (<) that implement the
sustitutability tests (“A<B” if “A can replace B”)
6. In case of mismatches, we know how to decide whether an
adaptor exists or not
– And if so, we know how to generate it
Agenda
1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks
How far we are
1. 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!
2. 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
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
WSDL
RDF
BPELWS
CORBA object
CORBA IDL
SDL
Message Seq. Charts
CORBA object
CORBA IDL
Larch-CORBA
CORBA-Roles, Petris-nets
Java
JML
UML seq.diagrams
C#
contracts
BPELWS
Web Service
Java Class
.NET assembly
How far we are
4. 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) <................> Java (Interfaces)
EDOC
<................> BPEL4WS
How far we are
5. There is a set of matchmaking operators (<) that implement
the sustitutability tests (A < 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
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
Agenda
1. Introduction
2. The problems
3. Assumptions for addressing these problems
4. Dealing with the assumptions
5. Concluding remarks
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?
End of Presentation
Thanks!