AP4 – Introduction to Model-Driven Interoperability (MDI)

AP4 – Introduction to Model-Driven Interoperability (MDI)
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 AP4 – Introduction to Model-Driven Interoperability (MDI) Welcome to the AP4 course titled “Introduction to Model-Driven Interoperability (MDI)”. In this course you will learn about model-driven architecture (MDA) and its application in developing interoperable enterprise software systems. Learn about model-driven architecture (MDA) and its application in developing interoperable enterprise software systems. © The ATHENA Consortium.

Introduction to Model-Driven Interoperability - Part 4-1
Version 5 Course description Model-driven development (MDD), and in particular OMG’s Model Driven Architecture (MDA), is emerging as the state-of-the-art practice for developing modern enterprise applications and software systems. The MDD paradigm provides us with a better way of addressing and solving interoperability issues when compared to earlier non-modelling approaches. The course gives an overview of interoperability and MDA, and introduces the ATHENA Model-Driven Interoperability (MDI) Framework, which provides guidelines on how MDD can be applied to the development of interoperable enterprise software systems. Model-driven development (MDD), and in particular OMG’s Model Driven Architecture (MDA), is emerging as the state-of-the-art practice for developing modern enterprise applications and software systems. The MDD paradigm provides us with a better way of addressing and solving interoperability issues when compared to earlier non-modelling approaches. The course gives an overview of interoperability and MDA, and introduces the ATHENA Model-Driven Interoperability (MDI) Framework, which provides guidelines on how MDD can be applied to the development of interoperable enterprise software systems. © The ATHENA Consortium.

Version 5 Course objective The participants will learn about interoperability and MDA and get an overview of the ATHENA MDI Framework. The courses AP5 and AP6 explores the MDI framework in more detail. The participants will learn about interoperability and MDA and get an overview of the ATHENA MDI Framework. The courses AP5 and AP6 explores the MDI framework in more detail. © The ATHENA Consortium.

Version 5 MDI training track No Topic Presenter A P 4 4-1 Interoperability & Model-Driven Architecture (MDA) <Person>, <Company>, <Country> 5 5-1 ATHENA Model-Driven Interoperability (MDI) Framework 5-2 Metamodelling Eclipse Modeling Framework (EMF) Tutorial / Exercise 5-3 UML Profiles and Domain-Specific Languages (DSLs) Eclipse Graphical Modeling Framework (GMF) Tutorial / Exercise 5-4 Method Engineering Eclipse Process Framework (EPF) Tutorial / Exercise 6 Model Mappings and Transformations ATL Tutorial (optional) MOFScript Tutorial (optional) Model-Driven Development with PIM4SOA From PIM4SOA to Web Services PIM4SOA to XSD ATL Tutorial / Exercise From PIM4SOA to Agents 5-5 From PIM4SOA to Peer-2-Peer (P2P) This course is a part of a larger training track on model-driven interoperability (MDI). The AP4 course introduces MDA in the context of interoperability. The AP5 course focuses on metamodelling, UML profiles and domain-specific languages (DSLs), and method engineering. The AP6 course focuses on model mappings and transformations with a focus on service-oriented development with PIM4SOA, Web services, agents and peer-2-peer (P2P). © The ATHENA Consortium.

Version 5 MDI website The training track is supported by the ATHENA Model-Driven Interoperability (MDI) Framework website that provides guidelines for how model-driven development (MDD) approaches can be applied in developing interoperable enterprise software systems. © The ATHENA Consortium.

4-1. Interoperability & Model-Driven Architecture (MDA)
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 4-1. Interoperability & Model-Driven Architecture (MDA) Part 4-1. Interoperability & Model-Driven Architecture (MDA). <Presenter> <Company>, <Country> < > © The ATHENA Consortium.

Version 5 Outline Interoperability What is MDA? Standards and technologies OMG MDA standards Eclipse technologies MDA and interoperability Conclusive remarks References The outline of the course is as follows: Interoperability What is MDA? Standards and technologies MDA standards Eclipse technologies MDA and interoperability Introduction to the ATHENA Model-Driven Interoperability (MDI) Framework Conclusive remarks References © The ATHENA Consortium.

Version 5 Interoperability Interoperability © The ATHENA Consortium.

Version 5 Definition Interoperability (def.) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” – IEEE Standard Computer Dictionary The IEEE Standard Computer Dictionary defines interoperability as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged”. © The ATHENA Consortium.

Rationale for interoperability
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Rationale for interoperability Interoperability is the key to increase competitiveness of enterprises. “Enterprise systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations” – European Group for Research on Interoperability, 2002 Application integration license revenue System implementation budget Misc. Integration B$ 20% 40% Hardware 10% System interoperability is a growing interest area, because of the continuously growing need of integration of new, legacy and evolving systems, in particular in the context of networked businesses and eGovernment. Enterprise applications and software systems need to be interoperable in order to achieve seamless business across organisational boundaries and thus realise virtual networked organisations. Interoperability is seen as the key to increase competitiveness of enterprises. According to the Yankee Group the cost of non-interoperability are estimated to 40% of enterprises IT budget. The fact that the enterprise application integration (EAI) market is increasing is a clear indication of the interoperability problem. Enterprises systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations. Imp. Software Services 10% 20% The cost of non-interoperability are estimated to 40% of enterprises IT budget. (Source: the Yankee Group 2001) © The ATHENA Consortium.

Knowledge integration
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Knowledge integration The originality of the ATHENA project is to take a multidisciplinary approach by merging three research areas supporting the development of Interoperability of Enterprise Applications and Software. Architecture & Platforms Architecture & Platforms: to provide implementation frameworks, Enterprise Modelling: to define interoperability requirements and to support solution implementation, Ontology: to identify interoperability semantics in the enterprise. Enterprise Modelling Ontology ATHENA The originality of the ATHENA project is to take a multidisciplinary approach by merging three research areas supporting the development of Interoperability of Enterprise Applications and Software. Architecture & Platforms: to provide implementation frameworks, Enterprise Modelling: to define interoperability requirements and to support solution implementation, Ontology: to identify interoperability semantics in the enterprise. © The ATHENA Consortium.

4-layered view of an enterprise
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 4-layered view of an enterprise Business Operational Architecture Semantics Laws, rules, principles Agreed norms and practices Operations Strategy Procedures and routines Governance Nomenclatures Classifications Ontology tools services Dictionaries Ontologies Business terms Enterprise Knowledge Architecture (EKA) Enterprise models Metamodels and languages Enterprise templates Enterprise methodology Reference architectures Product models Information and Communication Technology (ICT) Architecture ATHENA adopts a holistic perspective on interoperability in order to achieve real, meaningful interoperation between enterprises.ATHENA builds upon the FP5 thematic network IDEAS (Interoperability Development for Enterprise Applications and Software, IST ). The IDEAS network identified the need for a structured approach to collect, identify and represent the current state of the art, vision statements, and research challenges. It defined a framework for capturing and inter-relating this information from many perspectives called the IDEAS Interoperability Framework. The business layer is located at the top of the framework. In this layer, all issues related to the organisation and the operations of an enterprise are addressed. Amongst others, they include the way an enterprise is organised, how it operates to produce value, how it takes decisions, how it manages its relationships (both internally with its personnel and externally with partners, customers, and suppliers). The knowledge layer deals with acquiring a deep and wide knowledge of the enterprise. This includes knowledge of internal aspects such as products, the way the administration operates and controls, how the personnel is managed, and so on, but also of external aspects such as partners and suppliers, laws and regulations, legal obligations, and relationships with public institutions. The ICT systems layer focuses on the ICT solutions that allow an enterprise to operate, make decisions, exchange information within and outside its boundaries, and so on. The semantic dimension cuts across the business, knowledge and ICT layers. It is concerned with capturing and representing the actual meaning of concepts and thus promoting understanding. Software platforms EKA services Business and user services Modeling tools Infrastructure services Management tools © The ATHENA Consortium.

Holistic approach to interoperability
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Holistic approach to interoperability Enterprise A Enterprise B Business Business Interoperability (def.) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” – IEEE Standard Computer Dictionary Knowledge Knowledge Semantics Semantics Application Application Data Data ICT Communication To achieve meaningful interoperability between enterprises, interoperability must be achieved on all layers: Business layer: business environment and business processes Knowledge layer: organisational roles, skills and competencies of employees and knowledge assets ICT layer: applications, data and communication components Semantics: support mutual understanding on all layers To achieve meaningful interoperability between enterprises, interoperability must be achieved on all layers: Business layer: business environment and business processes Knowledge layer: organisational roles, skills and competencies of employees and knowledge assets ICT layer: applications, data and communication components Semantics: support mutual understanding on all layers © The ATHENA Consortium.

Interoperability challenges
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Interoperability challenges Enterprise model Platform Specific Model AKM ii - EM execution platform PIM execution platform PSM execution platform Enterprise model Interoperability objective Enterprise model Platform independent Model (PIM) Platform Specific Model AKM ii - EM execution platform PIM execution platform PSM execution platform Ontology-.based semantic interoperability? Web services interoperability Platform independent Model (PIM) Integrate enterprise models (UEML) across companies and EM tools Exchange information despite semantic and syntactical incompatibility Enable enterprises to invoke services (and processes (Uddi, Soap) packaged as services) from Bpml, Bpel, Xpdl? each other, and include remote Interoperability challenges exists on the different layers: Enterprise model interoperability: Integrate enterprise models across companies and EM tools. Ontology-based semantic interoperability: Exchange information despite semantic and syntactical incompatability. Web services (technology): Enable enterprises to invoke services (and processes packages as services) from each other, and include remote services in local processes. services in local processes Network protocols © The ATHENA Consortium.

Version 5 What is MDA? What is MDA? © The ATHENA Consortium.

Model-driven development (MDD)
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Model-driven development (MDD) CIM Business Context Models Model-driven approach to system engineering where models are used in understanding design construction deployment operation maintenance modification Model transformation tools and services are used to align the different models. PIM Model transformation Software Specification Models Business-driven approach to system engineering where models are refined from business needs to software solutions Computation independent model (CIM) capturing business context and business requirements Platform independent model (PIM) focusing on software services independent of IT technology Platform specific model (PSM) focusing on the IT technology realisation of the software services Model-driven development (MDD) represents an approach to system engineering where models are used in the understanding, design, construction, deployment, operation, maintenance and modification of software systems. Model transformation tools and services are used to align the different models, ensuring that they are consistent across e.g. different refinement levels. Model-driven development in our view represents a business-driven approach to software systems development that starts with a computation independent model (CIM) describing the business context and business requirements. The CIM is refined to a platform independent model (PIM) which specifies services and interfaces that the software systems must provide to the business, independent of software technology platforms. The PIM is further refined to a platform specific model (PSM) which describes the realisation of the software systems with respect to the chosen software technology platforms. In addition to the business-driven approach, a model-driven framework should also address how to integrate and modernise existing legacy systems according to new business needs. This approach is known as architecture-driven modernisation (ADM) in the OMG. PSM Software Realisation Models Model transformation © The ATHENA Consortium.

Version 5 OMG MDA . The current state of the art in Model-Driven Engineering (MDE) is much influenced by the ongoing standardisation activities around the OMG Model Driven Architecture® (MDA®). MDA is a framework which defines a model-driven approach to software systems development. MDA encapsulates many important ideas - most notably the notion that real benefits can be obtained by using visual modelling languages to integrate the huge diversity of technologies used in the development of software systems. The current state of the art in Model-Driven Engineering (MDE) is much influenced by the ongoing standardisation activities around the OMG Model Driven Architecture® (MDA®). MDA is a framework which defines a model-driven approach to software systems development. MDA encapsulates many important ideas - most notably the notion that real benefits can be obtained by using visual modelling languages to integrate the huge diversity of technologies used in the development of software systems. © The ATHENA Consortium.

Version 5 MDA from feet (1) Use of platform independent models (PIMs) as specification Transformation into platform specific models (PSMs) using tools MDA promotes the idea of designing software systems at a platform-independent model (PIM) level which can be transformed to software implementations with model transformation technologies that incorporates the knowledge of the execution platforms in question. © The ATHENA Consortium.

Version 5 MDA from feet (2) A PIM can be retargeted to different platforms Not the only reason why MDA might be of interest to you… J2EE .Net A PIM can be retargeted to different platforms. © The ATHENA Consortium.

Automation in software development
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Automation in software development Requirements Requirements Requirements Manually implement Manually implement Manually implement High-level spec (functional and nonfunctional) Implement with Interactive, automated support Source in domain-specific language (DSL) Source in domain-specific language (DSL) Compile Compile Source in a general-purpose language, e.g., Java or C++ One of the original goals of model-driven development was to increase automation in software development. Bridging the gap between requirements and manual implementation is done by introducing new modelling and abstraction layers where development tools can provide interactive and automated support for software implementation. (may generate code in Java or C++) (may generate code in Java or C++) Compile Compile Compile Implementation Implementation Implementation © The ATHENA Consortium.

Version 5 Goals The three primary goals of MDA are portability, interoperability and reusability. The MDA starts with the well-known and long established idea of separating the specification of the operation of the system from the details of the way the system uses the capabilities of its software execution platform (e.g. J2EE, CORBA, Microsoft .NET and Web services). MDA provides an approach for: specifying a system independently of the software execution platform that supports it; specifying software execution platforms; choosing a particular software execution platform for the system; transforming the system specification into one for a particular software execution platform; The three primary goals of MDA are portability, interoperability and reusability. The MDA starts with the well-known and long established idea of separating the specification of the operation of the system from the details of the way the system uses the capabilities of its software execution platform (e.g. J2EE, CORBA, Microsoft .NET and Web services). MDA provides an approach for: specifying a system independently of the software execution platform that supports it; specifying software execution platforms; choosing a particular software execution platform for the system; transforming the system specification into one for a particular software execution platform; © The ATHENA Consortium.

Version 5 Basic concepts System Existing or planned system. System may include anything: a program, a single computer system, some combination of parts of different systems Model A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. Architecture The architecture of a system is a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors. MDA prescribes certain kinds of models to be used, how those models may be prepared and the relationships of the different kinds of models. Viewpoint A viewpoint on a system is a technique for abstraction using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within that system. View A viewpoint model or view of a system is a representation of that system from the perspective of a chosen viewpoint. Platform A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented. The OMG MDA builds on the following basic concepts: System: Existing or planned system. System may include anything: a program, a single computer system, some combination of parts of different systems Model: A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. Architecture: The architecture of a system is a specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors. MDA prescribes certain kinds of models to be used, how those models may be prepared and the relationships of the different kinds of models. Viewpoint: A viewpoint on a system is a technique for abstraction using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within that system. View: A viewpoint model or view of a system is a representation of that system from the perspective of a chosen viewpoint. Platform: A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented. © The ATHENA Consortium.

Model-driven – a definition
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Model-driven – a definition A system development process is model-driven if the development is mainly carried out using conceptual models at different levels of abstraction and using various viewpoints it distinguishes clearly between platform independent and platform specific models models play a fundamental role, not only in the initial development phase, but also in maintenance, reuse and further development models document the relations between various models, thereby providing a precise foundation for refinement as well as transformation A system development process is model-driven if the development is mainly carried out using conceptual models at different levels of abstraction and using various viewpoints it distinguishes clearly between platform independent and platform specific models models play a fundamental role, not only in the initial development phase, but also in maintenance, reuse and further development models document the relations between various models, thereby providing a precise foundation for refinement as well as transformation © The ATHENA Consortium.

MDA – Three main abstraction levels
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 MDA – Three main abstraction levels Computation independent model (CIM) The computational independent viewpoint is focused on the environment of the system and on the specific requirements of the system. A CIM represents the computational independent viewpoint. The CIM hides the structural details and, of course, the details related to the targeted platform. Platform independent model (PIM) A platform independent model is a view of the system from a platform independent viewpoint. The platform independent viewpoint is focused on the operation of the system, hiding the platform specific details. A PIM exhibits platform independence and is suitable for use with a number of different platforms of similar types. The PIM gathers all the information needed to describe the behaviour of the system in a platform independent way. Platform specific model (PSM) A platform specific model is a view of the system from the platform specific viewpoint. A PSM combines the specifications in the PIM with the details that specify how the system uses a particular type of platform. The PSM represents the PIM taking into account the specific platform characteristics. The OMG MDA defines three main abstraction levels: Computation independent model (CIM) The computational independent viewpoint is focused on the environment of the system and on the specific requirements of the system. A CIM represents the computational independent viewpoint. The CIM hides the structural details and, of course, the details related to the targeted platform. Platform independent model (PIM) A platform independent model is a view of the system from a platform independent viewpoint. The platform independent viewpoint is focused on the operation of the system, hiding the platform specific details. A PIM exhibits platform independence and is suitable for use with a number of different platforms of similar types. The PIM gathers all the information needed to describe the behaviour of the system in a platform independent way. Platform specific model (PSM) A platform specific model is a view of the system from the platform specific viewpoint. A PSM combines the specifications in the PIM with the details that specify how the system uses a particular type of platform. The PSM represents the PIM taking into account the specific platform characteristics. © The ATHENA Consortium.

Different abstraction levels and multiple PSMs
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Different abstraction levels and multiple PSMs Domain Model Business Modelling language Technology patterns Application models Application Modelling Languages Coding patterns This picture illustrates the application of the three main abstraction levels. At the top we have the domain model expressed using a business modelling language. In the middle we find the application models that are described using technology-independent application modelling languages. At the bottom we find the actual applications described according to the coding languages. Between these three layers we find technology and coding patterns that are used in the model transformations. Application Coding languages © The ATHENA Consortium.

Version 5 PIM and PSMs PIM: Platform Independent Model UML PSM: Platform Specific Model UML and/or platform specific notation PSM: Platform Specific Model PSM: Platform Specific Model PSM: Platform Specific Model This simple figure illustrates that from on platform-independent model (PIM) we can generate towards many different platform-specific models (PSMs). Platforms: Web Services, ebXML, J2EE/EJB, CORBA, MS .Net, … © The ATHENA Consortium.

Model-Driven Architecture
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Model-Driven Architecture conformsTo Metametamodel meta MOF Metametamodel element M3 meta conformsTo Metamodel element Relational metamodel UML metamodel … M2 Metamodel meta conformsTo System The model-driven architecture defines a metamodel hierarchy for modelling a system. A system is described by a model (at the M1 level). A model conforms to a metamodel (at the M2 level) which defines the modelling constructs used in the model. The metamodel itself is described in a common meta-metamodel language (at the M3 level). The meta-metamodel language in the OMG MDA is MOF. MOF defines the core modelling constructs needed to describe all metamodels of interest to model-driven development. MOF can e.g. be used to describe the UML metamodel and a relational metamodel. repOf Model element … … M1 Model © The ATHENA Consortium.

Model-Driven Architecture: Example
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Model-Driven Architecture: Example conformsTo MOF Metametamodel Class Association source destination conformsTo Relational Metamodel Type name: String Table + type * + col + owner + keyOf + key 1..* Column {ordered} conformsTo This figure illustrates an example of the metamodel hierarchy. A MOF metamodel describes two concepts Association and Class with source and destination relationships. In the relational metamodel we use the MOF modelling constructs to define Table, Column and Type as classes and relationships between these classes using the Association construct. In the relational model we used the constructs defined in the relational metamodel to describe a database table for a Book (which is the System that we are describing). System Relational Model repOf … AuthorId PagesNb Title BookId Book © The ATHENA Consortium.

Version 5 Standards and technologies – OMG MDA standards Standards and technologies – MDA standards © The ATHENA Consortium.

Version 5 MDA overview Model composition Platform Independent Model OMG domain models Enterprise models <<realize>> Platform Specific Model Platform-specific artifacts map configuration Non-normative Enterprise and supplier specific configuration Enterprise Deployment Model map In order to support the MDA approach to software development we need standards to support the description of enterprise and domain models, as well as technical models at the platform-independent and platform-specific levels. Furthermore we need standards for the management and transformation of such models. Versioned repository Evolution management: Business, model, technology, deployment © The ATHENA Consortium.

MDA technology standards
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 MDA technology standards Unified Modeling Language (UML) UML is the de-facto standard industry language for specifying and designing software systems. UML addresses the modelling of architecture and design aspects of software systems by providing language constructs for describing, software components, objects, data, interfaces, interactions, activities etc. Meta Object Facility (MOF) MOF provides the standard modelling and interchange constructs that are used in MDA. These constructs are a subset of the UML modelling constructs. This common foundation provides the basis for model/metadata interchange and interoperability. XML Metadata Interchange (XMI) XMI is a format to represent models in a structured text form. In this way UML models and MOF metamodels may be interchanged between different modelling tools. Common Warehouse Metamodel (CWM) CWM is the OMG data warehouse standard. It covers the full life cycle of designing, building and managing data warehouse applications and supports management of the life cycle. MOF Queries/View/Transformations (QVT) The goals of the QVT are to provide a standard specification of a language suitable for querying and transforming models which are represented according to a MOF metamodel. In order to support the MDA approach to software development we need standards to support the description of enterprise and domain models, as well as technical models at the platform-independent and platform-specific levels. Furthermore we need standards for the management and transformation of such models. Fortunately OMG provides a set of specifications that are publicly available at Amongst these we UML, MOF, XMI, CWM and QVT. © The ATHENA Consortium.

Current MDA Architecture
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Current MDA Architecture OrgMM Enterprise modeling expert CIM models BSVR BPDM QVT ADM OWL PIM System models Ontology ODM UML2.0 System modeling expert QVT ADM PSM System models MOF2.0 This figure illustrates the use of some of these standards at the various modelling levels in the OMG MDA. MOF2Txt ADM XMI2.0 System realisation installation expert System ATL MOFScript EMF Java API MTF (IBM) QVT (MOF2Txt) © The ATHENA Consortium.

Version 5 MDA products Adaptive, Inc.Interactive Objects Software; ArcStylerAonix's AmeosKabira Technologies, IncARTiSAN's Real-Time StudioKnowGravity's CASSANDRA b+m ArchitectureWare Kennedy Carter Ltd: iUML and iCCGBITPlan GmbH smartGeneratorLIANTIS XCoderThe Borland Approach to MDAM2VP's MDA Consulting ServicesCalKey Technologies' CaboomMASTER Project Calytrix Technologies' SIMplicityMetaMatrix CommitmentCodagen Technologies; Codagen Architect 3.2Metamaxim's modelscopeCodeless Technology's CodelessMID's InnovatorConsortium for Business Object PromotionThe MOD Group's MDA ServicesConsyst's REP ++ StudioNeosight Technologies' BoldExpress StudioCompuware OptimalJOCI's MDA Services Data Access Technologies (DAT) Provides MDA ServicesObjectFrontier's FrontierSuite David Frankel Consulting Outline Systems Inc.'s PowerRADDomain Solutions' CodeGeniePathfinder Solutions PathMATEDot Net Builders' ConstructorPlastic Software's Agora Plastic 2005EDCubed's TETProject Technology's BridgePoint and DesignPointE2E BridgerealMethods FrameworkGentastic's e-GENSelect Business Solutions' Select Component FactoryM1 Global Solutions' MDEMia-Software's Model-In-ActionHendryx & AssociatesSoftaris Pty. Ltd.: MetaBossHerzum SoftwareSoftMetaWare's Generative Model Transformer project IBM's Rational Software ArchitectSofteam and Objecteering/UML An MDA CASE ToolIKV++ GmbH; m2c(tm)CARE Technologies S.A. / SOSY Inc's OlivaNova Model Execution SystemI-Logix' RhapsodyTata Consultancy Services: MasterCraftinnoQ's iQgenTelelogic's TAU Generation2 TechOne's ACE See A lot of tool vendors support the MDA approach. A full list of available products are maintaned at © The ATHENA Consortium.

Version 5 MDA success stories Looking Glass NetworksABB Research CenterLockheed MartinU.S. Government Intelligence Agencyff-eCommerceSwedish ParliamentThe Open System Architecture for Condition Based Monitoring (OSA-CBM) ProjectSwisslog Software AGDeutsche Bank Bauspar AGCGIUNextCarter Ground Fueling Ltd.BankHOSTPostgirot Bank ABGothaer VersicherungenE-SoftSysAustrian RailwaysDanzas Group Magnet Communications, Inc.National Services IndustriesHow CodeGenie worked for AMSCredit SuisseM1 Global SolutionsDaimlerChrysler See The MDA approach has also been proved to be a successful way of developing software systems. Success stories are posted at © The ATHENA Consortium.

Version 5 Standards and technologies – Eclipse technologies Standards and technologies – Eclipse technologies © The ATHENA Consortium.

MDA-compliant Eclipse technologies
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 MDA-compliant Eclipse technologies Eclipse Modeling Framework (EMF) EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. Eclipse Graphical Editing Framework (GEF) The Graphical Editing Framework (GEF) allows developers to take an existing application model and quickly create a rich graphical editor. Eclipse Graphical Modeling Framework (GMF) The Eclipse Graphical Modeling Framework (GMF) provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF. Atlas Transformation Language The ATL project aims at providing a set of transformation tools for GMT. These include some sample ATL transformations, an ATL transformation engine, and an IDE for ATL (ADT: ATL Development Tools). Eclipse Process Framework (EPF) To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process. The Eclipse community has started to provide technology support for the OMG model-driven architecture (MDA). Eclipse Modeling Framework (EMF) EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. Eclipse Graphical Editing Framework (GEF) The Graphical Editing Framework (GEF) allows developers to take an existing application model and quickly create a rich graphical editor. Eclipse Graphical Modeling Framework (GMF) The Eclipse Graphical Modeling Framework (GMF) provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF. Atlas Transformation Language The ATL project aims at providing a set of transformation tools for GMT. These include some sample ATL transformations, an ATL transformation engine, and an IDE for ATL (ADT: ATL Development Tools). Eclipse Process Framework (EPF) To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process. © The ATHENA Consortium.

Version 5 Technology overview OMG MDA specification Eclipse technology Comments MOF EMF UML UML profile/DSL GEF GMF QVT ATL SPEM EPF XMI CWM This table lists some of the OMG MDA specifications and their implemented counterparts in Eclipse. © The ATHENA Consortium.

MDA and interoperability (1)
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 MDA and interoperability (1) Interoperability from models point of view. MDA approach tries to build a interoperable model, from enterprise models and processes to apply MDA mechanisms. Enterprise B model Enterprise B external model Enterprise A model Model composition Model exchange Enterprise A model Enterprise A external model The model-driven development approach represents a business-driven approach to software development. The MDA approach tries to build an interoperable ICT model, from enterprise models to technology models. Interoperability can be seen as a quality of enterprise software systems. Alignment of models is enabled through common metamodel. We can verify higher level interoperability through simulation. MDA also provides flexibility and adaptability to accomodate changes at a higher abstraction level. © The ATHENA Consortium.

Introduction to Model-Driven Interoperability - Part 4-1 Version 5 MDA and interoperability (2) Using transformations to get interoperability It allows document transformations on the fly. It can contribute to new approaches for semantic interpretations on information exchanges. Semantic repository Enterprise A Enterprise B Document XA Model transformation can “assure” to carry forward of interoperability achieved and/or agreed on higher level down to infrastructure (lower level). Furthermore, it allows document transformations on the fly, and can contribute to new approaches for semantic interpretations on information exchanges. Document XB Transformation © The ATHENA Consortium.

Introduction to Model-Driven Interoperability - Part 4-1 Version 5 MDA and interoperability (3) Interoperability as a quality of enterprise software systems “Assure” to carry forward of interoperability achieved/agreed on higher level down to infrastructure (lower level). Verify higher level interoperability through simulation Alignment of models is enabled through common metamodel Model-driven development is more flexible and adaptive. Interoperability as a quality of enterprise software systems “Assure” to carry forward of interoperability achieved/agreed on higher level down to infrastructure (lower level). Verify higher level interoperability through simulation Alignment of models is enabled through common metamodel Model-driven development is more flexible and adaptive. © The ATHENA Consortium.

Version 5 Conclusive remarks (1) The MDA approach promises to deliver portable, interoperable and reusable software solutions. MDA pushes the goal of using visual modelling languages to manage all aspects of systems development. It provides modelling and metamodelling technologies which can be used to align different models. We see evidence that interoperability can be supported by model transformations and metamodel alignment using MDA technologies and standards. While success stories have been posted ( and a wide range of tools are available, one can still debate whether MDA has really delivered on its promise. The MDA approach promises to deliver portable, interoperable and reusable software solutions. MDA pushes the goal of using visual modelling languages to manage all aspects of systems development. It provides modelling and metamodelling technologies which can be used to align different models. We see evidence that interoperability can be supported by model transformations and metamodel alignment using MDA technologies and standards. While success stories have been posted ( and a wide range of tools are available, one can still debate whether MDA has really delivered on its promise. © The ATHENA Consortium.

Version 5 Conclusive remarks (2) In our opinion, MDA is still immature and needs to be improved in several areas: Key technologies such as the MOF Query/View/Transformation (QVT) are still under finalization ( The “CIM”, “PIM” and “PSM” defined by MDA are causing confusion. If we regard MDA as a conceptual framework that can be used to develop concrete software development approaches the terms make sense. Pushing UML as a “platform independent” way of doing model-driven development. UML was not really designed for such a task and needs to position itself amongst the emerging domain-specific languages. A MOF-based metamodel approach could be taken here to align models expressed in different modelling formalisms. Blind focus on generating implementations from higher-level models. MDA needs to address the use of models and metadata across the whole software lifecycle. In our opinion, MDA is still immature and needs to be improved in several areas particular with respect to interoperability: Key technologies such as the MOF Query/View/Transformation (QVT) are still under finalization ( The “CIM”, “PIM” and “PSM” defined by MDA are causing confusion. If we regard MDA as a conceptual framework that can be used to develop concrete software development approaches the terms make sense. Pushing UML as a “platform independent” way of doing model-driven development. UML was not really designed for such a task and needs to position itself amongst the emerging domain-specific languages. A MOF-based metamodel approach could be taken here to align models expressed in different modelling formalisms. Blind focus on generating implementations from higher-level models. MDA needs to address the use of models and metadata across the whole software lifecycle. © The ATHENA Consortium.

Approach to developing (1)
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Approach to developing (1) The CIM, PIM and PSM models as defined by the OMG MDA provide three coarse-grained abstraction levels for describing and discussing the model-driven approach on a conceptual level. For instance a model transformation is described as a refinement from a PIM model to a PSM model. When we apply the MDA approach and develop a concrete model-driven methodology the “CIM”, “PIM” and “PSM” models are replaced by actual models. Furthermore, the methodology may define more than three abstraction levels, as well as multiple and overlapping model views. We believe that there is a need for an interoperability framework that provides guidance on how MDD should be applied to address interoperability. The CIM, PIM and PSM models as defined by the OMG MDA provide three coarse-grained abstraction levels for describing and discussing the model-driven approach on a conceptual level. For instance a model transformation is described as a refinement from a PIM model to a PSM model. When we apply the MDA approach and develop a concrete model-driven methodology the “CIM”, “PIM” and “PSM” models are replaced by actual models. Furthermore, the methodology may define more than three abstraction levels, as well as multiple and overlapping model views. © The ATHENA Consortium.

Approach to developing (2)
Introduction to Model-Driven Interoperability - Part 4-1 Version 5 Approach to developing (2) While the OMG MDA promotes UML as the visual “universal” glue suitable for modelling everything, we are also seeing a trend towards development and co-existence of several domain-specific modelling languages, e.g. supported by the Microsoft Domain-Specific Language (DSL) tools ( Such approaches are now also being discussed in various OMG forums. UML is seen as a “general-purpose” language while DSLs may be more expressive for most purposes. A model-driven framework needs to acknowledge the existence of different models and views expressed in different modelling languages. The MDA technologies can help us to align these models through a common metamodelling language on which model transformations and model mappings can be defined. While the OMG MDA promotes UML as the visual “universal” glue suitable for modelling everything, we are also seeing a trend towards development and co-existence of several domain-specific modelling languages, e.g. supported by the Microsoft Domain-Specific Language (DSL) tools ( Such approaches are now also being discussed in various OMG forums. UML is seen as a “general-purpose” language while DSLs may be more expressive for most purposes. A model-driven framework needs to acknowledge the existence of different models and views expressed in different modelling languages. The MDA technologies can help us to align these models through a common metamodelling language on which model transformations and model mappings can be defined. © The ATHENA Consortium.

Version 5 References (1) [ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST ). [OMG] OMG, "OMG Model Driven Architecture", Object Management Group (OMG). [OMG] OMG, "Unified Modeling Language (UML)", Object Management Group (OMG). [OMG] OMG, "Business Modeling & Integration DTF", Object Management Group (OMG). [OMG] OMG, "Healthcare DTF", Object Management Group (OMG). [OMG 2001] OMG, "OMG Unified Modeling Language Specification Version 1.4", Object Management Group (OMG), Document formal/ , September [OMG 2001] OMG, "Model Driven Architecture (MDA)", Object Management Group (OMG), Document ormsc/ , July [OMG 2001] OMG, "UML Profile for Enterprise Distributed Components", IONA Technologies, Inc., Rational Software Corp., SINTEF, ad/ , 2001. List of references (1). © The ATHENA Consortium.

Version 5 References (2) [OMG 2002] OMG, "Request for Proposal: MOF 2.0 Query / Views / Transformations RFP", Object Management Group (OMG), Document ad/ , April [OMG 2002] OMG, "UML Profile for Enterprise Distributed Object Computing Specification", Object Management Group (OMG), Document ptc/ , [OMG 2002] OMG, "UML Profile for CORBA Specification, Version 1.0", Object Management Group (OMG), Document formal/ , April [OMG 2003] OMG, "MDA Guide Version 1.0.1", Object Management Group (OMG), Document omg/ , June [OMG 2003] OMG, "UML 2.0 Superstructure Specification", Object Management Group (OMG), Document ptc/ , August [OMG 2003] OMG, "Business Process Definition Metamodel - Request for Proposal", Object Management Group (OMG), Document bei/ , January [OMG 2003] OMG, "UML 2.0 OCL Specification", Object Management Group (OMG), Document ptc/ , October List of references (2). © The ATHENA Consortium.

Version 5 References (3) [OMG 2003] OMG, "Meta Object Facility", Object Management Group (OMG), Document ptc/ , [OMG 2003] OMG, "XML Metadata Interchange", Object Management Group (OMG), Document formal/ , May [OMG 2003] OMG, "UML 2.0 Infrastructure Specification", Object Management Group (OMG), Document ptc/ , December [OMG 2003] OMG, "Common Warehouse Metamodel (CWM), Version 1.1", Object Management Group (OMG), Document formal/ , [OMG 2004] OMG, "Enterprise Collaboration Architecture (ECA) Specification, Version 1.0", Object Management Group (OMG), Document formal/ , February [OMG 2004] OMG, "MOF Model to Text Transformation Language Request for Proposal", Object Management Group (OMG), Document ad/ , May [OMG 2004] OMG, "UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms", Object Management Group (OMG), Document ptc/ , September List of references (3). © The ATHENA Consortium.

Version 5 References (4) [OMG 2004] OMG, "Meta Object Facility (MOF) 2.0 Core Specification", Object Management Group (OMG), Document ptc/ , October [OMG 2005] OMG, "Software Process Engineering Metamodel Specification, Version 1.1", Object Management Group (OMG), Document formal/ , January [OMG 2005] OMG, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification", Object Management Group (OMG), Document ptc/ , November [OMG 2005] OMG, "MOF 2.0/XMI Mapping Specification, v2.1", Object Management Group (OMG), Document formal/ , September List of references (4). © The ATHENA Consortium.

Version 5 This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project. This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project. Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at In other cases please, contact at the same address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder. © The ATHENA Consortium.

AP4 – Introduction to Model-Driven Interoperability (MDI)

Similar presentations

Presentation on theme: "AP4 – Introduction to Model-Driven Interoperability (MDI)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

AP4 – Introduction to Model-Driven Interoperability (MDI)

Similar presentations

Presentation on theme: "AP4 – Introduction to Model-Driven Interoperability (MDI)"— Presentation transcript:

Similar presentations

About project

Feedback