These are my notes on Ed Seidewitz tutorial on Alf and fUML at Executable UML info day at today’s OMG technical meeting.
Alf aims at allowing to program in UML, without bothering to go back and implement at low level things that are specified already at the design level.
The role of Alf is to provide the missing details that cannot (or are very expensive to) be captured graphically by UML.
The good thing is that Alf works at the same semantic level of the UML models.
The picture will be:
- fUML = Executable UML Foundation
- Alf = Executable language for UML
Versions will be shortly aligned so that: Alf will be based on fUML 1.1, which is a proper subset of UML 2.4 (and on its semplification UML 2.5 planned for end 2011).
The formal foundation of the executable models is specified based on First Order Logic (FOL) .
The role of Alf is to provide a Java-like syntax that can be familiar for developers/designers. However, the surface syntax actually enables dataflow-based semantics.
At resources naming level, Alf adopts the UML naming rules (you can have spaces in names; names are case sensitive; and so on. So names may need single quotes for containing the names).
Several tricks need to be applied to actually design (even fairly simple) activity diagrams. For instance, you cannot have indeterministic semantics when you have outgoing outgoing data flows that land into several activities. A split node must be inserted, and thus the single token is copied into several ones. Or other peculiar cases, like the need of control+dataflows incoming in conditional nodes that produce only control flows. Or you may need to use datastores for multiplying incoming tokens. Or you may need implicit ouptup/input mapping in looping activities. Or to use parallel split for modeling ifs.
Within activities you only have one scope, while stack of calls is relevant only among activity invocations.
Alf does not constraint sequentiality. Parallel execution is allowed as soon as there is no dependency between activities.
Some other critical syntax issues: array indexes start from 1 (as in UML), not from 0 (as in main programming languages); and then details on structural feature actions, comparison with null (equivalent to checking if an item is empty or not empty)
In fUML an abstract operation has 0 methods, a concrete operation has only 1 method.
fUML provides reified semantics for associations.
Standard UML @Construct and @Destroy annotations are interpreted correctly.
Receptions are optional in UML but are mandatory in fUML if you want an object to receive a signal.
Profiles and stereotypes are currently not part of the fUML .
And btw, the hello world example for Alf is:
Seems quite easy! 🙂
The tutorial was given as part of the Executable UML Information Day at the OMG Technical meeting in Arlington, VA, on March 22, 2011. The full program of the day is available here:
http://www.omg.org/news/meetings/tc/agendas/va/Executable_UML_Info_Day_Agenda.htm
The official Alf specification is here:
http://www.omg.org/spec/ALF/
Disclaimer: This post is just a set of notes I took during the tutorial, it’s not meant to be complete or comprehensive, but I think it can provide a good understanding of the critical points.A more comprehensive post (by Ed himself) together with significant links is available here:
http://modeling-languages.com/blog/content/new-executable-uml-standards-fuml-and-alf
To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).
