The Unified Modeling Language (UML) is, of course, a modeling language. But there are now standard, executable semantics for a subset of UML (known as Foundational UML or fUML) and a standard language that provides a textual representation for this subset (the Action Language for fUML or Alf). Doesn’t this just make at least this subset of UML into a programming language? Well, yes. After all, a programming language is really itself a modeling language for modellng computations that can actually be executed on computation hardware. In this view, all programs are models, but only some models, the executable models, are programs. Which means that an “executable modelling language” is, by definition, a programming language. But is this a good thing? That is the question explored in this presentation, which argues that the answer is “yes”. And, moreover, UML as a programming language may, in fact, be important for moving forward in a number of, perhaps, unexpected areas, including agile development methods and programming for multi-core architectures.

1. UML® as a
Programming Language
Ed Seidewitz
Presented at the
Vienna University of Technology
3 December 2014
Copyright © 2014 Ed Seidewitz
UML® is a registered trademark of the Object Management Group
1

2. Developers provide feedback to
the architects (maybe)
Modeling is extra work (isn’t it?)
It is hard to validate the correctness of the models before development.
The developers may not follow the models, without providing feedback.
It is hard to keep the models and development artifacts in sync during
development (and maintenance).
Architects give models to developers
Developers
create artifacts
based on the
models
(maybe)
Architects
create the
models
Copyright © 2014 Ed Seidewitz 2

3. There are two responses
1. Code-based development
Use models for initial design, but then focus on code
Pro: Code is single source of “truth”
Con: Code is not as good for expressing design as
models.
Copyright © 2014 Ed Seidewitz 3

4. There are two responses
2. Model-driven development
Use models as the source artifacts for development
Pro: Models can be more easily understood and
evolved by human developers and maintainers.
Con: Model must be detailed enough to be
executable in its own right.
But is this really a “con”??
Copyright © 2014 Ed Seidewitz 4

5. The question Is…
If we are going to take the time to carefully
design our system using UML
Structural models
Behavioral models
Then why can’t we use these directly to
execute our system
Copyright © 2014 Ed Seidewitz 5

6. The answer is…we can!
Just add detailed behavior
But...
Making models detailed enough for machine
execution defeats the purpose of models for
human communication.
Executable models can still be more
understandable than executable code.
(Non-executable models are still useful, too.)
Copyright © 2014 Ed Seidewitz 6

7. The answer is…we can!
UML is not specified precisely enough to be executed
(at least not in a standard way).
Just add detailed behavior
But...
The Foundational UML (fUML) standard specifies
precise semantics for an executable subset of UML.
Copyright © 2014 Ed Seidewitz 7

8. The answer is…we can!
Graphical modeling notations are not good for
detailed programming.
Just add detailed behavior
But...
The Action Language for fUML (Alf) standard specifies
a textual action language with fUML semantics.
Copyright © 2014 Ed Seidewitz 8

9. Example: Property Management SOA
Graphical UML notation for
Data model
Message model
Interface and class models
Component models
Textual Alf notation for
Operation methods
Copyright © 2014 Ed Seidewitz 9

10. Property Data Model
Copyright © 2014 Ed Seidewitz 10

11. Service Request Message Model
Copyright © 2014 Ed Seidewitz 11

12. Service Reply Message Model
Copyright © 2014 Ed Seidewitz 12

13. Service Interface and Implementation
Copyright © 2014 Ed Seidewitz 13

14. Service Provider Component
Copyright © 2014 Ed Seidewitz 14
Composite structure and
ports are not in fUML, but
they are in the Precise
Semantics of Composite
Structure (PSCS) extension.

15. Operation method: establish
Copyright © 2014 Ed Seidewitz 15
/** Establish a new property record. */
activity establish (
in request: 'Property Record Establishment',
out reply: 'Property Management Success Reply' [0..1],
out error: 'Error Reply' [0..1] ) {
identifier = this.'property identifier factory'.'get next identifier'();
if (request.'property type' == 'Property Type'::personal) {
property = new 'Personal Property'::'create property'(identifier,request.name);
} else {
property = new 'Real Property'::'create property'(identifier,request.name);
}
reply = this.'create reply'(request.identifier, property);
}
Operation methods
are specified as UML
activities.
Newly created objects
persist at the current
execution locus.
Names can have
spaces or other
special characters.

16. Operation method: update
Copyright © 2014 Ed Seidewitz 16
/** Update the data of a property other than acquisition or disposition. */
activity update (
in request: 'Property Record Update',
out reply: 'Property Management Success Reply' [0..1],
out error: 'Error Reply' [0..1] ) {
property = Property -> select p (p.identifier == request.'property identifier');
if (property -> isEmpty()) {
error = new 'Error Reply' (
identifier => request.identifier + "/error",
'request identifier' => request.identifier,
'error code' => "PRU-001",
'error message' => "Property not found." );
} else if (property.status == 'Property Type'::disposed) {
…
} else {
if (request.'property location' -> notEmpty()) {
location = Location -> select loc
(loc.identifier == request.'property location');
'Property Location'.createLink(property, location);
}
…
}
}
A “select” maps to a
concurrent expansion
region over a class
extent.
Creating a link automatically
establishes a bidirectional
relationship.

17. The models are validated in a
development/test environment
We can program in UML!
The models are deployed in a production
environment
Developers
create fully
executable
models
Developers iteratively execute, test
and update the models
Copyright © 2014 Ed Seidewitz 17
Agile development…with executable models!

18. But why UML?
UML…
Allows abstractions closer to the
problem domain
Is already familiar to developers for
design
Has widely available
tooling
© 2014 Ed Seidewitz 18

19. Multi-core processing is the future
1
10
100
1 000
10 000
100 000
1 000 000
10 000 000
1975 1980 1985 1990 1995 2000 2005 2010
Transistors
(1000s)
Clock (MHz)
Copyright © 2014 Ed Seidewitz 19

20. Why is multi-core hard?
Traditional processor architecture
Single processor
Local registers / cache
Remote memory
Traditional programming language
Functions / procedures
Local variables / stack
Heap memory
Traditional modeling language
Things / Relationships
Events / Behaviors
Communication
Automatic
compilation
Human
implementation
Copyright © 2014 Ed Seidewitz 20

21. Why is multi-core hard?
Traditional processor architecture
Single processor
Local registers / cache
Remote memory
Traditional programming language
Functions / procedures
Local variables / stack
Heap memory
Traditional modeling language
Things / Relationships
Events / Behaviors
Communication
Multi-core processor architecture
Many processors
Much local memory
Global memory (?)
Concurrency is
natural here
Concurrency is
natural here
Concurrency is
NOT natural here!
Copyright © 2014 Ed Seidewitz 21

22. from Oracle presentation “Divide and Conquer
Parallelism with the Fork/Join Framework”
What makes it easier?
Result solve(Problem p) {
if (p.size() < SEQUENTIAL_THRESHOLD
{
return p.solveSequentially();
} else {
Result left, right;
INVOKE-IN-PARALLEL
{ left = solve(p.leftHalf());
right = solve(p.rightHalf());
}
return combine(left, right);
}
}
Pseudo-code
Divide and conquer (fork/join)
Copyright © 2014 Ed Seidewitz 22

23. from Oracle presentation “Divide and Conquer
Parallelism with the Fork/Join Framework”
What makes it easier?
Result solve(Problem p) {
if (p.size() < SEQUENTIAL_THRESHOLD
{
return p.solveSequentially();
} else {
Result left, right;
INVOKE-IN-PARALLEL
{ left = solve(p.leftHalf());
right = solve(p.rightHalf());
}
return combine(left, right);
}
}
class SolutionTask
extends
RecursiveAction {
Problem p;
SolutionTask(
Problem p) {…}
void compute() {SolutionTask left =
new SolutionTask(…);
SolutionTask right=
new SolutionTask(…);
invokeAll(left, right);
Java
Divide and conquer (fork/join)
Copyright © 2014 Ed Seidewitz 23

24. What makes it easier?
Result solve(Problem p) {
if (p.size() < SEQUENTIAL_THRESHOLD
{
return p.solveSequentially();
} else {
//@parallel
{ left = solve(p.leftHalf());
right = solve(p.rightHalf());
}
return combine(left, right);
}
}
solve(in p: Problem): Result {
Alf UML
«structured»
«structured»
«structured»
Divide and conquer (fork/join)
Copyright © 2014 Ed Seidewitz 24

25. What makes it easier?
Bulk data (select/map/reduce)
data->select x (filter(x))->collect x (map(x))->reduce combine
Alf
map
«parallel»
filter
«parallel»
«reduce»
combine
UML
Copyright © 2014 Ed Seidewitz 25

26. What makes it easier?
Asynchronous objects (actors)
GetAuthorization
ChargeApproved
new
CreditCardCharge
ChargeApproved
ChargeDenied
Copyright © 2014 Ed Seidewitz 26

27. But why UML?
Why not
Clojure
Scala F++
Haskell
Erlang
These all require new ways of
thinking about coding
…
Copyright © 2014 Ed Seidewitz 27

28. But why UML?
UML…
Allows abstractions closer to the
problem domain
Is already familiar to developers for
design
Has widely available
tooling
Copyright © 2014 Ed Seidewitz 28
Deals with concurrency in the

29. UML as a Programming Language
© 2014 Ed Seidewitz 29
LieberLieber AM|USE
for Sparx Enterprise Architect
http://www.lieberlieber.com/model-engineering/amuse
NoMagic Cameo Simulation Toolkit
for MagicDraw
https://www.magicdraw.com/simulation
Moka Model Execution Engine
for Eclipse Papyrus (open source)
https://wiki.eclipse.org/Papyrus/UserGuide/ModelExecution

30. UML as a Programming Language
© 2014 Ed Seidewitz 30
fUML Open Source Reference Implementation
http://fuml.modeldriven.org
(see also http://www.modelexecution.org)
Alf Open Source Reference Implementation
http://alf.modeldriven.org
Unified Modeling Language
http://www.uml.org
Ed Seidewitz
ed-s@modeldriven.com
@seidewitz