© 2005-2006 the athena consortium. 5-3. uml profiles and domain-specific languages (dsls),

54
© 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs) <Presenter> <Company>, <Country> <E-mail>

Upload: mervin-white

Post on 12-Jan-2016

221 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

© 2005-2006 The ATHENA Consortium.

5-3. UML Profiles and Domain-Specific

Languages (DSLs)

<Presenter>

<Company>, <Country><E-mail>

Page 2: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

2© 2005-2006 The ATHENA Consortium.

ATHENA Model-Driven Interoperability (MDI) Framework

MDA & Interoperability

Metamodelling

UML Profiles & DSLs

Model Transformations

Method Engineering

Reusable MDI Assets

• Method chunks• Tools and services

• Models and metamodels• Model transformations• DSLs and UML profiles

• Reference examples

Page 3: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

3© 2005-2006 The ATHENA Consortium.

Objective

• The objective of this part of the course is to:– Understand what a UML profile and a domain-specific

language (DSL) are.– Be able to develop your first DSL in the Eclipse

Graphical Modeling Framework (GMF) [optional exercise]

Page 4: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

4© 2005-2006 The ATHENA Consortium.

Outline

• UML profiles• Metamodelling (revisited)• Domain-specific languages (DSLs)• Eclipse Graphical Modeling Framework (GMF)• Examples

– UML profile for PIM4SOA– UML profile for Web services (XSD, WSDL and BPEL)

• References

Page 5: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

5© 2005-2006 The ATHENA Consortium.

UML profiles

Page 6: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

6© 2005-2006 The ATHENA Consortium.

UML profiles

• They 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

Page 7: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

7© 2005-2006 The ATHENA Consortium.

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

DB Partners

Page 8: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

8© 2005-2006 The ATHENA Consortium.

Restriction

• Is a semantical condition represented by a textual expression

• Imposes some kind of condition or requisite on the element to which it is applied

• OCL – Object Constraint Language

{An interface does not have attributes, only operations}

Page 9: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

9© 2005-2006 The ATHENA Consortium.

Tagged value

• Is a property associated to a model element

• Used to store information about the element

– Management information, documentation, coding parameters, ...

• Generally, the tools store this information but it is not shown in the

diagrams

Page 10: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

10© 2005-2006 The ATHENA Consortium.

Metamodels and profiles

MOF

UML process genericMeta-model

real-timemodel

WorkflowMeta-model

UMLFor J2EE

migrationmodel

Workflowmodel

Migration oriented process Meta-model

UMLReal-time

M3

M2

M1

extension

relationship

model <-> meta-model

relationship

Page 11: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

11© 2005-2006 The ATHENA Consortium.

Metamodelling (revisited)

Page 12: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

12© 2005-2006 The ATHENA Consortium.

Classification

Dog

Collie

Animal

Living

Being Four Legged

Object

Celebrity

Movie

Star

Lassie

Page 13: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

13© 2005-2006 The ATHENA Consortium.

Classification dimensions

Collie

Celebrity

Four Legged

Object

Animal

Dog

Movie Star

Model Element

Instance

Object

Ontological classification

(domain types)

Linguistic classification

(representation form)

Page 14: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

14© 2005-2006 The ATHENA Consortium.

Kinds of metamodels

• Two kinds of information of a set of models are modelled in metamodels– Form (linguistic aspects)

• OMG is predominantly occupied with this

– Content (ontological aspects)

Page 15: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

15© 2005-2006 The ATHENA Consortium.

Linguistic metamodelling

LassieCollie

Class Object

Class

represents represents

linguistic ”instance-of” linguistic ”instance-of”

linguistic ”instance-of” linguistic ”instance-of”

instance-of

ontological instance-of

ontological instance-of

L0 (called M0 in OMG)

L1 (called M1 in OMG)

L2 (called M2 in OMG)

L3 (called M3 in OMG)

Page 16: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

16© 2005-2006 The ATHENA Consortium.

Ontological metamodelling

Lassie

Collie Class

Breed

representslinguistic instance-ofO0

O1

O2

O3

Object

Biological rank

ontological ”instance-of”

linguistic instance-of

linguistic instance-ofontological

”instance-of”

ontological ”instance-of”

ontological ”instance-of”

L1 L2

Page 17: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

17© 2005-2006 The ATHENA Consortium.

Domain-specific languages (DSLs)

Page 18: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

18© 2005-2006 The ATHENA Consortium.

UML – one size fits all?

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

Page 19: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

19© 2005-2006 The ATHENA Consortium.

Software factory

• The Software Factories Web site (http://www.softwarefactories.com/) defines the term Software Factory in the following way:

• “A Software Factory is a software product line that configures extensible development tools like Visual Studio Team System with packaged content like DSLs, patterns, frameworks and guidance, based on recipes for building specific kinds of applications. For example, we might set up a Software Factory for thin client Customer Relationship Management (CRM) applications using the .NET framework, C#, the Microsoft Business Framework, Microsoft SQL Server, and the Microsoft Host Integration Server. Equipped with this factory, we could rapidly punch out an endless variety of CRM applications, each containing unique features based on the unique requirements of specific customers. Better yet, we could use this factory to create an ecosystem, by making it available to third parties, who could extend it to rapidly build CRM applications incorporating their value added extensions.”

Page 20: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

20© 2005-2006 The ATHENA Consortium.

UML and DSLs

• The issue of the role of UML is often stated in overly simplistic terms: MDD advocates the use of UML for all domain modeling while the Software Factories approach advocates that UML never used.

• This is an incorrect statement of the positions of both camps.– While the MDD approach treats UML, with customization, as the

modeling language of choice for most application modeling, 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.

– The MDD approach acknowledges the value of non-UML DSLs as a technique to be applied judiciously.

– Further, the Software Factories approach does not reject UML entirely. It suggests that you use UML for developing sketches and documentation, where DSLs should be used for developing models from which code is generated.

Page 21: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

21© 2005-2006 The ATHENA Consortium.

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.

Page 22: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

22© 2005-2006 The ATHENA Consortium.

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.

Page 23: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

23© 2005-2006 The ATHENA Consortium.

Eclipse Graphical Modeling Framework (GMF)

Page 24: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

24© 2005-2006 The ATHENA Consortium.

Graphical Modelling 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 v.1.0 released June 28, 2006

Page 25: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

25© 2005-2006 The ATHENA Consortium.

GMF overview

• GMF uses and depends on EMF and GEF– EMF:

• Core facility for defining models• generates java code for manipulating and persisting model

insances

– GEF:• Manipulates object models

• Simplifies combination of EMF and GEF• Generates GEF editors for manipulating EMF

models

Page 26: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

26© 2005-2006 The ATHENA Consortium.

Example #1: UML profile for PIM4SOA

Page 27: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

27© 2005-2006 The ATHENA Consortium.

PIM4SOA Implementation Alternatives

• Define a metamodel using a UML Profile

– they allow the model to be manipulated with ‘industry standard’

modelling tools.

– the metamodel could be severely affected by changes in the

UML infrastructure.

– The UML element semantics must be respected

• Define a metamodel using MOF

– decouple the metamodel from the notation, therefore if the

notation changes the metamodel is not severely affected.

– A graphical interface to the metamodel must be developed

Page 28: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

28© 2005-2006 The ATHENA Consortium.

Metamodel and profile development

1. MetamodelScope,

concepts, style

3. TestEvaluate in

user scenarios

2. UML profileMap

metamodel concepts to

UML

4. FeedbackAdd, remove, and modify concepts

Understanding of SOA concepts and interoperability issues• Initial (interoperability) requirements• SOA concepts• Partitioning of the metamodel into structures• Architectural style for developing interoperable software systems• Document the metamodel in RSM (.uml2) and develop it in EMF (.ecore)

Define how SOA models should be specified using UML• Map metamodel concepts to UML types• Define UML stereotypes and tagged values• Define new visual symbols• Define model views• Define validation rules• Implement UML profile in RSM

Evaluate and test UML profile in user scenarios• Four ATHENA use cases (pilots)

Feedback• Iterative development• Modifications according to test and evaluation

Page 29: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

29© 2005-2006 The ATHENA Consortium.

PIM4SOA profile implementation issues

PIM4SOA

GRIDP2PBDI Teams

WSA

PIM4SOAUML Profile

Aris Grai Metis Moogo POP*

Business expert

IT infrastructure

GAP

CIM

PIM

PSM

Easier Transformations

Easier Transformations

Modelling support

2 Transformations

Page 30: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

30© 2005-2006 The ATHENA Consortium.

PIM4SOA profile implementation platform

PIM4SOA

GRIDP2PBDI Teams

WSA

PIM4SOAUML Profile

Aris Grai Metis Moogo POP*

Business expert

IT infrastructure

GAP

CIM

PIM

PSM

eCore, MTF

RSM

eCore, MTF

EMF eCore

Page 31: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

31© 2005-2006 The ATHENA Consortium.

• Sketches out the stereotypes and the base classes for the PIM4SOA elements

• The PIM4SOA 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 will be

described separately (followed by an example)• UML extensions for Service Modelling• UML Extensions for Process Modelling• UML Extensions for Information Modelling• UML Extensions for Quality of Service Modelling

UML extensions for PIM4SOA modelling

Page 32: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

32© 2005-2006 The ATHENA Consortium.

UML extensions for PIM4SOA modelling

• UML extensions for Service Modelling

• UML Extensions for Process Modelling

• UML Profile for Information Modelling

• UML Extensions for QoS Modelling

Page 33: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

33© 2005-2006 The ATHENA Consortium.

UML extensions for service modelling

Stereotype Base Class Description

Collaboration Collaboration This element represents the definition of a service. Each service description is viewed as a collaboration between roles

CollaborationUse CollaborationUse (sometimes called CollaborationOccurence)

A collaboration use represents the usage of a service. This service must to be defined previously. CollaborationUse specification must

be encapsulated in a composition structure. This structure is provided by a collaboration definition or by a service provider.

RoleBinding Dependency This is not a mandatory feature. It is used to connect two roles in the structural part of a class or collaboration

ServiceProvider Class This element represent the service provider

Role Part A role represents a structural part in a collaboration

EndPoint Property[2] An endpoint represent the address for a service

Registry Package Registry represents a container to know where the services are placed

RegistryItem Class, Part Registry Item is an entity to relate a collaboration and an address

Message Operation The message concept is related with a role through an interface.

Item Parameter Item represents the data managed by a role

Page 34: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

34© 2005-2006 The ATHENA Consortium.

UML extensions for process modelling

Stereotype Base Class Description

Process Activity A process represents an activity diagram. This activity diagram is contained by a service provider or

collaboration

Task Structured Activity Node A structured task is related with a collaboration use. This element contains a set of interactions

Interaction Interaction,Call behaviorAction

An interaction represents a reference to a message. It also contains a reference to an input pin or an

output pinTagDefinition:JoinSpecification:string

Flow ControlFlow This flow relates two interactions.TagDefinition: GuardSpecification:String

ColaborationUsePath Dependency This dependency relates a “structuredTask” (source) with a collaboration use (target). This relationship contains a parameter indicating the order of containment.

Page 35: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

35© 2005-2006 The ATHENA Consortium.

UML extensions for information modelling

Stereotype Base Class Description

<<Document>> Class, Package Assigned to class or package. Indicates root and packaging of a business document information model as a reusable asset.

<<BusinessTypeLibrary>> Package Assigned to package. Indicates the business logic

<<Entity>> Class Assigned to class. Represents elements used to describe complex types

<<TypeLibrary>> Package Assigned to package. Indicates packaging of a reusable type library.

Page 36: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

36© 2005-2006 The ATHENA Consortium.

UML extensions for quality of service modelling (1)

Metamodel element

Stereotype Base Class Description

NFA NFA Part, Class Each collaboration is related with a NFA element to describe and model quality of service aspects

QoSContext QoSContext Package QoSContext allows describing the context of quality expressions.

QoSCategory QoSCategory Package It is mechanism of grouping QoSCharacteristics

QoSOffered QoSOffered Package QoSOffered inherits from the abstract class QoSConstraint. This constraint specifies the

quality that the provider must achieve

QoSRequired QoSRequired Package QoSRequired inherits from the abstract class QoSConstraint. This constraint specifies the

quality that the server must achieve

Page 37: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

37© 2005-2006 The ATHENA Consortium.

UML extensions for quality of service modelling (2)

Metamodel element

Stereotype Base Class Description

QoSContract QoSContract Package QoSContract inherits from the abstract class QoSConstraint. This constraint

specifies the agreement between constraints

QoSCharacteristic QoSCharacteristic Class QoS Characteristics represents quantifiable characteristics of services

QoSDimension QoSDimension Feature (structuralFeature) QoS Dimensions are dimensions for the quantification of QoS Characteristic

QoSValue QoSValue InstanceSpecification QoS Value instantiate QoS Characteristic and fixes it with specific

values of its value definitions (QoS DimensionSlot)

QoSDimensionSlot QoSDimensionSlot Documentation[1] QoS Dimension Slot represents the value of a primitive QoS Dimension or a

reference to another QoS Value

Page 38: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

38© 2005-2006 The ATHENA Consortium.

RSM and UML profile for PIM4SOA

Page 39: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

39© 2005-2006 The ATHENA Consortium.

Example #2: UML profile for Web services

Page 40: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

40© 2005-2006 The ATHENA Consortium.

UML profile

Business Modelling

Annotated Business Modelling

Detailed Design

PIM

PSM

Annotated PIM

Business Idea

WSDLWSDL POLICIESPOLICIESCLASSESCLASSES

Information System SolutionPIM

«Annotated» IS SolutionPIM

Platform Ready SolutionPSM

Deploymentdecisions

Business Expert

Platform Expert

BusinessLevel

PlatformLevel

RunningLevel

Transformation rules

generationUML profile

annotationUML profile

We have defined a basic metamodel for Web services that covers those basic aspects that all Web services have to fulfil, and two extended metamodels that extend the basic specification with important concepts for Web services technology, such as faults and security. Starting from these metamodels, we have defined three different UML profiles that try to make easy the specification and development of Web services.

Page 41: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

41© 2005-2006 The ATHENA Consortium.

UML profile for Web services

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

Page 42: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

42© 2005-2006 The ATHENA Consortium.

UML profile for XSD (1)Stereotype UML

construct Tagged value Description

<<any>> Class, Property

The stereotyped class or attribute will be relaced by an 'any' or 'anyAttribute' element. The tagged values are copied into the corresponding attributes of the generated element

namespace As defined in XML Schema specification processContents As defined in XML Schema specification

values="skip | lax | strict" default="strict"

<<attribute>> Property Assigned to UML attribute or association end. Indicates item is to be generated as an attribute within complexType and not as an element

default As defined in XML Schema specification fixed As defined in XML Schema specification form Overrides the attributeFormDefault for this

schema values="qualified | unqualified"

use As defined in XML Schema specification values="prohibited | optional | required" default="optional"

<<choice>> Class Elements marked with this stereotype represent a Choice model group conatined within a complexType definition

<<complexType>> Class ComplexType definition generated in XML Schema

memberNames Overrides the package-level default for naming complexType definitions values="qualified | unqualified"

mixed Determines whether this element may contain mixed element and character content. values="true | false" default="false"

modelGroup Overrides the package-level default model group values="all | sequence | choice"

<<element>> Property Assigned to UML attribute or association end. Indicates item is to be generated as element within complexType and not as attribute

anonymousRole The class type will be directly embedded within the complexType definition. Omit attribute or role type wrapper values="true | false" default="false"

anonymousType The class type will be anonymous for XML documents generated by the schema values="true | false" default="false"

form Overrides the elementFormDefault for this schema values="qualified | unqualified"

position If assigned, indicates position in the sequence model group

<<facet>> Property A facet is a single defining aspect of a value space. Generally speaking, each facet characterizes a value space along independent

Page 43: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

43© 2005-2006 The ATHENA Consortium.

UML profile for XSD (2)

Stereotype UML construct

Tagged value Description

<<any>> Class, Property

The stereotyped class or attribute will be relaced by an 'any' or 'anyAttribute' element. The tagged values are copied into the corresponding attributes of the generated element

namespace As defined in XML Schema specification processContents As defined in XML Schema specification

values="skip | lax | strict" default="strict"

<<attribute>> Property Assigned to UML attribute or association end. Indicates item is to be generated as an attribute within complexType and not as an element

default As defined in XML Schema specification fixed As defined in XML Schema specification form Overrides the attributeFormDefault for this

schema values="qualified | unqualified"

use As defined in XML Schema specification values="prohibited | optional | required" default="optional"

<<choice>> Class Elements marked with this stereotype represent a Choice model group conatined within a complexType definition

<<complexType>> Class ComplexType definition generated in XML Schema

memberNames Overrides the package-level default for naming complexType definitions values="qualified | unqualified"

mixed Determines whether this element may contain mixed element and character content. values="true | false" default="false"

modelGroup Overrides the package-level default model group values="all | sequence | choice"

<<element>> Property Assigned to UML attribute or association end. Indicates item is to be generated as element within complexType and not as attribute

anonymousRole The class type will be directly embedded within the complexType definition. Omit attribute or role type wrapper values="true | false" default="false"

anonymousType The class type will be anonymous for XML documents generated by the schema values="true | false" default="false"

form Overrides the elementFormDefault for this schema values="qualified | unqualified"

position If assigned, indicates position in the sequence model group

<<facet>> Property A facet is a single defining aspect of a value space. Generally speaking, each facet characterizes a value space along independent

Page 44: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

44© 2005-2006 The ATHENA Consortium.

UML profile for XSD (3)

UML representation Text representation

Page 45: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

45© 2005-2006 The ATHENA Consortium.

UML profile for WSDL (1)Stereotype UML

construct Tagged value Description

<<binding>> Class A concrete protocol and data format specification for a particular port type. A concrete protocol and data format specification for a particular port type. A <<binding>> class represents a binding component of the WSDL metamodel.

binding Binding type default=”soap:binding”

style The style attribute indicates whether the operation is a remote procedure call (RPC) or a document-oriented operation. default=”rpc”

transport The transport attribute specifies the type of binding to be used. default=”http://schemas.xmlsoap.org/soap/http”

<<definition>> Class A <<definition>> class represents a definition component of the WSDL metamodel.

targetNameSpace TargetNameSpace is an URI (Uniform Resource Identifier). It is mandatory and identifies the namespace which it will belong all of the component names.

<<element>> Class An <<element>> class represents an element of the XML Schema.

baseType The base type maxOccurs The maximum number of occurrences minOccurs The minimum number of occurrences name The name of the element <<fault>> Association An <<fault>> association represents a relationship

between an operation and a message in the WSDL metamodel.

<<import>> Class An <<import>> class represents an import component of the WSDL metamodel.

location Location is an URI. It is optional and indicates the location of some information for the namespace.

namespace Namespace is an URI (Uniform Resource Identifier). It is mandatory and indicates that the containing WSDL document can contain references to the WSDL definitions in that namespace.

<<input>> Association An <<input>> association represents a relationship between an operation and a message the WSDL metamodel.

<<message>> Class An abstract, typed definition of the data being communicated. A <<message>> class represents a message component of the WSDL metamodel.

<<operation>> Class An abstract, description of an action supported by the service. An <<operation>> class represents an operation component of the WSDL metamodel.

<<output>> Association An <<output>> association represents a relationship between an operation and a message the WSDL metamodel.

<<part>> Class A <<part>> class represents a part component of the WSDL metamodel.

type Type is a base type XSD. It is optionally and must be defined when the part component uses a base type but not when the part component uses an element of the XML Schema.

<<partElement>> Association A <<partElement>> association represents a relationship between a part component of the WSDL metamodel and

Page 46: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

46© 2005-2006 The ATHENA Consortium.

UML profile for WSDL (2)

Stereotype UML construct

Tagged value Description

<<binding>> Class A concrete protocol and data format specification for a particular port type. A concrete protocol and data format specification for a particular port type. A <<binding>> class represents a binding component of the WSDL metamodel.

binding Binding type default=”soap:binding”

style The style attribute indicates whether the operation is a remote procedure call (RPC) or a document-oriented operation. default=”rpc”

transport The transport attribute specifies the type of binding to be used. default=”http://schemas.xmlsoap.org/soap/http”

<<definition>> Class A <<definition>> class represents a definition component of the WSDL metamodel.

targetNameSpace TargetNameSpace is an URI (Uniform Resource Identifier). It is mandatory and identifies the namespace which it will belong all of the component names.

<<element>> Class An <<element>> class represents an element of the XML Schema.

baseType The base type maxOccurs The maximum number of occurrences minOccurs The minimum number of occurrences name The name of the element <<fault>> Association An <<fault>> association represents a relationship

between an operation and a message in the WSDL metamodel.

<<import>> Class An <<import>> class represents an import component of the WSDL metamodel.

location Location is an URI. It is optional and indicates the location of some information for the namespace.

namespace Namespace is an URI (Uniform Resource Identifier). It is mandatory and indicates that the containing WSDL document can contain references to the WSDL definitions in that namespace.

<<input>> Association An <<input>> association represents a relationship between an operation and a message the WSDL metamodel.

<<message>> Class An abstract, typed definition of the data being communicated. A <<message>> class represents a message component of the WSDL metamodel.

<<operation>> Class An abstract, description of an action supported by the service. An <<operation>> class represents an operation component of the WSDL metamodel.

<<output>> Association An <<output>> association represents a relationship between an operation and a message the WSDL metamodel.

<<part>> Class A <<part>> class represents a part component of the WSDL metamodel.

type Type is a base type XSD. It is optionally and must be defined when the part component uses a base type but not when the part component uses an element of the XML Schema.

<<partElement>> Association A <<partElement>> association represents a relationship between a part component of the WSDL metamodel and

Page 47: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

47© 2005-2006 The ATHENA Consortium.

UML profile for WSDL (3)

UML representation Text representation

Page 48: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

48© 2005-2006 The ATHENA Consortium.

UML profile for BPEL (1)Stereotype UML

construct Description

<<assign>> Action An assign activity maps to a BPEL assign activity with each entry action mapping to a copy element. The right-hand side of each assign statement provides the details of a from element and the left-hand side provides then details of the to element.

<<catch>> Action When an invoked operation throws an exception, or a throw activity explicitly throws an exception, normal execution within the containing scope is terminated.An exception can be caught within the containing scope so that error recovery behavior can be performed. This is modelled as an <<catch>> activity.

<<compensate>> Action Compensation can be triggered by a compensate activity. We follow the BPEL semantics for compensation and when it can be triggered. In particular, a compensate activity is only permitted in the following places: In a catch activity of the scope that immediately encloses the

scope for which compensation is to be performed. In the compensation handler of the scope that immediately

encloses the scope for which compensation is to be performed.

<<compensationHandler>> Action Compensation handler activities can be defined to reverse the work performed by a scope, if necessary. Compensation handler activities are not executed when control reaches the parent activity. If the parent activity completes successfully then the compensation handler is installed.

<<correlation>> Class, Property A correlation set is defined by a class stereotyped by <<correlation>> containing attributes with names and types matching those of properties defined within its namespace. A process specifies that it uses a correlation set through an attribute with the type of the correlation set. The stereotype <<correlation>> can also be applied (redundantly) to the attribute to distinguish it from other attributes.

<<data>> Class A message type has a number of parts, each of which is of a specified data type. Data types are represented by classes stereotyped as <<data>>.

<<external>> Package External packages contain elements that are defined in another model or elements that are defined directly as platform-specific artifacts (such as Web services or BPEL documents). External packages are not mapped to platform-specific artifacts. Elements that are reused can be modeled explicitly and placed in a package stereotyped with <<external>>.

<<invoke>> Action An invocation of an operation on a partner is represented as an activity with stereotype <<invoke>> with an entry action indicating the operation to be invoked and the attribute containing the input message. For two-way messages, assignment notation is used to indicate the attribute that is updated with the reply message.

<<loop>> Action A looping node is shown as an activity with the stereotype <<loop>>, which contains a decision node and an activity to be repeated, with a control link from the decision node to the activity. The guard on the control link provides the Boolean expression which determines whether the activity is executed each time round the loop.

<<messageContent>> Class A message type has a number of parts, each of which is of a specified data type. Message types are represented by classes stereotyped as <<messageContent>>

<<pick>> Action, It is often useful to group a set of receive activities and

Page 49: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

49© 2005-2006 The ATHENA Consortium.

UML profile for BPEL (2)

Stereotype UML construct

Description

<<assign>> Action An assign activity maps to a BPEL assign activity with each entry action mapping to a copy element. The right-hand side of each assign statement provides the details of a from element and the left-hand side provides then details of the to element.

<<catch>> Action When an invoked operation throws an exception, or a throw activity explicitly throws an exception, normal execution within the containing scope is terminated.An exception can be caught within the containing scope so that error recovery behavior can be performed. This is modelled as an <<catch>> activity.

<<compensate>> Action Compensation can be triggered by a compensate activity. We follow the BPEL semantics for compensation and when it can be triggered. In particular, a compensate activity is only permitted in the following places: In a catch activity of the scope that immediately encloses the

scope for which compensation is to be performed. In the compensation handler of the scope that immediately

encloses the scope for which compensation is to be performed.

<<compensationHandler>> Action Compensation handler activities can be defined to reverse the work performed by a scope, if necessary. Compensation handler activities are not executed when control reaches the parent activity. If the parent activity completes successfully then the compensation handler is installed.

<<correlation>> Class, Property A correlation set is defined by a class stereotyped by <<correlation>> containing attributes with names and types matching those of properties defined within its namespace. A process specifies that it uses a correlation set through an attribute with the type of the correlation set. The stereotype <<correlation>> can also be applied (redundantly) to the attribute to distinguish it from other attributes.

<<data>> Class A message type has a number of parts, each of which is of a specified data type. Data types are represented by classes stereotyped as <<data>>.

<<external>> Package External packages contain elements that are defined in another model or elements that are defined directly as platform-specific artifacts (such as Web services or BPEL documents). External packages are not mapped to platform-specific artifacts. Elements that are reused can be modeled explicitly and placed in a package stereotyped with <<external>>.

<<invoke>> Action An invocation of an operation on a partner is represented as an activity with stereotype <<invoke>> with an entry action indicating the operation to be invoked and the attribute containing the input message. For two-way messages, assignment notation is used to indicate the attribute that is updated with the reply message.

<<loop>> Action A looping node is shown as an activity with the stereotype <<loop>>, which contains a decision node and an activity to be repeated, with a control link from the decision node to the activity. The guard on the control link provides the Boolean expression which determines whether the activity is executed each time round the loop.

<<messageContent>> Class A message type has a number of parts, each of which is of a specified data type. Message types are represented by classes stereotyped as <<messageContent>>

<<pick>> Action, It is often useful to group a set of receive activities and

Page 50: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

50© 2005-2006 The ATHENA Consortium.

UML profile for BPEL (3)

Page 51: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

51© 2005-2006 The ATHENA Consortium.

RSM and UML profile for Web services

Page 52: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

52© 2005-2006 The ATHENA Consortium.

References

Page 53: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

53© 2005-2006 The ATHENA Consortium.

References

[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

Page 54: © 2005-2006 The ATHENA Consortium. 5-3. UML Profiles and Domain-Specific Languages (DSLs),

54© 2005-2006 The ATHENA Consortium.

This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.

Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.