1 / 21

A Flexible MDATool Set

Explore the evolution and future of Model-Driven Architecture (MDA) tools with insights from Anneke Kleppe. This presentation dives into the role of modeling languages and the importance of abstraction in software development. Learn about existing MDA tools, their limitations, and necessary advancements to meet complex client demands. Discover new roles in the industry, such as model creators and transformation engineers, and how they contribute to improved productivity, portability, and interoperability in software solutions.

finn
Télécharger la présentation

A Flexible MDATool Set

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. A Flexible MDATool Set Anneke Kleppe Klasse Objecten

  2. Outline • Intro • Future MDA tools • Today’s MDA tools

  3. Part 0: MDA Intro

  4. Platform Independent Model  SQL - EJB   EJB - JSP PSM SQL PSM EJB PSM JSP SQL Code EJB Code JSP Code MDA Overview

  5. Why Model Driven? • Productivity? • Portability? • Interoperability? • Maintenance and documentation? • Raising the level of abstraction! • Handling more complex systems

  6. MDA: a Revolution • 1960-1970: from assembler to 3GL languages • 2000-2010: from 3GL languages to modeling languages

  7. Future software development New roles for people involved: • Model creator (PIM analyst) • Transformation engineer (PSM creator) • Transformation definition developer • Language designer

  8. Software Development in 2015

  9. Part 1: Future MDA Tools

  10. Model Editor Model Validator Model Repository Transform Def.Editor Transform Executor Language Def. Editor Language Repository Code File Generator Code File Editor(IDE) Transf. Def. Repository Tools • What type of tools are there? MDA Connectivity Bus

  11. Requirements: Modeling Tools • Multi-user • Easy switch between visual / overview and textual / detail view • Early error detection / debug options • Code completion • Version control • Everything programming IDEs offer today

  12. Requirements: Language Tools Language Def. Editor: • See Modeling Tools • Extra: support for defining semantics Language Def. Repository: • See Transf. Def. Repository

  13. Requirements: TD Editor • See Modeling Tools

  14. Requirements: TD Repository • Classifications of Transf Defs • domain->GUI, domain->Web, domain->DB • Java->ER, UML->C# • Realtime process control, data entry • Easy access: library system tags • Quality assessments

  15. Requirements: TD Executor • General (QVT) executors and hard coded ones • Tuneable • I.e. value of x in “transform all strings in UML model to CHARVAR[x]” • I.e. on/off switch for aspects • Output = input for another executor • Open source and proprietary tools • Quality assessments of tools

  16. Requirements: General • Connectivity bus that supports interoperability • For instance, by providing a single XMI parser • Open standards supporting interchange • Modeling Languages (UML XMI is not a good example) • Transformation Definitions

  17. Part 2: Today’s tools

  18. Modeling tools • Not really multi-user • Few validation options • Break between overview and detail view    

  19. Language tools It’s beauty. Look’s like a house. • No support for expressing semantics

  20. Transformation tools • No repositories • Executors mostly hardcoded • Exception: ArcStyler • Little connectivity • Not possible to make a chain of executors • Little tuneability / Do It Yourself tuneability • Some open source tools available • AndroMDA, Octopus

  21. Conclusion • Raising the level of abstraction will improve • Productivity, portability, interoperability, etc. • Fulfilling full potential needs extra attention • 100% feasible • MDA is necessary to cope with more complex client demands

More Related