Object-Oriented Design Lecture 4: Use Case Modeling Sharif - - PowerPoint PPT Presentation

▶
object oriented design
SMART_READER_LITE
LIVE PREVIEW

Object-Oriented Design Lecture 4: Use Case Modeling Sharif - - PowerPoint PPT Presentation

Jan 24, 2023 22 likes •474 views

Object-Oriented Design Lecture 4: Use Case Modeling Sharif University of Technology 1 Department of Computer Engineering Four Steps of requirements capture 1. List candidate requirements 2. Understand system context 3. Capture functional

slide-1
SLIDE 1

Department of Computer Engineering

Object-Oriented Design

Lecture 4: Use Case Modeling

Sharif University of Technology 1

slide-2
SLIDE 2

Four Steps of requirements capture

1.

List candidate requirements

2.

Understand system context

3.

Capture functional requirements

4.

Capture nonfunctional requirements

Sharif University of Technology 2

slide-3
SLIDE 3

Activities of requirements workflow

Capture Functional Requirements

  • 1. Find actors and use cases
  • 2. Prioritize use cases
  • 3. Detail use cases
  • 4. Prototype user interface
  • 5. Structure the use-case model

Sharif University of Technology 3

slide-4
SLIDE 4

Use case modeling

  • Use case modeling typically proceeds as follows:
  • Find a candidate system boundary; You generally

begin with some initial estimate of where the system boundary lies, to help you scope the modeling activity.

  • Find the actors.
  • Find the use cases:
  • specify the use case;
  • identify key alternative flows.
  • Iterate until use cases, actors, and system boundary

are stable.

Sharif University of Technology 4

slide-5
SLIDE 5

Use Case Model

  • Four components:
  • System boundary - a box drawn around the use cases to

denote the edge or boundary of the system being

  • modeled. This is known as the subject in UML2.
  • Actors - roles played by people or things that use the

system.

  • Use cases - things that the actors can do with the

system.

  • Relationships - meaningful relationships between actors

and use cases.

Sharif University of Technology 5

slide-6
SLIDE 6

The subject (system boundary)

  • The subject is defined by who or what uses the system (i.e.,

the actors) and what specific benefits the system offers to those actors (i.e., the use cases).

  • The subject is drawn as a box, labeled with the name of the

system

  • The actors are drawn outside the boundary and the use

cases inside.

  • Use case modeling starts with only a tentative idea of

where the subject actually lies.

  • As actors and use cases are found, the subject becomes

more and more sharply defined.

Sharif University of Technology 6

slide-7
SLIDE 7

Actors

  • An actor specifies a role that some external entity

adopts when interacting with the system directly.

  • It may represent a role played by:
  • a user
  • another system
  • a piece of hardware
  • In UML 2, actors may also represent other subjects,

giving a way to link different use case models.

Sharif University of Technology 7

slide-8
SLIDE 8

Actors: Notation

  • Can be shown as a class icon stereotyped «actor» or as the "stick man"

actor icon.

  • “Stick-man" form usually used to represent roles that are likely to be

played by people, and the class icon form to represent roles likely to be played by other systems.

Sharif University of Technology 8

Accounting

slide-9
SLIDE 9

Actors: Important Notes

  • Although actors themselves are always external to the

system, systems often maintain some internal representation of one or more actors.

  • Time as an actor:
  • When you need to model things that happen to your system at a

specific point in time but which don't seem to be triggered by any actor; e.g. an automatic system backup that runs every evening.

Sharif University of Technology 9

slide-10
SLIDE 10

Identifying Actors

  • Need to consider who or what uses the system, and what

roles they play in their interactions with the system.

  • Asking the following questions helps identify actors:
  • Who or what uses the system?
  • What roles do they play in the interaction?
  • Who installs the system?
  • Who or what starts and shuts down the system?
  • Who maintains the system?
  • What other systems interact with this system?
  • Who or what gets and provides information to the system?
  • Does anything happen at a fixed time?

Sharif University of Technology 10

slide-11
SLIDE 11

Actors: Specification

  • Each actor needs a short name that makes sense from the

business perspective.

  • Each actor must have a short description (one or two lines)

that describes what this actor is from a business perspective.

Actor name: Order Processing Clerk Description: The Order Processing Clerk is responsible for processing sales orders, submitting reorder requests, requesting necessary deposits from members and scheduling the delivery of the goods to members.

11 Sharif University of Technology

slide-12
SLIDE 12

Use Case

  • "A specification of sequences of actions, including

variant sequences and error sequences, that a system, subsystem or class can perform by interacting with outside actors."

  • Always started by an actor.
  • Always written from the point of view of the

actors.

Sharif University of Technology 12

slide-13
SLIDE 13

Identifying Use Cases

  • The best way of identifying use cases is to start with the list
  • f actors, and then consider how each actor is going to use

the system.

  • Each use case must be given a short, descriptive name that

is a verb phrase.

  • Identifying use cases may also result in finding new actors.

Sharif University of Technology 13

slide-14
SLIDE 14

Identifying Use Cases: Helpful Questions

  • The following list of questions helps identify the use cases:
  • What functions will a specific actor want from the system?
  • Does the system store and retrieve information? If so, which

actors trigger this behavior?

  • What happens when the system changes state (e.g., system start

and stop)? Are any actors notified?

  • Do any external events affect the system? What notifies the

system about those events?

  • Does the system interact with any external system?
  • Does the system generate any reports?

Sharif University of Technology 14

slide-15
SLIDE 15

Use Case Diagram

Sharif University of Technology 15

slide-16
SLIDE 16

Project Glossary

  • The glossary provides a dictionary of key business terms

and definitions.

  • It should be understandable by everyone in the project,

including all the stakeholders.

  • As well as defining key terms, the project glossary must

resolve synonyms and homonyms.

Sharif University of Technology 16

slide-17
SLIDE 17

Project Glossary: Example

Sharif University of Technology 17

slide-18
SLIDE 18

Activities of requirements workflow

Capture Functional Requirements

  • 1. Find actors and use cases
  • 2. Prioritize use cases
  • 3. Detail use cases
  • 4. Prototype user interface
  • 5. Structure the use-case model

Sharif University of Technology 18

slide-19
SLIDE 19

Use Case Specification: Template

  • use case name - short, descriptive verb phrase in UpperCamelCase;
  • use case ID - alternative routes are specified by using Dewey-decimal

numbering;

  • brief description - a paragraph that captures the goal of the use case;
  • actors involved in the use case;
  • primary actors - actually trigger the use case;
  • secondary actors - interact with the use case after it has been triggered.
  • preconditions - these are things that must be true before the use case can

execute - they are constraints on the state of the system;

  • main flow - the steps in the use case;
  • postconditions - things that must be true at the end of the use case;
  • alternative flows - a list of alternatives to the main flow.

Sharif University of Technology 19

slide-20
SLIDE 20

Use Case Specification: Example

Sharif University of Technology 20

slide-21
SLIDE 21

Use Case: Flows

  • The steps in a use case are listed in flows of events, described in

structured language.

  • Every use case has one main flow (Primary Scenario), which lists the

steps in a use case that capture the situation where everything goes as expected and desired, and there are no errors, deviations, interrupts, or branches.

  • Alternative flows (Secondary Scenarios) are deviations from the main

flow, and can capture errors, branches, and interrupts to the main flow.

  • The main flow always begins by the primary actor doing something to

trigger the use case. Time can be an actor, so the use case may also start with a time expression in place of the actor.

Sharif University of Technology 21

slide-22
SLIDE 22

Use Case: Flow Description

Sharif University of Technology 22

slide-23
SLIDE 23

Use Case: Alternative Flows

  • Frequently do not return to the main flow; because they
  • ften deal with errors and exceptions to the main flow and

tend to have different postconditions.

  • Should preferably be documented separately.
  • May be triggered in three different ways, which should be

stated in their flow descriptions:

  • instead of the main flow: triggered by the primary actor, it

effectively replaces the use case entirely.

  • after a particular step in the main flow
  • at any time during the main flow

Sharif University of Technology 23

slide-24
SLIDE 24

Use Case: Alternative Flow Example

Sharif University of Technology 24

slide-25
SLIDE 25

Use Case: Finding Alternative Flows

  • Identify alternative flows by inspecting the main
  • flow. At each step in the main flow, look for:
  • possible alternatives to the main flow;
  • errors that might be raised in the main flow;
  • interrupts that might occur at a particular point in the

main flow;

  • interrupts that might occur at any point in the main

flow.

Sharif University of Technology 25

slide-26
SLIDE 26

26 Sharif University of Technology

Activities of requirements workflow

Capture Functional Requirements

  • 1. Find actors and use cases
  • 2. Prioritize use cases
  • 3. Detail use cases
  • 4. Prototype user interface
  • 5. Structure the use-case model
slide-27
SLIDE 27

27 Sharif University of Technology

Relationships

  • actor generalization - a generalization relationship between

a more general actor and a more specific actor

  • use case generalization - a generalization relationship

between a more general use case and a more specific use case

  • «include» - a relationship between use cases that lets one

use case include behavior from another

  • «extend» - a relationship between use cases that lets one

use case extend its behavior with one or more behavior fragments from another

slide-28
SLIDE 28

28 Sharif University of Technology

Actor Generalization

  • If two actors communicate with the same set of use cases in

the same way, we can express this as a generalization to another (possibly abstract) actor.

slide-29
SLIDE 29

29 Sharif University of Technology

Use Case Generalization

  • Used when one or more use cases are really specializations of a

more general case.

  • Child use cases may:
  • inherit features from their parent use case
  • add new features
  • verride (change) inherited features (except for inherited

relationships and extension points)

  • Use case generalization is documented in use case specifications

using a simple tag language on flow steps. There are two rules:

  • Each step number in the child is postfixed by the equivalent step

number in the parent if there is one.

  • If the step in the child overrides a parent step, it is postfixed by

"o" (for overridden) and then the step number in the parent.

slide-30
SLIDE 30

30 Sharif University of Technology

Use Case Generalization: Example

slide-31
SLIDE 31

31 Sharif University of Technology

«include» Relationship

  • The «include» relationship between use cases allows you to

include the behavior of one use case into the flow of another use case.

slide-32
SLIDE 32

32 Sharif University of Technology

«include» Relationship: Specification

  • The base use case is not complete without all of its inclusion use cases.
  • Inclusion use cases may be complete (instantiable) or incomplete (behavior

fragments)

slide-33
SLIDE 33

33 Sharif University of Technology

«extend» Relationship

  • provides a way to insert new behavior into an existing use

case.

  • The base use case is a complete use case and provides a set of

extension points that are hooks where new behavior may be added.

  • The extension use case provides a set of insertion segments

that can be inserted into the base use case at these hooks.

  • The relationship can specify exactly which extension points in

the base use case are being extended.

slide-34
SLIDE 34

34 Sharif University of Technology

«extend» Relationship: Example

slide-35
SLIDE 35

35 Sharif University of Technology

«extend» Relationship: Extension Points

slide-36
SLIDE 36

36 Sharif University of Technology

«extend» Relationship: Extension Use Cases

  • Are not complete use cases and therefore can't be

instantiated.

  • Normally consist of one or more behavior fragments known

as insertion segments.

  • The «extend» relationship specifies the extension point in the

base use case where the insertion segment will be inserted.

slide-37
SLIDE 37

37 Sharif University of Technology

Extension Use Case: Single-Segment Example

slide-38
SLIDE 38

38 Sharif University of Technology

Extension Use Case: Multiple-Segment Example

slide-39
SLIDE 39

39 Sharif University of Technology

«extend» Relationship: Conditional Extensions

slide-40
SLIDE 40

40 Sharif University of Technology

«extend» Relationship: Rules

  • The «extend» relationship must specify one or more of the

extension points in the base use case or it is assumed that the «extend» relationship refers to all extension points.

  • The extension use case must have the same number of

insertion segments as there are extension points specified in the «extend» relationship.

  • It is legal for two extension use cases to «extend» the same

base use case at the same extension point. But if this happens, the order in which the extensions execute is indeterminate.

slide-41
SLIDE 41

41 Sharif University of Technology

Use Case Modeling: Hints and Tips - 1

  • 1. Keep use cases short and simple
  • Include only enough detail to capture the

requirements.

  • A good rule of thumb is to ensure that the main flow
  • f a use case fits on a single side of paper.
  • Start by simplifying the text
  • Remove any design details
  • Reanalyze the problem: Are there more than one use case? Can

alternative flows be factored out?

slide-42
SLIDE 42

42 Sharif University of Technology

Use Case Modeling: Hints and Tips - 2

  • 2. Focus on the what, not the how
  • Use cases should show what the actors need the system to do,

not how the system should do it. The how comes later in the design workflow.

  • Example:

……………

  • 4. The system asks the Customer to confirm the order.
  • 5. The Customer presses the OK button.

……………

  • Some sort of user interface has been imagined: a form with an OK

button.

  • Better be written as:
  • 5. The Customer accepts the order.
slide-43
SLIDE 43

43 Sharif University of Technology

Use Case Modeling: Hints and Tips - 3

  • 3. Avoid functional decomposition
  • Functional Decomposition in Use Case Modeling: creating

a set of "high level" use cases, and then breaking these down into a set of lower-level use cases and so

  • n, until "primitive" use cases are reached that are

detailed enough to be implemented.

slide-44
SLIDE 44

44 Sharif University of Technology

Functional Decomposition in Use Case Modeling: Example

slide-45
SLIDE 45

Reference

  • Arlow, J., Neustadt, I., UML 2 and the Unified Process: Practical

Object-Oriented Analysis and Design, 2nd Ed. Addison-Wesley, 2005.

Sharif University of Technology 45