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.

Addition Primitives Natural BitString Real (no really!?!) Primitive Behaviours Boolean Functions Integer Functions String Functions BitString Functions UnlimitedNatural Functions Sequence Functions Collection Classes Map, Set, OrderedSet, List, Bag, Queue, Deque

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?)