Presentation at the Code Generation 2014 conference at Cambridge.
The Action Language for Foundational UML (ALF) is a standard domain modeling and programming language for the executable (foundational) subset of standard UML (fUML). ALF is used for specifying executable behaviors within an overall graphical UML model.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Jrgen Mutschall ALF The Standard Programming Language for UML
Code Generation 2014 Cambridge
1. Are you familiar with Java or C++? Java C++ No 2. Is your
focus on technical or legacy software solutions? Technical (e.g.
operating systems, embedded solutions, mission critical systems)
Legacy (e.g. business applications, web applications, desktop /
frontend solutions, databases) 3. What is the average software
life-cycle duration of your solution? < 10 years 10 20 years
> 20 years 4. What is the average team size of your software
projects? < 10 team members 10 30 team members 31 100 team
members >100 team members
Models are abstractions of the real world. Textual or graphical
notations Programming may be seen as a kind of modeling. A manual
written software solution works according to the mental model of
the developer (hopefully). A programming language is a modeling
language for creating models of execution*. Models are for people,
programs are for machines. Goal: better integration of
modeling/abstraction and programming Better tool support for
abstraction, verification, simulation, standardization, code
generation, .
A mission critical application is essential to the survival of
a business or organization. A mission critical application must be
rigorously tested ($$$$$). A productive software solution that is
essential (or very expensive to be replaced) will last a long time.
Well known example: FORTRAN code for the missions to the moon is
still in use. (50 years)
For vitally important scenarios it makes sense to verify the
promised functionality by a simulation. Usually it is very
expensive to do a real- life simulation. e.g. a crash test dummy
costs 100,000.- and a lot of real cars have to be crashed! Software
allows an upfront testing in a virtual, non-physical environment.
Goal: from informal unit tests to validated and documented
simulation results.
There are some efficient, proprietary simulation tools for
specific technical domains (e.g. LabView), but there are only a few
platform-independent and standardized solutions. The OMG standards
provide well established notations to specify a platform- and
language independent static and behavioral software design. E.g.
static modeling using SysML Block / UML Class diagrams. E.g.
dynamic modeling using Activity diagrams. Problem 1: Graphical
notations are not good for detailed modeling. Problem 2: The
notation needs to be precise enough to be executed. Problem 3: It
is difficult to make the model detailed enough for execution while
keep it simple enough for human communication. ALF, a standardized
action language based on a standardized execution model.
Usage of standards participates to cost and risk reduction. By
making easier communication/exchanges between various stakeholders
involved in the development process. Standards enable vendor
independence and tool interoperability. Users have a choice of
different vendors (no vendor lock-in) A higher availability of
educated engineers
Vision: certified design and simulation tools guarantee a
deterministic behavior of the development and simulation
environment. Using the certified development tools the behavior of
the resulting software solution can be platform-independently
assured and reproduced. Design and behavior specifications can be
interchanged between tools that comply to a common conformance
level. Delivery of fully-functional, platform- independent,
reusable software components.
In 1998, the OMG issued the RFP for Action Semantics for the
UML. In 2003, the OMG issued the first guide to its Model Driven
Architecture (MDA). Increased the importance of making models more
precise and to validate them In 2005, the OMG issued the RFP for
the Semantics of a Foundational Subset for Executable UML Models
(fUML). In 2008, the OMG issued the RFP for the Concrete Syntax for
a UML Action Language (ALF). In 2011, fUML 1.0 was finalized. The
fUML specification does not provide any surface syntax. In 2013,
ALF 1.0.1 and fUML 1.1 were finalized (current versions).
UML2.5 (2013) Complete revision of its text description to
simplify its presentation and disambiguate as much as possible its
semantics. fUML (2013) Foundational UML (fUML) is an executable
subset of standard UML with formal/operational semantics. Alf
(2013) 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. Also provides an extended textual notation for
structural modeling within the Fuml subset. Precise semantics of
UML Composite Structures RFP (2015?) Solicit a new specification
defining a precise semantics for UML composite structures and their
extensions.
The surface syntax ALF is expressively enough to arbitrary
switch between textual and graphical modeling.
Alf has a largely C-legacy (Java like) syntax, since that is
most familiar to the community that programs detailed behaviors.
Alf allows UML textual syntax when it exists e.g. colon syntax for
typing, double colon syntax for name qualification, etc. Alf does
not require graphical models to change in order to accommodate use
of the action language e.g. special characters are allowed in
names, arbitrary names are allowed for constructors, etc. Alf maps
to the fUML subset in order to provide its execution semantics, but
it is usable in context of models not limited to the fUML subset.
Alf provides a naming system that is based on UML namespaces for
referencing elements outside of an activity but also provides for
the consistent use of local names to reference flows of values
within an activity. Alf uses an implicit type system that allows
but does not require the explicit declaration of typing within an
activity, always providing for static type checking, based at least
on typing declared in the structural model elements. Alf has the
expressivity of OCL in the use and manipulation of sequences of
values. These sequence expressions are fully executable in terms of
fUML expansion regions, allowing the simple and natural
specification of highly concurrent computations. While the primary
goal of Alf is to be an action language, Alf also provides concrete
syntax for structural modeling, largely within the bounds of the
fUML subset.
UML colon type syntax with direction specifier Recursion on a
shared data structure.
but you are also free to use some functional add-ons
Simple names, similar to java e.g. Example, _example, A1, a1,
a__ Unrestricted names, characters surrounded with single quotes
e.g. Jrgen Mutschall, On/Off switch, +, escaping * fn A lot of
reserved words abstract, accept, active, activity, allInstances,
any, as, assoc, break, case, class, classify, clearAssoc, compose,
createLink, datatype, default, destroyLink, do, else, enum, for,
from, hastype, if, import, in, inout, instanceof, let, namespace,
new, nonunique, null, or, ordered, out, package, private,
protected, public, receive, redefines, reduce, return, sequence,
specializes, super, signal, switch, this, to, while
Boolean Literals true, false Natural Literals e.g. 1234, 0,
0b1010111000010000, 0B0100_1010_0101_1011, 0xAE10, 0X4a_5b, 057410,
0_045_133 Unbounded Value Literal * String Literals "This is a
string., "This is a string with a quote character (") in it." "This
is a string with a new line (n) in it."
Written with the well-known < > e.g. Set No partial
binding The binding must specify an actual element for every
template parameter of the template. The element being bound must
not have template parameters of its own. Copy Semantics, all
templates are expanded by lexical replacement Standardized Name
mapping: e.g. Set is mapped to
$$Set__UML$AuxiliaryConstructs$PrimitiveTypes$Integer__
// eol end-of-line comment lexical comment /* */ in-line
comment lexical comment //@ eol statement annotation execution
directives (do not confuse with stereotype annotations) /** */
documentation comment stored in the model /*@ */ inline code block
arbitrary embedded/inline code
A name is used to identify a named element. Named elements may
be member of a namespace (itself a named element) A named element
can be accessed from the outside by a qualified name Attention: a
local name is never qualified The separator of a qualified name may
be a :: or . Ordering::Order::customer or Ordering.Order.customer
FoundationalModelLibrary::BasicInputOutput or
FoundationalModelLibrary.BasicInputOutput Set MapString,
V=>Entry> Map.KeySet List< List >
CollectionClasses::Set::add
In the sense of an UML value specification An expression either
has a statically determined type or can be statically determined to
be untyped, denoted by the keyword any. An expression also has a
statically determined multiplicity. * if unbounded Almost all
expression can be evaluated concurrently by design See ALF Spec:
Local Names and Assigned Sources, mapping variables to data
flow
Public imports reexport the imported named element as a member
of the containing namespace public import
ProductSpecification::Product as Prod; // Import with alias package
Ordering { // Namespace definition } In this case, within the
Ordering namespace, the unqualified name for
ProductSpecification::Product is Prod, not Product. Since the
import is public, outside Ordering the qualified name
Ordering::Prod can be used to refer to the same element as
ProductSpecification::Product. Prevents from namespace pollution
and the typical name conflicts during mappings e.g. mapping from a
Xtext grammar to ALF syntax structures to fUML structures (3 times
a ClassDefinition with cross-refs in three namespaces)
Class Active Class Data Type Enumeration Association Signal
Activity
ALF does NOT support interfaces, but has multiple
inheritance!!! Class
In the above example, the activity getSingleton is nested in
the class Singleton. Because of this, it has visibility to the
private constructor for Singleton, which is not visible outside of
the class.
An active class is one whose instances (active objects) have
independent threads of control. When a contrast is necessary, a
class that is non-active may be referred to as a passive class. An
active class may have attributes, operations and nested
classifiers, just like a passive class. However, only an active
class may have receptions as features and only active objects may
receive signals. Active Classes active object instance of active
class A active object instance of active class B passive objects
passive objects
DataTypes and Enumerations Nothing special about data types and
enums
An association is a classifier that specifies a semantic
relationship that may exist between two or more instances. The
instances of an association are known as links. The features of an
association must all be properties. Association
A property is a structural feature of a classifier. The
attributes of classes, data types and signals are properties, as
are the association ends of an association. declares a property
that can hold zero or more objects of type Item in an ordered
sequence. If the multiplicity is [0..*], then a shorter form can
also be used in which the range 0..* is implicit: In addition, the
single keyword sequence may be used in place of the combination of
the two keywords ordered and nonunique. If a property definition
includes the keyword compose, then it is considered to be a
composition of the values it holds. This has semantic implications
when an instance of the owning classifier of the property is
destroyed . When an instance of class C is destroyed, the object it
holds for attribute b will also be automatically destroyed, but the
object it holds for attribute a will not.
Note that, in this case, it would be illegal to redefine only
one of A::p and B::p with an indistinguishable operation, since
then the other superclass operation would still be inherited and
would conflict with the redefining operation in C.
let interest : CurrencyAmount = this.principal * this.rate *
period; In the second form, the type name precedes the local name:
CurrencyAmount interest = this.principal * this.rate * period; Also
allowed: interest = this.principal * this.rate * period;
A constructor is an operation, specially identified using the
@Create stereotype annotation and used to initialize a newly
created object.
If an object creation expression is not constructorless, then,
in addition to creating an object, evaluation of the expression
calls the identified constructor on the newly created object. If a
constructor is explicitly named in the expression, then that is the
constructor that is called. new Employee::transferred(employeeInfo)
creates an object of the class Employee and calls the constructor
transferred on that object with the argument employeeInfo. If the
object creation expression names a class, then the constructor
called is one with the same name as the class. new Employee(id,
name) is equivalent to new Employee::Employee(id, name) Finally, if
the class of the object being created is active, then the
classifier behavior for that class is automatically started once
the object is created and after any constructor call
completes.
activity A(in x: Integer, in y: Boolean[0..1]) Invocation of
this activity with a positional tuple A(1, true) Argument 1
corresponds to the parameter x and the argument true corresponds to
the parameter y. This is equivalent to the invocation with the
named tuple: A(x=>1, y=>true) With a named tuple, the order
of the arguments may be changed A(y=>true, x=>1) Since the
parameter y is optional (multiplicity lower bound of 0), no
argument needs to be provided for it at all in the named tuple
notation. A(x=>1) is equivalent to A(1) is equivalent to A(1,
null)
A sequence property access expression of the form primary.name
is equivalent to the collect expression primary -> collect x
(x.name) It is not an error for the result of the target expression
in a property access expression to be empty. In this case, the
property access expression evaluates to an empty sequence.
A sequence reduction expression is used to reduce a sequence of
values to a single value by combining the elements of the sequence
using a binary operator. A sequence reduction expression has a
similar syntax to a sequence operation expression in that it starts
with a primary expression followed by the flow symbol ->. This
is then followed by the keyword reduce and the qualified name of a
behavior that acts as the binary operator over elements of the
sequence. As for sequence operation expressions, sequence reduction
expressions also allow the special notation in which a class name
is used as a shorthand for a class extent expression.
Can be efficiently implemented by a parallel and/or distributed
computing environment. Operation Description select Select a
sub-sequence of elements for which a condition is true. reject
Select a sub-sequence of elements for which a condition is false.
collect Concurrently apply a computation on each element of a
sequence. iterate Sequentially apply a computation to each element
of a sequence. forAll Test if a condition is true for all elements
of a sequence. exists Test if a condition is true for at least one
element of a sequence. one Test if a condition is true for exactly
one element of a sequence. isUnique Test if a computation has a
different value for every element of a sequence.
A link operation expression is used to create or destroy
instances of a named association, known as links. A link operation
expression has a similar syntax to an invocation expression,
consisting of a target association name, a link operation name and
a tuple of actual arguments for the link operation. Operation
Description A.createLink (e1, e2, ) Create a link of association A
with end values e1, e2, Association A must not be abstract.
A.destroyLink (e1, e2, ) Destroy a link of association A with end
values e1, e2, A.clearAssoc(e) Destroy all links of association A
with at least one end value e.
An activity is the specification of parameterized behavior as
the coordinated sequencing of subordinate units whose individual
elements are actions It is the fundamental mechanism for behavioral
modeling in Alf. Activities are namespaces that may be defined as
Alf units. Activities may also be implicitly defined by the in-line
specification of behavior for active classes or operations.
Activity
A signal is a classifier whose instances may be sent
asynchronously to an active object. The ability for an object to
receive a certain signal is specified using a reception declaration
in the class of the object. The features of a signal must all be
properties. Signal
A reception is a behavioral feature of an active class that
declares that instances of the class are prepared to react to the
receipt of a specific signal. Only active classes may have
receptions as features. Normally, the signal is defined separately
and referenced by name in the reception declaration. As a
convenience, Alf also allows the definition of the signal and a
declaration of a reception of it to be combined into a signal
reception definition.
An accept statement is used to accept the receipt of one or
more types of signals.
The execution semantics for activities in fUML are inherently
concurrent. Alf mapping to fUML takes advantage of this concurrency
in many places, particularly in the mapping of expressions. E.g.
the argument expressions in an operation invocation or an
arithmetic expression are evaluated concurrently, rather than
sequentially. Does not require the implementation of actual
parallelism in a conforming execution tool. It simply means that
such parallelism is allowed.
A cast expression is evaluated by first evaluating its operand
expression, producing a sequence of values. Any values of the
operand expression whose dynamic type does not conform to the type
of the cast expression are filtered out, so that all result values
of the cast expression are of the given type. If the cast
expression is untyped, then no values are filtered out.
(Integer)any[]{1,"banana",2} evaluates to Integer[]{1,2}
The instanceof operator checks if the dynamic type of its
operand conforms to the given type that is, whether the argument
type is the same as or a direct or indirect subclass of the given
type. The hastype operator checks if the dynamic type of its
argument is the same as the given type.
Isolation Expression $ Classify Impl Sub Packages
The isolation operator indicates that its operand expression
should be evaluated in isolation, similarly to the use of the
@isolated annotation for a statement . During the evaluation of the
operand expression, no object accessed as part of the evaluation of
the expression or as the result of a synchronous invocation from
the expression may be modified by any action that is not executed
as part of the operand expression or as the result of a synchronous
invocation from that expression. An isolation expression has the
type and multiplicity of its operand expression. See 8.5.3.1 of the
fUML Specification for a complete discussion of the semantics of
isolation.
A classify statement is used to dynamically reclassify an
already existing object. The statement identifies an already
existing object and the classes from which and/or to which the
identified object is to be reclassified.
The class of the object being created must not be abstract,
unless all of the following conditions hold: The object creation
expression is not constructorless. The namespace that owns the
class of the constructor also owns a package with the name Impl.
The Impl package contains a class with the same name as the class
of the constructor. The Impl class has a constructor that redefines
the constructor (which implies that the Impl class must be a direct
or indirect subclass of the class of the constructor). If these
conditions hold, then the identified Impl class constructor is used
instead of the original abstract class constructor, and the object
that is created is actually an instance of the Impl class. The
above mechanism is intended to allow for the definition of abstract
classes in model libraries that may be directly referenced by user
models and constructed as if they were concrete. Different
execution tools may provide different actual concrete
implementations of the library classes in the nested Impl package
of the model library without changing the library classes actually
referenced in user models. In particular, the Alf standard model
library collection package uses this mechanism.
ALF fUML Execution / Simulation Semantics of a Foundational
Subset for Executable UML Models (fUML), Version 1.1 , August 2013
the foundational subset defines a basic virtual machine for the
Unified Modeling Language, and the specific abstractions supported
thereon, enabling compliant models to be transformed into various
executable forms for verification, integration, and deployment.
(Chapter 1, fUML spec.) Syntactic Conformance: A conforming model
must be restricted to the abstract syntax subset defined for fUML.
Semantic Conformance: A conforming execution tool must provide
execution semantics for a conforming model consistent with the
semantics specified for fUML.
Abstract Syntax Conformance Only syntactic elements that are
included in the fUML abstract syntax metamodel (conformance level
specific). Meets all constraints imposed on its syntactic elements
by the UML 2 Superstructure. Model Library Conformance If an
execution tool provides elements from the fUML model library, they
must conform to the specified behavior. If a platform / tool
specific library is provided, the execution behavior of elements of
the models in that library may be entirely defined in fUML at the
same conformance level models accepted by the tool. Behavioral
modeling of the tool by itself
The semantic areas below are not explicitly constrained by the
execution model: The semantics of time The execution model is
agnostic about the semantics of time. The semantics of concurrency
The execution model includes an implicit concept of concurrent
threading of execution. It does not require that a conforming
execution tool actually execute such concurrent threads in a
physically parallel fashion. So long as the execution tool respects
the various creation, termination, and synchronization constraints
placed on such threads by the execution model, any sequentially
ordered, or partial or totally parallel, execution of concurrent
threads conforms to a legal execution trace. The semantics of
inter-object communications mechanisms The execution model is
written as if all communications were perfectly reliable and
deterministic. This is not realistic for all execution tool
implementations. Semantics of inter-object communication is not
predicated on any assumptions about whether or not such
communication is reliable i.e., that signals and messages are never
lost or duplicated, preserves ordering, happens with deterministic
or non- deterministic delays,
ALF Reference Implementation at http://modeldriven.org/alf/
fUML Reference Implementation at
http://portal.modeldriven.org/content/fuml-
reference-implementation-download Java standalone open-source
implementation to do conformance checks Translates Alf text input
files to fUML and executes the fUML with a token based
petri-network execution engine. Good starting point to check the
conformance of an own implementation.
Performance and scalability The debugger / simulator is allowed
to be 10 times slower and may consume 10 times more memory (disk
space), but has to manage real-life sized applications. As an
Execution-Platform (UML Virtual Machine) the generator must produce
production-ready code. No token based graph traversal execution
model allowed in a real-life products Performance, Performance,
Performance !!!! Support for a platform specific threading model.
Platform specific, concurrent implementation of the ALF standard
library and sequences. Compliant to the fUML execution semantics
Integration of UML runtime code and platform specific runtime code.
Allows incremental incorporation of ALF based models in existing
development environments. Still provide the capability to generate
pure OMG standards based, fully-tested ALF/fUML-models and
serialize them to XMI.
IDE/Editor support In Eclipse context, similar to Java support
Editing, cross references, code navigation, code completion, etc.
Integration of General Purpose Languages First of all, Java Xtend
as a Java superset, switch to Java 8 on general availability
Library support or embedded use Debugging support (in work) In
Eclipse context, similar to Java debugger Set breakpoint, step by
step debugging, inspection of object struture and values
Integration of Graphical Editors (in work) In Eclipse context,
support for UML2-EMF-based UML editors Tight integration of
graphical and textual modeling/programming Meta
Support for MOF Reflection as a library for ALF Support for the
definition of UML profiles Profile definition as MOF library use
Currently not part of the specification. Integration into the
MetaModules Language Workbench. Addition textual support for other
OMG standards Will also automatically translate to the appropriate
diagram type Most important: BPMN IFML Urgent need for the
additional specification of composites mapping Needed for SysML
Precise semantics of UML Composite Structures RFP (finalization
2015?)