www.artisansw.com

Slide 1

UML2 - a language for MDA?

Alan Moore

www.artisansw.com

Slide 2

Introduction

• What’s UML ever done for us?• Why MDA and why UML for MDA?• What does MDA require from UML?• How UML needs to change (further) in order to

support MDA

www.artisansw.com

Slide 3

UML Accomplishments

• The major (arguably only) graphical modeling notation– Notational consolidation has improved tool quality and breadth– Interchange between tools may actually happen

• Used by many people (not just software engineers) for many purposes– Breadth of diagrams means there’s something for everyone– Flexibility of meaning allows UML to be used outside its original mission

• UML 2 has delivered on requirements– Some important diagrammatic additions and modifications– Tidier class model– Broader diagram support and continuing flexibility should help spread

UML’s use still further

www.artisansw.com

Slide 4

Why MDA?

• From http://www.omg.org/mda/faq_mda.htm“There are many benefits to using the MDA approach,

with the most important being:–An architecture based on the MDA is always ready to deal with yesterday's, today's and tomorrow's "next big thing". –The MDA makes it easier to integrate applications and facilities across middleware boundaries. –Domain facilities defined in the MDA by OMG's Domain Task Forces will provide much wider interoperability by always being available on a domain's preferred platform, and on multiple platforms whenever there is a need.”

• From ARTiSAN Software– Central role for modeling, hence model editing tools– True interoperability provides a business case for new model processing tools

(code generation, document generation, analysis) …– … which help create multi-vendor business solutions …– … which add more value …– … and lead to more sales of model editing tools

www.artisansw.com

Slide 5

Why UML?

From http://www.omg.org/mda/faq_mda.htm“UML is the key enabling technology for the Model Driven Architecture: Every application using the MDA is based on a normative, platform-independent UML model. By leveraging OMG's universally accepted modeling standard, the MDA allows creation of applications that are portable across, and interoperate naturally across, a broad spectrum of systems from embedded, to desktop, to server, to mainframe, and across the Internet.”

www.artisansw.com

Slide 6

MDA Requirements (of UML)

“… MDA requires a high degree of formalization of the different models, architectures …”

“… Model transformation is central to MDA …”“ … In addition, mappings have to be specified in

detail …”“ Precise …”“ Computationally complete …”“ … formal, rigorous semantics …”

www.artisansw.com

Slide 7

Readying UML for MDA

• Make behaviour Unified– The current UML 2 behavioural models are too large and too

divergent to enable computational completeness

• Focus on Modeling, rather than diagramming– MDA is based on models and model transformation

• Add more Language characteristics– MDA needs more formality and precision

www.artisansw.com

Slide 8

Unification of Behaviour

• UML 2 Behavioural model– Currently three types of behaviour with three different semantics– Two too many

• Behaviour vs. Scenario– Many terms and no clear definition:

• Behaviour vs. Scenario• Executing vs. Emergent• Normative vs. Non-normative• Intentional vs. Extensional

– Confusion, even within UML2 experts about whether interactions are intentional or extensional

• Solution– Need one behavioural model– Need much clearer separation between the concepts of intention and

extension– Orthogonal combination of these two provides superset of current

capabilities

www.artisansw.com

Slide 9

UML 2 Behaviour(s)

• Currently have three different languages:– Interactions: largely expression based abstract syntax, semantics is

based on traces– Activities: standard function flow block abstract syntax, semantics is

token based– State-machines: Similar look to activity abstract syntax, but semantics is

event-based (only control tokens)• Reuse issue – elements in one behaviour might be useful

in others– Connection points in state machines

• Redundancy issue – some abstract syntax is (almost) shared– Pseudo-states/actions between activity and state machine

• Consistency issue – not clear whether some of the possible models are meaningful– Invoking an interaction

www.artisansw.com

Slide 10

Unified Behaviour Model

• Concept– Combine all behaviours into one abstract syntax and semantics– Syntax and semantics are superset of current state/activity/interaction– Existing diagrams remain but are views on unified model– Build on OCL expressions + small set of basic actions

(Update/Create/Send)• Advantages

– Richer set of features available through harmonisation– Smaller model because redundancy is eliminated– Build on existing OMG language– No consistency issues between different languages

• In Summary– More powerful– More implementable– Physicists think unification is important,so should we!

www.artisansw.com

Slide 11

Unified Behaviour MetaModel

Static Expression

ConnectionFlow

Action Vertex

Action

boolean preemptable

Transition

boolean isInternalboolean preempts

Static Expression

Pin

boolean triggering

Operation

Composite Action

StateRegion

Class

* 0..1subregion

0..1 0..1implementation

1*end

1*start

0..1*

guard

1 *

0..1

*

trigger

*

1

subaction

0..1

0..1

exit0..1

0..1

entry

0..11

invariant

*

0..1

ownedflow 2

*

end

• Fragment of 2U behaviour abstract syntax showing activity and state machine harmonisation

• State machine is specialisation of token flow semantics– State and region kinds of actions– Transition, kind of control flow

www.artisansw.com

Slide 12

Notation for Behaviour

Activity Diagram

DoingControlling

State1

Monitoring

State1

ControllingState1State1

Monitoring

State1State1

/ /

State ChartBehaviourAbstractSyntax

A ct ion

Another Action

[x>0]

[x<=0]

Sequence Diagramsimple action comp action

www.artisansw.com

Slide 13

Intentional vs. Extensional

“… Sequence diagrams describe behavior in an extensional manner, that is by enumerating the set of possible traces … The other description techniques supported by UML are intensional, i.e., they describe an abstract machine that induces a set of traces.”“… UML 1.x Sequence Diagrams might have been interpreted as “extensional.” However, UML 2.0 Sequence Diagrams can be seen as “intensional” as Activity Diagrams. The UML 2.0 Sequence Diagram semantics are now strong enough to enable them to be executable.”“… it is quite feasible and reasonable to specify system the complete behavior of a system in terms of MSCs (in fact, it is merely a form of procedural programming)”“… The above only applies to control constructs, but much more is needed for executability. I was under the impression that interactions were fairly limited in the kinds of actions they can model.”“… One of the ways that we are using interactions is to model Java methods.”

www.artisansw.com

Slide 14

A Possible Definition

• Behaviours are composed of or invoke other behaviours

• Sub-behaviours and invoked behaviours must be of the same subtype

• Extensional behaviours are occurrences of intentional behaviours (or more rarely other extensional behaviours)

• Extensional behaviours describe a view of the behaviour of which they are occurrences

Behaviour

Intentional Behaviour Extensional Behaviour

*1

subBehaviour**

invokes

0..1

* occurrence

original

ExecutionOccurrence{Abstract}

Behavior{Abstract}

InteractionFragment{Abstract}Interaction

behavior

*0..1enclosingInteraction

fragment

• Note that in UML 2, only Interaction has “occurrence” associations

www.artisansw.com

Slide 15

Implications

• Any behaviour can be used for either intentional or extensional purposes

• Any given behavioural diagram can be used for either intentional or extensional purposes

• Examples– Intentional interaction describes a Java procedure– Extensional state machine describes state-based

scenario

www.artisansw.com

Slide 16

Sequence Diagram for Java Procedure

calculate

Description :Calculator output:PrintStream

reader:Reader

itr

while (!finished) {output.println(); printlnoutput.print("calc> "); print( "calc > " )output.flush(); flush

if (!reader.readerLine()) {... readerLinefinished=false;

}}

(!finished)

sel

Text on left is Java rendering of the sequence diagram

www.artisansw.com

Slide 17

State Machine Example

/Idle

CokeAvailable/Available

GoodDispense/Dispense

Scenario

Ch ec k /

[12 > 0] /

Idle

Available

Dispense

Behaviour

Chec k /

[prodq> 0] /[prodq= 0] /

S elec tItem /

• The state machine on the right is a scenario through the state machine on the left

• Extensional “Behaviours” in the scenario reference Intentional Behaviours (hence the “/” notation)

www.artisansw.com

Slide 18

Model-centricity

• MDA is model-centric• UML is not so model-centric

– Diagram concepts in the metamodel• Lifeline, Activity Partition• Nodes and Artifacts

– Assumption that models will be edited through diagrams• Typed Element• Connectable Element

• Required– Clear separation of concrete syntax from abstract syntax– Purge UML of diagram-based abstract syntax– Tighten up well-formedness from a model-centric basis

www.artisansw.com

Slide 19

Separate Concrete Syntax

• UML 2 has no separate definition of the form of a diagram• Hence diagram form is (sometimes) written into abstract

syntax• Solution – provide separate (precise) model of concrete

syntax– Concrete syntax elements subtype Diagram Interchange classes– Concrete syntax elements relate to abstract syntax elements

Abstract SyntaxConcrete SyntaxDiagram Interchange

«views»«merge»

www.artisansw.com

Slide 20

Concrete Syntax and DI

• Concrete Syntax elements subtype DI elements (Diagram, Graph Node, Graph Edge…)

• Concrete Syntax elements reference Abstract Syntax• Abstract associations derived from DI graphical relationships• Constraints specify allowed topological relationships based on

appropriate Node and Edge subtypes

Class Diagram

Class NodeGeneralization Edge

Diagram Interchange::DiagramDiagram Interchange::Graph Edge Diagram Interchange::Graph Node

Generalization Classifier

*1

childClasseNodes {subsets child}*1

childGeneralizationEdges {subsets child}

2*/generalization /class

1

*

\generalizationElement

*

1 \classifierElement

«constraint»Can only link nodes and edges whose model elements are related by their general and specific roles.

www.artisansw.com

Slide 21

Activity Partition

• “Partitions divide the nodes and edges to constrain and show a view of the contained nodes.”

• Partition can represent any Element• Seems like a frame around a set of symbols on the

diagram.

ActivityPartition

ActivityNode{Abstract}

ActivityEdge{Abstract}

Element{Abstract}

*inPartition

nodeContents

0..1

* subgroup

superPartition

*

edgeContents

inPartition

*

0..1 represents

Activity Concrete Syntax

Activity Partition

ActivityEdgeSymbol ActivityNodeSymbol

ActivityNode{Abstract}

ActivityEdge{Abstract}

Element{Abstract}

*

1inPartition

edgeContents *

1inPartition

nodeContents

*

1 views

*

1views

*

1 views

www.artisansw.com

Slide 22

Lifeline

• Current– Lifeline represents a

ConnectableElement?– Many of the associations

(covered) express graphical relationships

• Alternative:– Lifeline in concrete

syntax, views a ConnectableElement

– Covered relationships would be represented in DI

UML

Lifeline

Interaction

ConnectableElement{Abstract}

InteractionFragment{Abstract}

EventOccurrence

StateInvariant

1

* lifeline

interaction

1

*

represents

*

*

covered

coveredBy

1

*

events

covered1 *

stateInvariantcovered

Interaction Concrete Syntax

Interaction Diagram

Lifeline

UML

Connectable Element

Interaction

*

1

1*views

* 1views

*

1

/contains

www.artisansw.com

Slide 23

Node and Artifact

• Implies that Java VM, NT Thread have to be Nodes! What if the user wanted them to be Artifacts?

• Implies that My App is an Artifact – why shouldn’t it be a class?

• Graphical form dictates model type

Pentium Processor

NT Thread

Java VM

My App«artifact»

Node

DeploymentTarget{Abstract}

Deployment

DeployedArtifact{Abstract}

Artifact

*nestedNode

1 *deploymentnode

*

* deployedArtifact

www.artisansw.com

Slide 24

Deployment Suggestion

• Classes can deploy other classes• Stereotypes used to add variations• Shadow indicates that contained element is

“deployed” on container

Class

Deployment*

1 location

deployment

1

*

deployedArtifact

«node»Pentium

«process»NT Thread«process»

NT Thread

«artifact»Java VM«artifact»

Java VM

MyAppMyApp

Class Node

boolean isShadowed

*1

deployedNode

www.artisansw.com

Slide 25

Type Metamodel

• No additional constraints (that I can see)

• Surely some of these combinations don’t have any meaning?

• N.B. Most of these situations cannot occur through a UML tool UI

TypedElement{Abstract}

Variable

ObjectNode{Abstract}

ValueSpecification{Abstract}

Parameter

StructuralFeature{Abstract}

Type{Abstract}

Classifier{Abstract}

Class

Association

BehavioredClassifier{Abstract}

Interface

DataType

Artifact

Signal

InformationItem

Actor

ParameterableClassifier{Abstract}

TemplateableClassifier{Abstract}

Collaboration

Class

UseCase

Enumeration

PrimitiveType

0..1type

www.artisansw.com

Slide 26

Connectable Element

• “If the type of the connector is omitted, the type is inferred based on the connector, as follows: … Any inferred associations are always bidirectionally navigable and are owned by the containing classifier.”

• Arguably, Property and Port must be typed by classes (or interfaces), but what if the Parameter or Variable has a primitive type?

• It isn’t possible to draw connectors between Variables/Parameters on Structure Diagrams

ConnectableElement{Abstract}

Property

Port

Variable

Parameter

ConnectorEnd

ConnectorAssociation

0..1

* end

role

1

2..* end* 0..1/definingEnd

*0..1type

www.artisansw.com

Slide 27

Language (Need for semantics)

• Issues in UML– The semantics of UML are defined imprecisely (in English)

• Translational and Operational semantics are not a complete answer

• Denotational semantics for UML may be the answer– Model of Semantic Domain– Solution for Semantic Variation points

• Approach– Continue to use translational semantics– Produce an operational semantics (reference architecture?)– Provide denotational semantics as validation for both

www.artisansw.com

Slide 28

Translational Semantics

• Definition– Translational semantics is based on two notions:

• 1. The semantics of a programming language can be preserved when the language is translated into another form, called the target language.

• 2. The target language can be defined by a small number of primitive constructs that are closely related to an actual or a hypothetical machine architecture.

• Current practise– Most UML vendors generate source code from models– Broad agreement on basics – significant numbers of detailed

differences– Many UML 2 features not covered yet

• Issues– Popular languages don’t have a close match for UML 2.0 features– Mature(?) technology – hard to channel into standard because of

competitive positions of vendors

www.artisansw.com

Slide 29

Operational Semantics

• Definition– In contrast to a semantics that describes only what a program does, the

purpose of operational semantics is to describe how a computation is performed … More commonly, concrete operational semantics refers to an interpreter approach in which a source language program is simulated directly.

• Current practise– Success in various forms with programming languages, very little with

UML• Issues

– Who defines – OMG standard reference model?– Performance – in many cases not production quality– Too prescriptive – no room for manoeuvre– How easy is it to understand the mapping in the absence of a language

like VDM?

www.artisansw.com

Slide 30

Denotational Semantics

• Definition– Denotational semantics is based on the recognition that programs and

the objects they manipulate are symbolic realizations of abstract mathematical objects …

– The idea of denotational semantics is to associate an appropriate mathematical object, such as a number, a tuple, or a function, with each phrase of the language. The phrase is said to denote the mathematical object, and the object is called the denotation of the phrase.

• Current practise– Little commercial interest– Partial attempt at denotational semantics for UML2 from 2U

• Notes– Can use UML/MOF and OCL to define mapping– Declarative approach so less prescriptive– Easy to support variations in straightforward way– Can be used to validate translational and operational approaches

www.artisansw.com

Slide 31

Approach

Abstract Syntax Semantic Domain

«denotes»

• UML semantics– UML abstract syntax is type-based – more specifically class-based– Semantic domain for UML describes the instances of those classes

• Need for Semantic Domain– Against abstract syntax model can only check whether class definitions

are self-consistent– Need to add new semantic domain model so we can add the well-

formedness rules we need to evaluate both the self-consistency of instances but also their conformance to their types.

– Can be clearer about which abstract syntax concepts have no instance semantics:

• Package, Comment, Dependency?

www.artisansw.com

Slide 32

Example of Syntax, Semantic and Mapping

UML2::Core::Constructs::Classes::SemanticMapping

Property{Abstract}

StructuralFeatureInstance{Abstract}

PropertyEvaluation{Abstract}

StructuralFeature{Abstract}

Attribute Slot

Classifier{Abstract}

Instance{Abstract}

ObjectClass

Property{Abstract}

StructuralFeatureInstance{Abstract}

PropertyEvaluation{Abstract}

StructuralFeature{Abstract}

Attribute Slot

Classifier{Abstract}

Instance{Abstract}

ObjectClass 1 *of

*0..1 owningClass

ownedStructuralFeature*

*

memberStructuralFeature*

0..1 owningObject

ownedStructuralFeatureInstance1 *

of

1*

type 1*

value

• Semantic Domain on right, Abstract Syntax on left• Mapping rules define the validity of a Semantic Domain construct

compared to its Abstract Syntax counterpart• Mapping defined in OCL – often commuting rules (every

StructuralFeatureInstance in an Object will be “of” a StructuralFeature in the Class “of” Object

www.artisansw.com

Slide 33

State Machine Example

State1

State3

State4

State5

State6

State7

SM Class

/

[x > 0 ] /

[x = 0 ] /

[x < 0 ] /

/

/

Junction

Transition*

1

/in *

1

/out

Abstract Syntax

Junction Instance

Transition Instance1

1

/in 1

1

/out

*1of

*1of

Semantic Domain

/State1 /State4

SM Object

/[x=-4]/

• Junction may have many inputs and outputs in abstract syntax, but exactly one input and one output in semantic domain.

www.artisansw.com

Slide 34

Semantic Variations

• Key Concept in MDA– Profiles for C++, Java, EJB … describe extensions to abstract

syntax– How describe extensions to semantics?

• Semantic Variation in UML2– UML concept of semantic variation points is hazy– Vaguely defined areas of doubt and uncertainty …– Need more precise concept

• Semantic Variation for MDA– UML should (at least) define whatever semantics it does define,

precisely– IMO, it should define a default semantics for all relevant

concepts

www.artisansw.com

Slide 35

Semantic Variation Approach

• A syntactic variation for each language

• A semantic variation for each language

UML AbstractSyntax UML Semantic Domain

UML for Java Java Semantic Domain

«denotation»

C++ Profile

UML for C++

«denotation»

C++ Semantic Domain

www.artisansw.com

Slide 36

Conclusion

• UML 2 superstructure has met the headline requirements set out in the RfP

• MDA has arisen since then and UML has a key role• In order for UML to support MDA, we need to address

issues of:– Unification

• Unified behavioural model• Clear separation between intentional and extensional behaviour

– Modeling• Provide a precise mechanism to describe concrete syntax• Remove notational concepts from abstract syntax• Ensure that models are consistent irrespective of means of creation

– Language• Provide at least one (for preference denotational) precise definition of

semantics• Define a precise scheme for semantic variation