lectures uml diagrams

8/12/2019 Lectures UML Diagrams

1/37

UML Modeling and

Requirement Analysis

1


2/37

EXERCISE


3/37

2. Draw a use case diagram for an ATM

system. Also write Use Case specification

tables for each use case (At least 4 use

cases).

1. Is Use Case diagram a part of UML

Modeling? (YES/No)

You have 35 minutes.


4/37

How are design ideas communicatedin a team environment?

If the software is large scale, employing perhaps dozens ofdevelopers over several years, it is important that all members of thedevelopment team communicateusing a common language.

This isnt meant to imply that they all need to be fluent in EnglishorC++,but it does mean that they need to be able to describe theirsoftwares operation and design to another person.

That is, the ideas in the head of say the analysthave to be conveyedto the designerin some way so that he/she can implement that ideain code.

Just as mathematicians use algebra and electronics engineers haveevolved circuit notation and theory to describe their ideas, software

engineers have evolved their own notation for describing thearchitecture and behaviour of software system.

That notation is called UML. The Unified Modelling Language. Somemight prefer the title Universal Modelling language since it can beused to model many things besides software.


5/37

What is UML ?

UML is not a language in the same way that we view programminglanguages such as C++, Java or Basic.

UML is however a language in the sense that it has syntaxand semanticswhich convey meaning, understanding and constraints (i.e. what is rightandwrongand the limitations of those decisions) to the reader and therebyallows two people fluent in that language to communicate and understandthe intention of the other.

UML represents a collection of 13essentially graphical(i.e. drawing)

notations supplemented by textual descriptions designed to capturerequirementsand design alternatives. You dont have to use them all, youjust chose the ones that capture important information about the systemyou are working on.

UML is to software engineers what building plans are to an architect and anelectrical circuit diagrams is to an electrician.

Note: UML does not work well for small projects or projects where just afew developers are involved. If you attempt to use it in this environment itwill seem more of a burden than an aid, but then it was never intended forthat. It works best for very complex systems involving dozens of developersover a long period of time where it is impossible for one or two people to

maintain the structure of the software in their head as they develop it.


6/37

What are the 7 mos t important diagramtypes?

Use Case Diagrams: A simple but very effective model used during the analysis phasefor

analysing requirementsthrough the process of exploring user

interactionswith the system.

The process involves documenting

Who initiatesan interaction, What information goes intothe system, What information comes outand

What the measurable benefitis to the user who initiatesthe interaction (i.e. what they get out of it).

Requirements analysis attempts to uncover and document theservicesthe system provides to the user.


7/37

Example Use-case Diagram for a student


8/37

Class Diagrams:

A powerful tool for exploring architecture, functionalityand

relationshipsbetween objects in our system (i.e. instances of

classes).

Example Class

Diagram


9/37

Sequence and Communication (Collaboration) Diagrams:

These two diagrams model the interaction of a set ofcollaborating objects through a process of message passingasthey attempt to achieve the functionality expressed in one ormore use cases.

In essence they model the behaviourof our system in responseto inputs from the external world.

Example Sequence

Diagram


10/37

State Charts: An extension of state transition diagrams.

Model the time dependent behaviourof objects or systems

in response to messages sent to it over a period of time.StateState Transition

following an event

Terminating State

Starting

State


11/37

Activity Diagrams. Used during analysis to explore areas of parallelismor

concurrencyin the customer business model.

Useful in areas of business systems modelling where manyprocesses or activities within the business are carried out in

parallel, e.g. simultaneously raising an invoicewhile at thesame time producing a delivery noteand shipping the goodsor order.

Gives an indication to the designer of things that happen inparalleland things that happen in sequence.

A bit like a flowchart but with parallelismand synchronisationbuilt in.

Can be useful in modelling concurrent processes/threads


12/37

Deployment Diagrams:

Deployment diagrams show how complex software will be

deployed across a complex distribution of computers and

networks, and probably have the weakest syntaxof all thediagram types (i.e. almost anything goes)

They are essentially a sketch of the systems physical

architecturee.g. computers, disk drives, GUIs, databases,

hardware interfaces, networks, programs running onsystem X and Y.

(see http://www.agilemodeling.com/essays/umlDiagrams.htm)
http://www.agilemodeling.com/essays/umlDiagrams.htmhttp://www.agilemodeling.com/essays/umlDiagrams.htm


13/37

Object Oriented Analysis and the Role of Domain Exper ts

During the early stages of any project development, much ofyour time will be spent in the analysis phase, attempting tounderstand whatthe system must do and how it interactswith the real world.

That is, what interfaces, functionalityand behaviourthesystem should provide for your customer.

Such analysis is often conducted in the presence of one ormore domain experts, i.e. somebody who is intimatelyfamiliar with the business processor procedures that you are

trying to automate (i.e. the problem domain) and can describethem to somebody else, often in a non-technical way.

In simple terms, a domain expertis somebody whounderstands or knows how to do the jobbefore it has beenautomated.


14/37

Example Domain Experts An accountant, could be considered to be a domain expertin the

sense that he/she knows intimately the procedures, forms, rulesand regulationsto be followed when dealing with the RevenueCanada.

Likewise,Architectsand Electriciansare domain experts when it

comes to obtaining advice on building and planning regulationsand electrical installations.

In a much simpler vein, Marysat at a supermarket checkout, orFredassembling enginesfor Toyota are also domain expertssince their experiencemakes them uniquely qualified tocomment on the processes involved.

In fact Mary and Fred's experience makes them especiallyuseful, since they may well have evolved new tips-and-techniquesfor getting the job done that may only exist insidetheir head (as opposed to a procedures manual) and as such, itis very important to get them working with you.


15/37

Use Cases

Concepts, Specifications, and Diagrams


16/37

Introduction

Invented by Ivar Jacobson in the late1960s (where have we seen his namebefore?)

Introduced to the OO community in the late

1980sAlistair Cockburn has extended Jacobsons

model

Is a way to specify functional requirements

Is notated using a use case specification

Is not part of the Unified ModelingLanguage (UML), but is many times used

in conjunction with it 16


17/37

What is a Use Case? (Cockburn)

A use case captures a contract between the

stakeholdersof a system about its behavior.

Describes the systems behavior under variousconditions as the system responds to a request from oneof the stakeholders called the primary actor.

1. The primary actor initiates some interaction with the system toaccomplish some goal.

2. The system responds,protecting the interests of all of thestakeholders.

3. Different sequences of behaviors, or scenarios,can unfold,depending on the requests and the conditions surrounding therequest. The use case gathers these scenarios together.

17


18/37

Use Case Specification: Natural Language Example

Use Case 1. Withdraw Money

The system displays the account types available to

be withdrawn from and the user indicates the

desired type. The system asks for the amount to bewithdrawn and the user specifies it. Next, the

system debits the users account and dispenses

the money. The user removes the money, the

system prints a receipt, and the user removes the

receipt. Then the system displays a closing

message and dispenses the users ATM card. After

the user removes his card, the system displays the

welcome message.

CMSC 345, Version 9/07S. Mitchell 18


19/37

19

Number

Name

Summary

Priority

Preconditions

Postconditions

Primary Actor(s)

Secondary Actor(s)

Trigger

Main Scenario Step Action

Extensions Step Branching Action

Open Issues

Use Case Specification Template*

*Adapted from A. Cockburn, Basic Use Case Template


20/37

20

Number Unique use case number

Name Brief verb-noun phrase

Summary Brief summary of use case major actions

Priority 1-5 (1 = lowest priority, 5 = highest priority)

Preconditions

Postconditions

Primary Actor(s)

Secondary Actor(s)

Trigger



Open Issues




21/37

21

Number

Name

Summary

Priority

Preconditions What needs to be true before the use case executes

Postconditions What will be true after the use case successfully executes

Primary Actor(s)

Secondary Actor(s)

Trigger



Open Issues



Precondition: y != 0

Postcondition: x / y

double divide(double x, double y) {

return (x / y);

}

Precondition: None

Postcondition: if y==0 Illegal, else x / y

double divide(double x, double y) {

if (y == 0) cout


22/37

22

Number

Name

Summary

Priority

Preconditions

Postconditions

Primary Actor(s) Primary actor name(s)

Secondary Actor(s) Secondary actor name(s)

Trigger



Open Issues



Actor

Anyone or anything with behavior

May be a person or system

Primary: The stakeholder who orwhich initiates an interaction with the

system to achieve a goal. Is generally a

category of individuals (a role).

Secondary: Provides a service to the

system. Is almost never a person.


23/37

23

Number

Name

Summary

Priority

Preconditions

Postconditions

Primary Actor(s)

Secondary Actor(s)

Trigger The action that caused the use case to be invoked


Step # This is the main success scenario or happy path

Step # Description of steps in successful use caseexecutionStep # This should be in a system-user-system, etc. format


Open Issues




24/37

24

Number

Name

Summary

Priority

Preconditions

Postconditions

Primary Actor(s)

Secondary Actor(s)

Trigger



Step # Alternative paths that the use case may take

Open Issues



Extension

Could be an optional path(s)

Could be an error path(s)

Denoted in use case diagrams (UML)

by


25/37

25

Number

Name

Summary

Priority

Preconditions

Postconditions

Primary Actor(s)

Secondary Actor(s)

Trigger



Open Issues Issue # Issues regarding the use case that need resolution




26/37

26

Number Unique use case number

Name Brief noun-verb phrase

Summary Brief summary of use case major actions

Priority 1-5 (1 = lowest priority, 5 = highest priority)

Preconditions What needs to be true before use case executes

Postconditions What will be true after the use case successfully executes

Primary Actor(s) Primary actor name(s)

Secondary Actor(s) Secondary actor name(s)

Trigger The action that causes this use case to begin


Step # This is the main success scenario or happy path.

Description of steps in successful use caseexecution This should be in a system-user-system, etc. format.


Step # Alternative paths that the use case may take

Open Issues Issue # Issues regarding the use case that need resolution




27/37

Number 1

Name Withdraw Money

Summary User withdraws money from one of his/her accounts

Priority 5

Preconditions User has logged into ATM

Postconditions User has withdrawn money and received a receipt

Primary Actor(s) Bank Customer

Secondary Actor(s) Customer Accounts Database

27

Use Case Specification Template Example

Continued


28/37

28

Trigger User has chosen to withdraw money


1 System displays account types

2 User chooses account type

3 System asks for amount to withdraw

4 User enters amount

5 System debits users account and dispenses money

6 User removes money

7 System prints and dispenses receipt

8 User removes receipt

9 System displays closing message and dispenses users ATM card

11 User removes card

10 System displays welcome message


5a System notifies user that account funds are insufficient

5b System gives current account balance

5c System exits option

Open Issues 1 Should the system ask if the user wants to see the balance?


29/37

Specification Writing

Guidelines No trace of design

Describes what the use case will do,

nothow it will do it (e.g., UI type is

irrelevant)A dialogue between the user and the

system

Complete, clear, and consistent

29


30/37

Use Case Diagrams

A way of visualizing the relationships between actors and use cases

among use cases

A graphical table of contents for the

use case set (Fowler)

30


31/37

31

1

Withdraw

Money

2

Deposit

Money

3

Transfer

Money

4

Check

Balance

ATM System

Bank

Customer

Customer

Accounts

Database

primary actor

role

systemnamesystemboundary

secondaryactor

use case

alternative

actor notation

stereotype

association


32/37

Using Use Case Specifications

in Conjunction with Use Case Diagrams

UML is a graphical modeling tool only.

Use case specifications are not part of

the UML But, since each ellipse in a UML use

case diagram represents a functional

requirement, it may in turn have an

associated use case specification.

32


33/37

33

1

Withdraw

Money

2

Deposit

Money

3

Transfer

Money

4

Check

Balance

ATM System

Bank

Customer

Customer

Accounts

Database

Teller 5

View

Transaction

Historyprimary actor

Why cant a Teller

do the things that a

Bank Customer can

do? Especially if heisa customer?

He can. But he must

step into the role of

a Bank Customer.


34/37

34

1

Withdraw

Money

Bank

Customer

Customer

Accounts

Database

1b

Withdraw from

Savings

1a

Withdraw from

Checking

Sub-use Case Diagram

This is an extenddependency.

It indicates that use case 1b is part of

use case 1, but it may or may not be

invoked.

The same is true of use case 1a.

All dependencies are

extend unless

stereotyped otherwise.

note/comment


35/37

35

1

Withdraw

Money

Bank

Customer

Customer

Accounts

Database

1b

Withdraw from

Savings

1a

Withdraw from

Checking


generalization


36/37

36

3

Transfer

Money

Bank

Customer

Customer

Accounts

Database

3b

Update Account

Balances

3a

Select

Accounts


This is an include dependency.

It indicates that use case 3b is

included in use case 3 and will be

invoked.

The same is true of use case 3a.

http://www.karonaconsulting.com/downloads/UseCases_IncludesAndExtends.pdf


37/37

References

Cockburn, A., Writing Effective Use Cases. NewYork: 2001, Addison-Wesley.

Cockburn, A., Resources for Writing Use Cases.http://alistair.cockburn.us/index.php/Resources_for

_writing_use_cases, accessed 9/18/07.

Cockburn, A., Basic Use Case Template. 1998,Humans and Technology.

Cockburn, Alistair, WWW home page,http://alistair.cockburn.us/index.php/Main_Page

Fowler, M., UML Distilled. 3rded. 2004, New York:

Addison Wesley. Fowler, M., WWW home page,

http://martinfowler.com

Jacobson, Ivar, WWW home page,http://www.ivarjacobson.com/locales/ivars-

f

lectures uml diagrams

Documents