Modeling and Systems Development Lecture 7

Functional Modeling Activity diagrams and use cases

Context of analysis • Recall the Systems Development Life Cycle (SDLC): – – – –

Planning Analysis Design Implementation

• Analysis: – requirements determination – functional modeling – structural modeling – behavioral modeling

2

Business process modeling • Activity diagrams: useful at several levels: – BPM – modeling details of a single use-case – modeling details of a single method

3

Example activity diagram initial node

decision node

action control flow

Also useful in BPM are swim lanes where activities are assigned to separate entities (see next slide)

merge node

object flow 4

Example swim lanes

from: Unified Modeling Language: Superstructure - version 2.1.1

5

Compare with flowcharts Inkoop, onderdeel Bestelproces Medewerker

iemand wil een nieuw product of dienst bestellen

Verder zullen we onder product ook dienst verstaan!

momenteel is dit altijd zo, behalve bij doorvekoop

toestemming van dir. vereist?

ja nee

Directie

dien verzoek in bij directie

is prod. noodzakelijk?

nee

wordt afgewezen

ja bepaal leverancier (uit lijst van favoriete leveranciers)

wordt toegestaan

einde Inkoop

plaats bestelling (via tel., fysiek of digitaal)

Legenda

vraag orderbevestiging

berg orderbevestiging op

ja

orderbevestiging mogelijk?

start of einde:

connector tussen opeenvolgende elementen:

processtap:

commentaar:

nee is sprake van doorvekoop?

ja

vul inkoopformulier in

berg inkoopformulier op

nee

einde Bestelproces

opvolgend proces: ontvangst van product

beslissing:

6

Use cases • A use case represents the interaction of the system with its environment • A use case should result in an observable result • Often a use case describes the external view of a business process

7

History of use cases • Originally called ‘usage scenarios’ and invented by Ivar Jacobson in 1967 • Improved in mid-1980’s by Jacobson • Added: concepts of Stakeholders and Interests by Cockburn • Use-cases are part of the UML

8

Use case terminology • Actor – role played by a person (or another system) interacting with the system under development

• Primary actor – actor that triggers a use-case

• Note that use-cases and actors are like classes, not like objects • Note that one actor may correspond to many people, and that one person may correspond to many actors 9

Use case relationships • Extend relationship: extension of the functionality of the use case to incorporate optional behavior. E.g. Destroy card is an extension of the ATM use case, used only when three wrong PIN codes are given. • Include relationship: mandatory inclusion of another use case. Used for functional decomposition, to break up a complex use case into several simpler ones. • Generalization relationship: supports inheritance, to place several use cases with a number of common properties under a unifying label. 10

Types of use cases • Overview use case e.g.: – make, change or cancel an appointment

• Detail use case (see next 2 slides) • Essential use case versus real use case : – an essential use-case is implementation independent, while a real use-case depends on implementation details (e.g. “click a radio button” as a way of making a choice)

11

Use case description • Overview information – name, ID, type, primary actor, brief description, importance level

• Relationships – association, extend, include, generalization

• Flow of events – normal flow of events – subflows – alternate or exceptional flows 12

Use case description: example Use-Case Name:

Make appointment ID:

Importance Level: high

Primary Actor:

patient

detail, essential

Stakeholders and interests:

Use-Case Type:

patient; doctor

Brief Description:

Patient makes, changes or cancels an appointment

Trigger:

patient calls

Relationships:

Normal Flow of Events: Subflows: (e.g.) Cancel appointment Alternate/Exceptional Flows: Create new patient (extends current use-case) 13

Normal flow of events 1. 2. 3. 4.

Patient contacts office regarding an appointment Patient provides receptionist with name/address Receptionist validates patient is in database (!) Receptionist executes use-case Make Payment Arrangements (here is an include relationship) 5. Receptionist asks patient: “new/change/cancel appointment?” and performs relevant subflow 6. Receptionist provides results to patient 14

Inheritance of use-cases • Is less common than include • May be used when e.g. “making an emergency appointment” would result in the definition of several alternate flows • When used, completely replace one or more of the flows (normal or alternate)

15

Guidelines for creating use case descriptions • Guidelines are mainly for the steps making up the flow of events., e.g. – Receptionist validates patient is in database • “Receptionist” is the initiator • general form of a step (SVDPI): – opt. followed by – 16

Guidelines for creating use case descriptions • Clarify initiator and receivers of actions (“who has the ball”) • Write from the perspective of an independent observer • Write the steps at the same level of abstraction • Apply the KISS principle

17

Use case diagrams multiplicity actor

association use-case system boundary 18

19

Syntactical corrections Make payment arrangements



Make old patient appt.

Make appointment

Make new patient appt.



Update patient info

Create new patient

20

Major steps in use case analysis • • • •

Identify the major use cases Expand the major use cases Confirm the major use cases Create the use case diagram

21

Identifying the major use cases • • • •

Find the system’s boundaries List the primary actors List the goals of the primary actors Identify and write the overview of the major use-cases • Carefully review the current use-cases

22

Tomtom 910 main menu

23

24

Expanding the major use cases • • • • • •

Choose one major use-case to expand Fill in details on the use-case template Fill in the steps of the normal flow of events Ensure the steps are not too complex Identify alternate or exceptional flows Fill in the steps of the alternate or exceptional flow 25

Confirming the major use cases • Review the current set • Iterate the entire set of steps until a – Consider semantics and syntax sufficient number of – Involve the users use cases are – Decompose and merge defined to proceed use-cases to the identification – Organize them (include of classes and extend relations)

26

Creating the use case diagram • • • •

Start with system boundary Place use-cases on the diagram Place actors on the diagram Draw associations between actors and the relevant use-cases

27

Weaknesses of use cases •

Trap1: getting lost in details; either – Trap 1a: too many use-cases; solution: cluster the use-cases in a logical way and restrict their number; or – Trap 1b: too many steps within a use-case solution: focus on main success scenario; or – Trap 1c: including user interface specifics solution: write technologically neutral, e.g. "System presents the options. User selects an activity." 28

Weaknesses of use-cases • Trap2: spend a lot of time on diagrams solution: – focus on textual description – don’t get into discussions on inherit or extend relationships between use cases in diagrams

29

Strengths of use cases • Drive the development process: – from requirements gathering to testing – easy to communicate with users

• Can be used semi-formally • Power – use the main scenario to get a quick overview – use alternative behaviors to get a complete system 30

Use case points • Similar in spirit to function points • Meant to be applied in object-oriented development • based upon – set of essential use-cases – use-case diagram

31

Use case points • Classify use-cases and actors (from u.c. diagram) as: simple, average, complex • E.g. an actor is average if it’s a separate system and interaction is via standard protocols (e.g. FTP) • The complexity of a use case depends on #transactions (e.g. cancelling an appointment) 32

Use case points • Use case points: obtained from Actor weight and Use case weight • Adjusting based on – technical complexity – environment

• Effort in hours = adjusted u.c. points × 20 33