1 / 25

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.

maribeth-madsen
Download Presentation

On the Role of Abstract Platform in Model Driven Development*

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 <platform-independence> 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-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 • Abstract platform • Abstract platform DSL request/response group communication • Abstract platform . . . asynchronous messaging JavaRMI CORBA JMS Any other MOM design design alternatives

  9. PIM PSM A C 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 characteristicsbesides “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. Replication transparency? Platform characteristics may play a role in (platform-independent) designs

  15. 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)

  16. 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

  17. 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

  18. 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

  19. Requirements for design languages for PIMs • Design language concepts should be precisely definedso 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

  20. 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

  21. PIM Transform Transform Compose Abstract platform and adaptability PIA: Model AP: Model PDA: Model APR: Model PSM: Model

  22. PIM Transform Transform Compose Abstract platform and adaptability PIA: Model AP: Model PDA: Model APR: Model PSM: Model

  23. PIM Transform Transform Compose Abstract platform and adaptability PIA: Model AP: Model PDA: Model APR: Model PSM: Model

  24. 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

  25. 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

More Related