Assignment I, part 1. Groups of three students. Specify one as group leader. group names to TA and me. Create an object-oriented conceptualization of an object-oriented personal finance system. Sketch out the classes that you find necessary and explain how each relates to others. Is a class hierarchy possible. What class aggregations exists? All analysis and design results are due by February 15 th.

Use Case Representation of Requirements One of the most fundamental problems in software engineering is determining and documenting the requirements of a system. The notion of use-cases, introduced by Jacobson, is an approach. It complements the activity modelling approach developed by Lunn, and has wider application.

Use Case Representation Actors are external to the system and make use of it. The use-case approach requires the analyst to determine all the potential actors involved in a system. An actor is typically a person, but may be a third- party organization or another computer system. One person may in fact be multiple actors, say a shop assistant may be a customer of the same shop at another time. We model actors, not individuals.

UML Use Cases An actor makes use of a system in different ways. Each of these ways is known as a use-case. A use-case may involve a number of actors, just as an individual actor may make use of several use-cases. We draw little stick men to represent actors and ovals to represent use-cases.

In a banking system, where a customer can withdraw money, we would draw:

Multiple Use Cases To withdraw money, a customer must have put money in, so there is at least one more use-case

It might be that the system which is being implemented in the bank needs to involve a cashier for depositing, but that to withdraw money the customer has to use the cash machine. The cashier is then an actor.

We might add two more use-cases to the bank system.

There is probably a need for another actor. (I never borrowed money without having to grovel to the bank manager, and the bank manager always looked carefully at my pitiful balance before grudgingly saying yes).

Use cases may in fact use other use-cases. The “withdraw cash” use-case would make use of the “account balance” use-case before issuing the money.

Use Case A use-case is a very abstract view of what the system provides to the various actors who use it. It is not intended to give a detailed, blow-by-blow account of how the services are provided. By keeping out detail, it is possible to reason at a higher level. Use-cases can be opened out using object- interaction diagrams to begin to define their precise operation.

Use Cases The first stage of any project should be an analysis of the use of the system being devised. The requirements stage in object modelling, as described in this course, involves constructing use-case models of the system. The next stage is to open up the architectural issues by elaborating the use-cases as scenarios, described earlier.

Here is a simple use-case model for a computer:

Use Case Model Example Programmers are distinguished from ordinary users of the computer by the fact that they compile and edit programs as well as running them (for testing) and printing files. Edit and compile use-cases make use of the run- program use case (editors and compilers being just programs to be run). Use-cases are simple to describe to potential users of the system, and therefore should be used in the dialogue as part of requirements analysis.

Interaction Diagrams Use-cases allow us to describe at a high level the basic functionality of a system in terms of the various actors who need to interact with the system. From the use-cases, which describe broad functionality, we begin to analyse the details of the functionality of the systems we want to construct. Use-cases are broken down into sequences of actions and events. These actions and events are mapped onto objects through object interaction diagrams.

Let us look at the bank example:

Action Sequences The “deposit cash” involves the following sequence of actions: Complete “pay in” slip Hand cash to cashier Increase “cash balance” of account Increase cashier's balance Increase bank's balance Issue receipt to customer

We can now construct an object interaction diagram something like:

At first we shall include “pay in slip” as an object.

We now include a second object.

A customer may have more than one account, normally. So it seems sensible to model both. However, we merely need to know about the account. In fact the person depositing money may not be the owner of the account.

There seems no need to keep a cashier balance separate, so we shall record the cashier balance in the cashier object.

)

.

The first step from requirements analysis to detailed analysis is: –through the use of object-interaction diagrams to define objects, their behaviour and their attributes. These objects will be found in many interaction diagrams, and –their overall behaviour is a composite of the behaviours from the individual interaction diagrams.

suppose we wished to discuss with a bank manager what happened when he/she checked an account balance. We might draw up a possible screen and describe it to the bank manager, asking for feedback on the suitability of the screen, its contents, and what the bank manager would expect to be able to do through the screen. It can be related to the use case diagram as below.