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 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 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-white Some 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 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A CC PIMPSM

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 reliable

14 Platform characteristics may play a role in (platform-independent) designs Replication transparency?

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: 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: ModelAP: Model Transform PDA: ModelAPR: Model Compose PSM: Model PIM

24 Abstract platform and adaptability PIA: ModelAP: Model Transform PDA: ModelAPR: Model Compose PSM: Model PIM

25 Abstract platform and adaptability PIA: ModelAP: Model Transform PDA: ModelAPR: Model Compose PSM: Model PIM

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 Example: UML 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 > 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.0’s composite structures

30 Example: Relations between the PIM of the application and the abstract platforms defined with the implicit and explicit approaches:

31 Example: The ConferenceAbstractPlatform

32 Example: The ConferenceBinding state-machine

33 Example Realization of the Abstract Platform

34 Example: Behaviour of the ConferenceComponent represented as a state-machine

35 Example: Alternative 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: