Tm354 - Unit 3.3

Front 1

What is an actor?

Back 1

UML employs the term actor to identify a user of a system. An actor can also be an external software system or subsystem that will interact with the proposed system.

Front 2

What is a use case and what needs it?

Back 2

Use cases are a way of capturing functional requirements. A use case is something that an actor needs to do with the help of a software system.

Front 3

Describe what the main elements in this use case diagram are.

Back 3

The main elements in the diagram are:

• the actors, represented by stick figures
• the use cases, represented by ovals
• the relationships between actors and use cases – their associations – represented by lines.

Front 4

Name two aspects of software development where use case modelling can help.

Back 4

So far we have encountered these two:

• Extracting requirements
• Representing requirements

Later in the module we will also discuss planning iterations of development and validating software systems.

Front 5

Suggest a reason why use case diagrams are an aid to communication between user and developer.

Back 5

Use cases offer users an opportunity to understand the system since the use case notation is relatively simple and doesn’t require an understanding of UML. This provides a mechanism that enables developer and client to share a common understanding of the system, as long as the developer provides some text to demonstrate their understanding of the problem.

Front 6

What is the purpose of a system boundary? Is it always necessary to draw one in a use case diagram?

Back 6

The purpose of a system boundary is to identify a single system, distinguishing between the internal and external components. Typically, the external components are the actors and the internal components are the use cases. UML says that the system boundary is optional.

Front 7

Explain why the actors in a use case diagram do not represent actual individuals.

Back 7

An actor in a use case diagram represents a particular role that an individual might play when interacting with a software system. For example, a receptionist checks guests into and out of a hotel. But it could be that the person who works as a receptionist at one hotel becomes a guest at another hotel in the chain and hence takes on another role. Actors can also represent other systems, rather than people/roles.

Front 8

Suggest a guideline that will help you decide whether or not to include an interaction with an external system on your use case diagram.

Back 8

One possible guideline would be to show interaction with an external system if the use case needs to communicate with the actors that represent the external system.

Front 9

Are roles in business process models the same as actors in use cases?

Back 9

Roles in business process models may not correspond directly to actors in use cases as although they interact with a business process they may not interact with a proposed system. Some roles may become irrelevant when introducing a new system or may not need to interact with the system.

Front 10

What items should the description of a use case typically contain?

Back 10

While the structure and format might vary among the different development processes, we suggest that you include the following items as a minimum:

• A unique identifier for the use case, to allow traceability throughout development

• The name of the actor that initiates the use case

• A short description of the goal of the use case

• A single sequence of steps that describe the main success scenario – you may find it helpful to number these steps for traceability, for identifying the detailed software requirements that they generate and for cases where you need to identify any extensions or variations that occur as a result of the other scenarios of a use case

• . a textual description of the pre- and postconditions.

Front 11

What is the relationship between a use case and a scenario? Give examples to illustrate your answer.

Back 11

For each use case there is a set of possible scenarios. A scenario is an instance of a use case. A scenario describes a sequence of interactions between the system and some actors.

​

Here are two examples of scenarios. A member of a lending library wishes to borrow a book, and is allowed to do that as long as they have no outstanding loans. Another member wishes to borrow a book, but has exceeded the quota for the number of books that can be borrowed. In each scenario the member wishes to borrow a book, but both the circumstances and outcomes of events are different in each instance. So a use case includes a complex set of requirements that the system must meet in order to cope with every eventuality.

Front 12

What is meant by a main success scenario?

Back 12

The main success scenario shows the steps normally followed to achieve the stated goal of the use case. But there can be other scenarios for the same use case, each one having different outcomes depending upon circumstances.

Front 13

How do use cases help with requirements capture?

Back 13

Use cases help with requirements capture through the identification of actors and tasks in the system. For each actor, the set of use cases establishes what that actor requires from the software system. The association between an actor and a use case is about communication.

Front 14

How do use cases help with the elicitation of detailed software requirements?

Back 14

Detailed software requirements can be associated with each step in a use case scenario. There may be more than one requirement for each step.

Front 15

How do use cases help with development?

Back 15

One of the difficulties that developers face is planning delivery times. Often a customer can put pressure on the developer to meet a particular deadline. It is part of the developer’s job to elicit from the users the use cases that have the highest priority and to indicate what functionality in the software system can be met under such constraints. The use case descriptions help the developer to:

• Understand the complexity of each use case
• Determine which actors interact with each use case and to what extent
• Establish which use cases carry the most risk
• Estimate how long each use case is likely to take to implement.

Understanding these aspects of the system can help developers plan the order in which the use cases should be developed, and provide an appropriate time frame. Several criteria – such as risk, coverage and criticality – can be used to help establish priorities of use cases.

Front 16

How do use cases help with the system’s architecture?

Back 16

Use cases, as standalone chunks of system specification, dictate the sorts of functionality that need to be provided by the system and constitute an aid for identifying interfaces in an architecture. Use cases can also be grouped in terms of similar functionality, therefore influencing the architecture of the system. Scenarios can be used to check how an architecture meets non-functional requirements, in particular those that can be affected by the architecture, such as security and safety requirements.

Front 17

How do use cases help with system validation (checking that the system actually supports the functionality required by the users)?

Back 17

One way to validate a system is to use the walk-through technique, checking the functionality related to each use case in turn. The walk- through technique can also be used to elicit system tests where each use case is required to deal with a number of scenarios – a process known as verification. For each software requirement generated from a step of a scenario, the fit criterion helps to devise the test.

Front 18

A typical lending library keeps a stock of books for the use of its members. Each member can take out a number of books up to a certain limit. After a given period, the library expects members to return the books that they have on loan.

When borrowing books, members are expected to scan a library card in the library self-service scanning machine and then scan the barcodes of their chosen books. Each new loan is recorded in the system for that member. When a book is on loan to a member, it is associated with that member – possession of the book passes from the library to the member for a defined period. The normal loan period for each book is two weeks. If the member fails to bring the book back on or before the due date, the library imposes a fine.

The library wants to extend the existing system so that anyone should be able to browse the stock of books held in the library, but only a member will be able to reserve a book. The ability to browse and make reservations will be provided through a web-browser interface.

In the extension to the existing system, the librarians should also be able to enrol new library members.

Draw a simple use case diagram for the proposed extension to the library, and identify the constraints or assumptions that you make. (Ignore the issue of fines, because there is not enough information.)

Back 18

Front 19

Suggest a precondition and a postcondition for a hotel check out guest use case. The goal of this use case is for the guest’s bill to be paid and the room made available.

Back 19

Precondition: the guest must be currently allocated to a room.

Postcondition: the room will have been made available (either designated as free to be reserved by another guest or assigned to a pending reservation) and the guest’s bill will have been paid.

Front 20

Prepare a textual description of the check in guest use case that appears in Figure 10. Follow the example of Table 1, which shows the main success scenario and other criteria for the make reservation use case. As part of your working, identify any exceptions to the main success scenario. You will need to make some reasonable assumptions that need to be recorded.

Back 20

The actor for the check in guest use case is the Receptionist, as shown in Figure 10. You need to consider the exchanges that take place between a guest and the hotel’s receptionist. This is an assumption, as there are some hotels with automatic check-in and no receptionists; we are not considering that type of hotel.

The main success scenario describes the simplest path for checking a guest into a room in a hotel. Our solution is shown in Table 2.