Quote from Ed Seidewitz to this exact question:

fUML is the culmination of a long quest of Stephen Mellor’s at OMG, so, in that sense, it is targeted at Executable UML. However, since the OMG community interested in UML execution semantics goes beyond just the Shlaer-Mellor community (submitters, for example, included IBM and Care, as well as Mentor Graphics and [then] Kennedy-Carter), the resulting specification had to be targeted at (generic) executable UML.

The goal of the specification is to give a precise semantics to a reasonable executable subset of UML, not to be specific to any executable modeling methodology. Stephen’s goal, though, was, of course, that this would also provide the basis for the next step in Executable UML, providing execution tool interoperability through standardization.

As to Alf, that is again a compromise among the desires of the various submitters. There was a strong general feeling on the submission team, however, that it had to syntactically “look like Java/C++/C#” to be accepted in the “mainstream” (IBM pushed particularly hard for an essentially Java-syntax minimum compliance point), and C-legacy syntax makes any language unfortunately much harder to process. Bit strings were an absolute requirement of the real-time folks — but note that, at least, Alf bit strings are abstracted from just being the integers they are in C and Java.

So, Alf is intended to look familiar to programmers who are not already in the executable UML camp, but to have the underlying concurrent data-flow activity model execution semantics of fUML. I see this as similar to the decision to make Java look like C++, though it also has very different underlying semantics.

It remains to be seen how well it will work — but it already has sparked a good deal of vendor interest.

This means that fUML is an e xecutable UML and not E xecutable UML