MDI

ATHENA Model-Driven Interoperability (MDI) Framework

About

Model-driven development (MDD), and in particular OMG’s Model Driven Architecture (MDA), is emerging as the state of practice for developing modern enterprise applications and software systems. The MDD paradigm provides us with a better way of addressing and solving interoperability issues compared to earlier non-modelling approaches.

The ATHENA Model-Driven Interoperability (MDI) Framework provides guidelines for how model-driven development (MDD) approaches can be applied in developing interoperable enterprise software systems.

Contributions

The following people (listed in alphabetical order by surname) have contributed to the development of the ATHENA MDI Framework:

• Gorka Benguria, ESI, Spain
• Arne-Jørgen Berre, SINTEF ICT, Norway
• Brian Elvesæter, SINTEF ICT, Norway
• Klaus Fischer, DFKI GmbH, Germany
• Thomas Friese, SIEMENS, Germany
• Xabier Larrucea, ESI, Spain
• Jörg Müller, SIEMENS, Germany
• Tor Neple, SINTEF ICT, Norway

Acknowledgements

The work is partly funded by the European Commission through the ATHENA IP (Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications Integrated Project) (IST-507849) (http://www.athena-ip.org/). The work does not represent the view of the European Commission or the ATHENA consortium, and the authors are solely responsible for the content.

Motivation and background

Interoperability

Definition

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

Rationale

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.

ATHENA project

ATHENA – Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications - is an Integrated Project sponsored by the European Commission in support of the Strategic Objective “Networked businesses and government” set out in the IST 2003-2004 Workprogramme of FP6. Building upon an ambitious Vision Statement “By 2010, enterprises will be able to seamlessly interoperate with others”, ATHENA aims to make a major contribution to interoperability by identifying and meeting a set of inter-related business, scientific & technical, and strategic objectives.

The ATHENA programme of work is defined for producing results that span the full spectrum of interoperability from technology components to applications and services, from research & development to demonstration & testing, and from training to evaluation of technologies for societal impact. In ATHENA, Research and Development is executed in close synergy and collaboration with Community Building, for ensuring that solutions to multi-disciplinary research challenges are of optimal industrial relevance leading to broad uptake by the end user.

The ATHENA consortium currently comprises 19 leading organisations in research, academia, industry and other stakeholder communities including SMEs, working collaboratively in pursuit of a common set of objectives in interoperability.

ATHENA is committed to creating a long term impact for advancing interoperability which is mainstream, inclusive and has critical mass. To this end, ATHENA is initiating an open, neutral and independent Enterprise Interoperability Centre (EIC) to which all stakeholders, in both private and public sectors, are invited to participate.

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: to provide implementation frameworks,
• Enterprise Modelling: to define interoperability requirements and to support solution implementation,
• Ontology: to identify interoperability semantics in the enterprise.

Holistic approach

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-2001-37368). 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.

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

MDI framework

Requirements of the framework

We believe that there is a need for an interoperability framework that provides guidance on how MDD should be applied to address interoperability.

The interoperability framework integrates principles of model-driven, service-oriented and adaptive software architectures:

• Model-driven architectures focus on design-time aspects of system engineering. Model-driven development methodologies describe how to develop and utilise (visual) models as an active aid in the analysis, specification, design and implementation phases of an ICT system.
• Service-oriented architecture (SOA) specifies systems composed of services offered by various service providers, which provides the basis for supporting new business models, such as “virtual organisations”.
• Adaptive software architectures focus on run-time aspects of system engineering. Agent and P2P technologies enrich an ICT system with dynamic and adaptive qualities.

Service-oriented architecture (SOA)

A service-oriented architecture (SOA) is defined by W3C as “A set of components which can be invoked, and whose interface descriptions can be published, discovered and invoked over a network.” (W3C). In a service-oriented model we typically find three roles:

• Service provider: A service provider is the party that provides software applications for specific needs as services. Service providers publish, unpublish and update their services so that they are available on the Internet.
• Service requester: A requester is the party that has a need that can be fulfilled by a service available on the Internet. A requester could be a human user accessing the service through a desktop or a wireless browser; it could be an application program; or it could be another service. A requester finds the required services via a service broker and binds to services via the service provider.
• Service broker: A service broker provides a searchable repository of service descriptions where service providers publish their services and service requesters find services and obtain binding information for these services. Examples of service brokers are UDDI (Universal Description, Discovery, and Integration) and XMethods. In many cases the role of the service broker is not explicitly needed. Services can be discovered by marketing channels or by referrals.

Adaptive business architectures

Globalisation and mass customisation are business trends that have created a situation where business processes that used to be managed by a single enterprise are now distributed and need to be planned and enacted across multiple partners. This leads to highly distributed architectures of business systems with amplified complexity and increased need for collaboration among the participating organizations. At the same time, organizations are in increasing need of solutions to allow them to cope flexibly with constantly changing environments.

MDA and adaptive architectures

The interoperability framework integrates principles of model-driven, service-oriented and adaptive architectures:

• Model-driven architectures focus on design-time aspects of system engineering. Model-driven development methodologies describe how to develop and utilise (visual) models as an active aid in the analysis, specification, design and implementation phases of an ICT system.
• Service-Oriented Architecture (SOA) specifies systems composed of services offered by various service providers, which provides the basis for supporting new business models, such as “virtual organisations”.
• Adaptive interoperability architectures focus on run-time aspects of system engineering. Agent and P2P technologies enrich an ICT system with dynamic and adaptive qualities.

Specification of the framework

The ATHENA model-driven interoperability framework builds on the vision: “Enterprises are able to flexibly develop and execute interoperable applications based on model-driven development approaches to service-oriented and adaptive software solutions”. The framework integrates principles of model-driven development, service-oriented architectures and adaptive architectures. The framework is structured in three main integration areas:

• Conceptual integration which focuses on concepts, metamodels, languages and model relationships. It provides us with a foundation for systemising various aspects of software model interoperability.
• Technical integration which focuses on the software development and execution environments. It provides us with development tools for developing software models and execution platforms for executing software models.
• Applicative integration which focuses on methodologies, standards and domain models. It provides us with guidelines, principles and patterns that can be used to solve software interoperability issues.

For each of these three areas a reference model to describe and support the application of model-driven development of software systems is specified.

Conceptual integration

The reference model for conceptual integration has been developed from a MDD point of view focusing on the enterprise applications and software system.

A computation independent model (CIM) corresponds to a view defined by a computation independent viewpoint. It describes the business context and business requirements for the software system(s). A platform independent model (PIM) corre-sponds to a view defined by a platform independent viewpoint. It describes software specifications independent of execution platforms. A platform specific model (PSM) corresponds to a view defined by a platform specific viewpoint. It describes the reali-sation of software systems. The figure shows this relationship with respect to an enterprise system. It also shows how MDA and ADM could be perceived as a “top-down” and a “bottom-up” approach to software development and integration. The models at the various levels may be semantically annotated using reference ontologies which help to achieve mutual understanding on all levels. We also see the usage of interop-erability patterns for horizontal and vertical integration.

We have identified four categories of system aspects where specific software inter-operability issues can be addressed by conceptual integration. These four aspects can be addressed at all three CIM, PIM and PSM levels.

1. Service aspects: Services are an abstraction and an encapsulation of the functional-ity provided by an autonomous entity.
2. Information aspects: Information aspects are related to the messages or structures exchanged, processed and stored by software systems or software components.
3. Process aspects: Processes describe sequencing of work in terms of actions, con-trol flows, information flows, interactions, protocols, etc.
4. Non-functional aspects: Extra-functional qualities that can be applied to services, information and processes.

All of the elements discussed above are integrated into the figure where we look at horizontal and vertical integration between multiple enterprise systems, here exemplified with two enterprise systems A and B.

We will use this reference model to address model interoperability, where meta-models and ontologies will be used to define model transformations and model mappings between the different views of an enterprise system.

• System abstraction: This dimension of system design reflects the abstraction in terms of implementation independency and is addressed by MDD.
• Generality: The applicability of a system design has impact on the adaptability and reusability of the system components.
• Viewpoint: System models represent a complex and strongly interrelated network of model entities. To address different issues and for complexity reduction different viewpoint on the model are used. This viewpoint may also be regarded for interop-erability.
• Composition: Systems are iteratively composed in a hierarchy from individual objects to the system in the enterprise context. On each of this aggregation layers the entities have to be interoperable.
• Time: The system itself is modified in status, configuration and design.
• Model abstraction: Meta-models help to describe and analyse the used models.

These dimensions can be used to analyse software systems or help to structure the system modelling process and to catalyse design decisions. Each of these dimensions may support interoperability achievements or could represent a challenge of interop-erability.

Technical integration

The reference model for technical integration has been developed from a service-oriented point of view where a software system provides a set of services required by the businesses and users of the enterprise.

The architecture of the enterprise applications and software systems can be described according to a 4-tier reference architecture where each tier provides different software services required by the enterprise. The software system itself is coupled to an ICT infrastructure illustrated by a service bus that provides the necessary communication infrastructure. Infrastructure services such as composition, mediation, matchmaking and transformation that enables interoperability between software systems should be provided. We recognize the need for a model repository for managing models of vari-ous kinds, a service registry for managing naming, directory and location of services, an execution repository for managing information and state needed in the execution of software services and processes, and a data repository for managing results and traces of the executions. The figure shows how a service bus comes into play when integrating two (or more) enterprises systems. The service bus will make use of infrastructure services, and registry and repository.

We have defined a reference architecture that separates the architecture of a software system into four logical tiers. The reference architecture consists of a local user-space called the user service domain, and a shared transactional business-space called the business service domain. The four tiers are as follows:

1. User interface tier provides presentation and user dialog logic.
2. User service tier provides the user’s model, which may include user session logic and user-side representations of processes and information. It is an abstraction for a set of business services.
3. Business service tier provides components that represent business functionality and pervasive functionality (vertical vs. horizontal services). This tier provides en-terprise-level services, and is responsible for protecting the integrity of enterprise resources. Components in this tier can be process-oriented, entity-oriented or work-flow-oriented.
4. Resource services tier provides global persistence services, typically in the form of databases. Resource adapters (e.g. JDBC or ODBC drivers) provide access, search and update services to databases and its data stored in a database manage-ment system (DBMS) like Oracle or Sybase.

In addition to these four tiers we need a service communication bus so that services deployed at the various tiers can interoperate both within a tier and across tiers.

Applicative integration

The reference model for applicative integration has been developed based on work related to enterprise architecture frameworks and software architecture frameworks. Enterprise and software models can be related in a holistic view, regardless of modelling language formalisms, by the use of metamodels. This is important in order to understand the dependencies between the different models and views to achieve interoperability.

The MDD methodology needs to follow a structured approach where interoperability requirements from business operations in a networked enterprise drive the development of software solutions. This means that MDD methodology needs to be related to enterprise architectures. A specific part needs to address how the MDD concepts and the technical software components are reflected in a model world of the enterprise. The figure shows how the model world, reflecting the applicative integration, is related to the reference models for conceptual and technical integration. Enterprise and software models can be built to understand and analyse the interoperability requirements of an enterprise.

An enterprise model describes a set of enterprise aspects, which includes business models capturing actors and stakeholders, business services, business information and business processes. These business models provide a context for the software solu-tions that needs to be developed and integrated.

Software models describe how software systems are used to support the businesses of an enterprise. The software models further refines the business models in terms of software realisation models. All these models should include descriptions of the four system aspects identified in the reference model for conceptual integration. The soft-ware models can be classified as CIM, PIM or PSM models according to a MDD abstraction.

In our interoperability framework we have identified a set of models that we see useful in achieving interoperability. However, we also acknowledge the fact that this is just a baseline. Different enterprises must be able to develop their own software views that they see purposeful. It is important that the applicative integration supports the development of a set of shared views amongst different stakeholders and provides means for managing the dependencies between these views. We believe a viewpoint-based integration approach must be chosen. This allows incorporating viewpoints, which are implicitly or explicitly defined by other enterprise or software modelling approaches into an applicative framework.

We have identified three basic viewpoints that can be used as a starting point for viewpoint-based integration of software systems; Business viewpoint focusing on the business context of the software system, Specification viewpoint focusing on the specification of the main components of the software system, and Realisation viewpoint focusing on the implementation of the software system. The figure illustrates the viewpoint metaphor exemplified using the three basic viewpoints. A business analyst is concerned with aspects related to the business context of the software system within the networked enterprise. A system architect is concerned with aspects related to the specification of the software system. A software developer is concerned with aspects related to the realisation of the software system.

Realisation of the framework

The reference models that we have just gone through specifies the conceptual part of the framework and identifies some of our MDD principles to interoperability. The realisation of the framework focuses on providing guidelines and existing method chunks for creating or customizing your own development and integration methodologies based on these principles, and guidelines and existing assets for creating or customizing your own MDI tool set.

The MDI framework aims at providing guidelines for the following topics:

• Model-driven architecture (MDA) and interoperability
• Metamodelling
• UML profiles and domain-specific languages (DSLs)
• Model transformations
• Method engineering

In addition it provides reusable assets in terms of method chunks, tools and services, models and metamodels, model transformations, DLSs and UML profiles and reference examples. The assets in the form of examples and tutorials will focus on applying Eclipse technologies for implementing your own MDI methodology and tool suite.

Courses

MDI training track

ATHENA has defined a training track on model-driven interoperability (MDI). The training track consists of three courses:

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

Model-driven architecture (MDA)

Introduction

This part of the framework describes model-driven architecture (MDA) and covers the following:

• What is MDA?
• Standards and technologies
• MDA and interoperability
• Conclusive remarks
• References

Available training material

ATHENA has defined a training track on model-driven interoperability (MDI). The training track consists of three courses:

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

What is MDA?

Model-driven development (MDD)

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.

Model-driven architecture (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.

MDA from 30.000 feet

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. A PIM can be retargeted to different platforms.

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.

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;

Basic concepts

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.

Model-driven development process

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

Three main abstraction levels

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.

MDA and interoperability

Interoperability from the modelling point of view

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.

Using transformations to achieve interoperability

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.

Standards and technologies

OMG MDA standards

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 http://www.omg.org/mda/specs.htm.

Unified Modeling Language (UML)

UML 2.0 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. UML now provides support for a wide variety of modelling domains, including real-time system modelling and is used more and more in embedded systems.

Meta Object Facility (MOF)

MOF 2.0 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. MOF plays an important role in defining transformations between models.

XML Metadata Interchange (XMI)

XMI 2.1 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.

MOF Queries/View/Transformations (QVT)

QVT 2.0 provides a standard specification of a language suitable for querying and transforming models which are represented according to a MOF metamodel.

Software Process Engineering Metamodel (SPEM)

SPEM 1.1 provides a standard for representing software development methods.

Common Warehouse Metamodel (CWM)

CWM 1.1 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.

Eclipse technologies

The Eclipse community has started to provide technology support for the OMG model-driven architecture (MDA).

Eclipse Modeling Framework (EMF)

 http://www.eclipse.org/emf/

"EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose, then imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications."

Eclipse Graphical Editing Framework (GEF)

http://www.eclipse.org/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)

http://www.eclipse.org/gmf/

"The Eclipse Graphical Modeling Framework (GMF) provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF. The project aims to provide these components, in addition to exemplary tools for select domain models which illustrate its capabilities."

Atlas Transformation Language (ATL)

http://www.eclipse.org/gmt/

The goal of the Eclipse Generative Modeling Tools (GMT) project is to produce a set of prototypes in the area of model-driven engineering (MDE). Amongst the technologies under the GMT project we find the Atlas Transformation Language (ATL) http://www.eclipse.org/gmt/atl/.

"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)

http://www.eclipse.org/epf/

"The Process Framework Project has two goals:

• To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process.
• To provide exemplary and extensible process content for a range of software development and management processes supporting iterative, agile, and incremental development, and applicable to a broad set of development platforms and applications."

Conclusive remarks

Promises

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 (http://www.omg.org/mda/products_success.htm) and a wide range of tools are available, one can still debate whether MDA has really delivered on its promise.

Immature

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 (http://www.zurich.ibm.com/pdf/ebizz/gardner-etal.pdf).
• 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.

Approach to developing

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.

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 (http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx). 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.

References

OMG MDA standards

[OMG] OMG, "OMG Model Driven Architecture", Object Management Group (OMG). http://www.omg.org/mda

[OMG] OMG, "Unified Modeling Language (UML)", Object Management Group (OMG). http://www.uml.org

[OMG] OMG, "Business Modeling & Integration DTF", Object Management Group (OMG). http://bmi.omg.org/

[OMG] OMG, "Healthcare DTF", Object Management Group (OMG). http://healthcare.omg.org/

[OMG 2001] OMG, "OMG Unified Modeling Language Specification Version 1.4", Object Management Group (OMG), Document formal/01-09-67, September 2001. http://www.omg.org/docs/formal/01-09-67.pdf

[OMG 2001] OMG, "Model Driven Architecture (MDA)", Object  Management Group (OMG), Document ormsc/01-07-01, July 2001. http://www.omg.org/docs/ormsc/01-07-01.pdf

[OMG 2001] OMG, "UML Profile for Enterprise Distributed Components", IONA Technologies, Inc., Rational Software Corp., SINTEF, ad/01-02-26, 2001.

[OMG 2002] OMG, "Request for Proposal: MOF 2.0 Query / Views / Transformations RFP", Object Management Group (OMG), Document ad/02-04-10, April 2002. http://www.omg.org/docs/ad/02-04-10.pdf

[OMG 2002] OMG, "UML Profile for Enterprise Distributed Object Computing Specification", Object Management Group (OMG), Document ptc/02-02-05, 2002. http://www.omg.org/technology/documents/formal/edoc.htm

[OMG 2002] OMG, "UML Profile for CORBA Specification, Version 1.0", Object Management Group (OMG), Document formal/02-04-01, April 2002. http://www.omg.org/docs/formal/02-04-01.pdf

[OMG 2003] OMG, "MDA Guide Version 1.0.1", Object Management Group (OMG), Document omg/03-06-01, June 2003. http://www.omg.org/docs/omg/03-06-01.pdf

[OMG 2003] OMG, "UML 2.0 Superstructure Specification", Object Management Group (OMG), Document ptc/03-08-02, August 2003. http://www.omg.org/docs/ptc/03-08-02.pdf

[OMG 2003] OMG, "Business Process Definition Metamodel - Request for Proposal", Object Management Group (OMG), Document bei/03-01-06, January 2003. http://www.omg.org/docs/bei/03-01-06.pdf

[OMG 2003] OMG, "UML 2.0 OCL Specification", Object Management Group (OMG), Document ptc/03-10-14, October 2003. http://www.omg.org/docs/ptc/03-10-14.pdf

[OMG 2003] OMG, "Meta Object Facility", Object Management Group (OMG), Document ptc/03-10-04, 2003. http://www.omg.org/docs/ptc/03-10-04.pdf

[OMG 2003] OMG, "XML Metadata Interchange", Object Management Group (OMG), Document formal/03-05-02, May 2003. http://www.omg.org/docs/formal/03-05-02.pdf

[OMG 2003] OMG, "UML 2.0 Infrastructure Specification", Object Management Group (OMG), Document ptc/03-09-15, December 2003. http://www.omg.org/docs/ptc/03-09-15.pdf

[OMG 2003] OMG, "Common Warehouse Metamodel (CWM), Version 1.1", Object Management Group (OMG), Document formal/03-03-02, 2003. http://www.omg.org/docs/formal/03-03-02.pdf

[OMG 2004] OMG, "Enterprise Collaboration Architecture (ECA) Specification, Version 1.0", Object Management Group (OMG), Document formal/04-02-01, February 2004. http://www.omg.org/docs/formal/04-02-01.pdf

[OMG 2004] OMG, "MOF Model to Text Transformation Language Request for Proposal", Object Management Group (OMG), Document ad/04-04-07, May 2004. http://www.omg.org/docs/ad/04-04-07.pdf

[OMG 2004] OMG, "UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms", Object Management Group (OMG), Document ptc/04-09-01, September 2004. http://www.omg.org/docs/ptc/04-09-01.pdf

[OMG 2004] OMG, "Meta Object Facility (MOF) 2.0 Core Specification", Object Management Group (OMG), Document ptc/04-10-15, October 2004. http://www.omg.org/docs/ptc/04-10-15.pdf

[OMG 2005] OMG, "Software Process Engineering Metamodel Specification, Version 1.1", Object Management Group (OMG), Document formal/05-01-06, January 2005. http://www.omg.org/docs/formal/05-01-06.pdf

[OMG 2005] OMG, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification", Object Management Group (OMG), Document ptc/05-11-01, November 2005. http://www.omg.org/docs/ptc/05-11-01.pdf

[OMG 2005] OMG, "MOF 2.0/XMI Mapping Specification, v2.1", Object Management Group (OMG), Document formal/05-09-01, September 2005. http://www.omg.org/docs/formal/05-09-01.pdf

Metamodelling

Introduction

This part of the framework describes metamodelling and covers the following:

• Applied metamodelling
• Standards and technologies
• Examples
• Tutorials (exercises)
• References

Available training material

ATHENA has defined a training track on model-driven interoperability (MDI). The training track consists of three courses:

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

Applied metamodelling

What is a metamodel?

Metamodelling is a controversial topic which is currently critical within the UML/OMG/MDA community.

• A metamodel is just another model (e.g. written in UML) and is thus a model of a set of models.
• Metamodels are specifications. Models are valid if no false statements according to metamodel (e.g. well-formed)
• Metamodels typically represents domain-specific models (real-time systems, safety critical systems, e-business)
• The domain of metamodelling is language definition. A metamodel is a model of some part of a language. Which part depends on how the metamodel is to be used. Examples of parts are syntax, semantics, views and diagrams.

Then we also have what is known as a meta-metamodel. This can said to be a model of metamodels. Reflexive metamodel are expressed using itself. A minimal reflexive metamodel contains all of the parts used to describe the set of models that are of interest.

In its broadest sense, a metamodel is a model of a modelling language. The term ”meta” means transcending or above, emphasising the fact that a metamodel describes a modelling language at a higher level of abstraction than the modelling language itself. In order to understand what a metamodel is, it is useful to understand the difference between a metamodel and a model. Whilst a metamodel is also a model, a metamodel has two main distinguishing characteristics.

1. Firstly, it must capture the essential features and properties of the language that is being modelled. Thus, a metamodel should be capable of describing a language’s concrete syntax, abstract syntax and semantics.
2. Secondly, a metamodel must be part of a metamodel architecture. Just as we can use metamodels to describe the valid models or programs permitted by a language, a metamodel architecture enables a metamodel to be viewed as a model, which itself is described by another metamodel. This allows all metamodels to be described by a single metamodel. This single metamodel, sometimes known as a meta-metamodel, is the key to metamodelling as it enables all modelling languages to be described in a unified way.

Why metamodel?

System development is fundamentally based on the use of languages to capture and relate different aspects of the problem domain. The benefit of metamodelling is its ability to describe these languages in a unified way. This means that the languages can be uniformly managed and manipulated thus tackling the problem of language diversity. For instance, mappings can be constructed between any number of languages provided that they are described in the same metamodelling language. Another benefit is the ability to define semantically rich languages that abstract from implementation specific technologies and focus on the problem domain at hand. Using metamodels, many different abstractions can be defined and combined to create new languages that are specifically tailored for a particular application domain. Productivity is greatly improved as a result.

Uses for a metamodel can be summarised as follows:

• Define the syntax and semantics of a language.
• Explain the language.
• Compare languages rigorously.
• Specify requirements for a tool for the language.
• Specify a language to be used in a meta-tool.
• Enable interchange between tools.
• Enable mapping between models.

How to metamodel?

There is a clearly defined process to constructing metamodels, which does at least make the task a well-defined, if iterative, process. The process has the following basic steps:

1. defining abstract syntax
2. defining well-formedness rules and meta-operations
3. defining concrete syntax
4. defining semantics
5. constructing mappings to other languages

Abstract syntax

The metamodel describes the abstract syntax of a language. The abstract syntax of a language describes the vocabulary of concepts provided by the language and how they may be combined to create models. It consists of a definition of the concepts, the relationships that exist between concepts and well-formedness rules that state how the concepts may be legally combined.

Concrete syntax

Visual syntax

A visual syntax presents a model or program in a diagrammatical form. A visual syntax consists of a number of graphical icons that represent views on an underlying model.

Textual syntax

A textual syntax enables models or programs to be described in a structured textual form. A textual syntax can take many forms, but typically consists of a mixture of declarations, which declare specific objects and variables to be available, and expressions, which state properties relating to the declared objects and variables.

Semantics

An abstract syntax conveys little information about what the concepts in a language actually mean. Therefore, additional information is needed in order to capture the semantics of a language. Defining a semantics for a language is important in order to be clear about what the language represents and means.

Standards and technologies

MDA standards

OMG Meta-Object Facility (MOF)

MOF 2.0 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. MOF plays an important role in defining transformations between models.

Eclipse technologies

Eclipse Modeling Framework (EMF)

EMF is a Java framework and code generation facility for building tools and other applications based on a structured model. For those of you that have bought into the idea of object-oriented modeling, EMF helps you rapidly turn your models into efficient, correct, and easily customizable Java code. For those of you that aren't necessarily sold on the value of formal models, EMF is intended to provide you with the same benefits and a very low cost of entry.

We can say that EMF provides a low cost entry, because an EMF model requires just a small subset of the kinds of things that you can model in UML, specifically simple definitions of the classes and their attributes and relations, for which a full-scale graphical modeling tool is unnecessary.

Actually, EMF started out as an implementation of the MOF specification but evolved from there based on the experience we gained from implementing a large set of tools using it. EMF can be thought of as a highly efficient Java implementation of a core subset of the MOF API. However, to avoid any confusion, the MOF-like core meta model in EMF is called Ecore
 

Examples

Example #1: Metamodel for service-oriented architecture (SOA)

Introduction

In order to reduce the gap between enterprise models and the service oriented implementations, a key result of A6 is the development of the PIM4SOA, taking on a model-driven stance. On the one hand applying this approach allows the separation of concerns between the business solutions, the logical solutions and the technology used, avoiding organisations having to reinvent the wheel when there are changes at the logical or technical layer. On the other, using an model-drven approach makes it possible for us to implement the same system functionality on different or combined platforms. For example, Web services technology could be used with peer to peer and agents technologies to provide new reasoning capabilities.

To implement the MDA approach first we need to identify the platform independent metamodel to be used to represent the logical solution; and second we need to identify candidate platform specific metamodels that will be used to generate the platform assets. Besides this, we require appropriate transformations between both abstraction levels, and possibly transformation to the new metamodel from higher abstraction metamodels.

The PIM for SOA metamodel covers four important aspects: service, process, information and quality of service.

• Information: in the context of virtual enterprises information represents one of the most important elements that need to be described. In fact the other aspects manage or are based on information elements.
• Service: our main intention is to be able to describe SOA independently from the technology used. Service represents business accessible functionality.
• Process: processes describe a set of interactions amongst services in terms of messages exchange.
• QoS a suitable feature is the description and the modelling of non-functional aspects related with the services described.

Service metamodel

This section describes the elements in the service oriented metamodel. Most of them have already been defined in [2]. This section is focused on service aspects. The service oriented metamodel has the objective of describing service architectures as proposed by the W3C [28]. These architectures represent the functionalities provided by a system or a set of systems to achieve a shared goal. These functionalities could be represented as a service or as a set of services. In this work we emphasise the concept of collaborations to address the different levels of service description. In this section we sketch out the main components of the service oriented metamodel.

Collaboration

Collaboration represents a pattern of interaction between participating roles. A binary collaboration specifies a service. A Collaboration definition contains a set of roles (provider, requester) and a set of collaboration use. Eventually it could be related with non-functional aspects. A Collaboration is related with a registry where it is specified the endpoints. Basically the attributes are:

• Subcollaborations: represent the usage of other collaborations
• Constraints: a collaboration could be constrained by the specification of a process.
• Roles:the roles involved within the collaboration
• Nfa: this element sets up a link to quality of service model definition
• Endpoint: we can specify at design time the end points
• RegistryItem: we can specify the registry item associated with the collaboration

CollaborationUse

A CollaborationUse represents the usage of collaboration. In other words, a CollaborationUse is the model element to represent a usage of a service. The CollaborationUse contains a reference to the endpoint pointing out the address. Its attributes are:

• Collaboration: specify a link to the collaboration definition
• Bindings: specify a link to specific roles within the current collaboration and within the current collaboration use
• RegistryItem: specifies which the registry item is.
• Nfa: specifies the link to quality of service attributes.

Role

A Role represents a part involved in a service. In fact, this part is considered as a composite structure of a service. From a service point of view, a Role could be a requester or a provider. In addition a Role is described as a composite structure of a collaboration or a service provider. Its attributes are:

• Provides: specify the item that he/she/it would provide
• Messages: specify the messages related with this role
• RoleType:This property specifies the type of the Role. Basically a Role can be a “requester” or a “provider”. If it is not none of them we can specify it as “other” and in the property “Other” we specify the name.
• Other: This property is only used for the special case where the role is neither a “requester” nor a “provider”.

RoleBinding

A RoleBinding relates a role with a usage of a service. When we specify a collaboration use we need to identify which are the roles involved This relationship is made between two Roles: one inside the collaborationUse and other inside a collaboration definition. Its attributes are:

• Role: This element represents a link to specific role within the collaboration definition of the current collaboration use
• BoundRole: This element represents a link to specific role within the current collaboration

RoleType

In a service oriented domain two are the RoleTypes identified: the requester and the provider. A RoleType provides a meaning for a specific part inside a collaboration and collaborationuse. This element is an enumeration composed by: “Provider”, “Requester” and “Other”.

Behaviour

Behaviour is an abstract class for the specification of messages sequence within a service.  This element represents a super class connecting a service aspect with process aspect.

ServiceProvider

A ServiceProvider specify an entity describing and specifying in its turn services, roles and constraints. ServiceProvider represents a service specification containing the specification of other services. Non functional aspects could also be added to specify quality aspects. These aspects are described using the OMG standard for quality of service [24]. Its attributes are:

• Behaviour: represents the process
• Participates: contains a set of the collaboration uses.
• Roles: defines the roles involved at this level.
• Nfa: establishes the link to the quality of service model
• QosCategory: defines the category in terms of quality of service
• Type: refers to the type of provider: “Abstract” or “Executable”

EndPoint

An EndPoint represents an address identifying a service. This element satisfies the W3C definition and it identifies univocally a service. It contains a name and an address. Its attributes is:

• Address: defines a string indicating the address

Registry

A Registry model element is based on index approach containing addressable services. A Registry contains RegistryItems and it references collaborations and their endpoints. It contains a set of registry items.

RegistryItem

A RegistryItem represents a service and an end point. A RegistryItem is contained by a registry. Its attributes are:

• Endpoint: represents a link to an end point (where it is located a service)
• Collaboration: represents a link to a collaboration
• CollaborationUse: represents a link to a collaboration use

Message

A message model element defines a chunk of information sent from one role to other role in a collaboration. A message is owned by a specific role. Its attributes are:

• Contains: defines a set of items related with the message
• Type: defines the type of the items related with the message
• Mode: differentiates messages between “regular” (normal) or “fault” (exceptions)

MessageMode

MessageMode differentiates between two kinds of messages. This element is a simple enumeration:

• “regular”: for normal messages
• “fault”: for exceptions

Information metamodel

This section describes the concepts needed to model information at a platform independent level. The starting point for the information-oriented metamodel are the UML constructs used in “plain vanilla” class modelling. We should be careful and try to avoid introducing new unnecessary concepts for information modelling. As this metamodel is based on EDOC [19] as well as on the Class related parts of the UML metamodel, we describe the basic elements and we provide an overview of the related metamodels. This section describes succinctly the main elements to represent information in the metamodel. Mainly it is based on UML2.0 elements
 

Item

Item defines the set of elements that a role manages.

ItemType

ItemTypes represents simple types: string, integer and boolean.

Association

Association represents the association between two entities. It is used to describe complex types. Container, contained and cardinality are the attributes necessary to related elements.

Document

Document represents an object with a specific structure and composed by entities. Document is a stereotyped package containing the structure of the document.

TypeLibrary

TypeLibrary defines a packaging structure containing some types of the application TypeLibrary is a stereotyped package containing data types.

Entity

Entity represents a structure element of information. Entity is a stereotyped class.

Process metamodel

The process metamodel is founded on work still in progress [10] for the BPDM [20] RFP from the OMG, with some modifications to allow integration with cross business process models and the other PIM4SOA packages.

The process elements of the PIM4SOA metamodel are shown below. The process aspect is closely linked to the Service aspect, the primary link being the abstract class ‘Scope’ above, which can be instantiated as a Process belonging to a ServiceProvider from that aspect.

The process contains a set of Steps (generally Tasks), representing actions carried out by the Process. A Process consists of StructuredTasks (sub-processes), Steps (atomic tasks and actions, at the PIM level), and Interactions/Flows linking the tasks together. These essentially fall into two categories, interactions with other Service Providers, or specialised actions requiring implementation beyond the scope of this model. For example, manual tasks to be processed by humans, or extensive computation requiring platform specific code.

The Process also contains a set of Flows between these actions, which may be specialises (ItemFlow) to indicate the transfer of specific data. This allows flexibility in that a business modeller bay choose to start by showing only control flow, and later refine the model to include information. This links in to the Item/ItemType parts of the Information aspect. Flows may diverge or reconverge using Guard and Join specifications.

Scope

Scope is an abstract container for individual behavioural steps. This is subclassed only by Process and StructuredTask (Process is the top level behavioural object, StructuredTask may be used to group related Steps in a ‘subroutine’ like manner.)

Step

Step is a single node in a process, such as making a decision or calling an external service. The ‘everyday’ specialization of Step is Task.

Process

Implements a behaviour for a service provider, as a set of tasks and decisions (Steps) linked by control flows (Flows), optionally including detail on the exchanged messages / items.

Structured Task

A composite task consisting of a collection of Steps related to a specific subsection of a Process

Task

The low level ‘building blocks’ of a process – these might be for example calls to another service (which can be transformed largely automatically to an implementation platform, with reference to the relevant collaborations) or might require manual intervention – either in the form of hand coded functions, or human interaction with the process.

• Collaboration Use Path: This is a path through the tree of CollaborationUses associated with this ServiceProvider. It must start with a CollaborationUse participated in by this SP, and walk through any sub collaborations to the ‘real’ collaboration being implemented by this Task

Interaction

Defines an interface for input or output flows on a Step. Can be viewed as a set of Pins, though it is not compulsory to refine the model to this level (depending on aims of the model). If the step is viewed as a service, this is similar to the declaration of a method/function in the interface (specifying a set of parameters or a ‘return value’).

Pin

Input or output for a specific item type when a flow connects to a Step in the Process. An example might be a CheckStockLevel task, with an input interaction, where one pin is tied to the item code being checked (perhaps of item type StockCode). If the step is viewed as a service, this is similar to an individual parameter to a function, or a component of the return value. The Parameter or Attribute referenced should be an appropriate sub-component of the message for the owning interaction.

• (ONE of the following should be used, dependant on message type being refined)
• Parameter: where a message has been defined as a set of items, this refers to the particular item required.
• Attribute: where the message has been defined with reference to an Entity, this selects the attribute of that entity required

Flow

Flows provide the links between Steps (tasks etc.) in the behaviour. A flow may be associated with a message type being transported.

ItemFlow

A flow between specific pins on interactions to show precise relationships between output from one Step/Interaction and input on another. This is the primary mechanism for data flow in the process model (see Pin)

JoinSpecification

Defines convergence behaviour when two flows provide input to a single Step/Interaction

• rule: String defining condition. Interpretation is currently left as platform specific (for instance, BPEL transform will attempt to treat this as an Xpath expression)

GuardSpecification

Defines conditions (e.g. in terms of Pin contents) under which an output flow is or is not activated – most useful from decision nodes.

• rule: String defining condition. Interpretation is currently left as platform specific (for instance, BPEL transform will attempt to treat this as an Xpath expression)

Quality of service (QoS) metamodel

In this section we address quality aspects at service level and from a service oriented point of view. As starting point this part of the metamodel is based on the quality of service OMG standard called UMLTM Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms [24]. Therefore we have extracted a set of elements needed from this standard to describe QoS elements. Our main intention is not to implement the profile in its entirety but only the necessary elements for this domain. Additional elements need to be added to set the relationships between quality aspects and the other aspects.

Most of elements in this metamodel have been defined in the OMG standard for specifying quality of service [24].

NFA

NFA represents Non-Functional Aspects for a specific usage of a service. This element is defined in Collaboration and ServiceProvider specification. This element is related with CollaborationUse element.

• A NFA element is related with a service usage and it specifies two important concepts. On the one hand it specifies a set of quality characteristics for a service use, and on the other hand it specifies a set of values for those characteristics and the QoSConstraints applied within the service.

Example #2: Metamodel for Web services

Introduction

The world of Web services is far from being one coherent set of interrelated specifications. The different specifications that make up the so-called WS-* stack arose out of a combination of loosely-coordinated ad-hoc industry efforts, regular standardization processes such as that of the W3C [1] or OASIS [2], and vendors competing by pushing for “their” specification to become a de-facto standard.

The total number of WS-* specifications proposed at some point or another in time is not far from a hundred. Some of these specifications have since then been superseded, abandoned or merged together, while others are still in the process of getting finalised. It will probably take a few more years for all parties to agree on a common set of specification. In the meantime, practitioners have to do with a WS-* landscape that is a combination of mature and accepted specifications, such as XML, SOAP and WSDL, nearly-there specifications, such as WS-Addressing and WS-Security, and still-immature specifications, such as WS-ReliableMessaging.

The figure above shows a logical grouping of the WS-* metamodels.

Web Services Definition Language (WSDL)

This section describes the WSDL 1.1 metamodel which has been developed based on information described in [3] and [5]. WSDL 1.1 is an XML format for describing network services as a set of endpoints operating on messages. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).

A WSDL document is simply a set of definitions. There is a definitions element at the root, and definitions inside. Services are defined using six major elements:

• Types, which provides data type definitions used to describe the messages exchanged.
• Message, which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system.
• Port type, which is a set of abstract operations. Each operation refers to an input message and output messages.
• Binding, which specifies concrete protocol and data format specifications for the operations and messages defined by a particular port type.
• Port, which specifies an address for a binding, thus defining a single communication endpoint.
• Service, which is used to aggregate a set of related ports.

Types

The types element encloses data type definitions that are relevant for the exchanged messages. For maximum interoperability and platform neutrality, WSDL prefers the use of XSD as the canonical type system, and treats it as the intrinsic type system. The XSD type system can be used to define the types in a message regardless of whether or not the resulting wire format is actually XML, or whether the resulting XSD schema validates the particular wire format.

Message

Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. The set of message-typing attributes is extensible. WSDL defines several such message-typing attributes for use with XSD:

• Element, refers to an XSD element using a QName.
• Type, refers to an XSD simple type or complex type using a QName.

The message name attribute provides a unique name among all messages defined within the enclosing WSDL document. The part name attribute provides a unique name among all the parts of the enclosing message.

Port type

A port type is a named set of abstract operations and the abstract messages involved. The port type name attribute provides a unique name among all port types defined within in the enclosing WSDL document. An operation is named via the name attribute.

WSDL has four transmission primitives that an endpoint can support:

• One-way. The endpoint receives a message.
• Request-response. The endpoint receives a message, and sends a correlated message.
• Solicit-response. The endpoint sends a message, and receives a correlated message.
• Notification. The endpoint sends a message.

WSDL refers to these primitives as operations.

Binding

A binding defines message format and protocol details for operations and messages defined by a particular port type. There may be any number of bindings for a given port type. The name attribute provides a unique name among all bindings defined within in the enclosing WSDL document. A binding references the port type that it binds using the type attribute.

Binding extensibility elements are used to specify the concrete grammar for the input, output, and fault messages. An operation element within a binding specifies binding information for the operation with the same name within the binding's port type.

A binding must specify exactly one protocol. A binding must not specify address information

Port

A port defines an individual endpoint by specifying a single address for a binding. The name attribute provides a unique name among all ports defined within in the enclosing WSDL document. The binding attribute (of type QName) refers to the binding using the linking rules defined by WSDL.

Binding extensibility elements are used to specify the address information for the port.

A port must not specify more than one address. A port must not specify any binding information other than address information.

Service

A service groups a set of related ports together. The name attribute provides a unique name among all services defined within in the enclosing WSDL document.

Ports within a service have the following relationship:

• None of the ports communicate with each other (e.g. the output of one port is not the input of another).
• If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. Each port provides semantically equivalent behavior (within the transport and message format limitations imposed by each binding). This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.).
• By examining it's ports, we can determine a service's port types. This allows a consumer of a WSDL document to determine if it wishes to communicate to a particular service based whether or not it supports several port types. This is useful if there is some implied relationship between the operations of the port types, and that the entire set of port types must be present in order to accomplish a particular task.

Example #3: Metamodel for BDI agents

In the design of a multiagent systems (MAS) we can distinguish models that describe the entities at the MAS level and models that describe the internal structure and/or the behaviour of individual agents. At the MAS we find concepts like teams, agents, roles, events, and plans. At the level of individual agents we find the same concepts again (note that teams can be viewed as individual agents and vice versa), where events and plans are described in much more detail, and additional concepts like capabilities and belief data. The figure displays the metamodel for BDI agents in JDE when the system is used in the more general team mode. Teams are formed by groups of agents but may also consist of only a single agent. The metamodel explains how the basic concepts relate to each other. For goal-oriented computing the concepts Event and Plan or TeamPlan, respectively, are most important and will be discussed in more detail in the rest of this section.

Events

Events motivate an agent to take action. There are a number of event types in BDI agents, each with different uses. These different event types help to model:

• Internal stimuli – events that an agent sends to itself, usually as a result of executing reasoning methods in plans that an agent has. These internal events are integral to the ongoing execution of an agent and the reasoning that it undertakes.
• External stimuli – such as messages from other agents, or percept that an agent receives from its environment.
• Motivations – that the agent may have, such as goals that the agent is committed to achieving.

Events are the origin of all activity within an agent-oriented system. In the absence of events an agent sits idle. Whenever an event occurs, an agent initiates a task to handle it. This task can be thought of as a thread of activity within the agent. The task causes the agent to choose between the plans it has available, executing a selected plan or plan set (depending on the event processing model chosen) until it succeeds or fails.

Plans

The Plan class describes a sequence of actions that an agent can take when an event occurs. Whenever an event is posted and an agent adopts a task to handle it, the first thing the agent does is try to find a plan to handle the event.

Plans can be thought of as pages from a procedures manual, or even as being like methods and functions from more conventional programming languages. They describe, in explicit detail, exactly what an agent should do when a given event occurs. Equipped with a set of plans, an agent has a set of skills and procedural knowledge that it can draw upon as required. When the event that a plan addresses occurs, the agent can execute this plan to handle it.

Each plan is capable of handling a single event. The event it can handle is identified by the plan's #handles event declaration. When an instance of a given event arises, the agent may execute one of the plans that declare they handle this event.

An agent may further discriminate between plans that declare they handle an event by determining whether a plan is relevant. It does this by executing the relevant() method of each plan. If plans do not specify a relevant() method, they are relevant for all instances of that event. When present, the relevant() method lets a plan specify exactly which instance of a given event it is relevant for.

Once the relevant plan(s) have been identified, the agent determines which of these are applicable. It does this by executing the plans' context() method. The context method is a logical expression that can bind the values of the plan's logical members. For every possible set of bindings, a separate applicable instance of the plan is generated.

When the agent has found all applicable instances of each relevant plan, it selects one of these to execute. If the event is a BDI event, this may cause a PlanChoice event to be posted, which may initiate some meta-level reasoning within the agent to select the most appropriate plan instance. The Events section has more details on meta-level reasoning.

When the agent executes a plan, it starts by executing the plan's body() method. The body method is a special kind of method called a reasoning method. Reasoning methods are quite different from ordinary methods in Java, as they are bound by extra logical rules and conditions. Each statement in a reasoning method is treated as a logical statement that can either succeed or fail.

Failure of a plan statement will cause the body() method to fail unless the plan specifically allows for this possibility. If execution proceeds to the end of the body() method, the body() method succeeds.

The body() method can call other reasoning methods as it executes. These reasoning methods must be declared in the plan using the #reasoning method declaration. They help break complex processing down into smaller components and make plans both simpler to understand and more scalable.

Tutorials (exercises)

Tutorial #1: Develop an information metamodel in EMF

In this tutorial we will describe how to develop an information metamodel in EMF. The objective of the tutorial is to get familiar with the EMF technology that is used to describe and develop metamodels.

For the tutorial we were searching for a visual editor that had the capability and the right options to create metamodels graphically. EMF 2.2.0 together with some part of GMF features on top of it has this capability and ofers a light editor based on Ecore. This MOF-like core meta-model makes it possible to create meta-models graphically and also generates java api and classes for manipulating and persisting these meta-models.

1. Create an EMF project

An EMF model is created from the file meny choosing new->project ->empty emf project. It can also be created directly by importing an ecore file, rose model, uml model or XML schema.

The newly created EMF project contains the src class which serve in code generation. We are not going to explore the abilities of code generation in this example. The interes in this case is the ability of EMF to create metamodels. Under the src folder are listed a number of jar files assisting the project.

2. Create a model folder

We create a folder called model, which is going to contain the models we will create.

3. Create a new ecore model

The feature for creating ecore files visualy, not as a tree structure editor is new in EMF 2.2.0. It is included as a plugin example and is still experimental. This feature is i GMF.

4. Develop the metamodel

Develop the metamodel using the language constructs EClass, Generalization, EAttribute, Aggregation and Association defined in ecore (see the subsections below for details). The final metamodel should look like the figure below.

EClass

Generalization

EAttribute

Aggregation

Association

5. Create the EMF model

After creating the metamodel as an ecore file, the next step is to create the EMF model or called in another way the generator model. This model will be used to create the java interfaces and other java code needed in manipulating or persisting the instances of the metamodel.

We have to be sure that the EMF model is created from the ecore model.

The next buton in the Ecore Import window is not active unless the ecore file is loaded.

In the end we can see the genmodel which can look like an ecore file.

6. Generate model and edit code

Through model code EMF generates java interfaces and classed for every element in the model.

In most cases, the properites need not be changed from their default values, but these options can provide a great deal of control over the code that gets generated.

A fully functional Eclipse editor can also be generated for any model. By default, it is split between two plug-ins: an "edit" plug-in includes adapters that provide a structured view and perform command-based editing of the model objects; an "editor" plug-in provides the UI for the editor and wizard. In our example we will use only the edit code. The editor for this example will be shown in another tutorial about GMF.

References

Metamodelling

• [Atkinson and Kühne 2003] C. Atkinson and T. Kühne, "Model-Driven Development: A Metamodeling Foundation", IEEE Software, vol. 20, no. 5, pp. 36-41, 2003. http://www.mm.informatik.tu-darmstadt.de/staff/kuehne/publications/papers/mda-foundation.pdf
• [Clark, et al. 2004] T. Clark, A. Evans, P. Sammut, and J. Willans, "Applied Metamodelling - A Foundation for Language Driven Development, Version 0.1", 2004. http://albini.xactium.com/web/index.php?option=com_remository&Itemid=54&func=select&id=1
• [Seidewitz 2003] E. Seidewitz, "What Models Mean", IEEE Software, vol. 20, no. 5, pp. 26-32, 2003.
• [Swithinbank, et al. 2005] P. Swithinbank, M. Chessell, T. Gardner, C. Griffin, J. Man, H. Wylie, and L. Yusuf, "Patterns: Model-Driven Development Using IBM Rational Software Architect", IBM, Redbooks, December 2005. http://www.redbooks.ibm.com/redbooks/pdfs/sg247105.pdf

Eclipse technologies

• EMF, http://www.eclipse.org/emf
• Help and tutorials, http://help.eclipse.org

UML profiles and domain-specific languages (DSLs)

Introduction

This part of the framework describes UML profiles and domain-specific languages (DSLs) and covers the following:

• Language engineering
• Standards and technologies
• Examples
• Tutorials (exercises)
• References

Available training material

ATHENA has defined a training track on model-driven interoperability (MDI). The training track consists of three courses:

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

Language engineering

UML profiles

UML profiles allow us to adapt the UML language to the needs of the analysts or the application domain. Allows designers to model using application domain concepts. There are three extension mechanisms:

• Stereotypes
• Restrictions
• Tagged values

Stereotypes

A stereotype extends the vocabulary of UML with new construction elements derived from existing UML but specific to a problem domain. Can have associated restrictions and tagged values. Possibility of assigning an icon for a better graphical representation.

Restrictions

A restriction is a semantical condition represented by a textual expression. It imposes some kind of condition or requisite on the element to which it is applied. Restrictions are described in the Object Constraint Language (OCL).

Tagged values

A tagged value is a property associated to a model element. It is used to store information about the element such as management information, documentation, coding parameters, etc. Generally, the tools store this information but it is not shown in the diagrams.

How do we create DSL’s?

DSL’s can be realized in two ways, either by customization of pre-existing languages through profiles or by creating a new language with a standardized meta-data architecture based on Meta Object Facility (Meta Object Facility).

The first approach through customization is achieved by marking up UML concepts with existing stereotypes and tags. For example in PIM4SOA a “Class” is stereotyped to be an “Entity”.

The second approach is based on the idea to create a brand new DSL from scratch. This involves using MDA facilities and standards to create a model of the DSL which is used to generate a tool for the it on an existing platform.

Domain-specific languages (DSLs)

DSL (Domain Specific Languages) are modelling languages designed for a specific purpose inside a problem domain. These languages provide abstractions that are tailored to a specific domain and their advantage is their ability to directly represent domain abstractions that fit the problem domain.

A DSL can be a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. For a more specific definition of DSLs check out DSL: An Annotated Bibliography

An important aspect of DSL’s is understanding the domain concept. In the software engineering world, a domain defines a set of common requirements, terminology, and concepts that is specific to a particular application domain. A DSL can therefore be any language that provides means of expressing these concepts and is created specifically to solve problems in this particular domain. In difference to general purpose-languages like UML (Unified Modeling Language ) , a DSL is able to focus on concepts of the domain model and is not intended to be able to solve problems outside of it.

The main benefit of using a DSL is their ability to provide abstractions that are tailored to a specific problem domain and thereby a potential increase in productivity and ease of use. While it is also possible to abstract the concepts of the problem domain in UML, it is obviously more intuitive and efficient to be able to directly capture the specific domain abstractions used by the language. Some other benefits of DSL’s are the possibility to raise the level of abstraction and the ability to produce a more precise model , since it is focused in a narrower view of the problem. This leads to a more flexible and agile product.

UML profiles vs. DSLs

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 (see http://msdn.microsoft.com/vstudio/DSLTools/)

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. DSLs (Domain Specific Languages) are modelling languages designed for a specific purpose inside a problem domain. These languages provide abstractions that are tailored to a specific domain and their advantage is their ability to directly represent domain abstractions that fit the problem domain.

A DSL can be a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain. An important aspect of DSL’s is understanding the domain concept. In the software engineering world, a domain defines a set of common requirements, terminology, and concepts that is specific to a particular application domain. A DSL can therefore be any language that provides means of expressing these concepts and is created specifically to solve problems in this particular domain.

While the MDA approach treats UML, with customization, as the modelling language of choice for most application modelling, it also acknowledges the value of custom languages in certain specialized circumstances. This is the purpose of the OMG Meta-Object Facility (MOF) standard that plays an important role in MDD. UML itself is defined using MOF and there are MOF definitions of many other languages. Thus the MDA approach also allows the creation of DSLs using MOF as a basis rather than using UML profiles.

Advantages of using UML profiles

• UML is an open standard modelling language for which there are many available books and training courses.
• UML profiles provide a lightweight approach that is easily implemented using readily available UML tooling.
• Models with UML profiles applied can be read by all UML tools even if they do not have any knowledge of the profile.
• Basing all DSLs on UML creates a set of related languages that share common concepts.
• UML can be used for high-level architectural models as well as detailed models from which code can be generated.

Disadvantages of using UML profiles

• UML profiles only permit a limited amount of customization.
  • It is not possible to introduce new modelling concepts that cannot be expressed by extending existing UML elements.
• The use of UML does require familiarity with modelling concepts.
   

Standards and technologies

MDA standards

Unified Modeling Language (UML) and profiles

The realization of DSL’s through profiling is based on the existing UML2.0 standard. The OMG(Object Management Group) defines the UML profiles as a way to tailor the languages to specific areas. This areas can be from business modeling, to enterprise architectures, service oriented architectures, QoS modeling or many other technologies.

Standard profiles developed by OMG are listed at Modeling Standards Page.

The advantage with UML profiles is the existing UML standard and the tool support for it. This reduces the effort in learning a new language and developing new tools. The tools that supports UML profiling are both open source and commercial. Some of the most used in the open sourse world are Eclipse or ArgoUML , while other proprietary tools are Borland Together 2006 for Eclipse , IBM Rational Software Architect and Modeler or Microsoft Visio.

A list of OMG’s UML2 tools is provided at: UML2.0 tools

While UML profiles are quiet supported in the marked and the open source community, developing DSL’s from scratch seems to be a more tricky task. The mainstream technologies for modeling DSL’s are divided in those which use standardized MDA facilities and those based on the Software Factory idea.

Eclipse technologies

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.

GMF uses and therefore depends on EMF. GMF is not in anyway a replacement for EMF. EMF provides core facilities for defining models, and generating java code for manipulating and persisting instances of those models. The generated code includes an implementation of the observer pattern.

Because it is common for GEF editors to manipulate an object model (and use observer pattern) it pairs very well with EMF and has become a popular combination (see IBM redbook on using emf and gef).

The GMF project aims to simplify the combination of these two technologies by allows GEF editors to be specified and generated using models. i.e. GMF allows you to generate GEF editors for manipulating your EMF models.

Other technologies

XMF-Mosaic

XMF-Mosaic is a model-based development platform based on Eclipse(open source IDE) and XMF . XMF stands for (eXecutable Metamodelling Facility) and is an extension of the existing standards such as MOF, QVT or OCL, with executable metamodelling capabilities This metamodelling facility provides the ability to create languages with all the key features(here semantics and syntax), the ability to create metamodels which involves having a meta-architecture(self defined languages)and the platform independency of metamodels, key "issue" of MDA.

Visual Studio 2005 DSL Tools

Visual Studio 2005 DSL Tools are a SDK(Standard Development Kit) that allows developers to use Microsoft’s platform to build visual modelling tools that run inside of VisualStudio. DSL Tools are always associated to Software Factories. This is not rare since they realize ideas from Software Factories, but they should not be mistaken to be the Software Factories. DSLs are the first piece, they are the first product launched in the marked and more to come is predicted in the later versions of VisualStudio. The purpose of DSL Tools is to construct custom designed tools that can be used to model a problem domain. The first step is to create the model with the domain-specific notation. Then a running designer will be generated. This designer is based on the domain model created and a XML description for the user interface.

Examples

UML profile for PIM4SOA

This section sketches out the stereotypes and the base classes for the PIM for SOA elements described in this document. The PIM for SOA metamodel is based on different metamodels for several purposes. Some of them have already been defined in standards specifications (e.g. Quality of service profile) and this profile keeps these profiles as they are. We only specify the elements used for our purpose.

The PIM for SOA metamodel is composed by four aspects: Service, Process, Information and quality of service aspects. Each aspect is related with a set of elements of the profile. For a clear profile description these elements are described separately in different sections.

UML extensions for service modelling

UML extensions for process modelling

UML extensions for information modelling

UML extensions for quality of service modelling

UML profile for Web services

The ATHENA Web service profiles feature for RSM is packaged as an Eclipse feature. An Eclipse feature is the smallest unit of separately downloadable and installable functionality for the Eclipse IDE. The Web services feature contains a set of Eclipse plugins that have been developed to extend the RSM tool with modelling support for Web services. The feature contains the following plugins:

• Web Service Basic Profile: This plugin implements the base UML modelling support for how to specify and develop Web services. This plugin can be extended with other specific Web service technology profiles (e.g. XSD, WSDL and BPEL) each covering different parts of the Web service stack.
• UML Profile for XSD: This plugin implements UML modelling support for XML Schema definitions
• UML Library for XSD: This plugin defines XSD types to be used when modelling XML Schema definitions in UML.
• UML Profile for WSDL: This plugin implements UML modelling support for WSDL.
• UML Profile for BPEL: This plugin implements UML modelling support for BPEL.

UML profile for XSD

The implementation of the UML profile for XSD has been based on the specification by David Carlson [Carlson]. A definition of UML extensions is given in the table below.

UML profile for WSDL

The implementation of the UML profile for WSDL has been based on specifications documented in [Provost] and [V. de Castro, et al. 2004]. A definition of UML extensions is given in the table below.

UML profile for BPEL

The implementation of the UML profile for BPEL has been based on the specification by Tracy Gardner et al. [Gardner 2003][Amsden 2003]. A definition of UML extensions is given in the table below.

Tutorials (exercises)

Tutorial #1: GMF editor for PIM4SOA

0. Editor generation overview

This is a UML2.0 activity diagram showing the steps in the process of creating a GMF editor.

The creation of an editor based on a domain model starts by creating a GMF project. In the same way as with EMF, a ecore file can be included in the project or created using EMF facilities or GMF features, like initialization of ecore diagrams, that are put on top of the EMF features.

In the graphical definition we define figures, nodes, compartments, connections etc. The output of this definition is a gmfgraph containing the specification of these definitions.

The tooling definition model is used to specify the palette, creation tools, actions, etc. for your graphical elements.

The mapping definition model will let us bind the three models we have so far: the domain, the graphical definition, and the tooling definition. To the right is an image of this model. This is a key model to GMF development and will be used as input to a transformation step which will produce our final model, the generation model.

1. Create a GMF project

If not created before, remember to create the EMF model file(*.genmodel).

Generate the model code (java interfaces and implementation) which will be placed in the src folder.

Generate the edit code ( a new plug-in f.eks org.eclipse.gmf .examples.pim4soa.edit) that includes adapters that provide a structured view and perform command-based editing of the model objects. This steps are explained in the EMF tutorial.

In the model folder import the meta-model (ecore file).

Create the EMF model and generate model and edit code.

2. Graphical definition

We will create a graphical definition by using the GMFGraph Simple Model wizard that will guide us through this process. The first two pages of the wizard will ask you to choose a destination folder for the *.gmfgraph that will be created and locate the ecore file that you are working on.

On the last page of the wizard we will choose the elements from the meta-model that will be processed. In our example we choosed to make the package as a diagram element, the document and entitiy as nodes in the diagram(this can be done by checking out on the first column beside the element name), associations as links(the second column) and attributes of document, entity and association as labels.

The result shows a tree structure of the graphical definition when we can see definitions of figures and how they are connected to diagram elements. For a better overview of the graphical definition we advice to change the names of labels from the default form.

3. Tooling definition

As mentioned before, the tooling definition model is used to specify the palette, creation tools, actions, etc. for your graphical elements.

The wizard is closely identical to the GMF Graph Simple Model wizard and the first two pages will guide you through the same requirements.

In the last page of the tutorial we choose the Package element as the diagram element and document, entity and association as processing elements.

The result will be a tooling definition file PIM4SOA Info.gmftool that has a tool registry, a palette with a tool group called PIM4SOA(meta-model name).

The tool group has three tool creatin elements, one for each processing element that we specified in the last page of the wizard.

4. Mapping definition

The mapping definition model will let us bind the three models we have so far: the domain, the graphical definition, and the tooling definition.

You will be asked to locate and load these three models in the second page of the Guide GMFMap creation wizard. The next button will become clear when all the models are loaded.

Choose a package as the diagram root element and go on the last page of the wizard.

On the last page of the wizard select Entity and Document as nodes and Association as links. Note that you can adjust the properties for the selected node or link by using the 'Change...' button in the dialog.

In the Mapping Definition ree structure we can see the mappings that are generated for each our processing elements. In document mapping we can see from the bottom a Labbel Mapping that is a straight forward mapping with the Diagram Label property mapped to the 'EAttribute name' feature on our Topic element in the domain model.

NOTE: The wizard does not set the Diagram Labels so this must be done manually by clicking on the drop down list beside the Diagram Label property and choosing the appropriate label.(labels are defined in the graphical definition).

In the property view of the Document Node Mapping we can see that the Document Node is mapped to the Document element of the metamodel and the tool performing this is the Creation Tool Document we defined in the Tooling definition.

NOTE: Make sure that the Tool is set to the right creation tool.

5. Code generation

Now that the minimal graphical elements and mappings are defined, we can generate the code needed to test our work so far. To accomplish this, we will first create a generator model (*.gmfgen) in order to set the properties for code generation, similar to the familiar EMF genmodel.

The next step now is to generate the model code from the PIM4SOA Info.gmfgen. After the code is succesfully generated you can notice a new plugin org.eclipse.examples.pim4soa.diagram in your workspace.

6. Run the diagram

Now that the diagram plug-in is generated we can run a new eclipse application to test our diagram.

When the new eclipse application is up and running create a new project(general) and in that project create a PIM4SOA Info Diagram.

A new editor similar to the ecore editor will appear on the screen. And you can start making your pim4soa information model. In the palette you can notice the meta-model elements that we processed.

7. Refine the graphical definitions

The example we just showed was e very simple one and not a completed PIM4SOA editor. In the editor you could see that there was no differences between a document and an entity and that these did not have any attributes.

Considering to change the color of the Entity and adding attributes to Documents and Entities we can go back to the PIM4SOA_Info.gmfmap and change the specifications of the graphical, tooling or mapping definitions.

First we change the figures in the gmfmap under the gmfgraph section(or in the graphical definition). This can be done by using the tree editor and adding new children by right clicking on the object. This new children in our case are Background Constant Color. Then we add a Label in the Figure Gallery default which is called Label AttributeLabel. Also we create a Diagram Label under Canvas which is called attribute. Sett the figure of the diagram label to be Label AttributeLabel from figures.

In order to alllow attributes to be added to an entity we must create a compartment. The figure of the compartement must be set as the Entity figure.
HINT: ALWAYS validate the file whenever you change something on it.(right click -> validate)

8. Refine tooling definition

In the tooling definitions we create a new creation tool for attributes. In the creation tool we include a small and large default image.

9. Refine the mapping definitions

The mapping refinement is a tricky task, but and the developer must be carefull with choosing the containment features, elements etc.

In order to create an attribute we have to mapp it to it correspondent element in the meta-model.

First we create a compartment mapping for the EntityCompartement in the graphical definition. This will be placed under Node Mapping <Entity/Entity>. Under the same Node Mapping we create a Child Reference. This Child Reference needs to be edited in the property view, where the Compartement have to be set as Compartement Mapping<EntityCompartement> and Containment Feature as EReference attribute.

Under the Child Reference we create a Node Mapping from the Diagram Node , Diagram Label Attribute to the Element , EClass Attribute. Make sure that the Tool is Creation Tool Attribute.

After saving the mapping definition the generator code and model code must be regenerated.

10. The final editor

Here is the new generated editor with a document in a lightGreen rectangle, while the entity is has a lightGray background. In the entity element you might notice that now they have attributes like name and cone in the product info.

References

Language engineering

• [Atkinson and Kühne 2003] C. Atkinson and T. Kühne, "Model-Driven Development: A Metamodeling Foundation", IEEE Software, vol. 20, no. 5, pp. 36-41, 2003. http://www.mm.informatik.tu-darmstadt.de/staff/kuehne/publications/papers/mda-foundation.pdf
• [Clark, et al. 2004] T. Clark, A. Evans, P. Sammut, and J. Willans, "Applied Metamodelling - A Foundation for Language Driven Development, Version 0.1", 2004. http://albini.xactium.com/web/index.php?option=com_remository&Itemid=54&func=select&id=1
• [Seidewitz 2003] E. Seidewitz, "What Models Mean", IEEE Software, vol. 20, no. 5, pp. 26-32, 2003.
• [Swithinbank, et al. 2005] P. Swithinbank, M. Chessell, T. Gardner, C. Griffin, J. Man, H. Wylie, and L. Yusuf, "Patterns: Model-Driven Development Using IBM Rational Software Architect", IBM, Redbooks, December 2005. http://www.redbooks.ibm.com/redbooks/pdfs/sg247105.pdf

Eclipse technologies

• EMF, http://www.eclipse.org/emf
• GEF, http://www.eclipse.org/gef
• GMF, http://www.eclipse.org/gmf
• GMF Tutorials
  • Cheat Sheats in Eclipse Help->Cheat Sheats
  • http://wiki.eclipse.org/index.php/GMF_Tutorial

Model transformations

Introduction

This part of the framework describes model transformations and covers the following:

• Model transformations
• Standards and technologies
• Examples
• Tutorials (exercises)
• References

Available training material

ATHENA has defined a training track on model-driven interoperability (MDI). The training track consists of three courses:

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

Model transformations

Model mapping and transformation

An important aspect of Model Driven Development (MDD) is model transformations, which allows automatically transformations of models. A model transformation is a transformation of one or more source models to one or more target models, based on the meta models of each of these models. In other words the instances of one meta model is transformed into instances of another meta model.

Such transformations are defined by mapping rules. Each mapping rule describes what one, or more elements in the source model should be transformed to in the target model. When all mapping rules are applied, the mapping describes the complete transformation from the source model to the target model.

Thus given a source model, and the metamodels of both the source and the target models, one can automatically generate the target model by applying the correct mapping to the source model.

A common use of transformations is the transformations of Platform Independent Model (PIM) to Platform Specific Model(PSM), and PSM to code. The PIM should, as the name implies describe the system in a total platform independent way. Thus, whether your system stores data in a database or not, or is implemented in C, C++ or Java is in no interest here. The PIM simply captures what your system does, not how. After making a PIM of the system, one should then make PSM’s for the different types of technologies used. The PSM should describe how the system is implemented, using a specific technology. In other words, if your system is implemented using Java, WSDL, and BPEL, you make one for each technology. When all the PSM’s are made, one should create mapping rules describing the transformation from the PIM, to each of the PSM’s.

As a last step, it’s now possible to describe mappings from each of the PSM’s to code. This code could be complete code, but most times it would be more of a skeleton of the code, where parts of the code would have to be manually entered.

Mapping

Mapping is performed by defining relations between two models. The relations can be 1-to-1, n-to-1, 1-to-n or n-to-n. Mapping is performed in “design time”.

The mapping is defined with models one meta-level higher than the input and output of the transformation. The mapping is used to perform transformation of instances of the mapped models. “The mapping describes the rules used for the transformation”.

We can map between models that are on the “same” abstraction level illustrated with horizontal mapping, or we can map between abstraction levels illustrated with vertical mapping in the figure below.

Transformations

A transformations occur at "run-time" and takes input and produces output. A transformation is a one-way process which transforms according to a predefined mapping. Two main categories of transformation:

• Vertical transformation
• Horizontal transformation

In a vertical transformation the source model has the same level of abstraction as target model. Not to be confused with “meta-levels”. Examples of horizontal transformation:

• Refactoring
• Merging

In a horizontal transformation the source model is at a different level of abstraction than the target model. Examples of vertical transformation:

• Refinement (specialization)
  • PIM->PSM transformations
• Abstraction (generalization)
   

Standards and technologies

MDA standards

MOF QVT

The Object Management Group (OMG) has defined a standard for model transformations in Model Driven Architecture (MDA). This standard is called Query, Views, and Transformation (QVT). Queries are performed on input models to find specific elements or transformation. An example of a query could be to find all classes in a model. Views are models derived from other models. The result of the query is a kind of view. Transformations are, as explained above, the process of transforming an input model to an output model. A more detailed description of QVT can be found at http://umt-qvt.sourceforge.net/

Queries are performed on input models for finding specific elements or information. Example: Return all classes. Views are models derived from other models. The result of a query is a kind of view. Transformations takes a model as input and creates a new model Example: PIM->PSM. Mappings are defined in Relations language or Core language. Uses Queries and Views.

To define a transformation the abstract syntax must be defined as a metamodel in MOF. Concrete syntax expressed as text (program code) or models. Transformations are defined in two variations: Declarative or imperative.

• Relations
  • Declarative specification of the mapping between MOF models
  • Equivalent with Java code (high-level)
• Relations to Core transformation
  • Equivalent with compiling Java code into byte code
• Core
  • Equivalent with Java byte code (low-level)
• Operational mappings
  • Standard language for defining Relations (or Core) in an imperative way
• Black box
  • Offers the possibility to plug-in code from any programming language with a MOF binding

Given a defined metamodel for source and target, metamodels must be well-defined according to MOF (models on level M2). One can define transformations between these two worlds in a general, standardized manner. The transformation can be used on all instances of the source metamodel. The result will be an instance of the target metamodel.

Transformation tehnologies

There are multiple technologies for mapping and transformation:

• Java
• IBM Model Transformation Framework (MTF)
• Atlas Transformation Language (ATL)
• Not many QVT-based ones: QVT support in Borland Together Architect 2006

Java

Technologies such as MDR and EMF allow for generation of Java API toward arbitrary metamodels. Using these APIs mappings can be defined in a Java program. The transformation is performed by running the Java program on a model instance given as input. The drawback is that API generation for metamodels is needed. The pros are a well-known language for mapping definition.

IBM MTF

MTF was developed in order to experiment with QVT related concepts,. MTF is not QVT compliant. MTF rules describe the relationships between the input and the output metamodel. Provides functionality to define mappings between metamodels and execute the model transformations.

Atlas Transformation Language (ATL)

The Atlas Transformation Language (ATL) is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations as described by the MDA approach. It is not QVT, but similar and with the corresponding functionality. A transformation model in ATL is expressed as a set of transformation rules. The recommended style of programming is declarative. OCL is used to expression constraints on rules. Guards (constraints) on the entry point for a rule. Different kinds of M3/M2 (meta)metamodel technology supported: Netbeans MDR and EMF Ecore. Can use either EMF or MDR metamodels as input and output. Can also be used to produce textual output.

• Developed by LINA (Laboratoire D’Informatique De Nantes Atlantique)
  • Université de Nantes Faculté des Sciences et Techniques
  • Building IRIN 2, rue de la Houssinière, BP 92208
  • 44322 Nantes cedex 3
  • France
• Proposal to the OMG MOF/QVT RFP.
• Model transformation language
  • Hybrid
    • Declarative => transformations based on simple mappings
    • Imperative => for complex mappings
  • Based on OCL
• Documentation
  • http://www.eclipse.org/gmt/atl/doc/

An ATL transformation program is composed of rules that define how source model elements are matched and navigated to create and initialize the elements of the target models. The ATL programs for model to model transformation are called modules. A module is composed of :

• Header
  • transformation name
  • variables of source and target models
• Import
  • libraries to be imported
• Helpers
  • define (global) variables and functions
• Rules
  • describe the transformation from a source model to a target model

Examples

Example #1: ATL - Book2Publish

This example shows a model to model (M2M) transformation from a book model to a publication model.

Reminder on transformation

Goal

Transform instances Book into instances of Publication.

ATL transformation code

Header

Helper

Helper to to build the author's list

Iterate on a collection

• acc is an accumulator which gets the initial value
• elem is an iterator which iterates on each element of the collection
• For each iteration expression-avec-elem-et-acc is
  • evaluated
  • and then put into acc

Helper to get the total of pages

Rule

Tutorials (exercises)

Tutorial #1: ATL - Book2Publish

This tutorial describes how to develop the Book2Publish example using Rational Software Modeler (RSM) and ATL.

Tutorial steps

Step 1: Create an ATL project Book2Publication

Step 2: Create the Book.emx metamodel (UML model)

Step 3: Export and import the Book.emx metamodel as Book.ecore

Steps 4 & 5: Create the Publication.emx metamodel (UML model) & Export and import the Publication.emx metamodel as Publication.ecore

Step 6: Create an ATL file Book2Publication.atl

Step 7: Write the ATL transformation

Step 8: Create a source model theBooks.ecore containing book instances

Step 9: Configure the ATL transformation

Step 10: Run the ATL transformation

Tutorial #2: ATL - PIM4SOA to XSD

0. Tutorial overview

In the scope of model-driven engineering, model transformation aims to provide a mean to specify the way to produce target models from a number of source models. In our example we choose to use a single input model.

PIM4SOA to XSD transformation include mapping the elements of the pim4soa meta-model to some elements of XSD meta-model. When the elements are mapped, artifacts from a model that conforms to the pim4soa metamodel( used as an input) are transformed to artifacts in another model that conforms to the XSD metamodel.

1. PIM4SOA information metamodel (source metamodel)

PIM4SOA meta-model describes the concepts needed to model information at the platform indipendent model. In our transformation we are going to use only a subpart of the elements from this meta-model. In here we describe the elements that are used in the mapping.

• ItemTypes are the basic building block and they represend simple types like string, integer or boolean
• An Association represent the association between two entities and is used to describe complex types. Container contained and cardinality are the attributes neccessary to related elements.
• A Document represents an object with a specific structure and composed by entities.
• An Entity represents a structure element of information

2. Simple XSD metamodel (target metamodel)

This is a conceptual and simplified XSD metamodel that is used only as an example. The elements of this meta-model that will be used in the mapping are the XSDSchema, which includes XSDComplexTypes that are refered as complex objects and XSDSimple types that are basic types. XSDElements and XSDAttributes are included in XSDComplexTypes.

3. Mapping

This figure shows the mapping:

• Document from the PIM4SOA metamodel maps to XSDSchema.
• Entity from the PIM4SOA metamodel maps to XSDComplexType.
• Attribute from the PIM4SOA metamodel maps to XSDAttribute.
• Association from the PIM4SOA metamodel maps to XSDElement.
• ItemType from the PIM4SOA metamodel maps to XSDSimpleType.

4. The input model

This is a simple Purchase Order modeled in a PIM4SOA editor. The editor is generated with GMF.

In the model we can find a document order, three entities orderHeader, productInfo and productRecord, respectively with their attributes, three associations and two itemtypes. This artifacts will be transformed into XSDSchema artifacts as described in the mapping.

5. Create an ATL project

Before creating a new ATL project make sure to be in the ATL prospective.

Create the Atl project and than create two folders into it. The folders could be named for metamodels and models, because PIM4SOA and XSDSchema metamodels will be placed in the metamodels folder, while the input model and the generated one will be placed in the models folder.

6. Models and metamodels

Create:

• Metamodel for PIM4SOA and XSDSchema using the ecore example diagram
• the input Purchase Order model using the PIM4SOA_INFO diagram example from GMF

If already created import the input models and metamodels to the specified folders

7. Create an ATL file

In this part we create an Atl file that will contain the neccessary Atl code for transforming the Purchase Order from a PIM4SOA model into a XSDSchema model.

The model and metamodel specifications required from the ATL File wizard are only referances. A path to the actuall file must be given to these references before the transformation is run.

The ATL file created include has the specifications that we entered in the wizard as the header. The header section defines the name of the transformation module and the name of the variables corresponding to the source and target models.It also encodes the execution mode of the module.

8. ATL rules and helpers

In Atl there exist two kind of rules: the matched and called rules. In these example we are using only matched rules. Matched rules constitute the core of an ATL transformation since they make it possible to specify for which kind of source element targets elements must be generated and the way the generated target elements have to be initialized.

The called rules provide ATL developers with convenient imperative programming facilities. Called rules can be seen as a particular type of helpers: they have to be explicitly called to be executed and they can accept parameters. However, as opposed to helpers, called rules can generate target model elements as matched rules do. A called rule has to be called from an imperative code section, either from a match rule or another called rule.

ATL helpers can be viewed as the ATL equivalent to Java methods. They make it possible to define factorized ATL code that can be called from different points of an ATL transformation.

Document2Schema

The first rule shown transforms a Document element into a Schema element. In these cases the schema takes the document name and the targetNamespace is set to http://www.w3.org/2001/XMLSchema. We also have to make sure that the Entity elements from the PIM4SOA model is put into the collection xsd_complexType, and that the ItemType elements that are not Entity elements are put into the xsd_simpleType collection.

Entity2ComplexType

The entity to complex type rule states that an entity is transformed into a complex type that will take the name of the entity. Every attribute of the entity is transformed into an xsd_attribute and the associations from this entity to other entities are transformed into xsd elements. In these cases we can se the use of a helper context that is called from a rule to retrieve all the association coming from this entity. The helper context retrieves all instances of an association and returns those that have the source entity as contained reference.

Association2Element

This rule maps associations between entities, to elements that are contained by the complexType that is referenced by the container reference of the association. The associations that are not between two entities are not mapped, as we do not need any links between the XSDSchema and the elements that comprises it. These relationships are already specified by the xsd_element aggregation of the metamodel.

Attribute2Attribute

This rule maps the attributes of the source model to attributes in the target model.

ItemType2SimpleType

Since an ItemType is a generalization of an Entity in these rules we needed some constrains in order to transform only the ItemTypes and not the Entities. Atl makes use of OCL and provides some operations useful in the constraining process. In this case a oclIsKindOf operation is used and it returns a boolean value stating whether it is either an instance of an Entity or of one of its subtypes.

9. Run the file

On the run configuration window create a new Atl Transformation(dubble click in ATL Transformation) and set the project name to be the atl project you are working on and the Atl file is the Atl file included in this project.

On the model choice specify the source and target models and metamodels. You need to set a path for these specifications and remember:

• IN -> input model(*.pim4soa)
• PIM4SOA -> source metamodel(PIM4SOA Info.ecore)
• OUT -> output model(choose your file name)
• XSDSchema -> target metamodel(XSD metamodel.ecore)

10. The result

This is the result of running the model transformation with the input model.

References

Model transformations

• OMG, "Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification", Object Management Group (OMG), Document ptc/05-11-01, November 2005. http://www.omg.org/docs/ptc/05-11-01.pdf
• INRIA, "ATL - The Atlas Transformation Language Home Page". http://www.sciences.univ-nantes.fr/lina/atl/
• Eclipse.org, "ATL Home page". http://www.eclipse.org/gmt/atl/
• IBM, "Model Transformation Framework". http://www.alphaworks.ibm.com/tech/mtf/
• IBM, "Model Transformation with the IBM Model Transformation Framework". http://www-128.ibm.com/developerworks/rational/library/05/503_sebas/

Eclipse technologies

• EMF, http://www.eclipse.org/emf
• Help and tutorials, http://help.eclipse.org

Method engineering

Introduction

This part of the framework describes method engineering and covers the following:

• Method engineering
• Standards and technologies
• Examples
• Tutorials (exercises)
• References

Available training material

ATHENA has defined a training track on model-driven interoperability (MDI). The training track consists of three courses:

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

Method engineering

Methodology definition

A method is a systematic process, technique or mode of inquiry that is used to aid in the creation of a satisfactory software product. [Blum94]. In a model-driven development approach we use a method to produce models. Method include technique and process. For example a CRC method includes CRC technique and CRC process.

• Technique: A specific construct supporting a method
• Process: A sequence of actions leading to some result

A methodology is a body of methods. It is meant to support all software development phases.

As we can see in the figure a methodology consists of a set of methods, each having their own technique and a process. A methodological process guides the usage of these methods. Methodologies typically build upon underlying concepts (or paradigms). Examples of such paradigms are: Object-oriented software development, component-based software development and service-oriented software development.

Principles for modern software development

Software development methodologies has evolved gradually over the past years. A modern software development methodology typically follows a set of these principles:

• Architecture-centric, e.g. service-oriented architecture
• Iterative and incremental process
• Service- and component-orientation
• Manage a highly dynamic environment.
  • Processes to support iterative and incremental development.
  • Software system mush be designed to be easy to change.
• Model-based
• “Round-trip” engineering
• Divide and conquer
• Quality check
• Configurable process

Process

The process depends on the type of system. It is very rare that a brand new system is being developed. Most of the cases developers are involved in re-engineering or modification. Re-engineering is a radical process of re-designing an old system while modification is a process of fixing a major problem or changing a feature. Another typical process scenario is to add new functionality to an existing system, by developing and integrating a new module (e.g. component or service).

Existing methodologies

• The Rational Unified Proces(RUP) is an iterative software development process created by the Rational Software Corporation. It is an adaptable process framework that describes how to develop software effectively using proven techniques.
• KobrA methodology for modeling architectures is a systematic approach to using UML that is refreshingly simple and straightforward. One of the problems on components is that the term "component" is so heavily overloaded . To overcome this, KobrA has introduced a new term "Komponent". Komponents are the "logical" components that represent the logical building blocks of a software system.
• Catalysis is another UML based method for object and component based development.
• Select Perspective is a methodology in agile modelling that uses multiple, best-of-breed modelling techniques, both text and diagram-based.
• The Object Oriented Role Analysise Method (OOram) is a method, based on the concept of role, for performing object-oriented modeling. OOram is a precursor for the Unified Modeling Language (UML). ( Developed by profesor Trygve Reenskaug ).
• Some other lightweight methodologies are eXtreme programing (XP), Adaptive Software Development (ASD), SCRUM – an agile method for project management, and Crystal Clear – an agile developing method.

Method engineering

From the engineering perspective, a method is made up of a set of product models and a set of corresponding process models. A product model represents the concepts that are used in the method, relationships between these concepts as well as constraints that they have to satisfy. A process model represents the way to accomplish the development of the corresponding product.

Method engineering process

In a method engineering process there are two foci:

1. Re-enginering of existing methodolologies into smaller methods or method chunks and describe the methodology as a set of configured modules. These method chunks will be stored in a method chunks repository.
2. Assembly of situation-specific methods based on existing method chunks.

Method chunk

A method chunk is an autonomous and coherent part of a method supporting the realisation of some specific system development or management activity. Such a modular view of methods favours their adaptation, configuration and extension. Moreover, this view permits to reuse chunks of a given method in the construction of new ones.

Problems and opportunities

There exist no authoritative compilations of method chunks that can be assembled to fit particular project contexts, and such that deliverables of applying one method chunk, can be mapped to inputs of another method chunk. Method chunks are rarely presented as elements that are separated from the problems solved with them, or from the cases used to illustrate their application. There is no agreed taxonomy of method chunks. Methods are in the heads of people, and not yet in the services of systems. There are no services to assess which methods to use in a given situation, given the bounded rationality of the engineer, often, sub-optimal methods are selected, making projects expensive and crippling system development.

However, there exists a near-consensus in the Method Engineering community, on the requirements for a method-chunk repository. There exists a wealth of architectural styles (service oriented, agents,...) that can assist the development of an MCR. Platforms such as ATHENA’s MPCE are offering infrastructural services, needs-awareness and proto-communities that are conducive for the MCR development and test.

To support method engineering we need a modelling and execution platform. This platform must provide use case users, developers, method chunk managers and method chunk developers appropriate workplaces with services. We also see the need for both a use case repository and a method chunk repository.

Software architecture

Even if it is used by many, the term “architecture” has no well established definition. Nevertheless, in the field of software engineering there is no shortage of more or less overlapping definitions (see for instance www.sei.cmu.edu/architecture/definitions.html). Here we present one consistent set of definitions targeting architectural descriptions for software-intensive systems, namely the IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. This recommended practice seeks to become a common frame of reference within which to codify common elements between different architectural description initiatives, and has become influential and used as a baseline for architectural description frameworks, for instance within OMG. It reflects generally accepted trends in practices for architectural description and provides a frame of reference within which future developments in software architectural technology can be deployed.

According to the recommended practice, software-intensive systems are those complex systems “where software contributes essential influences to the design, construction, deployment and evolution of the system as a whole”. The purpose of IEEE Std 1471-2000 is to facilitate the expression and communication of architectures and thereby lay a foundation for quality and cost gains through standardisation of elements and practices for architectural description of software-intensive systems. This is in contrast to past attempts at architecture description where only hardware-related architectural aspects were addressed. With increasingly complex software, architectural integrity of the software should also be addressed and the recommended practice facilitates this.

The figure shows the conceptual model of architectural description as defined in IEEE Std 1471-2000.

Starting with system, it is defined to be “a collection of components organized to accomplish a specific function or set of functions.” For the purposes of the recommended practice, “the
term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, whole enterprises, and other aggregations of interest.” From this it follows that anything can be a system as long as it fulfils some purpose (i.e., accomplishes function(s)) and one chooses to view it as a whole.

A system inhabits an environment, while the environment of a system can influence that system. The environment, sometimes referred to as the context, “determines the settings and circumstances of developmental, operational, political, and other influences upon that system. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems”. Essentially, one draws a line between the system of interest and anything outside that system that influences it in some way. This line is the interface between the system and its environment.

A system has one or more stakeholders. A stakeholder has one or more concerns relative to the system. Concerns are “those interests which pertains to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders.” Typical concerns a stakeholder can have relative to a system are functionality, performance, security, reliability, safety, etc.

A system exists to fulfil one or more missions in its environment. The existence of a system has a purpose; it should meet one or more objectives of one or more stakeholders. Often some of these objectives coincide with enterprise objectives so that using the system is an efficient use of resources in the enterprise. So far, the terminology presented has only been related to systems and their environments. However, most of IEEE Std 1471-2000 is concerned with architectural descriptions, and in the following terminology related to this are presented.

A system has an architecture and this can be described in an architectural description. Note the distinction between the architecture of a system, which is conceptual, from the description of this architecture, which is concrete. Architectural description is defined as “a collection of products to document an architecture”. The architectural description can be divided into one or several views. Each view covers one or more stakeholder concerns. View is defined as “a representation of a whole system from the perspective of a related set of concerns”. A view is created according to rules and conventions defined in a viewpoint. Viewpoint is defined as “a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis”. The distinction between view and viewpoint is analogous to that between a searchlight and what one sees using the searchlight as shown in the figure below.

Standards and technologies

MDA standards

Software Process Engineering Metamodel (SPEM)

The Software Process Engineering Metamodel (SPEM) is a metamodel and a UML profile to describe software engineering processes.

• Identifies the typical concepts of a process (process, phase, role, model, etc.)
• Defines them using UML extensions (stereotypes applied to various elements: class, use cases, operations, etc.)
• Assigns a characteristic icon to each new item.

The SPEM representation of a process is based upon the collaboration between active entities called ProcessRoles that execute tasks called Activities on concrete entities called WorkProducts. SPEM defines notational icons or graphical representation for SPEM concepts that are represented by UML stereotypes.

Modelling constructs

The concepts defined in SPEM are:

• WorkDefinition: It’s a kind of operation that describes the work performed in the process. Its main subclass is Activity, but phase, iteration and lifecycle are also subclasses of WorkDefinition.
• Activity: It’s the main subclass of WorkDefinition. An activity describes any part of work executed or assisted by a ProcessRole like tasks, operations and actions. An activity may consist of atomic elements called steps.
• Process: A Process is a ProcessComponent intended to stand alone as a complete, end-to-end process. It is distinguished from normal process components by the fact that it is not intended to be composed with other components.
• Document: It is a specialization of a WorkProduct that contains information.
• Guidance: Indirect support to actual software developers or managers working with a process-centred software engineering environment through interpretation of an instantiated process model.
• Phase: A phase is a specialization of WorkDefinition such that its precondition defines the phase entry criteria and its goal (often called a “milestone”) defines the phase exit criteria. Phases can be sequential or can run in parallel.
• ProcessPackage: It is a special notation for packages in a SPEM context. A package is a cohesive collection of work products.
• ProcessPerformer: The process performer is the performer of higher-level aggregate WorkDefinitions that cannot be associated with individual ProcessRoles. ProcessPerformer represents abstractly the “whole process” or one of its components, and is used to own WorkDefinitions that do not have a more specific owner.
• ProcessRole: The process role is the performer of activities. Also defines responsibilities over specific WorkProducts, and defines the roles that perform and assist in specific activities.
• UMLModel: It is a specialization of a WorkProduct that allows to model static, dynamic and behavioural view of process.
• WorkProduct: A work product or artefact is anything produced, consumed, or modified by a process. It may be a piece of information, a document, a model, source code, a service provided to an end user and so on. A WorkProduct describes one class of work product produced in a process.

Eclipse technologies

Eclipse Process Framework (EPF)

The Eclipse Process Framework (EPF) presents a process management tool platform and conceptual framework for authoring, tailoring and deploying development processes.

First release version 1.0 planned for September 2006

Goals

The Process Framework Project has two goals:

1. To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process.
2. To provide exemplary and extensible process content for a range of software development and management processes supporting iterative, agile, and incremental development, and applicable to a broad set of development platforms and applications.

Process framework

Typically the word framework is used in the context of an environment one can use to define partial or complete solutions for a particular problem domain. In defining these solutions reusable structures are used as starting points or building blocks.

A process framework is a similar thing. It defines reusable method content, processes, building blocks and tools that can be utilized to define specific processes and methods. (EPF Composer ships with one or more of these process frameworks, to help the developer in the process, but as well is equiped with the ability to create a completely new method from scratch)th

Method content is primarily expressed using work producs, roles, tasks and guidance. Roles are identified in the development process and these represent a set of skills. Competencies and responsabilities in the development team. These roles are responsible for specific work products and for creating or modifying these work products, roles are assigned to perform tasks.

In addition to roles, tasks and work products EPF supports the addition of guidances in the form of whitepapers, concept description, guidelines, examples etc. Guidence is also present in the process representation.

In the representation of the process the main concept is the activity which can be nested to define breakdown structures and they can relate to each other to form work flows. Activities in EPF define to kind of processes: delivery processes and capability patterns.

Delivery processes represent a complete and integrated processs templete for performing one specific type of project.

Capability patterns are processes that express process knowledge for a key area of interest such as disipline or a best practice. They can be directly used by process practitioners to guide their work.

EPF Composer

EPF Composer is a tool platform for process engineers, project leads, project and program managers who are responsible for mainteining and implementing processes for development organizations or individual projects

Aims to:

• provide for development practitioners a knowledge base of intelectual capital that allows them to browse, manage and deploy content.
• provide process engineering capabilities by supporting processe engineers and project managers in selecting, tailoring, and rapidly assembling processes for their concrete development process.

EPF Composer allows you to take method content and to structure it in one specific way using a predefined schema. This schema is an evolution of the SPEM 1.1 OMG specification, which is currently being evaluated to become the 2.0 version of this specification. This method contents can overcome the limits of software engineering covering other design and disiplines such as bussiness transformations, sales cycles and so on. In EMF Composer they are represented as a construct of roles defining development skills and responsabilities for work products. Method contents can be found in books or publications on software engineering methods, best practices, standards, regulations or even homegrown methods.

In EMF Composer processes are typically expressed as workflows or breakdown structures. This framework provides oportunities that aims at supporting processes based on many different development approaches, development culture and development process representation.

Key concepts

• Redesigned tools for authoring, configuring, viewing, and publishing development processes.
• Just-in-time generation of publication previews
• Management of method content using simple form-based user interfaces.
• Intuitive rich text editors for content description
• Processes with:
  • breakdown structure editors
  • workflow diagrams
• Support for many alternative lifecycle models.
• Improved reuse and extensibility capabilities.
• Reusable dynamically-linked process patterns

Examples

The COMET methodology

The COMET methodology is an example of a methodology that was created to support component-based software development. COMET follows a use-case driven, model-focused approach aimed at supporting the process of developing and maintaining products and product families. The methodology provides guidelines for specifying and implementing products, system, and components. The process is a structured set of development methods, procedures and modelling techniques that are used for the specification, development, testing and deployment of products, systems, or components.

At the official COMET website http://modelbased.net/comet/ you will find detailed description of the COMET methodology which includes:

• The metamodels for business, requirements, component and platform models.
• The UML profiles for business, requirements, component and platform modelling.
• The methods (techniques and processes) for business, requirements, component and platform modelling.

Tutorials (exercises)

Tutorial #1: EPF - Requirements modelling

EPF is still a very young release but at the same time very promising. We have to wait until september for the first official release. For EPF I made a tutorial that gives an overview on EPF and the tool implementing it that is called EPF Composer. The first part of the tutorial guides the user step by step in creating method contents like roles, tasks and work products. The second part is concerned with processes and here I was showing an example how to extend the OpenUP process with some activities from COMET requirements modelling.

COMET requirements modelling

The Use Case Model describes the Product in terms of actors, use cases and scenario descriptions. The Use Case Model consist of two main parts:

• The System Boundary Model, which identifies the Product under consideration (area of concern) and describes the Product boundaries as well as the main services offered by the Product.
• The Use Case Scenario model, which includes more detailed descriptions of the Product resulting from further analysis using the common use case detailing technique, by diving into a use case discovering new use cases and actors. Use case scenarios are also described in this work product.

In EPF Composer we are going to create a Requirement Model Library which is going to include the configuration and the plug-in. As described before the method content are locatet in the plug-in and it they describe what is to be produced, the necessary skills required and the step-by-step explanations describing how specific development goals are achieved. These method content descriptions are independent of a development lifecycle. This lifecycle is described in the process. Processes take the method content elements and relate them into semi-ordered sequences that are customized to specific types of projects.

Step 1: Create method content

To create a method content for requirement modeling in Comet, we are not creating a method from scratch, but extending the OpenUP/Basic iterative development process.

Before starting, an important issue in EMF Composer is the viewing perspective. EMF composer proposes two viewing perspectives:

• The Authoring Perspective provides views and functions to navigate and author method content and processes. You must be in the Authoring Perspective to create or modify any element types. The Authoring Perspective contains two Views: the Library View and the Configuration View.
• The Browsing Perspective allows you to preview and navigate through a Method Configuration without making any changes

Make sure that the right configuration is chosen in the drop down box above the library view.

The first step is to create a method plug-in which we are going to name for comet_requirement. Make sure that you are in the Authoring Perspective.

The plug-must be included in the configuration and this is done by dubbel clicking on the configuration and selecting the Plug-in and Package selection window above properties.

In the new created plug-in you can find the method contents and the processes. In the method content choose Content Packages and by right clicking on it choose to create a new content package. The new content packages we created in this example is called use case models and from the figure you can see that it automatically includes roles, tasks, work products and guidance.

Step 2: Create work products

Work product is a general term for task inputs and outputs, descriptions of content elements that are used to define anything used, produced, or modified by a task. The three types of work product are artifacts, deliverables and outcomes. A short description for these work products will be that:

• an artifact is a tangible work product that is consumed, produced, or modified by tasks
• a deliverable is a collection of work products, usually artifacts
• and an outcome is an intangible work product that may be a result or state

In this example we are going to create an artifact (1).

• (2) After a new artifact is selected by rightclicking on the work products under use case models, the artifact editor is displayed. In the editor we can see the name and presentation name field, which can be seen as the name of the file and the name in the publishing presentation. Here we can also see fields for purpose or description.
• (3) In a browsing prespective this artifact is published as an html page. As seen in the picture in this example we created two work products that are the System Boundary Model and the Use Case Scenario Model

Step 3: Create roles

• (1) A Role defines a set of related skills, competencies, and responsibilities of an individual or individuals. Under roles in the use case models package we are going to create a role named ifi_student .
• (2)In the same way as for the creation of a work product a name, presentation name and description must be writen. In the role editor we can also specify the skills for this role or its assignment approaches.

• (3) Now we can assign the work products to this role by changing to the Work Producs window above the Properties view. The task that we created can be added here.
• (4) And here we can see a preview of the role ifi_student.

Step 4: Create tasks

• (1) A task is an assignable unit of work. Every task is assigned to a specific role. The granularity of a task is generally a few hours to a few days and usually affects one or only a small umber of work products.
• (2) Like the work product and role editor, the task editor has the standard fields for namem presentation name, description and purpose.
• (3) A task can have a series of steps that detail how to perform that task. The Step Editor allows you to:
  • Create a new step
  • Remove a step
  • Move a step up the list
  • Move a step down the list
  • In our example we created four possible steps in creating a system boundary model.

• (4) This part of the editor allows you to define the roles that perform the task. You should select a role as the Performing Role for this task. You can also add one or more roles as Additional Performers. We created another role in here that is called ifi_assistent_teacher and this should be an additional performer in this task.
• (5) This part of the editor allows you to define the work products that are inputs and outputs for this task. You can select any number of work products as Mandatory Inputs, Optional Inputs, and Outputs. To add a work product, click the appropriate add button, select the work products you want to add, and then click ok.We defined the context statement from bussiness modeling to be an optional input for this task.

• (6) And the total picture of the task is shown in the preview tab.

Step 5: The method contents

After creating the task for making the scenario models, here is the result of using EMF Composer for defining the method content in the Comet Requirement Modeling. In the screen we can see the definition of the role Ifi Student with the tasks he/she performs, the work products that is responsible for and the skills needed to fullfill this role.

Step 6: Working with processes

In Process Authoring the process engineer defines additional lifecycle elements such as Activities (summary tasks), Phases , Iterations and Milestones , that can then be used to compose the core elements into processes. A complete process corresponding to a project plan or a phase we call a Delivery Process . We can also create smaller more granular sections of process, termed Capability Patterns that can be used as building blocks to more easily compose delivery processes.

The COMET metodology describes four phases in its lifecycle. The first is the Inception Phase in which bussiness model contents are created and the developers start working on the requirement modeling. In the second phase, Elaboration phase the developers continue in refining the bussiness model, but the center of attention in this phase is requirements modeling. The definition of architecture is also started in this phase. The Specification&Construction phase include refining of the requirements, full definition of the architecture and modeling the product in PSM level. The last phase, the Transition is defined as a smothly deployment of the robust system.

A process can be created from scratch or extend another predefined process in a standard method. Since COMET is inspired from RUP(and many other methodologies) we decided to use the predefined processes in a basic OpenUP library that is shiped together with EMF Composer. In our example we are going to create to activities that will extend the Manage Requirements activity in the Elaboration phase.

• (1) As seen in the picture the new activities are Identify System Boundaries and Detail scenarios. In the property view it is shown that they are an extend to OpenUP_basic/elaboration_phase

Now as you can see in the screenshot of EMF Composer the Process editor is more complex than the method content editors. The first tab, description is standard like the others with name, presentation name and description. In this example we are more interesting in the work breakdown structure that is a hierarchical breakdown of work, such as activities, tasks, and steps, defining a process.

The other tabs above the properties view are:

• (2) Team Allocation tab shows the activities in the capability pattern and the roles that are the performers of the tasks in the activities. In the Manage Requirements activity there are four role descriptors (links to roles). The analyst and stakeholder are roles defined in OpenUP while Ifi Student and Ifi Asistent Teacher are performers of the tasks created in this example.

• (3) Work Product Usage tab shows the activities in the capability pattern and the work products that are input and outputs of the tasks in the activities. Here we can find the System Boundary Model and Use Case Scenario Model that are artifact descriptors linked to the artifacts created and other artifacts descriptors from OpenUP.
• (4) Consolidated View shows the full set of information for each activity in the Capability Pattern. It shows the tasks, work products and roles within each activity.

Step 7: Create a delivery process

• (1) Under processes in comet_requirement plug-in right click on the delivery process and then new-> delivery process.
• (2) A new window will appear and request the name of the delivery process and the configuration which should be the same as the one we were working on, in this case the OpenUP.

Step 8: Create a phase

A Phase is a special type of activity that represents a significant period in a project, ending with a major management checkpoint, milestone or set of deliverables. An Elaboration phase is created as an example(remeber that Inception is the first phase).

Step 9: Create an activity

• Activities represent the key building blocks for processes. Activities represent a grouping of breakdown elements such as other activities, task descriptors, role descriptors, work product descriptors, and milestones.
• In the property view we can change the characteristics of the activity, like if it has multible occurrences, is repeatable and so on

Step 10: Applying capability patterns

When developing a process, it is not necessary to develop the process from scratch, adding descriptors one by one. You can reuse existing capability patterns or even capability pattern parts to individually customize the pattern's content to the particular situation for which it is applied. A capability pattern must be applied to one specific activity in a process.

One of the advantages of EMF Composer is its ability to reuse and extend other methods and plugins. As we described before since COMET is using some of the concepts included in UP, we are going to structure our example as an extention of the existing Manage Requirement activity in the Elaboration phase.

After extending the Elaboration Iteration[n], this activity includes now different other activities described in OpenUpBasic. This are listed as a break down structure with the names in green color.

Step 11: Create a task description

• (1) Task descriptors populate the work breakdown structure’s activity. They are linked to the task created in the method content. In the same way as with artifacts, roles needs to be assigned to tasks descriptors. Work products must be set as inputs or outputs and steps be described. This is done through the Roles, Work Products and Steps tabs.
• (2) In our example the Detail scenario task descriptors is primarly performed by an IFI Student and assisted by an IFI Assistent Professor
• (3) As seen in the picture, the System Boundary Model is a mandatory input for this task descriptor. Steps are defined in the same way as with the artifact editor.

References

ATHENA & INTEROP

• [ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST-507849). http://www.athena-ip.org/
• [ATHENA A6 2006] ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, 2006.
• [ATHENA A6 2006] ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, 2006.
• [INTEROP] INTEROP, "INTEROP Home Page", INTEROP NoE. http://www.interop-noe.org/
• [INTEROP TG6 2005] INTEROP TG6, "State of the Art: Exploration of Methods and Method Engineering Approaches", Deliverable DTG 6.1, 2005.

Software development methodologies

• Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development Process, Addison-Wesley 1999.
• Trygve Renskaug et al: Working with Objects - The OOram Software Engineering Method 1996, ISBN 0134529308
• Rational: The Rational Development process
• Paul Allen, Stuart Frost, Component-Based Development for Enterprise Systems, Applying the SELECT Perspective, SIGS Book and Multimedia 1998
• Desmond D’Souza, Alan Wills: Objects, Components and Frameworks with UML – The Catalysis approach 1998 (November), Addison-Wesley, ISBN 0-201-31012-0
• Watts S.Humphrey, Managing the Software Process (CMM), Addison Wesley 1990.
• Martin Fowler. “The New Methodology”. Abridged version published in Software Development Magazine, December 2000. http://www.martinfowler.com
• Dirk Riehle. “A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other”. SKYVA International, 2000. http://www.riehle.org
• Jim Highsmith. “Messy, Exciting and Anxiety-Ridden: Adaptive Software Development”. Published in American Programmer Magazine, April 1997. http://www.ksinc.com/articles/CAS.html
• Jim Highsmith. “Adaptive Software Development”. Presented at OOPSLA 2000.
• Kent Beck. Extreme Programming Explained: Embrace Change. Addison‑Wesley, 2000.
• Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland. “SCRUM: A Pattern Language for Hyperproductive Software Development.” In Pattern Languages of Program Design 4. Edited by Neil Harrison, Brian Foote, and Hans Rohnert. Addison‑Wesley, 2000. Page 637-652.
• Alistair Cockburn. Crystal “Clear”. AOL, 2000. http://members.aol.com/acockburn

Eclipse technologies

• EPF, http://www.eclipse.org/epf
• EMF, http://www.eclipse.org/emf
• Help and tutorials, http://help.eclipse.org