lafore_robert_objectoriented_programming_in_c
.pdf
Chapter 16
806
In a large project, just identifying all the actors may be difficult. The designer needs to look for people or other systems that:
•Provide information to the system
•Need information from the system
•Assist other actors
Use Cases
A use case is a specific task, usually initiated by an actor. It describes a single goal the actor wants to attain. Examples are the withdrawal of cash by the bank customer, the aiming of the telescope by the astronomer, and the investigation of a book’s availability by the bookstore clerk.
In most situations the use case is initiated by the actor, but sometimes it’s initiated by the system, as when the electric company’s accounting program sends you a reminder that you haven’t paid your bill, or your car’s computer turns on a warning light when it decides the engine is too hot.
In general, everything you want the system to do should be specified by a use case.
Scenarios
A use case usually consists of a number of scenarios. The use case specifies a goal, while a scenario represents a particular outcome when attempting to reach that goal. For example, let’s consider a use case consisting of a bookstore clerk querying the store’s computer system for the location of a particular book. There are several possible outcomes or scenarios:
•The book is in the store and the computer displays its shelf location.
•The book is out of stock, but the system gives the customer the opportunity to order it from the publisher.
•The book is not only out of stock, it’s out of print; so the sytem informs the customer that she or he is out of luck.
In a formal development process, each scenario would have its own documentation, describing in detail all the events in the scenario.
Use Case Diagrams
The UML specifies how to diagram use cases. Actors are represented by stick figures; use cases by ovals. A rectangular frame surrounds the use cases, leaving the actors outside. This rectangle is the system boundary. The system inside is what the software developer is trying to design. Figure 16.3 shows a use case diagram for a bookstore computer system.
Chapter 16
808
The simplest version of a use case description is a paragraph or so of text. Sometimes two columns are used, with the actor’s actions in one column and the system’s response in another. A more formal version might include such details as preconditions, postconditions, and a detailed sequence of steps. A UML diagram called an activity diagram, which is a form of flowchart, is sometimes used to show graphically the sequence of steps in a use case.
Use case diagrams and use case descriptions are primarily used in the initial design of a system to aid communication between users and developers. However, they are also useful throughout the development process. They can be consulted whenever anyone needs to verify what the system is supposed to do, and they can even provide a basis for testing and documentation.
From Use Cases to Classes
When the actors and use cases have been identified, the development process moves from the elaboration to the construction phase. The emphasis shifts from the users to the developers. Our first concern is to develop the classes that will be used in the program.
One approach is to look at the nouns in the use case descriptions. We want objects in the program to correspond with objects in the real world, and these nouns represent real-world entities specified by the users. They are candidates for classes, but not all nouns make good classes. We need to eliminate nouns that are too general, too trivial, or which are better represented as attributes (simple variables).
Once we have some candidate classes, we can begin to understand how they interact by examining the verbs in the use case descriptions. In many cases a verb translates into a message sent from one object to another, or some other association between classes.
A UML class diagram (described in previous chapters) can be used to show classes and their relationships. A use case is realized by a sequence of messages between objects. We can use another UML diagram, an interaction diagram, to detail such a sequence. In fact, we might want to use a separate interaction diagram for each of the scenarios in a use case. We’ll see examples of sequence diagrams, one kind of interaction diagram, in the next section.
The development process is easier to visualize using an example, so let’s walk through the development of a real program. Of necessity this example is so small that it’s questionable whether it even requires a formal development process. However, applying the process to even this small project should help to demystify the topics we’ve mentioned.
Chapter 16
812
There are also other kinds of reports Beverly might want, such as a Net Worth statement. It might even be nice to have the program interface with an income tax program and online banking. And from a big-picture perspective, there are commercial landlord programs available, so it might not be smart for Beverly to contract to have one custom-written. We’ll ignore all of these distractions to make the problem more tractable.
The Elaboration Phase for the LANDLORD Program
In the elaboration phase of a major software development project, a group of people, which includes the potential users of the program and the software people designing it, meet to discuss what the program should do. In this small example the group is Beverly, who will be using the system, and you, the software expert who will both design and code it.
Actors
The group begins by identifying the actors. Who will be inputting information into the program? Who will be requesting information? Will anyone else interact with the program? Will the program interact with other programs or systems?
In the LANDLORD example, only one person will be using the program: the landlord. The same person inputs information and asks to see it displayed in various ways.
Even in this small project one can imagine other actors. If the landlord’s accountant could access the program’s data (perhaps via the Internet), the accountant would be an actor, and if the program provided data to an income tax program, that program would also be an actor. For simplicity we’ll ignore these possibilities.
Use Cases
Next the group considers what tasks the actor will want to carry out. In a real software project this would be a major effort, with input from many users and much discussion and refining of ideas. Here it’s not too complicated to list the tasks the landlord needs. These tasks are recorded on a use case diagram.
In our situation the the landlord actor will need to do the following:
•Start the program
•Add a new tenant to the Tenant List
•Input a rent to the Rent Record
•Input an expense to the Expense Record
•Display the Tenant List
•Display the Rent Record
Chapter 16
814
Add a New Tenant
The program presents the Tenant Input screen, which prompts the user to enter the new tenant’s name and apartment number. It then places this information on a new row in the Tenant List. This list is automatically sorted by apartment number.
Input a Rent Payment
The Rent Input screen prompts the user to enter the tenant’s name, the month the rent is for, and the amount of rent received. The program looks in the Tenant List for the name of the tenant, and uses the corresponding apartment number to access the Rent Record. If this is the first time the tenant has paid rent, a new row is created in the Rent Record and the rent amount is inserted for the appropriate month. Otherwise, the rent is inserted in the existing row.
Input an Expense Payment
The Expense Input screen prompts the user to enter the payee (the person or company the landord is paying), the amount paid, the day and month the payment was made, and the budget category. The program then creates a new row containing this information and inserts it in the Expense Record.
Display the Tenant List
The program displays the Tenant List, each row of which contains an apartment number and the tenant’s name.
Display the Rent Record
The program displays the Rent Record, each row of which contains an apartment number and the amount paid each month.
Display the Expense Record
The program displays the Expense Record, each row of which contains the month, day, payee, amount, and budget category.
Display the Annual Summary
The program displays the Annual Summary, which consists of
1.The sum of all rents paid for the year to date
2.A list of the total expenses for each budget category
3.The resulting balance (profit or loss for the year to date)