--- toc: false ... Part II ======= After finishing the initial domain analysis, we can move to considering how do these variations impact the control software of a traffic light. Let's first extract the features relevant to the control software from the [last version of our domain model](/country specific features). We can remove the jurisdictions, constraints, and physical properties `mountLocation` and `orientation`, since they do not impact the control software in any way. We also remove `red`, `yellow`, and `green` because they are mandatory and `countdownTimer` as it won't be considered in this part. ``` TrafficLightSystem Lamps LeftGreenArrow ? RightGreenArrow ? redAndYellowToGreen ? allWayFlashingRedAsStop ? allWayYellow ? or advancedOrExtendedLeft ? greenFlashing leftArrow ``` Consider the above simplified model as the **`interface`** between the domain model and the control software. The presence or absence of these features will be decided at the domain level but our control software must handle all possible decisions. This interface model describes all variability from the control software point of view. From our domain analysis, we learned that all kinds of lamps, including the arrow lamps, can be in three states: `on`, `off`, and `flashing`. Let's focus first on a single traffic light. The images below show different traffic light configurations with all lamps turned on
|  |  |  |  |