Chapter 5 Functional Modeling

Use-Case Descriptions
Use-case diagrams are functional diagrams in that they portray the basic functions of the systemthat is, what the users can do and how the system should respond to the users actions Creating use-case diagrams is a two-step process: First, the users work with the project team to write text-based use-case descriptions; Second, the project team translates the use-case descriptions into formal use-case diagrams Use cases capture the typical interaction of the system with the systems users (end users and other systems). Each possible execution path through the use case is referred to as a scenario The key thing to remember is that each use case is associated with one and only one role that users have in the system

Types of Use Cases

Two separate dimensions on which to classify a use case based on the purpose of the use case and the amount of information that the use case contains: Overview versus detail; and Essential versus real

An overview use case is used to enable the analyst and user to agree on a high-level overview of the requirements A detail use case typically documents, as far as possible, all the information needed for the use case An essential use case is one that describes only the minimum essential issues necessary to understand the required functionality. A real use case goes further and describes a specific set of steps

Elements of a Use-Case Description

A use-case description contains all the information needed to build the diagrams that follow, but it expresses the information in a less formal way that is usually simpler for users to understand Overview Information The overview information identifies the use case and provides basic background information about the use case. The use-case name should be a verbnoun phrase

The use-case ID number provides a unique way to find every use case and also enables the team to trace design decisions back to a specific requirement The primary actor is usually the trigger of the use casethe person or thing that starts the execution of the use case The brief description is typically a single sentence that describes the essence of the use case The importance level can be used to prioritize the use cases A use case may have multiple stakeholders that have an interest in the use case Each use case typically has a trigger the event that causes the use case to begin A trigger can be an external trigger, such as a customer placing an order or the fire alarm ringing, or It can be a temporal trigger, such as a book being overdue at the library or the need to pay the rent Relationships Use-case relationships explain how the use case is related to other use cases and users There are four basic types of relationships: association, extend, include, and generalization

An association relationship documents the communication that takes place between the use case and the actors that use the use case An extend relationship represents the extension of the functionality of the use case to incorporate optional behavior An include relationship represents the mandatory inclusion of another use case. The include relationship enables functional decompositionthe breaking up of a complex use case into several simpler ones The generalization relationship allows use cases to support inheritance

Guidelines for Creating Use-Case Descriptions

The essence of a use case is the flow of events. Writing the flow of events in a manner that is useful for later stages of development generally comes with experience

First, write each individual step in the form subjectverbdirect object and, optionally, preposition indirect object Second, make clear who or what the initiator of the action is and who the receiver of the action in each step is Third, write the step from the perspective of an independent observer Fourth, write each step at the same level of abstraction Fifth, ensure that the use case contains a sensible set of actions The sixth guideline is the KISS principle. If the use case becomes too complex and/or too long, the use case should be decomposed into a set of use cases The seventh guideline deals with repeating steps

Use Case Diagrams

A use-case diagram illustrates in a very simple way the main functions of the system and the different kinds of users that will interact with it

Actors
The labeled stick figures on the diagram represent actors An actor is not a specific user, but instead is a role that a user can play while interacting with the system An actor can also represent another system in which the current system interacts A specialized actor (i.e., new patient) can be placed on the model, shown using a line with a hollow triangle at the end of the more general actor (i.e., patient).

Association
Use cases are connected to actors through association relationships; these relationships show with which use cases the actors interact The association typically represents two-way communication between the use case and the actor

Use Case
A use case, depicted by an oval in the UML, is a major process that the system will perform that benefits an actor or actors in some way There are times when a use case includes, extends, or generalizes the functionality of another use case in the diagram There are times when a single use case contains common functions that are used by other use cases There are times when it makes sense to use a generalization relationship to simplify the individual use cases

Subject Boundary
The use cases are enclosed within a subject boundary, which is a box that defines the scope of the system and clearly delineates what parts of the diagram are external or internal to it

Creating Use-Case Descriptions and Use-Case Diagrams

Identifying the Major Use Cases

The first step is to review the activity diagram. This helps the analyst to get a complete overview of the underlying business process being modeled. The second step is to identify the subjects boundaries. This helps the analyst to identify the scope of the system The third step is to identify the primary actors and their goals. The primary actors involved with the system will come from a list of stakeholders and users. The fourth step is to identify and write the major use cases, with basic information about each, rather than jumping into one use case and describing it completely The fifth step is to carefully review the current set of use cases. It may be necessary to split some of them into multiple use cases or merge some of them into a single use case

Expanding the Major Use Cases

The sixth step is to choose one of the major use cases to expand. Using the importance level of the use case can help do this. The seventh step is to start filling in the details on the use-case template. The eighth step is to fill in the steps of the normal flow of events required to describe each use case. The steps focus on what the business process does to complete the use case, as opposed to what actions the users or other external entities do The ninth step is to ensure that the steps listed in the normal flow of events are not too complex or too long. Each step should be about the same size as the others The tenth step focuses on identifying the alternate or exceptional flows. Alternate or exceptional flows are those flows of success that represent optional or exceptional behavior The eleventh step is simply to write the description of any alternate or exceptional flows

Confirming the Major Use Cases

The twelfth step is to carefully review the current set of use cases and to confirm that the use case is correct as written, which means reviewing the use case with the users to make sure each step is correct The thirteenth and final step is to iterate over the entire set of steps again. Users will often change their minds about what is a use case and what it includes

Creating a Use-Case Diagram

There are four major steps in drawing a use-case diagram. First, the use-case diagram starts with the subject boundary. This forms the border of the subject, separating use cases (i.e., the subjects functionality) from actors (i.e., the roles of the external users).

Second, the use cases are drawn on the diagram. These are taken directly from the detailed use-case descriptions. Third, the actors are placed on the diagram. The actors are taken directly from the primary actor element on the detailed use-case description The fourth and last step is to draw lines connecting the actors to the use cases with which they interact

Refining Project Size and Effort Estimation Using Use-Case Points

To estimate size and effort using use-case points, at least the set of essential use cases and the use-case diagram must have been created Simple actors are separate systems with which the current system must communicate through a welldefined application program interface Average actors are separate systems that interact with the current system using standard communication protocols Complex actors are typically end users communicating with the system using some type of GUI Depending on the number of unique transactions that the use case must address, a use case is classified as a simple use case (13), an average use case (47), or a complex use case (>7) In this case, there are two sets of factors: technical complexity factors (TCF) and environmental factors (EF)