Let’s consider a few more jurisdiction-specific features.

1. In Europe, the light sequence from red to green is red->red+yellow->green; whereas, in North America, it is red->green.
2. In USA, flashing red lights in all directions are used to indicate an all-way stop.
3. In USA, all flashing yellow lights, which indicate danger and are used typically at night or in low traffic, are prohibited.
4. In Canada, flashing green light indicates right of way for the left turn and it is equivalent of the green left arrow.
5. Sometimes, the traffic lights are oriented vertically but sometimes horizontally (e.g., in Quebec in Canada).

The constraint C1 means that leftArrow is to be used for indicating advanced or extended left, then LeftGreenArrow lamp type must be supported. It is the typical requires constraint, whereby one feature depends another.

Let’s instantiate such model using the configurator. How many instances do you think are possible?

Explore the possible instances per jurisdiction—this will give you an idea of the details that still need to be investigated, decisions that need to be taken, and missing constraints that need to be added. For example, what is allowed or not allowed in Australia? It is possible to have horizontal orientation outside of Quebec? What is the allowed variability across Europe or across North America?

Exercise 1

In some jurisdictions, the lamps are of different shapes. In general, the lamps are of ball shape. But in Quebec, for example, the red lamp is square and the yellow lamp is diamond.

1. Extend the model to add the choices for the shape properties of the lamps.
2. Add an optional clafer allBalls and write a constraint in its context restricting the shape of all lamps to be balls.
3. Write a constraint for vertical orientation, all lamps must be of shape ball.

After that compare your solution with one possible Exercise 1 solution. Another Exercise 1 solution using inheritance.

Conclusion of Part I

As you can see, the possible number of systems in our traffic lights domain is very large despite just having a few features. Also, the model we have so far is quite incomplete.

Further extensive validation of the model with experts and further domain elicitation activities are needed. Decisions need to be taken about which features and properties of the system are in our scope and will be implemented and which ones lie outside of the scope of our implementation. Having a model provides a basis for conducting these activities in an effective manner due to the ability to reason about it using instance generators.

Every element in our model can be thought of a feature of our system. Every feature comes with a set of requirements; these are system requirements, as we have not yet distinguished hardware and software requirements. By selecting and eliminating the features, we can configure a particular variant of the system. We can use the features to organize our development work of the system.

Since we now have established and understood the extent of our domain and the requirements for our system, we can now move to Part II about domain concepts in control software.

Part II control software

1. minimal traffic lights
2. adding variability
3. grouping choices
4. complex grouping and nesting
5. linking the jurisdiction and the system
6. nested constraints