On the Role of Abstract Platform in Model Driven Development

1
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 / metamodelling
• Transformation language engineering
• UML
• 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 ltplatform-independencegt you have to
  engineer it
• Find appropriate architectural concepts to
  support this quality property
• Focus on design of distributed applications
• Cope with distribution
• Exploit distribution
• Reuse of middleware

5
Related models in MDA development
. . .
design
design alternatives
6
Related models in MDA development
DSL
request/response
group communication
. . .
asynchronous messaging
JavaRMI
CORBA
JMS
Any other MOM
design
design alternatives
7
Platform-independence

• Platform-independence is not black-or-white
• Some abstraction gaps are too large
• There are different levels of platform-independenc
  e
• 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
Abstract platform
Abstract platform
DSL
request/response
group communication
Abstract platform
. . .
asynchronous messaging
JavaRMI
CORBA
JMS
Any other MOM
design
design alternatives
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

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-independen
  t 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
reliable
14
Platform characteristics may play a role in
(platform-independent) designs
15
Platform characteristics may play a role in
(platform-independent) designs

• How to choose between alternative designs (i) and
  (ii) during platform-independent design?
• Platform-specific aspects such as supported
  distribution transparencies (RM-ODP) play role in
  the selection of an adequate architecture
• e.g., if platform provides support for
  replication transparency, solution (i) would not
  introduce a single point of failure, and
  therefore would be acceptable as an alternative
  for the implementation of a highly available
  service

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

20
Abstract platform definition approaches
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
• designers must know the characteristics of the
  abstract platform when defining PIM of an
  application and
• 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
PDA Model
APR Model
PSM Model
24
Abstract platform and adaptability
PIA Model
AP Model
PDA Model
APR Model
PSM Model
25
Abstract platform and adaptability
PIA Model
AP Model
PDA Model
APR Model
PSM Model
26
Implicit Approach in UML

• UML 2.0 concepts imply abstract platform based on
  request-response invocations and message passing
• A certain degree of customization obtained
  through semantic variation points and profiles
• Semantics of profiles is unclear
• Implications for implicit approach
• plain UML is not conclusive with respect to the
  abstract platform implied, and,
• customization mechanisms have to be applied in
  order to precisely define specific abstract
  platforms.

27
Implicit Approach in UML

• Customization managed in profiles
• Profile assumes roles of abstract platform model
• If relevant abstract platform characteristics
  cannot be represented by resolving semantic
  variation points and profiling
• New languages for abstract platform should be
  defined in terms of MOF metamodels
• Design concepts of these languages are not
  constrained by UML
• Meta-model assumes the role of abstract platform
  model

28
ExampleUML profile specializing the exchange of
asynchronous messages
29
Explicit Approach in UML

• The abstract platform is defined as reusable
  models to be composed with PIM of application
• UML 2.0 model library packages
• Packages stereotypes as ltltmodelLibrarygtgt
• Package is imported by PIM of the application
• An abstract platform can have complex behaviour
  and structure
• We want to specify the service of the abstract
  platform (freedom of implementation)
• UML 2.0s composite structures

30
Example

• Relations between the PIM of the application and
  the abstract platforms defined with the implicit
  and explicit approaches

31
ExampleThe ConferenceAbstractPlatform
32
ExampleThe ConferenceBinding state-machine
33
ExampleRealization of the Abstract Platform
34
ExampleBehaviour of the ConferenceComponent
represented as a state-machine
35
ExampleAlternative realization of the
ConferenceAbstractPlatform
36
Limitations of UML representation

• No standard syntax for Actions (only
  interoperability)
• Ports and their implementation
• Ordering events

37
Conclusions

• Platform-independence is not black-or-white
• Defining 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 necessary
• Requirement design language should allow
  designer to define suitable abstract platforms
• Explicit 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