I remember more than 10 years ago when we were making a decision on what the modeling language we should be using for creating Conformiq Designer models. It was quite clear that we wanted to have a graphical notation that the user could use to capture high-level control flow and life cycle of objects as well as event loop structures and high-level logic of message, event and timeout processing. With our focus on Telecom and Embedded testing the choice was obvious, we wanted to have UML state charts and UML class diagrams. What was really a problem was the surface level textual notation, which we desperately needed for enriching the graphical models with detailed behavioral details; a notation that we would use to describe how data works in the system, to declare data types and classes, express arithmetics, conditional rules, and more. Back then there was no real standard or even an industry accepted “norm”, which meant that pretty much all the modeling tools for executable modeling adopted some proprietary textual notation.
OMG (Object Management Group) was working on Semantics of a Foundational Subset for Executable UML Models, which provided the first precise operational and base semantics for a subset of UML, but even that work (which resulted in fUML specification—an executable subset of UML that can be used to define the structural and behavioral semantics of a system) did not provide any concrete syntax. So we needed to come up with something else and we ended up choosing Java. After all, Java is a modern object-oriented language that was expressive enough for describing pretty much any computational process. It has sound semantics and sensible syntax. It was also well known and really the language that, if you knew any programming language, the chances were that you knew Java. For example, the vast majority of computer science students were using it sooner or later in their studies. Well, if you look at the latest TIOBE index (https://www.tiobe.com/tiobe-index), it’s still number one there, so it wasn’t such a bad choice at all!
Back then, because the modeling tools used their own notations and conventions, this made it very difficult for us to support 3rd party modeling tools because full support would also mean that we would need to implement pretty much a full-blown compiler for each and every proprietary notation.
OMG eventually recognized this problem and they initiated work around textual concrete syntax which finally resulted in an adopted action language called Action Language for fUML or Alf. Alf is basically a textual notation for behavioral UML modeling that can be attached to a UML model. Alf can be used for example to describe a behavior of a transition in a UML state chart or a method of an operation in a classifier.
Alf is really the long-awaited standardized way of using UML for detailed behavioral modeling that enables for example:
- definition of detailed system operations using UML also for testing and development
- simulation of UML models in order to see how the modeled system behaves and operates in practice
- different stakeholders with developers and testers to share common modeling vocabulary and tooling—common skill set is used across all forms of modeling
- tool vendors to implement a support for a common language that enables direct model reuse across multiple different tools used for various different purposes—which makes it possible to use the common tooling across various modeling disciplines
- more model reuse over the entire software development lifecycle meaning that developers and testers can directly reuse the system specifications and design assets and simply enrich those assets with required detail
- automatic test generation from UML models through a scalable system model driven MBT solution that is capable of creating test cases directly from design models (such as any Conformiq tool).
What I think is really cool with this whole approach is that it for the first time it really enables us to integrate development and testing in an unparalled way. This enables something that I call “model driven workflow” (MDW), where all the modeling happens through common tooling using preferably a common vocabulary that closely integrates the design, development and testing in order to enable early verification, reduce turnaround time, enable more reuse, increase productivity and quality, and reduce maintenance effort and cost. The whole MDW is a big topic that I will be writing about shortly in the future. I think that this is going to be a huge thing in the future, especially after seeing all the benefits that adopting this kind of a model driven workflow has brought to some of our most advanced customers.
Syntactically Alf looks much like C or Java while it adopts some notational convenience from Object Constraint Language (OCL). Also some Alf constructs look a bit similar to those seen in many of the popular functional languages. The basic idea with the language is that it maps to fUML. That is, the Alf notation syntactically maps to fUML activity models, plus the semantics of the Alf notation are defined by its mapping to fUML. Alf therefore is at the same semantic level as the rest of the UML model. One can think that fUML effectively provides a virtual machine for executing Alf language. Even more, Alf leverages the inherently concurrent and flow-oriented nature of the underlying fUML activity semantics.
All this just means at least two things; the first is that in order to fully understand the semantics of Alf code, one should understand the mapping. For example that statements in Alf map to structured activity nodes with control flows enforcing sequential execution, “local names” map to object flows, and so on. The second thing, with all this discussion about semantic mapping, is that I want to emphasize here another benefit of using Alf which is that Alf allows detailed behavioral modeling at higher level of abstraction provided by the underlying semantic framework. With object oriented and even with functional languages, the behavior is specified more at the level of how the thing is done and not so much as what is to be done. This is what Alf aims to do with this whole semantic mapping. And this is important in all modeling – we really want to raise the level of abstraction allowing separation of concerns. It is also very important with MBT, as the purpose of system modeling for test generation is to model the system’s intended behavior as a whole, albeit on a higher level of abstraction that the implementation. Why not actually use a language that also embraces such a high level of abstraction?
So what about modeling with Alf? Well, as with Java-based Conformiq Designer, a behavioral system model for test generation consists of action language and optionally of state machine diagrams and other useful diagrams. In the case of Alf-based Conformiq Designer, we use UML models augmented with Alf action language. Interestingly, the use of diagrams is optional and it is possible to create a full-blown behavioral system model using only Alf code.
Below is an example system model created using MagicDrawTM version 18.2 from No Magic that can be used to generate a test case with inputs and expected outputs defined using UML2 activity diagrams annotated with Alf action code.
Here we have a model of a system that accepts a message, expects that its payload is a string with value “Hello world” which it echoes back. If we would give Conformiq Designer this model, you would get one test case out where we would:
- stimulate the system under test with a message whose body is, “Hello world”
- expect that the system under test responds with message whose body likewise is, “Hello world”
I’m personally quite excited about Alf as I have waited for quite some time for a standardized action language to become a reality. It has been a big pain to work without a such a standardized language as described in this post. Such an action language can solve numerous challenges and bring coherence in to the overall modeling landscape in an unparalled way. What remains to be seen in the case of Alf is if the industry picks up the language, which again requires much more than “mere” commendable design principles. But I’m optimistic…
So if you haven’t yet looked at Alf, I suggest that you do. It’s really cool.