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