UML Modeling and Requirement Analysis

EXERCISE

1. Is Use Case diagram a part of UML Modeling? (YES/No)

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).
You have 35 minutes.

How are design ideas communicated in a team environment?

If the software is large scale, employing perhaps dozens of developers over several years, it is important that all members of the development team communicate using a common language.

This isnt meant to imply that they all need to be fluent in English or C++, but it does mean that they need to be able to describe their softwares operation and design to another person.
That is, the ideas in the head of say the analyst have to be conveyed to the designer in some way so that he/she can implement that idea in code. Just as mathematicians use algebra and electronics engineers have evolved circuit notation and theory to describe their ideas, software engineers have evolved their own notation for describing the architecture and behaviour of software system. That notation is called UML. The Unified Modelling Language. Some might prefer the title Universal Modelling language since it can be used to model many things besides software.

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

UML is however a language in the sense that it has syntax and semantics which convey meaning, understanding and constraints (i.e. what is right and wrong and the limitations of those decisions) to the reader and thereby allows two people fluent in that language to communicate and understand the intention of the other. UML represents a collection of 13 essentially graphical (i.e. drawing) notations supplemented by textual descriptions designed to capture requirements and design alternatives. You dont have to use them all, you just chose the ones that capture important information about the system you are working on. UML is to software engineers what building plans are to an architect and an electrical circuit diagrams is to an electrician. Note: UML does not work well for small projects or projects where just a few developers are involved. If you attempt to use it in this environment it will seem more of a burden than an aid, but then it was never intended for that. It works best for very complex systems involving dozens of developers over 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.

What are the 7 most important diagram types?

Use Case Diagrams:

A simple but very effective model used during the analysis phase for analysing requirements through the process of exploring user interactions with the system.

The process involves documenting

Who initiates an interaction, What information goes into the system, What information comes out and What the measurable benefit is to the user who initiates the interaction (i.e. what they get out of it).

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

Example Use-case Diagram for a student

Class Diagrams:
A powerful tool for exploring architecture, functionality and relationships between objects in our system (i.e. instances of classes).

Example Class Diagram

Sequence and Communication (Collaboration) Diagrams: These two diagrams model the interaction of a set of collaborating objects through a process of message passing as they attempt to achieve the functionality expressed in one or more use cases.
In essence they model the behaviour of our system in response to inputs from the external world.

Example Sequence Diagram

State Charts:
An extension of state transition diagrams. Model the time dependent behaviour of objects or systems State Transition in response to messages sent to it over a following period of time. an event

State

Starting State

Terminating State

Activity Diagrams.
Used during analysis to explore areas of parallelism or concurrency in the customer business model. Useful in areas of business systems modelling where many processes or activities within the business are carried out in parallel, e.g. simultaneously raising an invoice while at the same time producing a delivery note and shipping the goods or order. Gives an indication to the designer of things that happen in parallel and things that happen in sequence.

A bit like a flowchart but with parallelism and synchronisation built in.
Can be useful in modelling concurrent processes/threads

Deployment Diagrams:
Deployment diagrams show how complex software will be deployed across a complex distribution of computers and networks, and probably have the weakest syntax of all the diagram types (i.e. almost anything goes) They are essentially a sketch of the systems physical architecture e.g. computers, disk drives, GUIs, databases, hardware interfaces, networks, programs running on system X and Y.

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

Object Oriented Analysis and the Role of Domain Experts

During the early stages of any project development, much of your time will be spent in the analysis phase, attempting to understand what the system must do and how it interacts with the real world.
That is, what interfaces, functionality and behaviour the system should provide for your customer. Such analysis is often conducted in the presence of one or more domain experts, i.e. somebody who is intimately familiar with the business process or procedures that you are trying to automate (i.e. the problem domain) and can describe them to somebody else, often in a non-technical way. In simple terms, a domain expert is somebody who understands or knows how to do the job before it has been automated.

Example Domain Experts An accountant, could be considered to be a domain expert in the sense that he/she knows intimately the procedures, forms, rules and regulations to be followed when dealing with the Revenue Canada.

Likewise, Architects and Electricians are domain experts when it comes to obtaining advice on building and planning regulations and electrical installations. In a much simpler vein, Mary sat at a supermarket checkout, or Fred assembling engines for Toyota are also domain experts since their experience makes them uniquely qualified to comment on the processes involved.

In fact Mary and Fred's experience makes them especially useful, since they may well have evolved new tips-andtechniques for getting the job done that may only exist inside their head (as opposed to a procedures manual) and as such, it is very important to get them working with you.

Use Cases
Concepts, Specifications, and Diagrams

Introduction

Invented by Ivar Jacobson in the late 1960s (where have we seen his name before?) Introduced to the OO community in the late 1980s Alistair 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 Modeling Language (UML), but is many times used in conjunction with it
16

What is a Use Case? (Cockburn)

A use case captures a contract between the stakeholders of a system about its behavior.

Describes the systems behavior under various conditions as the system responds to a request from one of the stakeholders called the primary actor.
1. The primary actor initiates some interaction with the system to accomplish some goal. 2. The system responds, protecting the interests of all of the stakeholders. 3. Different sequences of behaviors, or scenarios, can unfold, depending on the requests and the conditions surrounding the request. The use case gathers these scenarios together.

17

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 be withdrawn 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/07 S. Mitchell 18

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action

Extensions
Open Issues

Step

Branching Action

*Adapted from A. Cockburn, Basic Use Case Template

19

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action Unique use case number Brief verb-noun phrase Brief summary of use case major actions 1-5 (1 = lowest priority, 5 = highest priority)

Extensions
Open Issues

Step

Branching Action

*Adapted from A. Cockburn, Basic Use Case Template

20

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Precondition: y != 0 What needs to be true before the use case executes What will be true after the use case successfully executes

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

Step Action

Postcondition: x / y double divide(double x, double y) { return (x / y); }

Extensions
Open Issues Main Scenario

Trigger

double divide(double x, double y) { if (y == 0) cout << Illegal\n; else return (x / y);

Step

Branching } Action

*Adapted from A. Cockburn, Basic Use Case Template

21

Actor

Use Case Specification Template* Anyone or anything with behavior

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action Primary actor name(s) Secondary actor name(s)

May be a person or system Primary: The stakeholder who or which 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.

Extensions
Open Issues

Step

Branching Action

*Adapted from A. Cockburn, Basic Use Case Template

22

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario The action that caused the use case to be invoked Step Step # Step # Step # Action This is the main success scenario or happy path Description of steps in successful use case execution This should be in a system-user-system, etc. format

Extensions
Open Issues

Step

Branching Action

*Adapted from A. Cockburn, Basic Use Case Template

23

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action

Extension Could be an optional path(s) Could be an error path(s) Denoted in use case diagrams (UML) by <<extend>>

Extensions
Open Issues

Step
Step #

Branching Action
Alternative paths that the use case may take

*Adapted from A. Cockburn, Basic Use Case Template

24

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Step Action

Extensions
Open Issues

Step
Issue #

Branching Action
Issues regarding the use case that need resolution
*Adapted from A. Cockburn, Basic Use Case Template
25

Use Case Specification Template*

Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main Scenario Unique use case number Brief noun-verb phrase Brief summary of use case major actions 1-5 (1 = lowest priority, 5 = highest priority) What needs to be true before use case executes What will be true after the use case successfully executes Primary actor name(s) Secondary actor name(s) The action that causes this use case to begin Step Step # Action This is the main success scenario or happy path. Description of steps in successful use case execution This should be in a system-user-system, etc. format.

Extensions
Open Issues

Step
Step # Issue #

Branching Action
Alternative paths that the use case may take Issues regarding the use case that need resolution
*Adapted from A. Cockburn, Basic Use Case Template
26

Use Case Specification Template Example

Number Name Summary

1 Withdraw Money User withdraws money from one of his/her accounts

Priority
Preconditions Postconditions Primary Actor(s) Secondary Actor(s)

5
User has logged into ATM User has withdrawn money and received a receipt Bank Customer Customer Accounts Database

Continued

27

Trigger Main Scenario

User has chosen to withdraw money Step 1 2 3 4 5 Action System displays account types User chooses account type System asks for amount to withdraw User enters amount System debits users account and dispenses money

6
7 8 9 11 10 Extensions Step 5a 5b 5c Open Issues 1

User removes money

System prints and dispenses receipt User removes receipt System displays closing message and dispenses users ATM card User removes card System displays welcome message Branching Action System notifies user that account funds are insufficient System gives current account balance System exits option Should the system ask if the user wants to see the balance?
28

Specification Writing Guidelines

No trace of design Describes what the use case will do, not how it will do it (e.g., UI type is irrelevant) A dialogue between the user and the system Complete, clear, and consistent

29

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

system name

ATM System
primary actor 1 Withdraw Money

system boundary

secondary actor

Bank Customer

2 Deposit Money

role association

3 Transfer Money

Customer Accounts Database

use case

4 Check Balance

<<Customer Accounts Database>> alternative actor notation stereotype

31

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

ATM System
1 Withdraw Money 2 Deposit Money Bank Customer 3 Transfer Money 4 Check Balance Teller primary actor 5 View Transaction History

Why cant a Teller do the things that a Bank Customer can do? Especially if he is a customer?

Customer Accounts Database

He can. But he must step into the role of a Bank Customer.

33

Sub-use Case Diagram

1a Withdraw from Checking

<<extend>> 1 Withdraw Money Bank Customer <<extend>>

1b Withdraw from Savings

This is an extend dependency. It indicates that use case 1b is part of use case 1, but it may or may not be All dependencies are note/comment invoked. extend unless
stereotyped otherwise.

Customer Accounts Database

The same is true of use case 1a.

34

Sub-use Case Diagram

1a Withdraw from Checking 1 Withdraw Money Bank Customer 1b Withdraw from Savings generalization

Customer Accounts Database

35

Sub-use Case Diagram

3a Select Accounts

<<include>> 3 Transfer Money Bank Customer <<include>>

3b Update Account Balances

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.

Customer Accounts Database

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

36

References
Cockburn, A., Writing Effective Use Cases. New York: 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. 3rd ed. 2004, New York: Addison Wesley. Fowler, M., WWW home page, http://martinfowler.com Jacobson, Ivar, WWW home page, http://www.ivarjacobson.com/locales/ivarscorner.cfm 37