Extending Use Cases

As the system evolves over time, additional features and functionality will be added to meet new or existing user needs. Indeed, if the scope of your project was originally two times what your team could accomplish, then you will have necessarily eliminated half of the functionality in the first release or you will not have released the project on time. In some cases, this means that you simply deferred use cases from that release to the next, and you can add them to the use-case model at the next iteration. However, it's even more likely that many of the use cases you've implemented didn't do everything you could envision doing for the user. In other words, you "scope managed" the use cases themselves by not implementing all that was envisioned .

Table 21-1. Defining a Use Case

Item	Value
Use-case name	Control Light
Actors	Resident and Light Bank
Brief description	This use case prescribes the way in which lights are turned on and off and also how they are dimmed and brightened in accordance with how long the user presses a button on the Control Switch.
Flow of events	Basic flow begins when the Resident presses the On/Off/Dim button on the Control Switch. When the Resident removes pressure on the On/Off/Dim button within the timer period, the system "toggles" the state of the light as follows . If the light is On, the light is then turned Off, and there is no illumination . If the light is Off, the light is then turned On to the last remembered brightness level.
Alternative flow of events	When the Resident holds down the On/Off/Dim button for more than 1 second, the system initiates a brightening/ dimming activity for the room's Light Bank. While the Resident continues to press the On/Off/Dim button: The brightness of the controlled light is smoothly increased to a system-wide maximum value at a rate of 10 percent per second. When the brightness reaches its maximum value, the brightness of the controlled light is then smoothly decreased to a system-wide minimum value at a rate of 10 percent per second. When the brightness reaches its minimum value, the use case continues at subflow step 1. When the Resident releases the On/Off/Dim button: The use case terminates and the brightness stays at the current level.
Pre-conditions	The selected On/Off/Dim button must be Dim Enabled. The selected On/Off/Dim button must be preprogrammed to control a Light Bank.
Post-condition	On leaving this use case, the system remembers the current brightness level for the selected On/Off/Dim button.
Special requirements	Performance : For any action that is perceptible to the Resident, the response time from a control panel action to system response must be less than 50 milliseconds .

In these cases, you may wish to extend ^[1] an existing use case at the later release. Of course, you might also ask, "Why not simply update the use case to include this functionality? Why use the extend concept at all?" There are three primary reasons for this construct.

^[1] [UML 1.3] An extend relationship defines that instances of a use case may be augmented by some additional behavior in an extended use case.

1. The extend relationship can simplify maintenance of the use case and allow the team to focus and elaborate on the extended ("what's new or different") functionality, as an entity, without worrying about rereading or managing the base use case itself.

2. When an extension is envisioned as a use case is developed, extension points can be provided in the base use case as a map to "future features." This provides an indication of future intent to the design team and may aid development of a more robust architecture. It also provides a pointer to the area of the use case that needs further development in the next release.

3. The extended use case may represent optional behavior, as opposed to a new, basic, or alternative flow.

The last rationale is perhaps the most useful. For example, if some of the HOLIS systems included an optional "light bar" indicator on the Control Switch, then an extended use case could extend the behavior of the base Control Light use case as shown in Figure 21-4.

Figure 21-4. Extended Control Light use case

From the perspective of the flow of events, under certain defined circumstances a use case executes the extended flow of the use case as if it were an alternate flow, but upon completion, flow of the use case returns to the extension point in the base use case, as shown in Figure 21-5.

Figure 21-5. A base use case with extended flow

In order to apply this construct, all that is required is to indicate the extension points in the basic flow and the conditions (customer has purchased the light indicator option) under which the extended flow is to be executed. These conditions are expressed in what is called a conditional guard , which is the state that must be true for the extension to execute. In order to simplify maintenance, the conditional guard and extension points may be described in the extending use case, in which case the base use case will be entirely unaffected by the existence of the extension.