Unified Modeling Language
as an
Executable Modeling LanguageThis Time We Mean It
Vienna University of Technology
Ed Seidewitz
25 October 2016

We can model that!We can model that!
OOAD orthodoxy (c. 1980s)
Organize programs to model the basic concepts of
the problem domain.
Problem
Programming languages (even OOPLs) are not
particularly good as problem domain modeling
languages.
• Too much of a program must focus on
implementation details.
• As the program grows, the “big picture” gets lost.
UML Prehistory
Object-Oriented Analysis and Design (1)
2

We can model that!We can model that!
Solution
Use a graphical modeling notation for analysis and
design.
• “Model the problem domain” during analysis.
• “Model the solution” in problem domain terms during
design.
• Use the solution model as a “blueprint” for coding.
Consequence
“Modeling” in the software community became drawing
pictures, for problem domain representation and solution
blueprinting.
• Precise “meaning” was only to be found in the
programs themselves.
UML Prehistory
Object-Oriented Analysis and Design (2)
3

We can model that!We can model that!
Unified Modeling Language (UML) intended to
“unify” the various OOAD graphical modeling
languages of the early 1990s.
1995 – UML 0.9 by Booch, Rumbaugh and Jacobson
(“3 amigos”)
1996 – UML 1.0 proposed by Rational
1997 – UML 1.1 adopted by Object Management
Group (OMG)
The intent of OMG standardization was primarily to
allow syntactic interchange of models between tools.
Unified Modeling Language v1.x
4

We can model that!We can model that!
There was a hope to add semantic interoperability to the
UML standard with UML 2.
1999 – UML 2.0 Request for Information (RFI)
2000 – UML 2.0 Requests for Proposal (RFPs)
2003 – UML 2.0 Adopted
2005 – UML 2.0 Finalized
2011 – UML 2.4.1
“However, the presence of numerous variation points in these
semantics (and the fact that they are defined informally using natural
language), make it impractical to define this as a formal compliance
type, since the number of possible combinations is very large.”
– UML Superstructure Specification, v2.0 – 2.4.1
Unified Modeling Language v2.x
5

We can model that!We can model that!
The UML 2.5 specification document is reorganized to be
“consumable” and to remove redundancy and correct
inconsistencies. Primarily focused on semantics
descriptions.
2008 – Future Development of UML RFI
2009 – UML Specification Simplification RFP (UML 2.5)
2012 – UML 2.5 Adopted
2015 – UML 2.5 Finalized (current version)
“A tool demonstrating semantic conformance provides a
demonstrable way to interpret UML semantics, e.g., code
generation, model execution, or semantic model analysis.”
– UML 2.5 Specification, Semantic Conformance
Unified Modeling Language v2.5
6

We can model that!We can model that!
Before UML, there were already a number of
approaches to modeling with precise, executable
semantics.
1988, 1991 – Shlear-Mellor Object-Oriented Analysis
1988, 1998 – Harel Statecharts
1994 – Real-Time Object-Oriented Modeling
(ROOM)
In 1998, Stephen Mellor came to an Object
Management Group meeting for the first time, to talk
about defining an action language for UML with
precise semantics.
Executable Modeling Before UML
7

We can model that!We can model that!
Foundational UML (fUML) is an executable subset of standard
UML that can be used to define, in an operational style, the
structural and behavioral semantics of systems.
1998 – Action Semantics for the UML RFP
2003 – UML 1.5 with action semantics formalized
2003 – UML 2.0 adopted
2005 – Semantics of a Foundational Subset for
Executable UML Models RFP
2008 – fUML 1.0 Beta (based on UML 2.2)
2010 – fUML 1.0 (based on UML 2.3)
2012 – fUML 1.1 (based on UML 2.4.1)
2016 – fUML 1.2.1 (based on UML 2.4.1)
2017 – fUML 1.3 (based on UML 2.4.1)
2018? – fUML 1.4 (based on UML 2.5)
Foundational UML (fUML)
8

We can model that!
Composite
Structure
Semantics
State Machine
Semantics
Interaction
Model
Semantics
fUML Scope
Non-
Executable
Model
Semantics
The semantics of fUML provide the foundation for formally
specifying the (execution) semantics of the rest of UML.
Some areas of UML (e.g., use case and requirements
models) may not be best formalized based on an
executable semantics foundation.
Complete
Activity Model
Semantics
Foundational Semantics
9

We can model that!We can model that!
• Foundational UML Subset (fUML) – A computationally
complete subset of the abstract syntax of UML (Version
2.4.1)
– Kernel – Basic object-oriented capabilities
– Common Behavior – General behavior and asynchronous
communication
– Activities – Activity modeling, including structured activities
(but not including variables, exceptions, swimlanes,
streaming or other “higher level” activity modeling)
• Execution Model – A model of the execution semantics of
user models within the fUML subset
• Foundational Model Library
– Primitive Types – Boolean, String, Integer, Unlimited
Natural
– Primitive Behaviors – Boolean, String and Arithmetic
Functions
– Basic Input/Output – Based on the concept of “Channels”
fUML Key Components
10

We can model that!We can model that!
The Action Language for Foundational UML (Alf) is a
textual surface representation for UML modeling elements
with the primary of acting as the surface notation for
specifying executable (fUML) behaviors within an overall
graphical UML model.
2008 – Concrete Syntax for a UML Action Language RFP
2010 – Alf 1.0 Beta (based on UML 2.4 and fUML 1.0)
2013 – Alf 1.0.1 (based on UML 2.4.1 and fUML 1.1)
2017 – Alf 1.1 (based on UML 2.4.1 and fUML 1.3)
2018? – Alf 1.2 (based on UML 2.5 and fUML 1.4)
Action Language for fUML (Alf)
11

We can model that!We can model that!
• Concrete Syntax – A BNF specification of the legal textual
syntax of the Alf language.
• Abstract Syntax – A MOF metamodel of the abstract syntax
tree that is synthesized during parsing of an Alf text, with
additional derived attributes and constraints that specify the
static semantic analysis of that text.
• Semantics – The semantics of Alf are defined by mapping
the Alf abstract syntax metamodel to the fUML abstract
syntax metamodel.
• Standard Model Library
– From the fUML Foundational Model Library
• Primitive Types (plus Natural and Bit String)
• Primitive Behaviors (plus Bit String Functions and Sequence
Functions)
• Basic Input/Output
– Collection Functions – Similar to OCL collection operations for
sequences
– Collection Classes – Set, Ordered Set, Bag, List, Queue,
Deque, Map
Alf Key Components
12

We can model that!
A virtual machine based
on concurrent UML
activity flow semantics.
The target for
“compiled”
models.
Architecture for Executable UML Tooling
fUML Execution
Engine
Model Development
Environment
Other Tools
Target Platform
Providing all the
capabilities expected
in a code-based IDE.
In memory
or via XMI
transfer.
Simulation,
analysis,
optimization,
etc.
13

We can model that!
Demo Example: Ordering

We can model that!
OrderLineItem – Textual View

We can model that!
OrderLineItem – getAmount operation

We can model that!
OrderLineItem – After compilation

We can model that!
OrderLineItem - Constructor

We can model that!
Order – Textual representation

We can model that!
Order – getAmount operation

We can model that!
testOrder – Simple test driver

We can model that!
Composite
Structure
Semantics
Complete
Activity Model
Semantics
State Machine
Semantics
Specifying Execution Semantics
Non-
Executable
Model
Semantics
Interaction
Model
Semantics
Foundational Semantics
fUML operational semantics are
specified as an execution model
written in fUML itself.
Base Semantics
The base semantics of the subset of
fUML used in the execution model are
specified using formal logic.
22

We can model that!
Execution Semantics and Base Semantics
(forall (n a xa f xn)
(if (and (ExecutableNode n)
(buml:activity n a)
(classifies a xa f)
(property-value xa n xn f)
(ipc:subactivity_occurrence-neq xn xa))
(forall (n a xal xa2 xn)
(if (and (ExecutableNode n)
(buml:activity n a)
(classifies a xa1 f)
(classified a xa2 f)
(property-value xa1 n xn f)
(property-value xa2 n xn f)
(= (psl:root occ xa1) (psl:root occ xa2))))
Execution Semantics
(Operational Specification)
Base Semantics
(Axiomatic Specification)
• Foundational UML (fUML) semantics are
specified operationally as a UML Model
written in Base UML (bUML).
• Base UML semantics are specified
axiomatically using Common Logic/Process
Specification Language (PSL).
23

We can model that!We can model that!
• Visitor Pattern
– Evaluations of Value Specifications
– Executions of Behaviors
– Activations of Activity Nodes
• Strategy Pattern
– Polymorphic Dispatching SVP
– Event Dispatching SVP
– Nondeterminism
Execution Model
LiteralString
LiteralString
Evaluation
evaluate()
Activity
Activity
Execution
execute()
DecisionNode
DecisionNode
Activation
run()
receiveOffer()
fire()
Dispatch
Strategy
dispatch()
GetNextEvent
Strategy
getNextEvent()
Choice
Strategy
choose()
FIFOGetNextE
ventStrategy
FirstChoice
Strategy
RedefinitionBased
DispatchStrategy
24

We can model that!
Execution Environment (1)
25
• Manages extents
• Proves pre-instantiated
discoverable services
• Evaluates value specifications
• Executes behaviors (synchronously)
• Starts behaviors or active objects
(asynchronously)

We can model that!
Execution Environment (2)
26
• Creates visitor objects
• Registers strategies
• Registers primitive types and primitive
behavior execution “prototypes”

We can model that!We can model that!
• fUML Implementations
– Open Source Reference Implementation
(Academic Free License 3.0)
http://fuml.modeldriven.org
– Moka for Papyrus Eclipse UML Tool
https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution
– Cameo Simulation Toolkit for MagicDraw from NoMagic
https://www.magicdraw.com/simulation
– Advanced Modeling | UML Simulation and Execution (AM|USE)
by LieberLieber for Enterprise Architect from Sparx Systems
• Alf Implementations
– Open Source Reference Implementation
(GNU General Public License 3.0)
http://alf.modeldriven.org
– Alf UI Interation for Papyrus Eclipse UML Tool (incubation)
(install from within Papyrus)
– Alf Plugin for MagicDraw (beta)
(install from within MagicDraw)
Implementations
27

Addendum:
Operational Semantics Overview
28

We can model that!
Denotational Mapping
evaluate(specification: ValueSpecification): Value
Abstract Syntax
Element
(Representation)
Semantic Model
Element
(Interpretation)
29

We can model that!
Abstract Syntax: Value Specifications
30

We can model that!
Semantics: Values
31

We can model that!
Representation: Instance Model
32

We can model that!
Interpretation: Instance Model
j = evaluate(v)
33

We can model that!
Semantics: Extensional Values
There are concepts in
the semantic model that
have no explicit
representation in the
abstract syntax.
34

We can model that!
Abstract Syntax/Semantics: Behavior
35

We can model that!
Abstract Syntax: Activities
36

We can model that!
Semantics: Activities
Additional semantic
concepts have
specifically to do with
dynamic behavior.
37

We can model that!
Model: Simple Activity
38

We can model that!
Representation: Simple Activity
39

We can model that!
Interpretation: Simple Activity Execution (1)
40

We can model that!
Interpretation: Simple Activity Execution (2)
41