uml: this time we mean it!
TRANSCRIPT
Unified Modeling Language as anExecutable Modeling LanguageThis Time We Mean ItVienna University of TechnologyEd Seidewitz25 October 2016
We can model that!We can model that! 2
OOAD orthodoxy (c. 1980s)Organize programs to model the basic concepts of the problem domain.
ProblemProgramming 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)
We can model that!We can model that! 3
SolutionUse 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)
We can model that!We can model that! 4
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 Rational1997 – 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
We can model that!We can model that! 5
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 Adopted2005 – UML 2.0 Finalized2011 – 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
We can model that!We can model that! 6
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 RFI2009 – 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
We can model that!We can model that! 7
Before UML, there were already a number of approaches to modeling with precise, executable semantics.
1988, 1991 – Shlear-Mellor Object-Oriented Analysis1988, 1998 – Harel Statecharts1994 – 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
We can model that!We can model that! 8
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 RFP2003 – UML 1.5 with action semantics formalized2003 – UML 2.0 adopted2005 – Semantics of a Foundational Subset for
Executable UML Models RFP2008 – 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)
We can model that! 9
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
We can model that!We can model that! 10
• 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
We can model that!We can model that! 11
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 RFP2010 – 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)
We can model that!We can model that! 12
• 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
We can model that! 13
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.
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! 22
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.
We can model that! 23
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).
We can model that!We can model that! 24
• Visitor Pattern– Evaluations of Value Specifications
– Executions of Behaviors
– Activations of Activity Nodes
• Strategy Pattern– Polymorphic Dispatching SVP
– Event Dispatching SVP
– Nondeterminism
Execution Model
LiteralStringLiteralString Evaluation
evaluate()
ActivityActivity
Execution
execute()
DecisionNode
DecisionNode Activation
run()receiveOffer()fire()
Dispatch Strategy
dispatch()
GetNextEvent Strategy
getNextEvent()
Choice Strategy
choose()
FIFOGetNextEventStrategy
FirstChoice Strategy
RedefinitionBased DispatchStrategy
We can model that! 25
Execution Environment (1)
• Manages extents• Proves pre-instantiated
discoverable services
• Evaluates value specifications• Executes behaviors (synchronously)• Starts behaviors or active objects
(asynchronously)
We can model that! 26
Execution Environment (2)• Creates visitor objects• Registers strategies• Registers primitive types and primitive
behavior execution “prototypes”
We can model that!We can model that! 27
• fUML Implementations– Open Source Reference Implementation
(Academic Free License 3.0) http://fuml.modeldriven.org
– Moka for Papyrus Eclipse UML Toolhttps://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution
– Cameo Simulation Toolkit for MagicDraw from NoMagichttps://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
28
Addendum: Operational Semantics Overview
We can model that! 29
Denotational Mapping
evaluate(specification: ValueSpecification): Value
Abstract Syntax Element
(Representation)
Semantic Model Element
(Interpretation)
We can model that! 30
Abstract Syntax: Value Specifications
We can model that! 31
Semantics: Values
We can model that! 32
Representation: Instance Model
We can model that! 33
Interpretation: Instance Model
j = evaluate(v)
We can model that! 34
Semantics: Extensional Values
There are concepts in the semantic model that
have no explicit representation in the
abstract syntax.
We can model that! 35
Abstract Syntax/Semantics: Behavior
We can model that! 36
Abstract Syntax: Activities
We can model that! 37
Semantics: Activities
Additional semantic concepts have
specifically to do with dynamic behavior.
We can model that! 38
Model: Simple Activity
We can model that! 39
Representation: Simple Activity
We can model that! 40
Interpretation: Simple Activity Execution (1)
We can model that! 41
Interpretation: Simple Activity Execution (2)