Description of System to be built :

• Machine is for returnable bottles, cans and crates.
• Used by several customers at same time, each customer can return all 3 types of item on same occasion.
• System has to check, for each item, what type has been returned.
• System registers how many items each customer returns and, when the customer asks for a receipt, the system will print out what he/she deposited, the value of the returned items, and the total return sum that will be paid to the customer.
• System also used by an operator.
• Operator wants to know how many of each item type have been returned during the day. At end of day, operator asks for a printout of the total number of items that have been deposited in the machine on that particular day.
• Operator needs to be able to change information in the system, such as deposit values of items.
• Should something go wrong with the system, e.g. a can gets stuck or the receipt roll is finished, the operator is called by an alarm signal.

Actors: These are the users of the system. They model anything that needs to exchange information with the system. Can be humans, or other systems and are external to the system to be built.

In e.g. above, actors are ____________________________.

Use Cases: A use case is a specific way of using the system to perform some part of the functionality. Each use case is a complete course of events initiated by an actor and it specifies the interaction that takes place between an actor and the system. A use case is thus a special sequence of related transactions performed by the actor and the system in dialogue. View use cases as specifying state transition diagrams. Each stimulus between the actor and the system causes a state change in the diagram. Use cases are identified via actors.

Questions to help identify use cases:

• What are the main tasks of each actor?
• Will the actor have to read/write/change any of the system information?
• Will the actor have to inform the system about outside changes?
• Does the actor wish to be informed about unexpected changes?

3 major uses cases are suggested here: 1 for Customer, 2 for Operator

Customer Use Case:____________________
Operator Use Cases:____________________________________________

Draw a Use Case Diagram:

1) Returning an item: This use case is started by the Customer when he/she wants to return cans, bottles or crates. With each item that the Customer places in the recycling machine, the system will increase the number of items from Customer as well as the daily total of this particular type. When the Customer has deposited all his/her items, he/she will press the receipt button to get a receipt on which the returned items have been printed as well as the total return sum.

2) Generate Daily Report: This use case is started by the Operator when he/she wants to print out information about the deposit items returned during the day. The system will print out how many of each deposit item type have been received, as well as the overall total for the day. The total number will be reset to zero to start a new daily report.

3) Change Item: This use case is used by the operator to change information in the system. The return value as well as the size of each returnable item can be changed, and new types of item can be added.

The above use cases will be expanded in more specific detail as the system evolves:

Extends Generalization: Use case extensions specify how one use case *may* be inserted into another, and thus extend another use case description. The 'extends' relationship between use cases indicates something may occur, but also might not occur.

E.g. of the 'extends' generalization : The Item Stuck use case 'extends' the Returning Item Use Case.

Diagram:

Item Stuck: When an item gets stuck, the alarm is activated to call the Operator. When the Operator has removed the stuck item, he/she resets the alarm and the Customer can continue to return items. The Customer's total thus far is still valid. The Customer does not get credit for the stuck item.

Uses Generalization: The 'uses' relationship between use cases indicates that some use cases *always* consist of or use other sub-use cases. E.g. to follow.