Programming in UML: An Introduction to fUML 1.3 and Alf 1.1

19 March 2018
Copyright © 2018 Model Driven Solutions, Inc.
Programming in UML:
An Introduction to fUML and Alf
Updated for fUML 1.3 and Alf 1.1

Copyright © 2018 Model Driven Solutions, Inc. 19 February 2018
Agenda
I. Introduction
II. Elements of Executable UML
III. Standard Model Library

I. Introduction
A. A Motivating Example
B. Executable UML
C. The Standards

A. A Motivating Example
• E-Commerce Ordering System
– Loosely based on the Online Bookstore Domain Case Study given
in Appendix B of the book Executable UML: A Foundation for Model
Driven Architecture by Stephen J. Mellor and Marc J. Balcer
(Addison-Wesley, 2002)
• To be designed in UML
– Class models for structure
– State machine models for behavior
• To be implemented on the Web
– Using Java/JEE
– …or maybe C#/.Net
– …or maybe LAMP
– …or whatever…

Ordering: Class Model
Order is an active class
whose classifier behavior
is responsible for handling
ordering functionality.
Order is an active class
whose classifier behavior
is responsible for handling
ordering functionality.

Order: Classifier Behavior
A state machine abstracts
system behavior into a
finite number of states.
A state machine abstracts
system behavior into a
finite number of states.
The system is modeled as
having discrete transitions
between the 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.
A transition may trigger
further system behavior or
system behavior may be
dependent on the current
state.

Order Behavior: EstablishCustomer Activity
An activity specifies
behavior as the
coordinated
execution of a set of
subordinate actions.
An activity specifies
behavior as the
coordinated
execution of a set of
subordinate actions.
An action in one
activity may call
another activity.
An action in one
activity may call
another activity.
Data and control
flow between the
various actions.
Data and control
flow between the
various actions.
Other actions provide
various data and
computational functions.
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.
Full executability requires
complete specification of
behavior and computation. This
is often much more easy to
specify using a textual notation.

The Question Is…
• If we are going to take the time to carefully design our system
using UML, e.g.,
– Structural models of classes and associations
– Behavioral models using state machines or operations and messages
• Then why can’t we use these directly to execute our system?
The answer is: We can!
• Just add detailed behavior…
– …which is best done using a textual action language…
– …which should be at the same semantic level as the rest of the model.

B. Executable UML: Perceived Issues
• Making models detailed enough for machine execution defeats
the purpose of models for human communication.
• UML is not specified precisely enough to be executed (at least
not in a standard way).
• Graphical modeling notations are not good for detailed
programming.

Executable UML: Issue Resolutions
• 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.
• UML is not specified precisely enough to be executed (at least
not in a standard way).
– The Foundational UML (fUML) standard specifies precise
semantics for an executable subset of UML.
– fUML Version 1.0 formal specification now available.
• Graphical modeling notations are not good for detailed
programming.
– The Action Language for fUML (Alf) standard specifies a
textual action language with fUML semantics.
– Alf Version 1.0 finalization in progress.

C. The Standards
• Unified Modeling Language (UML)
• Executable UML Foundation (fUML)
• UML Action Language (Alf)

Unified Modeling Language (UML)
The Unified Modeling Language (UML) is a graphical language for
modeling the structure, behavior and interactions of software,
hardware and business systems, standardized by the Object
Management Group (OMG).
• UML Version 1.1 (first standard) – December 1997
• UML Version 1.5 (with action semantics) – March 2003
• UML Version 2.0 (new version) – July 2005
• UML Version 2.4.1 – July 2011
• UML Version 2.5 (spec simplification) – May 2015
• UML Version 2.5.1 (current standard) – December 2017

Executable UML Foundation (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.
• fUML Version 1.0 – January 2011
• fUML Version 1.1 – July 2013
• fUML Version 1.2.1 – December 2016
• fUML Version 1.3 (current standard) – October 2017
• fUML Version 1.4 (migration to UML 2.5.1) – 2018 (planned)

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, Real, Unlimited Natural
– Primitive Behaviors – Boolean, String and Arithmetic Functions
– Basic Input/Output – Based on the concept of “Channels”
Added in fUML
1.1
Added in fUML
1.1

Other Precise Semantics Specifications
The following specifications build on the foundation of fUML:
•Precise Semantics of UML Composite Structure (PSCS)
– Version 1.1 (beta) – June 2017
•Precise Semantics of UML State Machines (PSCS)
– Version 1.0 (alpha) – December 2016 (in finalization)
•Precise Semantics of Time for Foundational UML
– RFP issued – December 2017
– Revised submissions due – August 2019

UML Action Language (Alf)
The Action Language for Foundational UML (Alf) is a textual
surface representation for UML modeling elements with the
primary purpose of acting as the surface notation for specifying
executable (fUML) behaviors within an overall graphical UML
model. (But which also provides an extended notation for
structural modeling within the fUML subset.)
• Alf Version 1.0 (beta) – November 2012
• Alf Version 1.0.1 (migration to fUML 1.1) – September 2013
• Alf Version 1.1 (current standard) – June 2017
• Alf Version 1.2 (migration to fUML 1.4) – 2018/2019 (planned)

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

II. Elements of Executable UML
A. Activities
B. Actions
C. Structure
D. Asynchronous Communication

A. Activities
• Activities and Parameters
• Actions and Flows
• Textual Notation
• Tokens
• Offers
• Control Nodes
• Structured Nodes

Activities and Parameters
An activity is a specification of behavior as
the coordinated execution of subordinate
actions, using a control and data flow
model.
An activity is a specification of behavior as
the coordinated execution of subordinate
actions, using a control and data flow
model.
An activity may have input,
output and return parameters.
An activity may have input,
output and return parameters.
The parameters have corresponding activity
parameter node on the boundary of the
diagrammatic representation of an activity.
The parameters have corresponding activity
parameter node on the boundary of the
diagrammatic representation of an activity.

Actions and Flows
An action is a fundamental
unit of executable behavior
within an activity.
An action is a fundamental
unit of executable behavior
within an activity.
A pin is an activity node that
either accepts input to or
provides output from an action.
A pin is an activity node that
either accepts input to or
provides output from an action.
An object flow provides
a path for passing
objects or data.
An object flow provides
a path for passing
objects or data.
A control flow specifies
the sequencing of
actions.
A control flow specifies
the sequencing of
actions.
An activity diagram is a graph structure
consisting of activity nodes connected by
activity edges.
An activity diagram is a graph structure
consisting of activity nodes connected by
activity edges.

Textual Notation
activity DoSomething(in input: Integer, out output Integer): Integer {
output = A(input);
return B();
}
activity DoSomething(in input: Integer, out output Integer): Integer {
output = A(input);
return B();
}
Alf behavioral notation
maps to fUML activity
models.
Alf behavioral notation
maps to fUML activity
models.
The semantics of the Alf notation
is defined by its mapping to
fUML
The semantics of the Alf notation
is defined by its mapping to
fUML

Tokens
a = DoSomething(1, b);a = DoSomething(1, b);
A token is a container for an object, datum
or locus of control that may be present at an
activity node.
A token is a container for an object, datum
or locus of control that may be present at an
activity node.
The activity is invoked
with an argument of 1
for its input parameter.
The activity is invoked
with an argument of 1
for its input parameter.
An object token with a
value of 1 is placed on
the input activity
parameter node.
An object token with a
value of 1 is placed on
the input activity
parameter node.
The object token flows to
the input pin of action A
along the object flow.
The object token flows to
the input pin of action A
along the object flow.
Action A fires and
produces an object
token on its output pin.
Action A fires and
produces an object
The object token flows
to the output activity
parameter node along
the object flow.
the object flow.
When it is done, action A
produces a control token,
which flows to action B
along the control flow.
When it is done, action A
produces a control token,
which flows to action B
along the control flow.
Action B accepts the
control token and fires,
producing an object
Action B accepts the
control token and fires,
producing an object
the object flow.
the object flow.
Values on the output activity
parameter nodes are copied
to the output arguments.
Values on the output activity
parameter nodes are copied
to the output arguments.

Offers
An output pin offers its
tokens to the targets of
all outgoing object flows.
An output pin offers its
tokens to the targets of
all outgoing object flows.
A single token can only flow to one
target. If two competing targets are
both ready to accept an offer for the
same token, it is indeterminate
which will get the token.
A single token can only flow to one
target. If two competing targets are
both ready to accept an offer for the
same token, it is indeterminate
which will get the token.
Note: fUML semantics do not guarantee
“liveliness” or “fairness” in the execution of
actions competing for tokens.
Note: fUML semantics do not guarantee
“liveliness” or “fairness” in the execution of
actions competing for tokens.
Actions with no control constraints
execute concurrently. This means that
they may execute in parallel – or they
may execute sequentially in any order.
Actions with no control constraints
execute concurrently. This means that
they may execute in parallel – or they
may execute sequentially in any order.

Fork and Join Nodes
order = 'Create Order'();
//@parallel
{
'Fulfill Order'(order);
'Invoice Order'(order);
}
'Close Out Order'(order);
order = 'Create Order'();
//@parallel
{
'Fulfill Order'(order);
'Invoice Order'(order);
}
'Close Out Order'(order);
A fork node copies the
tokens it is offered,
and offers a copy on
each outgoing flow.
A fork node copies the
tokens it is offered,
and offers a copy on
each outgoing flow.
A join node waits for a token
to be offered on all incoming
flows and then offers tokens
on its outgoing flow.
A join node waits for a token
to be offered on all incoming
flows and then offers tokens
on its outgoing flow.
In the Alf textual notation,
forks and joins are implicit in
the parallel block notation.
In the Alf textual notation,
forks and joins are implicit in
the parallel block notation.
Note: Alf does not actually provide any
notation for competition for tokens on
output pins. A fork node is always inserted
for multiple flows out of any output pin.
Note: Alf does not actually provide any
notation for competition for tokens on
output pins. A fork node is always inserted
for multiple flows out of any output pin.

Control Nodes
An initial node
generates a single
control token.
An initial node
generates a single
control token.A merge node
passes on any
tokens it receives.
A merge node
passes on any
tokens it receives.
A decision node
routes tokens based
on a decision input
value.
A decision node
routes tokens based
on a decision input
value. An activity final
node terminates
the activity when it
receives a token.
An activity final
node terminates
the activity when it
receives a token.
A control node is an activity
node used to coordinate the
flow of (the offers for) tokens
between other nodes.
A control node is an activity
node used to coordinate the
flow of (the offers for) tokens
between other nodes.
Note: A data store node
is used so a “card”
token is available for
each iteration.
Note: A data store node
is used so a “card”
token is available for
each iteration.
Note: Since the decision
node “gates” control flow,
it must be provided with an
incoming control token.
Note: Since the decision
node “gates” control flow,
it must be provided with an
incoming control token.
Added in fUML
1.3
Added in fUML
1.3

Structured Nodes
card = 'Select Credit Card'();
do {
charge = 'Create Credit Card Charge'(card);
if ('Check Charge Approval'(charge)) {
'Notify Customer of Approval'(charge);
declined = false;
} else {
'Notify Customer of Denial'(charge);
declined = true;
}
} while (declined);
card = 'Select Credit Card'();
do {
charge = 'Create Credit Card Charge'(card);
if ('Check Charge Approval'(charge)) {
'Notify Customer of Approval'(charge);
declined = false;
} else {
'Notify Customer of Denial'(charge);
declined = true;
}
} while (declined);
A structured node is an activity
node used to group subordinate
nodes into a control structure.
A structured node is an activity
node used to group subordinate
nodes into a control structure.
An loop node iterates
the execution of its
body while a
condition is true.
An loop node iterates
the execution of its
body while a
condition is true.
By default, the
condition is tested
after execution of
the body.
By default, the
condition is tested
after execution of
the body.
A conditional node
executes one
clause or another
based on the result
of a test (or tests).
A conditional node
executes one
clause or another
based on the result
of a test (or tests).
Inputs to the loop node
initialize loop variables
available across all
iterations of the loop.
Inputs to the loop node
initialize loop variables
available across all
iterations of the loop.
Note: There is no normative UML
graphical notation for loop or
conditional nodes.
Note: There is no normative UML
graphical notation for loop or
conditional nodes.
break;
true
Alf also provides
a traditional
break statement.
Alf also provides
a traditional
break statement.

Expansion Regions
'Get Outstanding Orders'(customer) ->
select order ('Is Delinquent?'(order)) ->
iterate order ('Refer for Collection'(order));
'Get Outstanding Orders'(customer) ->
select order ('Is Delinquent?'(order)) ->
iterate order ('Refer for Collection'(order));
An expansion region is
used to apply subordinate
actions on all members of
an input collection
An expansion region is
used to apply subordinate
actions on all members of
an input collection
A parallel expansion
region applies nested
behavior concurrently
to all collection
elements.
A parallel expansion
behavior concurrently
to all collection
elements.
An iterative expansion
behavior sequentially
to all collection
elements.
An iterative expansion
behavior sequentially
to all collection
elements.
Alf provides specialized
notation that maps to typical
uses of expansion regions.
Alf provides specialized
notation that maps to typical
uses of expansion regions.

Reduction
A reduction action “inserts”
a binary function between
the elements of a
sequence of values.
A reduction action “inserts”
a binary function between
the elements of a
sequence of values.
this.totalAmount =
this.lineItems.amount->reduce MoneyFunctions::Add;
this.totalAmount =
this.lineItems.amount->reduce MoneyFunctions::Add;
this.totalAmount =
this.lineItems.amount->reduce MoneyFunctions::Add
?? new Money(0, 0);
this.totalAmount =
this.lineItems.amount->reduce MoneyFunctions::Add
?? new Money(0, 0);
This is shorthand for
“this.lineItems->collect item (item.amount)”.
This is shorthand for
“this.lineItems->collect item (item.amount)”.
If the input sequence is empty, then
reduction results in “null” (the empty
sequence). An Alf null-coalescing
expression can be used to provide a
default value for this case. (Corresponding
UML not shown.)
If the input sequence is empty, then
reduction results in “null” (the empty
sequence). An Alf null-coalescing
expression can be used to provide a
default value for this case. (Corresponding
UML not shown.)

B. Actions
• Invocation Actions
• Object Actions
• Structural Feature Actions
• Link Actions
NOTE: Some of these actions will be discussed in more detail later.NOTE: Some of these actions will be discussed in more detail later.

Invocation Actions
• Call Behavior
– Calling an activity
– Calling a primitive behavior
• Call Operation
• Send Signal
• Accept Event
PlaceOrder(customer, product)
Max(throttle, limit) count + quantity
order.addProduct(product, quantity)
vehicle.EngageBrake(pressure)
accept (signal: EngageBrake)

Object Actions
• Value Specification
• Create Object
• Destroy Object
• Test Identity
• Read Self
• Read Extent
• Read Is Classified Object
• Reclassify Object
1 true "Hello"
new Order()
order.destroy()
order == myOrder name != customerName
this
Order.allInstances()
vehicle instanceof Car car hastype Hatchback
reclassify order from PendingOrder to ClosedOrder

Structural Feature Actions
• Read Structural Feature
• Add Structural Feature Value
• Remove Structural Feature Value
• Clear Structural Feature Value
order.customer
order.datePlaced = today
order.lineItems->add(item)
order.lineItems->addAt(1,item)
order.lineItems->remove(item)
order.lineItems->removeAt(1)
order.card = null

Link Actions
• Read Link
• Create Link
• Destroy Link
• Clear Association
Owns.person(house=>thisHouse) thisHouse.person
Owns.addLink(person=>jack, house=>newHouse)
Owns.removeLink(person=>jack, house=>oldHouse)
Owns.clearAssoc(jack)

Computation
• Indexing (from 1 , not 0)
• Increment/Decrement
• Arithmetic/Logic
• Comparison
• Conditional
• Isolation
order.lineItems[i] order.lineItems->at(i)
index++ ++count
total + value address & mask
total > threshold index <= count
count != 0 && total/count > limit
count < min || count > max
$this.sensor.getReading().value

C. Structure
• Structural and Behavioral Models
• Classes
• Associations

Structural and Behavioral Models
• A structural model (e.g., a class model) specifies the relevant
(types of) instances in a domain that may exist at any one point
in time.
– Structural semantics define how a structural model constrains
allowable instances.
• A behavioral model (e.g., an activity model) specifies behavior
over time
– Behavioral semantics define how a behavioral model changes the
state of instances over time.

Classes
• Attributes
• Data Types
• Primitive Types
• Operations and Methods
• Structural Semantics
• Behavioral Semantics
A class is a classifier of objects that persist in the extent of
the class, with an identity that is independent of the value of
their attributes at any one time.
A class is a classifier of objects that persist in the extent of
the class, with an identity that is independent of the value of
their attributes at any one time.

Classes and Attributes
A class may have
attributes whose types
are primitive, data
types or other classes.
A class may have
attributes whose types
are primitive, data
types or other classes.
A referential attribute,
whose type is a class, is
conventionally notated as
an association with a class-
owned association end.
A referential attribute,
whose type is a class, is
conventionally notated as
an association with a class-
owned association end.
A bidirectional association
results in corresponding
referential attributes on
both associated classes.
A bidirectional association
results in corresponding
referential attributes on
both associated classes.

Data Types
A data type is a classifier of transient data
values whose identity is based on the values
of their attributes.
A data type is a classifier of transient data
values whose identity is based on the values
of their attributes.
Data types may
have attributes, but
not operations.
Data types may
have attributes, but
not operations.

Primitive Types
• From UML 2.4.1 PrimitiveTypes Package
– Boolean
– Integer
– Real
– UnlimitedNatural
– String
Used since fUML
1.1
Used since fUML
1.1

Classes: Operations and Methods
An operation specifies a
behavior that may be
synchronously invoked
on an instance of a class.
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.
A method defines
the actual behavior
that is invoked.

Classes: Structural Semantics
Structural semantics specify how
a structural model constrains
Objects are instances
of classes with values
for each attribute.
Objects are instances
of classes with values
for each attribute.
Class-owned association
ends are structural features
with values, like attributes.
Class-owned association
ends are structural features
with values, like attributes.
fUML does not actually give
semantics to an association
with class-owned ends, only to
the ends as structural features.
fUML does not actually give
semantics to an association
with class-owned ends, only to
the ends as structural features.
Note: fUML does provide
“reified” semantics for
associations that own their own
ends, as will be discussed later.
Note: fUML does provide
“reified” semantics for
associations that own their own
ends, as will be discussed later.

Classes: Behavioral Semantics
• Creating an Order
• Adding a Line Item
• Canceling an Order
Behavioral semantics specify how a behavioral model
changes the state of instances over time.

Creating an Order
order = new Order (customer, today)
Before After
@Create
public Order (in customer: Customer, in datePlaced: Date) {
this.datePlaced = datePlaced;
this.totalAmount = new Money(dollars=>0, cents=>0);
this.customer = customer;
this.customer.orders->add(this);
}
@Create
this.customer = customer;
this.customer.orders->add(this);
}
A new object is created
and the constructor
operation is invoked.
A new object is created
and the constructor
operation is invoked.
The constructor initializes
the new order’s attribute
values…
The constructor initializes
the new order’s attribute
values…
…and adds the order
to the customer’s list.
…and adds the order
to the customer’s list.

Adding a Line Item
Before After
order.addProduct (product, 2)
public addProduct
(in product: Product, in quantity: Integer) {
lineItem = new LineItem(product, quantity);
this.lineItems->add(lineItem);
this.totalAmount = MoneyFunctions::Add
(this.totalAmount, lineItem.amount);
}
public addProduct
(in product: Product, in quantity: Integer) {
lineItem = new LineItem(product, quantity);
this.lineItems->add(lineItem);
this.totalAmount = MoneyFunctions::Add
(this.totalAmount, lineItem.amount);
}
The method for the
operation creates a
new line item object…
The method for the
operation creates a
new line item object…
The addProduct
operation is invoked
on an existing Order
object.
The addProduct
operation is invoked
on an existing Order
object.
…adds the new object
to the list of line items
for the order…
…adds the new object
to the list of line items
for the order…
…and updates
the total order
amount.
…and updates
the total order
amount.

Canceling an Order
Before After
order.cancel()
@Destroy
public cancel() {
this.customer.orders->remove(this);
}
@Destroy
public cancel() {
this.customer.orders->remove(this);
}
A destructor operation is
invoked, after which the
order object is destroyed.
Because line items
are aggregated by
composition, they
are destroyed, too.
Because line items
are aggregated by
composition, they
are destroyed, too.
References to the
destroyed object must
be explicitly removed.
References to the
destroyed object must
be explicitly removed.

Associations
• Classes and Associations
• Structural Semantics
• Behavioral Semantics
An association is a classifier whose instances are links that
relate other instances.
An association is a classifier whose instances are links that
relate other instances.

Classes and Associations
An association (that owns its
ends) is a classifier of
persistent links between the
associated classes, which exist
in the extent of the association.
An association (that owns its
ends) is a classifier of
persistent links between the
associated classes, which exist
in the extent of the association.

Associations: Structural Semantics
Links are now semantic
instances of the indicated
associations.
Links are now semantic
instances of the indicated
associations.
allowable instance models.
allowable instance models.

Associations: Behavioral Semantics
• Creating an Order (revised)
• Canceling an Order (revised)

Creating an Order (revised)
order = new Order (customer, today)
Before After
@Create
Customer_Order.addLink(customer, this);
}
@Create
Customer_Order.addLink(customer, this);
}
A single action creates
a bidirectional link.
A single action creates
a bidirectional link.

Canceling an Order (revised)
Before After
order.cancel()
@Destroy
public cancel() { }
@Destroy
public cancel() { }
Links in which the
destroyed object
participates are now also
automatically destroyed.
Links in which the
destroyed object
participates are now also
automatically destroyed.

D. Asynchronous Communication
• Signals and Receptions
• Classifier Behaviors
• Asynchronous Behavior

Signals and Receptions
A signal is a classifier
whose instances may
be communicated
asynchronously.
A signal is a classifier
whose instances may
be communicated
asynchronously.
A reception is a
declaration of the ability
to receive a signal.
A reception is a
declaration of the ability
to receive a signal.
A signal may have
attributes that represent
transmittable data.
A signal may have
attributes that represent
transmittable data.
More than one
class can receive
the same signal.
More than one
class can receive
the same signal.

Classifier Behaviors
An active class is one that
has a classifier behavior.
Only active class may
receive signals.
An active class is one that
has a classifier behavior.
Only active class may
receive signals.
A classifier behavior is an
autonomous behavior
started when an active
class is instantiated.
A classifier behavior is an
autonomous behavior
started when an active
class is instantiated.

Asynchronous Behavior
accept (submission: SubmitCharge);
card = submission.card;
do {
new CreditCardCharge(card, this);
accept (response: ChargeApproved) {
this.customer.ChargeApproved(response.charge);
break;
} or accept (response: ChargeDeclined) {
this.customer.ChargeDeclined(response.charge);
}
while (true);
accept (submission: SubmitCharge);
card = submission.card;
do {
new CreditCardCharge(card, this);
accept (response: ChargeApproved) {
this.customer.ChargeApproved(response.charge);
break;
} or accept (response: ChargeDeclined) {
this.customer.ChargeDeclined(response.charge);
}
while (true);
The order object
accepts a signal to
submit a charge.
The order object
accepts a signal to
submit a charge.
The order object creates
a new credit card charge
object, which begins its
asynchronous behavior.
The order object creates
a new credit card charge
object, which begins its
asynchronous behavior.
Note: UML semantics require a separate action
to start the behavior of a new object. However,
Alf notation for creating an active class maps to
both create and start object behavior actions.
Note: UML semantics require a separate action
to start the behavior of a new object. However,
Alf notation for creating an active class maps to
both create and start object behavior actions.
The order object
accepts a signal from
the charge object that
the charge is approved.
The order object
accepts a signal from
the charge object that
the charge is approved.The order object
sends a signal to the
customer that the
charge is approved.
The order object
sends a signal to the
customer that the
charge is approved.

III. Standard Model Library
• Primitive Behaviors
• Collection Functions
• Collection Classes
• Basic Input/Output

Primitive Behaviors
• Integer Functions – Arithmetic, Comparison, Conversion
• Unlimited Natural Functions – Comparison, Conversion
• Boolean Functions – Logical Operations, Conversion
• Bit String Functions – Bit-wise operations, Conversion
• String Functions – Concatenation, Size, Substring
• RealFunctions – Arithmetic, Comparison, Conversion
Added in fUML 1.1Added in fUML 1.1

Collection Functions
Collection functions operate on sequences of values of any type.
• Testing and accessing functions
– Examples: seq->isEmpty(), seq1->equals(seq2), seq->at(n)
• Non-mutating funtions
– Examples: seq2 = seq->including(x), seq3 = seq1->union(seq2)
• Mutating “in place” functions
– Examples: seq->add(x), seq1->addAll(seq2), seq2->remove(x)

Collection Classes
Collection classes define objects that represent collections of
values of a given type.

Basic Input Output: Channels

Basic Input Output: Reading and Writing Lines
activity ReadLine
(out errorStatus: Status[0..1]): String {
return StandardIntputChannel.allInstances().readLine(status);
}
activity ReadLine
(out errorStatus: Status[0..1]): String {
return StandardIntputChannel.allInstances().readLine(status);
}
activity WriteLine
(in value: String, out errorStatus: Status[0..1]) {
StandardOutputChannel.allInstances().writeLine(result, status);
}
activity WriteLine
(in value: String, out errorStatus: Status[0..1]) {
StandardOutputChannel.allInstances().writeLine(result, status);
}

Hello World
activity Hello() {
WriteLine("Hello World!");
}
activity Hello() {
WriteLine("Hello World!");
}

References
• Foundational UML (fUML)
– Semantics of a Foundational Subset for Executable UML Models
standard, http://www.omg.org/spec/FUML
– fUML Open Source (Reference) Implementation Project,
http://fuml.modeldriven.org/
• Action Language for fUML (Alf)
– Action Language for Foundational UML (Alf) standard,
http://www.omg.org/spec/ALF
– Alf Open Source (Reference) Implementation Repository,
http://alf.modeldriven.org/
• Contact
– Email: ed-s@modeldriven.com
– Twitter: @seidewitz or http://twitter.com/seidewitz

Programming in UML: An Introduction to fUML 1.3 and Alf 1.1

More Related Content

What's hot (20)

Similar to Programming in UML: An Introduction to fUML 1.3 and Alf 1.1 (20)

More from Ed Seidewitz (10)

Recently uploaded (20)

Programming in UML: An Introduction to fUML 1.3 and Alf 1.1

Editor's Notes