1 / 15

CS22120 Model Driven Engineering and MDA Nigel Hardy

CS22120 Model Driven Engineering and MDA Nigel Hardy. Model Driven Engineering. Development focuses on creating models Models which are: close to the problem domain; therefore understandable to the user; But are the basis for implementation

edana
Download Presentation

CS22120 Model Driven Engineering and MDA Nigel Hardy

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. CS22120 Model Driven Engineering and MDA Nigel Hardy

  2. Model Driven Engineering • Development focuses on creating models • Models which are: • close to the problem domain; • therefore understandable to the user; • But are the basis for implementation • “Computer-Aided Software Engineering” from 1980s • c.f. CAE from manufacturing • Tools appeared • Developed through proprietary systems to UML

  3. Model-driven Architecture (MDA) • Object Management Group, 2001http://www.omg.org/mda/ • Basic idea: use modelling to drive development • Generate code from models • Allow rapid prototyping from models • Allow testing of models • Allows multiple targets • OS, Hardware, Storage mechanisms • Not yet a reality • Moving in this direction

  4. MDA claim - taking it to the next level

  5. Model Transformation • Platform-independent model (PIM) • ?UML • ?more domain specific • Platform definition model (PDM) • What is the target like • Platform-specific model (PSM) (or models) • Domain specific language (DSL) • or General Purpose Language (GPL) • Model Transformation Language

  6. Models? • They are all models • UML • Java • Assembler • Some closer to execution env. • Some more remote • Some more abstract and intelligible to user • Some less so • Models must all do the same thing • Logically the same • Initial models and derived models • Initial: human input • Derived - +/- automatic

  7. One we already do • E-R diagram (?UML) • PIM • SQL for relational implementation • PSM

  8. What’s wrong with what we do now? • If any modelling is done (e.g. UML) then it often gets ignored or changed when you actually build something • Separation of what you are trying to do from how you do it • Multiple implementations may differ • Application knowledge (Business Knowledge) has longest life, but is tied closely to implementation strategy at the design stage

  9. How does MDA do it better? • Stress on platform independent models (PIMs) • Transformation of platform independent models to get platform specific models (PSMs) • Multiple compatible implementations • Where the marks can be used to automate the generation of a PSM, and PSM can be used to generate code, then can change PIM, and the code will change

  10. Model right and generate code - e.g. executable UML

  11. Executable UML • A “profile” of UML • Testable • Completeness, coherence • “Compilable” to PSM

  12. Example • (data only) • Using AndroMDA (http://www.andromda.org/) • High volume biological data • “Post genomic” • Transcriptomics, proteomics, metabolomics • Complex structure • FuGE (http://dx.doi.org/doi:10.1038/nbt1347)

  13. FuGE • 1 top level model • Reasonably intelligible • XML transport implementation • JAVA class library implementation • ?SQL relational implementation • Specialisations • 'omics

  14. Advantages/disadvantages of model-driven development Advantages: • System building is done at a higher (more efficient level) • Concentrates on what is important • Emphasizes reuse • Rapid modelling could replace rapid prototyping • Documentation always matches the code (although the code is no longer important) Disadvantages: • Not working for general case (very good in some domains, e.g. telecomms) • De-emphasizes the user interface aspects • Overkill for some systems?

  15. Summary • Nothing magical about software process models • Each raises some valid issues about what is involved in developing software • Doesn’t help when scheduling tasks with main elements - down to management • Even if followed appropriately, they don’t guarantee successful project development. • Mix of staff skills • Quality procedures • Clear management

More Related