We first add our TrafficLight back. Since the green arrows are an optional component, we want to have an easy way of asserting that they are either not present or off without going into too much logic. Currently, in Clafer, one cannot define custom constraints but one can define an optional clafer and make it equivalent to a set of constraints. That’s the trick we do with arrowsOff, which asserts that the arrows are neither on or flashing, which is also true when the arrows are not present.

As for our TrafficSignals, we can now exactly define in what state the lamps should be. Most of the time, it’s very straightforward (compared to our previous attempt using constraints); however, there are some variations depending on the system features.

• in proceed, we turn the green arrows on, only if they are present
• in advancedLeft and extendedLeft, we either have green.flashing or leftGreenArrow.flashing depending on the system feature variant greenFlashing or leftArrow.

Also, we often assert arrowsOff, which is very convenient and we don’t have to duplicate the complex constraints.

Let’s try it out. Again, assert certain signals and see what are the states of the lamps. E.g., when you turn all features off and require [ red.on ]:

Exercise 2

The lamps are the so called actuators, they allow the system affect the environment. In general, the system may also have to sense the state of the environment and change it’s behavior accordingly. For example, a traffic light may have a sensor to read the transponder signals of privileged emergency vehicles, such as, police, firetruck, or medical services.

Add a clafer emergencyVehicle to represent the state of the sensor indicating an emergency vehicle approaching and immediately switch to the allYellow if allowed or to warning signal otherwise.

After that compare your solution with one possible Exercise 2 solution.

Conclusion of Part II

We now, finally, we have a meaningful model of domain concepts for control software with traffic signals controlling the traffic light lamps and supporting all variations of the system features.

Let’s see how we can now configure a particular traffic light application.

Part III: application configuration

1. control software
2. lamp abstraction
3. valid states
4. add the missing constraints
5. traffic light signals