The Unified Modeling Language (UML) has arguably succeeded in becoming the most commonly used modeling notation for software development. But “modeling” in the software community seems largely to mean simply drawing pictures, either to represent the problem domain or to blueprint a solution, without a precise enough meaning to fully specify the functionality of the system being developed. As a result, the UML standard,S up to and including UML 2.4.1, do not define the semantics of UML models at all precisely.
Nevertheless, there has also long been an interest in models that are more precise, even to the extent that they may be executed in their own right. It has taken a while for this viewpoint to penetrate into the mainstream of UML usage. But there has been in a great deal of work in recent years toward the standardization of the formal semantics of UML models – the “meaning” behind the pictures: the Foundational UML (fUML) specification adopted in 2008; the Action Language for fUML (Alf), adopted in 2010; the UML 2.5 specification (which includes a semantics conformance point for the first time); and the Precise Semantics of UML Composite Structures.
This presentation reviews the state of this work and the implications in practice of bringing real meaning to UML.
2. UML Prehistory: Object-Oriented Analysis and Design (1)
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.
3. UML Prehistory: Object-Oriented Analysis and Design (2)
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.
4. Unified Modeling Language v1.x
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.
5. Unified Modeling Language v2.x
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 Latest formal version
“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
6. Unified Modeling Language v2.5
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
2013 – UML 2.5 Finalized (planned)
“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
7. Executable Modeling Before UML
Before UML, there were already a number of approaches to modeling
with precise, executable semantics.
1998, 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.
8. Foundational UML (fUML)
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 Formal (based on UML 2.3)
2012 – fUML 1.1 Beta (based on UML 2.4.1)
9. Composite
Structure
Semantics
Complete
Activity Model
Semantics
State Machine
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.
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.
10. fUML Key Components
• 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”
11. Action Language for fUML (Alf)
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 Beta (based on UML 2.4.1 and fUML 1.1)
12. Alf Key Components
• 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
14. Using Alf to Define a Method
An operation specifies a
behavior that may be
synchronously invoked on
an instance of a class.
A method defines the
actual behavior that
is invoked.
15. Order: Classifier Behavior
A state machine abstracts
system behavior into a finite
number of states.
The system is modeled as
having discrete transitions
between the states.
A transition may trigger
further system behavior or
system behavior may be
dependent on the current
state.
Order is an active class
whose classifier behavior is
responsible for handling
ordering functionality.
16. Using Alf to Define an Activity (1)
An activity specifies
behavior as the
coordinated execution
of a set of subordinate
actions.
An action in one
activity may call
another activity.
Data and control
flow between the
various actions.
Other actions provide
various data and
computational functions.
Full executability requires
complete specification of behavior
and computation. This is often
much more easy to specify using
a textual notation.
18. 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.
19. The models are validated in a
development/test environment
The Goal: Programming in UML
The models are deployed in a production
environment
Developers
create fully
executable
models
It’s just programming, only better!
Developers iteratively execute, test and update
the models
20. Implementations
• fUML Implementations
– Open Source Reference Implementation
(Academic Free License 3.0)
http://fuml.modeldriven.org
– 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
http://www.lieberlieber.com/model-engineering/amuse/product-overview/
• Alf Implementations
– Open Source Reference Implementation
(GNU General Public License 3.0)
http://alf.modeldriven.org
– Alf for Papyrus Eclipse UML Tool (Ongoing)
21. Ongoing Work
• fUML Version 1.2
• Alf Version 1.1
• Precise Semantics of UML Composite Structures
• Additional “Precise Semantics” RFPs
– State machines
– Interactions
– Complete activities/process modeling
22. Addendum: Specifying Execution Semantics
• Execution Model
• Semantics of Values
• Semantics of Behavior
• Execution Semantics and Base Semantics
• Execution Environment
37. 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).
38. Execution Environment
• Locus
– Manages extents
– Provides pre-instantiated discoverable services
• Executor
– Evaluates value specifications
– Executes behaviors (synchronously)
– Starts behaviors or active objects (asynchronously)
• Execution Factory
– Creates visitor objects
– Registers strategies
– Registers primitive types and primitive behaviors