Nathalie Moreno and Antonio VallecilloDept. Lenguajes y Ciencias de la Computación

Universidad de Málaga

{vergara,av}@lcc.uma.es

COTS component/

Legacy System

What do we do

in MDA with re-use?BUSINESS COMPONENT

BEHAVIORALSTRUCTURAL CHOREOGRAPHY

PIM

PSM

CIM

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

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

PIMPIM

Transformation

PSMPSM

Applying the MDA pattern

PIMPIM

Transformation

PSMPSM

“A model of a subsystem that contains no information specific to the platform, or the technology that is used

to realize it.”

“A model of a subsystem that contains no information specific to the platform, or the technology that is used

to realize it.”

TOP-DOWN

Applying the MDA pattern

PIMPIM

PSMPSM

“Converting one model to another model of the

same system.”

“Converting one model to another model of the

same system.”

Transformation

TOP-DOWN

Applying the MDA pattern

PIMPIM

Transformation

PSMPSM

“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.”

“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.”

TOP-DOWN

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

COTS(BLACK BOX)

COTS

SPECIFICATION ADAPTER

SPECIFICATION

STRUCTURE BEHAVIOR

ADAPTER

NO NO NO

PIM

LANGUAGE

PSM

LANGUAGE

CODE

BEHAVIORAL MODELSTRUCTURAL MODEL

CHOREOGRAPHY MODEL

MDA TRANSFORMATION/IMPLEMENTATION

DOCUMENTATION ORMDA TRANSFORMATION/ REV.

ENGINEERING

< ?

CHOREOGRAPHY

STRUCTURE BEHAVIOR

CHOREOGRAPHY

ADAPTABLE?

YES

NO

NO

COMPONENT SPECIFICATION

MDA TRANSFORMATION/IMPLEMENTATION

GENERATEDCOMPONENT

WORTH DEVELOPING?

YES

NO

REVIEW

ADAPTABLE?NO

STRUCTURE BEHAVIOR CHOREOGRAPHY

< ? < ?

ADAPTABLE?

STRUCTURE BEHAVIOR

CHOREOGRAPHY

MDA TRANSFORMATION

MDA TRANSFORMATION

MDA TRANSFORMATION

Based on the following assumptions1. 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 choreography3. 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

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

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

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!

Antonio Vallecillo

av@lcc.uma.es

+34 952 13 27 94