Fluents: Events or Ticks?

Imagine you have a system that can have a number of states, and "events" for state transitions.  Fluents are then the constructs that help to reason about state transitions.

Here is an example inspired by [Queins et. al. 2000] that got picked up by [Letier 2005]: Assume that you have the task of building a light controller.  By pushing a button, light is turned out and will switch off after some time.  pushing the button when the light is on will reset the timer.

In this example, we may have the state variables light ∈ {on, off} and timer ∈ {0..n}.  For now, the timer simply counts ticks.  To set these state variables, we may have the events "pushButton", "switchOn", "switchOff", and "tick".

A Fluent is a proposition defined by a pair of sets of events.  Events from the first set the fluent to true, the second to false, e.g.:

fluent LightOn = <switchOn, switchOff>

We can use the Fluent in  temporal logic (e.g. LTL):

â—» (pushButton X LightOn)

The box means "always", and X means "next". So the above means "When pushing the button, next the fluent LightOn must be true".

Quite a bit is fishy here.  For instance, what exactly does "next" mean?  This is where Letier’s contribution comes from: it could be the next event (which he calls asynchronous) or the next tick (which he calls synchronous).  Also check out how restrictive the statement is in the asqnchronous case: It is not allowed to insert any events after pushButton, which would make refinement through stuttering impossible.

Aspects in Requirements Engineering

After Aspect Oriented Programming (AOP) became popular, people started to think about Aspect Oriented Requirements Engineering (AORE).  Kaindl published a neat article trying to figure out what exactly was meant by that. Amongst other things, he points out that there is confusion about whether "Aspect" is meant as a synonym for crosscutting concern or a solution to it (in his opinion, the first doesn’t make much sense, and I agree; even the secion he doesn’t like to much, but the term is established, and we’re stuck with it now).

So Aspects solve cross-cutting concerns; in Software Development, typicall cross-cutting concerns are authorization, authentication, transaction management and more.  Aspects provide a means to modularize these concerns.

Kaindl points out that almost always there is the hidden assumption that crosscutting concerns in software are the same as crosscutting concerns in requirements – but there is no foundation for that assumption!  In fact, I would consider this a dangerous assumption.

So where does that leave us? Kaindl’s point is that we should avoid falling into the trap that cross-cutting concerns in requirements are not necessarily the same as in software.  But what are the cross-cutting concerns in requirements?  That’s a question that needs more research, but I am sure that it depends on the representation of the requirements, amongst other things.  In a plain text specification, every entity (noun) or every action (verb) could be considered a cross-cutting concern.  Consider a specification for a simple traffic light.  Many requirements may refer to the same,  traffic light in the specification.  In the specification, the traffic light is a crosscutting concern.  But not in the implementation – there, the traffic light may be one neatly capsuled object.  Other representations don’t have this problem.  KAOS, for instance, explicitly models objects.

Food for thought.

The Hunt for Gollum

This weekend an amazing film got released: The Hunt for Gollum, a side plot from the Lord of the Rings.  Watch it for free online.  This movie shows how the whole can be so much more than the sum of the parts, and that the Internet is an amazing enabler.  Enjoy.

Requirements in Cocktail Recipes

Being able to follow recipes is certainly a good foundation for mixing a decent drink.  Even experienced bartenders follow recipes, although they manage without the measuring cups and they have the recipes in their head.  Why is that?  A recipe is like a blueprint.  But unlike the blueprint for an air traffic control system, almost everybody can read the blueprint for a Martini.  Interestingly, not everybody can read a cooking recipe!  Just ask any freshman to sauté chopped onions, I rest my case.  

But why are recipes for cocktails relatively easy, and those for software so incredibly difficult?  For one, they are of a different nature!  A recipe is more like a system specification or a process description.  It is designed to be used over and over again for producing a desired, repeatable result.  The software is usually built exactly once, and then distributed many times.  Although in practice, the software is modified, fixed and extended, and having an accurate specification can make a big difference.

Recipes are easy, because we can assume common knowledge between the cook and the writer of the recipe.  When James Bond orders a Martini, the bartender understands what’s meant by shaken, and we know what stirring is.  On the other hand, every chef knows how to sauté, but not every teenager who is away from home for the first time does.  We can strive to make our technical specifications better by stating explicitly what skill set we expect the reader to have, and many technical books have a section describing their target audience – a good practice.

Specifications are easy if a good requirements document exists.  Many projects fail because of faulty requirements, as Tom DeMarco beautifully described in his novel "The Deadline", where the leading characters inspects the requirements for a air traffic control system, just to realize that they say nothing in a sophisticated way.  Contrast that with a recipe, where the requirements are simple: "Make me a Martini", "I need to drive, something without alcohol, please".  "Martini" describes what I want, but not how it’s prepared (although 007 begs to differ).  I leave the implementation details to the barkeeper, who decides what glass to use, the proportions of liquor and so forth.  Likewise, if we collect the requirements for a software, we shouldn’t describe the how ("use XML", "must be Oracle"), but the what ("allow secure communication over the Internet", "must allow ODBC access").

But the main reason why the bartender’s job is so much easier is that he doesn’t have to design the product on the spot.  He gets the requirements and simply picks an existing recipe that fits the bill.

Vincenti distinguishes between radical design and normal design.  Building a car today is normal design – we have done it many times before, the driver sits up front (there once were cars with the driver in the back), and so forth.  But in software we often do radical design, and success at best means building something that will function well enough to warrant further development.

Sadly, in software we are typically faced with radical design, no matter how much the vendors promise a world where solutions are assembled like Lego pieces.  So be prepared to put the required effort in for describing, specifying and building your software – it will be worth it.

Chandler closes down

Mich Karpor, creator of Lotus 1-2-3 and founder of OSAF finally pulled out the Chandler project, an open source development of a new Personal Information Manager, after six years.  The project made some headlines when it started and recently again after the publishing of the book Dreaming in Code.

I saw Kapor once at MIT, where he gave a guest lecture, and I value his enthusiasm.  It’s a shame the project folded.