On the Role of Abstract Platform in Model Driven Development*
-
Upload
maribeth-madsen -
Category
Documents
-
view
29 -
download
4
description
Transcript of On the Role of Abstract Platform in Model Driven Development*
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
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