software engineering design & modelling capturing requirements using use cases

56
Software Engineering Software Engineering Design & Modelling Design & Modelling Capturing Requirements Capturing Requirements Using Using Use Cases Use Cases

Upload: angelica-mary-dickerson

Post on 28-Dec-2015

236 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

Software Engineering Software Engineering Design & ModellingDesign & Modelling

Capturing Requirements Capturing Requirements Using Using

Use CasesUse Cases

Page 2: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

2

Chapter OutlineChapter Outline

Use casesUse cases Use case diagramsUse case diagrams Case StudyCase Study

Page 3: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

3

IntroductionIntroduction No system exists in isolation.No system exists in isolation. Every system interacts with human or Every system interacts with human or

automated actors that use the system for automated actors that use the system for some purposesome purpose and those actors expect the system to behave in and those actors expect the system to behave in

predictable wayspredictable ways We can use UML to capture and model the We can use UML to capture and model the

requirements associated with a systemrequirements associated with a system will look at will look at use cases use cases and and use case diagram use case diagram

in modelling requirementsin modelling requirements

Page 4: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

Use CasesUse Cases

Page 5: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

5

IntroductionIntroduction A use case A use case

specifies the behaviour of a system or part of a specifies the behaviour of a system or part of a systemsystem

is used to capture intended behaviour of the is used to capture intended behaviour of the system (functional requirements), without having system (functional requirements), without having to specify how that behaviour will be implementedto specify how that behaviour will be implemented

As we implement our system, these use cases As we implement our system, these use cases are realized by collaborations whose are realized by collaborations whose elements work together to carry out each use elements work together to carry out each use casescases

Well-structured use cases denote essential Well-structured use cases denote essential system or sub-system behaviours only.system or sub-system behaviours only.

Page 6: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

6

DefinitionDefinition A use case is a description of a set of A use case is a description of a set of

sequences of actions, including variants, sequences of actions, including variants, that a system performs in order to yield an that a system performs in order to yield an observable result of value to an actor.observable result of value to an actor. it is a sequence of actions that an actor performs it is a sequence of actions that an actor performs

within a system to achieve a particular goalwithin a system to achieve a particular goal Graphically, a use case is rendered as an Graphically, a use case is rendered as an

ellipseellipse

Use case’s name

Page 7: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

7

Every use case must have a name that Every use case must have a name that distinguishes it from other use casesdistinguishes it from other use cases simple namesimple name Path name : the name prefixed by the name Path name : the name prefixed by the name

of the package in which that use case lives of the package in which that use case lives Graphically, a use case is drawn Graphically, a use case is drawn

showing only its nameshowing only its name

Place orderSensors:: Calibrate location

simple name

path name

Page 8: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

8

ActorsActors An actor represents a coherent set of roles An actor represents a coherent set of roles

that users of use cases play when interacting that users of use cases play when interacting with these use caseswith these use cases an actor represents a role that a human (user), a an actor represents a role that a human (user), a

hardware device, or even another system plays hardware device, or even another system plays with a systemwith a system

An instance of an actor represents an An instance of an actor represents an individual interacting with the system in a individual interacting with the system in a specific wayspecific way

Although actors are used in models, actors Although actors are used in models, actors are not actually part of the systemare not actually part of the system they live outside the systemthey live outside the system

Page 9: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

9

Graphically, actors are rendered as stick figuresGraphically, actors are rendered as stick figures we can define general kinds of actors (such as we can define general kinds of actors (such as

Customer) and specialize them (such as Customer) and specialize them (such as CommercialCustomer) using generalization CommercialCustomer) using generalization relationshipsrelationships

• Actors may be connected to use cases Actors may be connected to use cases only by associationonly by association• indicates that the actor and the use case indicates that the actor and the use case

communicate with one another, each one communicate with one another, each one possibly sending and receiving messagespossibly sending and receiving messages

CommercialCustomer

Customeractor

actor

generalization

Page 10: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

10

PropertiesProperties1.1. A use case describes a set of sequencesA use case describes a set of sequences

each sequence represents the interaction of the each sequence represents the interaction of the things outside the system (its actors) with the things outside the system (its actors) with the system itself (and its key abstraction)system itself (and its key abstraction)

a use case represents a functional requirement a use case represents a functional requirement of your system as a wholeof your system as a whole

2.2. A use case involves the interaction of A use case involves the interaction of actors and the systemactors and the system

3.3. A use case may have variantsA use case may have variants use cases that are specialized versions of other use cases that are specialized versions of other

use casesuse cases use cases that are included as parts of other use cases that are included as parts of other

use casesuse cases use cases that extend the behaviour of other use cases that extend the behaviour of other

core use casescore use cases

Page 11: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

11

4.4. A use case carries out some tangible A use case carries out some tangible amount of workamount of work

from the perspective of a given actor, a use from the perspective of a given actor, a use case does something that’s of value to an actorcase does something that’s of value to an actor

5.5. Use cases can be applied to the whole or Use cases can be applied to the whole or part of the system, including sub-systems part of the system, including sub-systems and even individual classes and interfacesand even individual classes and interfaces

these use cases not only represent the desired these use cases not only represent the desired behaviour of these elements, but they can also behaviour of these elements, but they can also be used as the basis of test cases for these be used as the basis of test cases for these elements as they evolve during developmentelements as they evolve during development

Page 12: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

12

Flow of EventsFlow of Events A use case describes A use case describes whatwhat a system does but it a system does but it

does not specify does not specify howhow it does it. it does it. We can specify the behaviour of a use case by We can specify the behaviour of a use case by

describing a flow of events, that should describing a flow of events, that should include: -include: - how and when the use case starts and endshow and when the use case starts and ends when the use case interacts with the actors and when the use case interacts with the actors and

what objects are exchangedwhat objects are exchanged the basic flow and alternative flows of the behaviourthe basic flow and alternative flows of the behaviour

Therefore, a flow of events can consist ofTherefore, a flow of events can consist of the main flow of eventsthe main flow of events exceptional flow of events or alternative flow of exceptional flow of events or alternative flow of

eventsevents

Page 13: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

13

ScenariosScenarios Typically, we describe the flow of events Typically, we describe the flow of events

for a use case in textfor a use case in text But eventually, we will want to use interaction But eventually, we will want to use interaction

diagrams to specify these flows graphically diagrams to specify these flows graphically (we will learn in the next chapter)(we will learn in the next chapter)

It is desirable to separate main versus It is desirable to separate main versus alternative flows because a use case alternative flows because a use case describes a set of sequencesdescribes a set of sequences It would be highly impossible to express all the It would be highly impossible to express all the

details of a use case in just one sequencedetails of a use case in just one sequence

Page 14: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

14

Ex: - A use case Ex: - A use case HireEmployeeHireEmployee in a Human in a Human Resource system may have many Resource system may have many business variations, e.g.: -business variations, e.g.: - A person can be hired from another A person can be hired from another

company (the most common scenario)company (the most common scenario) A person might be transferred from one A person might be transferred from one

division to anotherdivision to another A foreign national can be hiredA foreign national can be hired

Each of these variant can be expressed Each of these variant can be expressed in a different sequencein a different sequence Each sequence is called a scenarioEach sequence is called a scenario

A scenario is a specific sequence of actions that A scenario is a specific sequence of actions that illustrates behaviourillustrates behaviour

A scenario is an instance of a use caseA scenario is an instance of a use case

Page 15: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

15

CollaborationsCollaborations

A use case captures the intended A use case captures the intended behaviour of the system without having to behaviour of the system without having to specify how that behaviour is implementedspecify how that behaviour is implemented However, we eventually need to implement our However, we eventually need to implement our

use cases by creating a society of classes and use cases by creating a society of classes and other elements that work together to other elements that work together to implement the behaviour of this use caseimplement the behaviour of this use case

This society of elements (both static and This society of elements (both static and dynamic structure) is modelled in the UML dynamic structure) is modelled in the UML as a collaborationas a collaboration

Page 16: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

16

In UML, we can explicitly specify the In UML, we can explicitly specify the realization of a use case by collaborationrealization of a use case by collaboration A given use case is usually realized by A given use case is usually realized by

exactly one collaborationexactly one collaboration

Place Order

Order Managementuse case

collaboration

realization

Page 17: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

17

Example: - Describing the use case Example: - Describing the use case ValidateUserValidateUser in the context of an ATM systemin the context of an ATM system Main flow of eventsMain flow of events

The use case starts when the system prompts the The use case starts when the system prompts the CUSTOMER for a PIN number.CUSTOMER for a PIN number.

The CUSTOMER enters a PIN number via the The CUSTOMER enters a PIN number via the keyboardkeyboard

The CUSTOMER commits the entry by pressing the The CUSTOMER commits the entry by pressing the Enter buttonEnter button

The system checks this PIN number to see if it is valid.The system checks this PIN number to see if it is valid. If it is, the system acknowledges entryIf it is, the system acknowledges entry

Use case ends once the system acknowledges the Use case ends once the system acknowledges the entryentry

A simple example 1A simple example 1

Page 18: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

18

Exceptional flow of eventsExceptional flow of events A CUSTOMER can cancel a transaction at A CUSTOMER can cancel a transaction at

anytime by pressing the CANCEL button, thus anytime by pressing the CANCEL button, thus restarting the use caserestarting the use case

No changes are made to the CUSTOMER’s accountNo changes are made to the CUSTOMER’s account

Exceptional flow of eventsExceptional flow of events The CUSTOMER can clear a PIN number The CUSTOMER can clear a PIN number

anytime before committing itanytime before committing it The CUSTOMER can re-enter a new PIN The CUSTOMER can re-enter a new PIN

numbernumber Exceptional flow of eventsExceptional flow of events

If the CUSTOMER enters an invalid PIN If the CUSTOMER enters an invalid PIN number, the use case restartsnumber, the use case restarts

If this happens three times in a row, the If this happens three times in a row, the system cancels the entire transaction and the system cancels the entire transaction and the card will automatically be swallowed by the card will automatically be swallowed by the ATM machineATM machine

Page 19: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

19

Validate Validate UserUser

Validate that the customer is an authorised user or Validate that the customer is an authorised user or the ATM machine.the ATM machine.Pre-condition:Pre-condition:An ATM card and an authorised PIN numberAn ATM card and an authorised PIN numberMain flow of events:Main flow of events:1. The user inserts the ATM card.1. The user inserts the ATM card.2. The system prompts the CUSTOMER for a PIN 2. The system prompts the CUSTOMER for a PIN number.number.3. The CUSTOMER enters a PIN number via the 3. The CUSTOMER enters a PIN number via the keyboard.keyboard.4. The CUSTOMER presses the ENTER button.4. The CUSTOMER presses the ENTER button.5. The system checks the PIN number to see if it is 5. The system checks the PIN number to see if it is valid. If it is, the valid. If it is, the system acknowledges entry.system acknowledges entry.Post-condition:Post-condition:The CUSTOMER is authorised to continue the The CUSTOMER is authorised to continue the transaction.transaction.

Validate Validate UserUser

DescriptionDescription Use CaseUse Case

Customer

Page 20: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

20

Use CaseUse Case DescriptionDescriptionValidate Validate UserUser(continue(continue…)…)

Alternate flow of events:Alternate flow of events:1. The user inserts the ATM card.1. The user inserts the ATM card.2. The system prompts the CUSTOMER for a PIN 2. The system prompts the CUSTOMER for a PIN number.number.3. The CUSTOMER presses the CANCEL button.3. The CUSTOMER presses the CANCEL button.5. The system stops the transaction and returns the 5. The system stops the transaction and returns the ATM cards.ATM cards.Post-condition:Post-condition:No changes are made to the CUSTOMER account.No changes are made to the CUSTOMER account.

Alternate flow of events:Alternate flow of events:1. The user inserts the ATM card.1. The user inserts the ATM card.2. The system prompts the CUSTOMER for a PIN 2. The system prompts the CUSTOMER for a PIN number.number.3. The CUSTOMER enters a PIN number via the 3. The CUSTOMER enters a PIN number via the keyboard.keyboard.4. The CUSTOMER presses the CLEAR button.4. The CUSTOMER presses the CLEAR button.5. The CUSTOMER re-enters the PIN number via 5. The CUSTOMER re-enters the PIN number via the keyboard.the keyboard.6. The CUSTOMER presses the ENTER button.6. The CUSTOMER presses the ENTER button.7. The system checks the PIN number to see if it is 7. The system checks the PIN number to see if it is valid. If it is, the valid. If it is, the system acknowledges entry.system acknowledges entry.Post-condition:Post-condition:The CUSTOMER is authorised to continue the The CUSTOMER is authorised to continue the transaction.transaction.

Page 21: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

21

Use CaseUse Case DescriptionDescriptionValidate Validate UserUser(continue(continue…)…)

Alternate flow of events:Alternate flow of events:1. The user inserts the ATM card.1. The user inserts the ATM card.2. The system prompts the CUSTOMER for a PIN 2. The system prompts the CUSTOMER for a PIN number.number.3. The CUSTOMER enters a PIN number via the 3. The CUSTOMER enters a PIN number via the keyboard.keyboard.4. The CUSTOMER presses the ENTER button.4. The CUSTOMER presses the ENTER button.7. The system checks the PIN number to see if it is 7. The system checks the PIN number to see if it is valid. If it is not valid. If it is not valid, the system prompts user to retry. valid, the system prompts user to retry. 8. Repeat step 3-7 (maximum three times).8. Repeat step 3-7 (maximum three times).9 If user repeats more than 3 times, system will not 9 If user repeats more than 3 times, system will not return the return the ATM card to the CUSTOMER.ATM card to the CUSTOMER.Post-condition:Post-condition:The ATM card is swallowed by the ATM machine. The ATM card is swallowed by the ATM machine. The CUSTOMER is not able to perform any The CUSTOMER is not able to perform any transactions.transactions.

Page 22: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

22

A simple example 2A simple example 2 Example: In an on-line Bookstore system, Example: In an on-line Bookstore system,

user needs to log-in first before he/she could user needs to log-in first before he/she could order and purchase any desired books. order and purchase any desired books. Describe the use case for the log-in process Describe the use case for the log-in process of the on-line Bookstore system.of the on-line Bookstore system.

Answer: For every log-in process, there are Answer: For every log-in process, there are two flowstwo flows When the log-in is successful (main-flow)When the log-in is successful (main-flow) When the log-in is not successful (alternate-flows)When the log-in is not successful (alternate-flows)

For each flow, we can describe the sequence/flow For each flow, we can describe the sequence/flow of events.of events.

Page 23: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

23

Log-inLog-in A CUSTOMER needs to log-in before performing any A CUSTOMER needs to log-in before performing any transactiontransaction

Pre-condition:Pre-condition:A registered user.A registered user.Main flow of events:Main flow of events:1. The CUSTOMER clicks the Log-in button on the Home 1. The CUSTOMER clicks the Log-in button on the Home

Page.Page.2. The system displays the Log-in Page.2. The system displays the Log-in Page.3. The CUSTOMER enters his/her user ID and password.3. The CUSTOMER enters his/her user ID and password.4. The CUSTOMER clicks the OK button.4. The CUSTOMER clicks the OK button.5. The system validates the log-in information against 5. The system validates the log-in information against

the ACCOUNT the ACCOUNT table in the database.table in the database.6. CUSTOMER is an authorised user; the system displays 6. CUSTOMER is an authorised user; the system displays

the Personal the Personal Home Page to the CUSTOMERHome Page to the CUSTOMERPost-condition:Post-condition:The CUSTOMER has been authorised to perform The CUSTOMER has been authorised to perform

transactions.transactions.

Log-inLog-in

Customer

Page 24: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

24

Log-inLog-in(cont…)(cont…)

Alternate flow:Alternate flow:1. The CUSTOMER clicks the Log-in button on the Home 1. The CUSTOMER clicks the Log-in button on the Home

Page.Page.2. The system displays the Log-in Page.2. The system displays the Log-in Page.3. The CUSTOMER enters his/her user ID and password.3. The CUSTOMER enters his/her user ID and password.4. The CUSTOMER clicks the OK button.4. The CUSTOMER clicks the OK button.5. The system validates the log-in information against 5. The system validates the log-in information against

the ACCOUNT the ACCOUNT table in the database.table in the database.6. CUSTOMER is not an authorised user; the system 6. CUSTOMER is not an authorised user; the system

displays a pop-up message to inform the displays a pop-up message to inform the CUSTOMER.CUSTOMER.

Post-condition:Post-condition:The CUSTOMER is not authorised to perform The CUSTOMER is not authorised to perform

transactions.transactions.

Page 25: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

Use Case Use Case DiagramsDiagrams

Page 26: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

26

IntroductionIntroduction Use case diagrams are used to model the Use case diagrams are used to model the

dynamic aspect of a systemdynamic aspect of a system are central to modelling the behaviour of a are central to modelling the behaviour of a

system, a subsystem, or a classsystem, a subsystem, or a class A use case diagram shows a set of use A use case diagram shows a set of use

cases and actors and their relationshipscases and actors and their relationships Use case diagrams are applied to model Use case diagrams are applied to model

the use case view of a systemthe use case view of a system involves modelling involves modelling

the context of a system, subsystem or classthe context of a system, subsystem or class The requirements of the behaviour of these The requirements of the behaviour of these

elementselements

Page 27: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

27

Use case diagrams are important forUse case diagrams are important for visualizing, specifying, and visualizing, specifying, and

documenting the behaviour of an documenting the behaviour of an elementelement They make systems, subsystems, and They make systems, subsystems, and

classes approachable and understandable classes approachable and understandable by presenting an outside view of how those by presenting an outside view of how those elements may be used in contextelements may be used in context

testing executable systems through testing executable systems through forward engineeringforward engineering

comprehending executable systems comprehending executable systems through reverse engineeringthrough reverse engineering

Page 28: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

28

With the UML, we apply use case With the UML, we apply use case diagrams to visualize the diagrams to visualize the behaviour of a system, subsystem, behaviour of a system, subsystem, or class so thator class so that users can understand how to use that users can understand how to use that

elementelement developers can implement that developers can implement that

elementelement

Page 29: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

29

DefinitionDefinition A use case diagram is a diagram A use case diagram is a diagram

that shows a set of use cases and that shows a set of use cases and actors and their relationshipsactors and their relationships

It commonly contains: -It commonly contains: - Use casesUse cases ActorsActors Dependency, generalization and Dependency, generalization and

association relationshipsassociation relationships May also contain notes, constraints, May also contain notes, constraints,

packages and instancespackages and instances

Page 30: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

30

Organizing use case Organizing use case diagramsdiagrams

There are three types of There are three types of relationships that can be applied in a relationships that can be applied in a use case diagram: -use case diagram: - (A)(A) Generalization relationships Generalization relationships

between actors (as seen in slide 9)between actors (as seen in slide 9) (B)(B) Dependency and generalization Dependency and generalization

relationships between use casesrelationships between use cases (C)(C) Association relationships between Association relationships between

actors and use casesactors and use cases

Page 31: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

31

User

Individual user

Corporate user

Cellular network

(A)

(C) Place phone call

Receive phone call

Use scheduler

Cellular Telephone

Place conference call

Receive additional call

<<extend>>

<<extend>>

(B)

Time scheduler

Date scheduler

Page 32: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

32

Generalization relationships between Generalization relationships between use cases are similar to use cases are similar to generalization among classes: -generalization among classes: - The child use case inherits the The child use case inherits the

behaviour and meaning of the parent behaviour and meaning of the parent use caseuse case

The child use case may add to or The child use case may add to or override the behaviour of its parentoverride the behaviour of its parent

The child use case may be substituted The child use case may be substituted any place that the parent may appearany place that the parent may appear

Page 33: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

33

For dependency relationships among use For dependency relationships among use cases, there are two stereotypes that can be cases, there are two stereotypes that can be applied: -applied: - includeinclude

one use case explicitly includes the behaviour of one use case explicitly includes the behaviour of another use case at a specified point within a another use case at a specified point within a course of actioncourse of action

The include use case does not stand alone; it has to be The include use case does not stand alone; it has to be connected with one or more base use cases.connected with one or more base use cases.

We apply We apply includeinclude relationship in order to factor relationship in order to factor common behaviour by pulling such behaviour common behaviour by pulling such behaviour from other use cases that it includesfrom other use cases that it includes

includeinclude relationship is essentially an example of relationship is essentially an example of delegation wheredelegation where

a set of responsibilities in the system is captured in one a set of responsibilities in the system is captured in one place (the included use case) and other parts of the place (the included use case) and other parts of the system (other use cases) can include this set of system (other use cases) can include this set of responsibilities whenever they need to use that responsibilities whenever they need to use that functionalityfunctionality

Page 34: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

34

UML notation:UML notation:

ExampleExample

Base Use CaseBase Use Case Included Use CaseIncluded Use Case<<include><<include>>>

Log inLog in

Add to Wish ListAdd to Wish List

Check OutCheck Out

<<include><<include>>>

<<include><<include>>>CustomCustom

erer

A CUSTOMER of an internet bookstore must be logged-in A CUSTOMER of an internet bookstore must be logged-in first before he/she can add items to his/her Wish List or to first before he/she can add items to his/her Wish List or to check out the items in the Shopping Cartcheck out the items in the Shopping Cart

Page 35: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

35

extendextend A base use case implicitly includes the behaviour A base use case implicitly includes the behaviour

of another use case at one or more specified of another use case at one or more specified points.points.

We apply We apply extendextend relationship in order to factor relationship in order to factor variants by pushing such behaviour into other use variants by pushing such behaviour into other use cases that extend itcases that extend it

extendextend relationship is used to relationship is used to model the part of a use case the user may see as model the part of a use case the user may see as

optional system behaviouroptional system behaviour model a separate sub-flow that is executed only model a separate sub-flow that is executed only

under given conditionsunder given conditions model several flows that may be inserted at a model several flows that may be inserted at a

certain point, governed by explicit interaction with certain point, governed by explicit interaction with an actoran actor

Page 36: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

36

UML notation:UML notation:

ExampleExample

Base Use CaseBase Use Case Extended Use CaseExtended Use Case<<extend>><<extend>>

Cancel OrderCancel OrderCheck Order StatusCheck Order Status

<<extend>><<extend>>(order ID)(order ID)

CustomCustomererA CUSTOMER of an internet bookstore has the option of A CUSTOMER of an internet bookstore has the option of cancelling an Order in conjunction with checking the status cancelling an Order in conjunction with checking the status of that Order.of that Order.

Page 37: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

37

Actors may be connected to use Actors may be connected to use cases only by associationcases only by association• indicates that the actor and the use indicates that the actor and the use

case communicate with one another, case communicate with one another, each one possibly sending and each one possibly sending and receiving messagesreceiving messages

Page 38: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

38

Use Case Diagrams – Use Case Diagrams – Common UsesCommon Uses

When we model the behaviour of a When we model the behaviour of a system (the static use case view of system (the static use case view of the system), we will apply the use the system), we will apply the use case diagrams in two ways: -case diagrams in two ways: - To model the context of a systemTo model the context of a system To model the requirements of a systemTo model the requirements of a system

Page 39: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

39

1) Modelling the context of the system1) Modelling the context of the system Involves drawing a line around the whole Involves drawing a line around the whole

system and determining which things or actors system and determining which things or actors lie outside the system and interact with itlie outside the system and interact with it

Ex: - In a credit card validation system, things such Ex: - In a credit card validation system, things such as accounts, transactions, and fraud detection agents as accounts, transactions, and fraud detection agents are found inside the system, whereas things such as are found inside the system, whereas things such as credit card customers and retail institutions are credit card customers and retail institutions are found outside the systemfound outside the system

The things that live inside the system are responsible The things that live inside the system are responsible for carrying out the behaviour that those on the for carrying out the behaviour that those on the outside expect the system to provideoutside expect the system to provide

All those things on the outside that interact with the All those things on the outside that interact with the system constitute the system’s context, which defines system constitute the system’s context, which defines the environment in which the system livesthe environment in which the system lives

A use case diagram is used to specify the A use case diagram is used to specify the actors and the meaning of their rolesactors and the meaning of their roles

Page 40: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

40

Perform Perform card card

transactiontransaction

Process Process customer customer

billbill

Reconcile Reconcile transactionstransactions

Manage Manage customer customer accountaccount

CustomeCustomerr

IndividuIndividual al

customecustomerr

CorporCorporate ate

customcustomerer

Retail Retail institutiinstituti

onon

SponsorinSponsoring g

financial financial institutioninstitution

Credit Card Validation Credit Card Validation SystemSystem

Example: -Example: -

Page 41: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

41

To model the context of a system,To model the context of a system, Identify the actors that surround the system by Identify the actors that surround the system by

consideringconsidering Which groups require help from the system to perform their Which groups require help from the system to perform their

taskstasks Which groups are needed to execute the system’s functionsWhich groups are needed to execute the system’s functions Which groups interact with external hardware or other software Which groups interact with external hardware or other software

systemssystems Which groups perform secondary functions for administration Which groups perform secondary functions for administration

and maintenanceand maintenance Organize actors that are similar to one another in a Organize actors that are similar to one another in a

generalization/ specialization hierarchygeneralization/ specialization hierarchy Provide a stereotype for actors, if it aids Provide a stereotype for actors, if it aids

understandabilityunderstandability Populate a use case diagram with these actors and Populate a use case diagram with these actors and

specify the paths of communication form each actor to specify the paths of communication form each actor to the system’s use casethe system’s use case

Page 42: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

42

2) Modelling the requirements of a system2) Modelling the requirements of a system Involves specifying what the system should Involves specifying what the system should

do (from the point of view of outside the do (from the point of view of outside the system), independent of how that system system), independent of how that system should do itshould do it

A use case diagram is used to specify the A use case diagram is used to specify the desired behaviour or the requirements of a desired behaviour or the requirements of a systemsystem A requirement is a design feature, property or A requirement is a design feature, property or

behaviour of a systembehaviour of a system When a system’s requirements is stated, we are When a system’s requirements is stated, we are

asserting a contract between the things that lie asserting a contract between the things that lie outside the system and the system itselfoutside the system and the system itself

It declares what we expect the system to doIt declares what we expect the system to do A system’s functional requirements can be A system’s functional requirements can be

expressed as use cases, and the UML’s use case expressed as use cases, and the UML’s use case diagrams are essential for managing these diagrams are essential for managing these requirementsrequirements

Page 43: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

43

Perform card transaction

Process customer bill

Reconcile transactions

Manage customer account

Customer

Retail institution

Sponsoring financial

institution

Credit Card Validation SystemExample: -

Report on account status

Detect card fraud

Manage network outage

Page 44: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

44

To model the requirements of a system: -To model the requirements of a system: - Establish the context of the system by Establish the context of the system by

identifying the actors that surround itidentifying the actors that surround it For each actor, consider the behaviour that each For each actor, consider the behaviour that each

expects or requires the system to provideexpects or requires the system to provide Name these common behaviours as use casesName these common behaviours as use cases Factor common behaviour into new use cases Factor common behaviour into new use cases

that are used by others; factor variant behaviour that are used by others; factor variant behaviour into new use cases that extend more main line into new use cases that extend more main line flowsflows

Model these use cases, actors, and their Model these use cases, actors, and their relationships in a use case diagramrelationships in a use case diagram

Adorn these use cases with notes that assert Adorn these use cases with notes that assert non-functional requirements (if necessary)non-functional requirements (if necessary)

Page 45: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

45

Use Case Diagrams - Use Case Diagrams - SummarySummary

When you draw a use case in the UMLWhen you draw a use case in the UML Give it a name that communicates its Give it a name that communicates its

purposepurpose Show only those use cases that are important Show only those use cases that are important

to understand the behaviour of the system or to understand the behaviour of the system or the part of the system in its contextthe part of the system in its context

Show only those actors that relate to these Show only those actors that relate to these use casesuse cases

Try not to show too many kinds of Try not to show too many kinds of relationshipsrelationships

Page 46: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

Case Study: On-Case Study: On-Line BookstoreLine Bookstore

Page 47: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

47

On-line Bookstore is a web application that On-line Bookstore is a web application that can be accessed by the store’s registered can be accessed by the store’s registered customer, whereby each customer can order customer, whereby each customer can order books, review one or more books sold in the books, review one or more books sold in the book store, and sell used books to other book store, and sell used books to other customers. Before performing any one of customers. Before performing any one of these transactions, the customer must first these transactions, the customer must first log-in into the system using their user id and log-in into the system using their user id and password kept in their account. password kept in their account.

ProblemProblem: Draw the use-case diagram for the : Draw the use-case diagram for the above systemabove system

Page 48: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

48

The steps involved: -The steps involved: - Identify the actor : CUSTOMERIdentify the actor : CUSTOMER Identify the use case for the actor:Identify the use case for the actor:

CUSTOMERCUSTOMER REGISTERREGISTER LOG-INLOG-IN ORDER BOOKSORDER BOOKS CHECK OUTCHECK OUT REVIEW BOOKSREVIEW BOOKS SELL USED BOOKSSELL USED BOOKS

For each use case, determine include and For each use case, determine include and extend relationships, if anyextend relationships, if any

A Customer needs to log-in first before he/she can A Customer needs to log-in first before he/she can order books, check out, review books or sell used order books, check out, review books or sell used books: include relationshipbooks: include relationship

A Customer can proceed to check out after he/she A Customer can proceed to check out after he/she has ordered books: extend relationshiphas ordered books: extend relationship

Page 49: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

49

RegisterRegister

Order booksOrder books

Sell used Sell used booksbooks

Review booksReview books

CustomeCustomerr

On-line Bookstore On-line Bookstore SystemSystem

Log-inLog-in

<<include<<include>>>>

<<include<<include>>>>

<<include<<include>>>>

Check outCheck out<<extend<<extend

>>>>(CustID)(CustID)

Use Case Use Case Context Context

DiagramDiagram

Page 50: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

50

RegisterRegister

Order booksOrder books

Sell used Sell used booksbooks

Review booksReview books

CustomeCustomerr

On-line Bookstore On-line Bookstore SystemSystem

Log-inLog-in

<<include<<include>>>>

<<include<<include>>>>

<<include<<include>>>>

Check outCheck out<<extend<<extend

>>>>(CustID)(CustID)

Use Case Use Case Functional Functional

Requirements Requirements DiagramDiagram

Page 51: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

51

Use Use CaseCase

DescriptionDescription

RegisterRegister A new CUSTOMER needs to first register into the system A new CUSTOMER needs to first register into the system before performing any transaction.before performing any transaction.Actor/s: CUSTOMERActor/s: CUSTOMERPre-condition: An unregistered CUSTOMER.Pre-condition: An unregistered CUSTOMER.Main flow of events:Main flow of events:1. The CUSTOMER clicks the REGISTER button on the 1. The CUSTOMER clicks the REGISTER button on the Home Page.Home Page.2. The system displays the Register Page.2. The system displays the Register Page.3. The CUSTOMER enters all of the required 3. The CUSTOMER enters all of the required information.information.4. The CUSTOMER clicks the SEND button.4. The CUSTOMER clicks the SEND button.5. The system checks that all of the required information 5. The system checks that all of the required information were entered. If were entered. If yes, the system update the CUSTOMER’s record in the yes, the system update the CUSTOMER’s record in the CUSTOMER CUSTOMER and ACCOUNT tables in the database. System displays and ACCOUNT tables in the database. System displays OK message.OK message.Post-condition:Post-condition:The new CUSTOMER has registered. The ACCOUNT and The new CUSTOMER has registered. The ACCOUNT and CUSTOMER tables are updated.CUSTOMER tables are updated.

Log-inLog-in A CUSTOMER needs to log-in before performing any A CUSTOMER needs to log-in before performing any transactiontransactionActor/s: CUSTOMERActor/s: CUSTOMERPre-condition: A registered user.Pre-condition: A registered user.Main flow of events:Main flow of events:1. The CUSTOMER clicks the Log-in button on the Home 1. The CUSTOMER clicks the Log-in button on the Home Page.Page.

Page 52: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

52

Use CaseUse Case DescriptionDescriptionLog-inLog-in(continue(continue…)…)

2. The system displays the Log-in Page.2. The system displays the Log-in Page.3. The CUSTOMER enters his/her user ID and 3. The CUSTOMER enters his/her user ID and password.password.4. The CUSTOMER clicks the OK button.4. The CUSTOMER clicks the OK button.5. The system validates the log-in information against 5. The system validates the log-in information against the ACCOUNT the ACCOUNT table in the database.table in the database.6. CUSTOMER is an authorised user; the system 6. CUSTOMER is an authorised user; the system displays the Personal displays the Personal Home Page to the CUSTOMERHome Page to the CUSTOMERPost-condition:Post-condition:The CUSTOMER has been authorised to perform The CUSTOMER has been authorised to perform transactions.transactions.Alternate flow:Alternate flow:1. The CUSTOMER clicks the Log-in button on the 1. The CUSTOMER clicks the Log-in button on the Home Page.Home Page.2. The system displays the Log-in Page.2. The system displays the Log-in Page.3. The CUSTOMER enters his/her user ID and 3. The CUSTOMER enters his/her user ID and password.password.4. The CUSTOMER clicks the OK button.4. The CUSTOMER clicks the OK button.5. The system validates the log-in information against 5. The system validates the log-in information against the ACCOUNT the ACCOUNT table in the database.table in the database.6. CUSTOMER is not an authorised user; the system 6. CUSTOMER is not an authorised user; the system displays a pop-up message to inform the CUSTOMER.displays a pop-up message to inform the CUSTOMER.Post-condition:Post-condition:The CUSTOMER is not authorised to perform The CUSTOMER is not authorised to perform transactions.transactions.

Page 53: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

53

Use CaseUse Case DescriptionDescriptionOrder Order BooksBooks

A CUSTOMER can order books to purchase.A CUSTOMER can order books to purchase.Actor/s: CUSTOMERActor/s: CUSTOMERPre-condition: User have logged-in.Pre-condition: User have logged-in.Main flow of events:Main flow of events:1. The CUSTOMER enters the keyword for a book and 1. The CUSTOMER enters the keyword for a book and clicks the clicks the SEARCH button on the Personal Home Page.SEARCH button on the Personal Home Page.2. The system displays the matching books on the web 2. The system displays the matching books on the web Page.Page.3. The CUSTOMER chooses the desired book and 3. The CUSTOMER chooses the desired book and clicks the ADD TO clicks the ADD TO SHOPPING CART button on the web page. SHOPPING CART button on the web page. 4. The system adds the book into the CUSTOMER’s 4. The system adds the book into the CUSTOMER’s Order table Order table in the database. in the database. Post-condition:Post-condition:The ORDER table has been updated.The ORDER table has been updated.

Check Check OutOut

A CUSTOMER can purchase the books in his/her A CUSTOMER can purchase the books in his/her Shopping Cart.Shopping Cart.Actor/s: CUSTOMERActor/s: CUSTOMERPre-condition: The user have logged in and has at least Pre-condition: The user have logged in and has at least one book in the Shopping Cart. Main flow of events:one book in the Shopping Cart. Main flow of events:1. The CUSTOMER clicks the Check out button on the 1. The CUSTOMER clicks the Check out button on the Web Page.Web Page.

Page 54: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

54

Use CaseUse Case DescriptionDescriptionCheck Check OutOut(continue(continue…)…)

2. The system displays the books in the ORDER table of 2. The system displays the books in the ORDER table of the the CUSTOMER on the web Page.CUSTOMER on the web Page.3. The CUSTOMER checks the order list for any 3. The CUSTOMER checks the order list for any inconsistency. If inconsistency. If nothing found, CUSTOMER clicks the PROCEED nothing found, CUSTOMER clicks the PROCEED button. button. 4. The system displays the Invoice page.4. The system displays the Invoice page.5. The Customer enters the relevant credit card 5. The Customer enters the relevant credit card information and clicks information and clicks the OK button.the OK button.6. The system checks that the credit card is valid. Then, 6. The system checks that the credit card is valid. Then, the system the system displays the Delivery Details page.displays the Delivery Details page.7. The CUSTOMER chooses destination for delivery, 7. The CUSTOMER chooses destination for delivery, along with along with delivery options. Then, he/she clicks the PROCEED delivery options. Then, he/she clicks the PROCEED button. button. 8. The system will display the check-out information for 8. The system will display the check-out information for confirmation.confirmation.7. The CUSTOMER checks that all information is 7. The CUSTOMER checks that all information is correct and then correct and then clicks the OK button. clicks the OK button. 8. The system sends a confirmation via CUSTOMER’s e-8. The system sends a confirmation via CUSTOMER’s e-mail.mail.Post-condition:Post-condition:The ORDER table has been updated.The ORDER table has been updated.

Sell used Sell used booksbooks

A CUSTOMER can sell his/her used books.A CUSTOMER can sell his/her used books.Actor/s: CUSTOMERActor/s: CUSTOMERPre-condition: The user have logged-in..Pre-condition: The user have logged-in..

Page 55: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

55

Use CaseUse Case DescriptionDescriptionSell Used Sell Used BooksBooks(continue(continue…)…)

Main flow of events:Main flow of events:1. The CUSTOMER clicks the Sell Used Books button 1. The CUSTOMER clicks the Sell Used Books button on the Home on the Home Page.Page.2. The system displays the Sell used books web page.2. The system displays the Sell used books web page.3. The CUSTOMER enters the required information on 3. The CUSTOMER enters the required information on the used books the used books that he/she wants to sell. that he/she wants to sell. 4. The CUSTOMER clicks the SEND button on the 4. The CUSTOMER clicks the SEND button on the webpage.webpage.5. The system displays a confirmation page listing the 5. The system displays a confirmation page listing the information that information that the CUSTOMER has entered. the CUSTOMER has entered. 6. The CUSTOMER checks that the information 6. The CUSTOMER checks that the information displayed are accurate. displayed are accurate. If yes, the CUSTOMER clicks the OK button on the If yes, the CUSTOMER clicks the OK button on the web page.web page.7. The system updates the USED BOOKS table in the 7. The system updates the USED BOOKS table in the database. database. Post-condition:Post-condition:The Used Books table has been updated.The Used Books table has been updated.

Review Review BooksBooks

A CUSTOMER can review books.A CUSTOMER can review books.Actor/s: CUSTOMERActor/s: CUSTOMERPre-condition: User have logged-in..Pre-condition: User have logged-in..Main flow of events:Main flow of events:1. The CUSTOMER enters the keyword to search for a 1. The CUSTOMER enters the keyword to search for a book and then book and then clicks the SEARCH button on the Personal Web Page.clicks the SEARCH button on the Personal Web Page.

Page 56: Software Engineering Design & Modelling Capturing Requirements Using Use Cases

56

Use CaseUse Case DescriptionDescriptionReview Review BooksBooks(continue(continue…)…)

2. The system displays the matching books on the web 2. The system displays the matching books on the web Page.Page.3. The CUSTOMER checks for the desired book and 3. The CUSTOMER checks for the desired book and clicks on the chosen book icon. clicks on the chosen book icon. 4. The system displays the book’s detail in the Book 4. The system displays the book’s detail in the Book Detail web page.Detail web page.5. The CUSTOMER clicks the REVIEW button on the 5. The CUSTOMER clicks the REVIEW button on the web page.web page.6. The system displays the Review Book web page.6. The system displays the Review Book web page.7. The CUSTOMER clicks on the desired star button 7. The CUSTOMER clicks on the desired star button and the click the and the click the OK button on the web page.OK button on the web page.8. The system calculates the overall rating of the book 8. The system calculates the overall rating of the book and updates the and updates the Book table in the database.Book table in the database.9. The system displays the Book Detail web pages that 9. The system displays the Book Detail web pages that have been have been updated. updated. Post-condition:Post-condition:The BOOK and REVIEW tables are updated.The BOOK and REVIEW tables are updated.