Use Cases

Originally, Jacobson [JBR98] defined a use case as "a behaviorally related sequence of transactions in a dialog with the system." A more recent definition of the use case is given by [BRJ99] as "a description of a set of actions, including variants that a system performs to yield an observable result of a value to an actor." The basic idea behind a use case is to represent a sequence of interactions between the system and its users located outside the system. In other words, a use case shows how an actor uses a system to achieve a certain goal and what the system should do for the actor to achieve that goal. It describes how the actor and the system collaborate to deliver a result of value to the actors [BS03].

Use cases are widely accepted to be the best practice for capturing system requirements [Kru98]. Functional requirements capture the intended behavior of the system. The use case model expresses the functionalities the system is supposed to provide to its users. Use cases only specify how the system should behave; they do not specify how the behavior should be implemented. Therefore, use cases are considered to be an excellent way of communicating with customers and users of the system.

The UML symbol for a use case is shown in Figure 5-3. The use case Simulate only shows that users should be able to send the message simulate to the system and the system will execute all the necessary operations. For the moment, how the simulation will be achieved is not important. The same way, the use case Get Weather Data only shows that users may ask the system to carry out this functionality; how the data will be obtained is not relevant at this point. The data may be obtained from reading a data file or a database, or obtained directly from an on-line weather station.

Si muíate Get Weather Data

Figure 5-3. Example of use cases.

Use cases have names that distinguish them from each other. Usually, use case names are of form <Verb><Noun>, such as Get Weather Data, Simulate, that shows that users are making a request to the system and the system should provide back some results.

An actor and a use case are related through an association as shown in Figure 5-4. The actor (Farmer) initiates the use case by sending a message to the use case. Use cases are always started by actors. The communication shown in Figure 5-4 is unidirectional, as it goes from the actor to the use case. The sense of the communication is clear; it goes from the actor to the use case.

Farmer

Farmer

Get Weather Data

Figure 5-4. Farmer asks the system for weather data.

In Figure 5-5, the association linking the actor and the use case is bidirectional; it is not clear whether the actor initiates the use case or the use case communicates with the actor. It is important to clearly describe the type of communication between actors and use cases, as it helps to better understand how the system works.

0 0

Post a comment