On the Role of Abstract Platform in Model Driven Development*

Marten van Sinderen

Centre for Telematics and Information Technology,University of Twente, The Netherlands

AMDA Workshop, Enschede, 20 May 2004

* based on EDOC 2005 paper by Almeida, Dijkman, van Sinderen, Ferreira Pires

2

Setting the context…

OMG for many years successful with its CORBA middleware standards

Application development centred around CORBA

Situation changed with the advent of many other middleware standards and products

OMG introduced MDA as the new application development paradigm that subsumes any middleware

Middleware is an important platform type

3

Setting the context...

Not being able to agree on definition of “platform” and “specific” or “independent” in the OMG should not prevent us from:

finding proper abstraction criteria for designs that remain stable in face of technology changes... And raising the level of abstraction

A lot of confusion especially because of issues associated with MDA

Language engineering / metamodellingTransformation language engineeringUML:

• Constrain the designer• Obscure semantics

4

Setting the context…

Lack of methodological support for separation of platform-independent and platform-specific concerns (whatever these may be)

prevents exploiting separation of concerns beneficially

Zachman:• If you need <platform-independence> you have to engineer it

• Find appropriate architectural concepts to support this quality property

Focus on design of distributed applicationsCope with distribution

Exploit distribution

Reuse of middleware

5

Related models in MDA development

...

design

design alternatives

6

Related models in MDA development

asynchronous messaging

JMS

Any other MOM

CORBA JavaRMI

design

design alternatives

request/response

...

group communication

DSL

7

Platform-independence

Platform-independence is not black-or-whiteSome abstraction gaps are too large

There are different levels of platform-independence

Platform characteristics considered throughout the development

The levels should be identified and defined

Preferably, platform characteristics assumed in models explicitly defined

8

Related models in MDA development

asynchronous messaging

JMS

Any other MOM

CORBA JavaRMI

design

design alternatives

request/response

...

group communication

Abstract platform

Abstract platform

Abstract platform

DSL

9

Abstract platform

A platform-independent design relies on an abstract platform in an analogous way as a platform-specific design relies on a platform

A C

PIM PSM

10

MDA Guide

some examples of “generic platform types” mentions briefly the need for a “generic platform model” which “can amount to a specification of a particular architectural style” there are other relevant abstract platform characteristics besides “architectural style”!

e.g., QoS characteristics, transparencies supported, reusable components

how does this “generic platform model” look like?

Is it a meta-model? Is it a profile? Other models?

11

Abstract Platform Definition

How to define an abstract platform?i.e., how to choose assumptions (on platform characteristics) relevant at a platform-independent level?

and then how to represent it?language issues

12

Abstract Platform Definition

Some abstract platform characteristics become relevant when identifying application parts and their interactions

e.g., characteristics of the support for interactions between system parts (at different levels of decomposition)

Some other platform characteristics play a more subtle, but not negligible, role

13

Platform characteristics may play a role in (platform-independent) designs

Users

Users

Users

interactions

components

Conference Binding

reliable

14

Platform characteristics may play a role in (platform-independent) designs

(i) centralised server-based solution

(ii) distributed peer-to-peer solution

Server

Users

Users

Users

Client Comp1

Client Comp2

Client Comp3

Users

Users

Users

Client Comp1

Client Comp2

Client Comp3

interactions

components

desired functionality

Replication transparency?

16

Abstract Platform Definition

Apparently, this places the designer in a dilemma:

platform selection affects platform-independent design

Solution: define at platform-independent level, QoS requirements on platform-specific realizations, to:

guide and justify decisions at a platform-independent level (assumptions)provide input for platform specific realization (requirements)

17

Abstract Platform Definition

Should it be “very abstract”?

One size fits all?In the example, abstract platform definition depended on design choices required

Generality is required because of reuse of abstract platforms and transformations that depend on it

18

Abstract platform and design languages

PIMs are described in a design language

Design language characteristics and characteristics of abstract platforms are interrelated

e.g., usage of operation invocation (in UML) for interaction between application parts in a PIM, implies abstract platform w/ operation invocation

This is an example of implicit (language-level) abstract platform definition

19

Abstract platform and design languages: explicit definition

Abstract platforms may need to be defined explicitly

e.g., if abstract platform requires group communication and that is not supported directly by language concepts

e.g., if we consider a trader component (ODP/OMG/UDDI-like) as part of abstract platform

21

Requirements for design languages for PIMs

Design language concepts should be precisely defined so that abstract platform characteristics can be derived

for at least two reasons:

1. designers must know the characteristics of the abstract platform when defining PIM of an application; and

2. abstract platforms are a starting point for platform-specific realization

A design language should enable the definition of appropriate levels of platform-independence

22

Abstract platform and adaptability

Abstract platform is stable point in development process

Application models (PIM) can stay the same under platform technology changes

Mappings from abstract platform to concrete platforms can stay the same under application changes

Composed transformations (with application part and abstract platform part) can be partially reused

23

Abstract platform and adaptability

PIA: Model AP: Model

Transform Transform

PDA: Model APR: Model

Compose

PSM: Model

PIM

24

Abstract platform and adaptability

PIA: Model AP: Model

Transform Transform

PDA: Model APR: Model

Compose

PSM: Model

PIM

25

Abstract platform and adaptability

PIA: Model AP: Model

Transform Transform

PDA: Model APR: Model

Compose

PSM: Model

PIM

37

Conclusions

Platform-independence is not black-or-whiteDefining assumptions in platform-independent designs with abstract platform concept while preserving implementation freedom

Design language concepts and characteristics of abstract platforms are interrelated

Careful consideration of abstract platform representation necessaryRequirement: design language should allow designer to define suitable abstract platformsExplicit approach is often neglected

38

Conclusions

Term abstract platform is meant as a warning

Abstract platform heterogeneity at the PIM-level

Can we converge at this level? Can we find canonical abstract platforms (concepts / patterns / components)?

• Can we estimate the (in)stability of technologies?

Risky if abstract platform is implicit

How can we integrate designs based on different abstract platforms?

Ongoing work in A-MUSE: http://a-muse.freeband.nl