1 / 16

MDD – Model Driven Development MDA – Model Driven Architecture

OMG MDA Model-Driven Architecture abstractions - Using UML for EDOC for CORBA, J2EE, XML and MS .Net Enterprise Collaboration Architecture and Distributed Component Profile - responses to OMG MDA and OMG UML for EDOC – input to UML 2.0.

joella
Download Presentation

MDD – Model Driven Development MDA – Model Driven Architecture

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. OMG MDA Model-Driven Architecture abstractions - Using UML for EDOCfor CORBA, J2EE, XML and MS .NetEnterprise Collaboration Architecture and Distributed Component Profile - responses to OMG MDA and OMG UML for EDOC – input to UML 2.0 MDD – Model Driven DevelopmentMDA – Model Driven Architecture Arne-Jørgen Berre SINTEF Tele og data, Oslo Distributed Information Systems Phone: (+47) 22 06 74 52 E.mail: Arne.J.Berre@informatics.sintef.no

  2. OMG Model-Driven Architecture

  3. MDA – Model Driven Architecture PIM: Platform Independent Model UML UML and/or Platform specific notation PSM: Platform Specific Model PSM: Platform Specific Model PSM: Platform Specific Model PSM: Platform Specific Model Platforms: Web Services, ebXML, J2EE/EJB, CORBA, MS .Net, …

  4. Versioned RegRep MDA PIM and PSM Model composition OMG Domain Models Enterprise models Platform Independent Model PIM <<realize>> Platform-specific artifacts Platform Specific Model PSM map configuration Non-normative Enterprise- And Supplier-Specific configuration map Enterprise Deployment Model • Evolution management: • Business, model, technology, deployment

  5. Isolates domain specifications from platform details Reduces complexity Preserves domain model semantics Increases stability and lifetime Generates to platform/legacy of choice Decreased development time fast iterative development separation between the engineering and business requirements Increased quality. Builds on industry directions Many partial implementations exist Tool/platform support proliferating Summary of MDA benefits for Domain Specifications. Users Domain Specifications MDA

  6. Work/Code on a higher/better abstraction level: Assembler (1950) – 3GL (1960) – (Java/Smalltalk bytecode compilation, since 1980) – What’s next ? Agile: You express executable models in direct cooperation with your customers (in an old language?) – i..e AM/XM, Agile Modeling, Extreme Modeling Issue: What are the right language abstractions (i.e. relationships/associations, components, services, ..) – can be domain specific Creation of domain specific languages – through metamodel configuration CBSE in this contexct – Reusable Model components … MDD-x is your next programming language

  7. Executable models • OCL++ Expressions • Business semantics • Action semantics PIM Semantic Precision Extensions MOF Platform-specific Environment UML Engine Adaptors • Direct model execution • Continuous operation • Version controlled transition • Management for multiple abstraction levels agents Management services

  8. Synchronised model transformations UML Tool View Of Model PIM Change events Native model IDE View Of Artifacts PSM isomorphic Change events Deployment Tool View • Platform/Artifact-specific views; developer choice of views • Multi-tool/view/model synchronization • Incremental, iterative development

  9. MOF 2.0 XMI 2.0 UML 2.0 OCL 2.0 QVT OMG MDA technologies Microsoft “White Horse” – “secret product” • Previously OMG MDA active people • Steve Cook (prev. IBM) • Jack Greenfield (prev. Rational) • Wojtek Kozaczynski (prev. Rational) • Stewart Kent (prev. IBM/Univ. Kent)

  10. Architecture Patterns Business Process Event Entities Relationship Process Process Process Process Collaboration Component Architecture Message Model Mapping Component Model Mapping ebXML MOM COM CORBA EJB UML EDOC & Technology Mapping Enterprise Collaboration Architecture Work Flow ebXML BP FCM DCP Webservices

  11. Higher level abstractions Domain specific abstractions Model transformation tools (QVT ++) Executable models – virtual machines Reusable models / components Some MDD/MDA research issues

  12. Issues related to the classification model: Concept: Which abstractions ?, run time mapping Process/Roles: Methodology for MDD Business: Market for models Product: xx.ilities Technology: Dev. Env, standards Off-the-shelf: Selection, customisation, Rel.paradigm: Agile methods, CBSE, SoA Structuring of issues, MDD

  13. C; Level above, CIM – to be investigated further C: More needed for behavioural specifications (rules, ext. seq diagrams, Java code) – understanding / assesment Ps: Agile methods – vs Product lines vs MDD C: UML formal semantics ? (Behaviour vs meaning of the language) T: Code generation vs execution – lack of efficient tools C; SW Arch (ADLs) vs. UML C: Declarative vs Operational specifications/models C/T: Model driven vs Object oriented (OO produces models) – sequence/state diagrams could be oo implemented (libraries) C: Model: abstraction, purpose (understand vs execute) C: From an analysis model to a good component specification/impl – how to distinguish problem from solution ? P: SEI, Constructive vs. Analytical interface (QoS), .. P: UML Component model – functional/non-functional interfaces Ps: Horizontal modellers versus vertical mapping/transform. Modelers Incremental model compilation, model interfaces (to be Agile) Aspect oriented languages and models/CBSE MDD Issues

  14. Dangerous metaphors Lehmans law,Belady: 1985, Continuing change, increasing compexity 1. Composition languages, scripting, AD, coordination, glue (Piccola) agents, forms, scripots, channels,. 2. Component Models. Trends – Pecos, CBSE for Field devices (ABB), ref. automotive industry (passive, active, event components – data sharing, verification) 3. Component Migration – legacy sw systems – Moose language-independent reengineering platform FAMoose -metrix/visualisation -nr att, nr methods, … OO Reeng. Patterns book Coping with evolution – are components the ansewer

  15. Composition languages and infrastructures (TRAITS – EOCOP, OOPSLA 2003) Domain specifici component models Component migration Testing strategies for continuous development Agile processes (implicit architecture) Architecture driven sw development Research agenda

  16. Recovering traceability links Code path Document path Evolution Is important – has CBSE a role to play ? – composition (adaption, flexibility, …) Where to take components from

More Related