Você está na página 1de 107

Introduction to UML

Objective
UML Concepts
– To learn UML concepts
– To be able to understand and review UML
artefacts
– UML and Use Case Analysis
The Audience

UML

•Familiarity with OOT I was better off earlier...


•UML
•Knowledge of at least one
OO language •UML diagrams
•Understand and review
Contents
– Introduction to UML
– Class Relationships
– UML Views
– Use Case View
– Static View
– Physical View
– Interaction View
– State Machine View
– Activity View
– Extensibility Mechanisms in UML
– Miscellaneous
Introduction to UML
Object Oriented Technology
Implementation methodology wherein:
•Programs are organised as co-operative collections of objects
•Each of these objects is an instance of some class
•Classes are member of some hierarchy united by inheritance
relationship

Requirements The System


OOA OOD OOP

Design methodology that includes:


Analyse the requirements in terms •Object oriented decomposition of the
of objects and classes which may system
be found in the vocabulary of •Notation to capture logical and physical
problem domain and also static and dynamic models of the
system under design
Introduction to UML
Modelling
– Analysis
• What is to be done? What are the building blocks?
• Accomplished by discovering objects and classes in
problem domain
– Design
• How is it to be done? How the building blocks are put
together?
• Realised by creating a software architecture,
capturing structure and behaviour of the system
– Model
• A model is a representation in a certain medium of
something in the same or some other medium
Introduction to UML
Modelling
– Why model?
• Models help us to understand the working of a
system; before actually building it
• Models permit us to specify structure and or
behaviour of a system
• Models provide a template, which guides in
constructing the system
• Models document the decision made about the system
structure and behaviour
• Models can be used to create other related work
products
• Simplification of the system; capture 60% of the
system
Introduction to UML
Modelling
– Elements of a model

notation

The Success Triangle

process tool

 Notation
– Iconic language used for expressing each element of a system
 Process
– Activities leading to orderly construction of the system
 Tool
– Automated support to assist process of analysis and design
Introduction to UML
Modelling
– Some tools
• Rational Rose
• System Architect
• GDPro
• Master Craft
• Object Analyst
• Together J
Introduction to UML
What is UML?
– A modelling language, mainly consisting of
graphical notations that OO methods use to
express designs
– A visual language used to specify, visualise,
construct and document details of a software
system
– Used to capture decisions and understandings
of a software system to be constructed
– Used to establish a common language among
analyst / designers and developers
Introduction to UML
Building blocks of UML
– Things
• Icons or visual symbols representing things in a
software system
– Relationships
• Relationship among the things of a software system
– Diagrams
• Meaningful combination of things and relationships
– Extensibility mechanisms
• Extend UML vocabulary in a controlled manner
Introduction to UML
Things

An Actor
Component
A Component
Actor

A Use Case Device A device


Use Case

className
attribute1 A Class Package
A Package
f1()

object Note
An Object A note
Introduction to UML
UML Diagrams

1. Class diagram
2. Object diagram
Capture the structure
3. Component diagram
4. Deployment diagram

5. Use Case diagram


6. Sequence diagram
7. Collaboration diagram Capture the behaviour
8. State transition diagram
9. Activity diagram

Each UML diagram captures a model of the system


Introduction to UML
UML Diagrams
– Class diagram
• Represents the static structure in terms of classes and
their relationships
– Object diagram
• Represents objects and their relationships; snapshot
of a running system
– Component diagram
• Shows physical components of a system, e.g. EXE,
DLL, JAR
– Deployment diagram
• Represents deployment of components of a system on
specific pieces of hardware
Introduction to UML
UML Diagrams
– Use Case diagram
• Represents services of a system from user’s point of
view
– Sequence diagram
• A transitory representation of objects and their
interactions
– Collaboration diagram
• A spatial representation of objects, links and
interactions
– State transition diagram
• Behaviour of an object in terms of its state changes
– Activity diagram
• Behaviour of an operation as a set of actions
Class Relationships in UML
Class Relationships
– Relationship among objects of a system and
how they should interact is determined by the
relationship among their respective classes

C ?
A
? B
D

C
D
A B
Class Relationships in UML
Different Class Relationships
– Association
– Aggregation Structural

– Composition

– Dependency Using

– Inheritance Sharing

– Realises Implementing
Class Relationships in UML
Association
– Classes should share association relationship, if
their objects:
• Should be capable of sending messages to each other
• Should be able to invoke each other’s member
functions
– A “glue” that holds together (classes of) a
system
• Without association, we have only set of unconnected
classes
– Association relationship is manifested in the
exchange of messages among instances of
associated classes
Class Relationships in UML
Association
– At analysis stage:
• Association represents logical relationship among
objects
• The directionality of association is of no great
important
• One need not worry about the implementation
– At design stage:
• Association captures design decision of data
structures and separation of responsibilities among
classes
• The directionality of association is important
• Navigable association at design stage represents state
information (of associated class) available to the class
• Implementation need not be equated to direct
pointers or references
Class Relationships in UML
Association

B
- m _ iC o u n t : in t

+ B ()
-m _ p B + C re a t e ()
1 + G e t A ()
+ G e t C o u n t O f C ()

0 ..1 1

-m _ d w C 10

-m _ d w A 10 C
- m _ iC o u n t : in t
A
- m _ iI d : i n t + C ()
+ C ()
+ A () + G e t C o u n t ()
1
+ S e tB ( )
+ F o o ()
Class Relationships in UML
Association

Travel

Customer Account

association
Association end
Invoke member fn.

Person Car

Invoke member fn. of Tachometer

Controller Tachometer
Cannot invoke member
fn. of Controller

navigation
Association

• Special type of association


Navigation • One-way association
Class Relationships in UML
Association
– Multiplicity / Cardinality
• Maximum or number of instances of a class for the
class on the other side of relationship

Symbol Meaning
1 One and only one instance
0..1 Zero or one instance
* Zero to any positive number of instances
1..* One to any positive number of instances
M..N From M to N number of instances; M and N are positive integers; M < N

1 1
Customer Account

1 0..3
Person PurchaseOrder
Class Relationships in UML
Association
– Code generation

Customer must have one Account

1 1
Customer Account

Account must have one Customer

class Customer class Account


{ {
Account *the_Account; Customer *the_Customer;
}; };
Class Relationships in UML
Association
– Code generation with ‘role names’
• It is possible to specify roles classes play in the
relationship

1 1
Person Car
Owner Vehicle

class Person class Car


{ {
Car *Vehicle; Person *Owner;
• Role names are
}; converted into
}; attribute names inside
the class body
• Role names are attributes of relationship
Class Relationships in UML
Association
– Code generation with different cardinality

1 0..*
Customer PurchaseOrder

class PurchaseOrder
{
Customer *the_Customer;
};

class Customer
{
UnboundedSetByReference<PurchaseOrder> the_PurchaseOrder;
};

Declaration of one-to-many relationship Reference attribute


Name of the container class: List, Array, Vector
Class Relationships in UML
Association Class
– An association can also have its own attributes
– In such a case, it is both an association and a
class and is referred to as an Association Class
– Association class is useful when each link must
have attributes values, operations or references
to objects
– Association class can be regarded as a class
with some attributes and an extra class
reference for each association end
Class Relationships in UML
Association Class

Association part of the association class

* *
Company Employer Employee
Person

Class part of the association class


Job

Salary

* *
Company Holding Owner
Person

Stock

Quantity
Class Relationships in UML
Aggregation
– The relationship between two classes is
aggregation if:
• The two related classes share association relationship,
and
• one class can be said to be a part of the other class
– Relationship between a ‘whole’ and its ‘part’
• Part happens to be a part of the whole; but
• Part can exist even if whole does not exist
• Assembly and parts; books and library

Association

Aggregation
Class Relationships in UML
Aggregation

Library Book

aggregate
Basket Things

1 0..*
Classroom Chair
theClassRoom theChair

class Chair
{
ClassRoom *theClassRoom;
};

class ClassRoom
{
UnboundedSetByReference<Chair> theChair;
};
Class Relationships in UML
Composition
– A stronger form of Aggregation
– Relationship between a ‘container’ (composite)
and the ‘contained’ (part)
– Container is responsible for creating and
destroying the contained parts
• Contained object may only be a part of one composite
• No other class will destroy the parts, other than the
composite

Aggregation

Composition
Class Relationships in UML
Composition

Room Wall

composite
Stack Array

1 1..*
Bill Item
monthlyBill item

class Item
{
Bill *monthlyBill;
};

class Bill
{
UnboundedSetByValue<Item> item; Attribute is contained by value
};
Class Relationships in UML
Dependency
– When behaviour of one class depends on the
structure and behaviour of another class,
relationship is ‘dependency’
• Dependent class: client
• Other class: supplier
– Consider classes A and B
• They share none of relationships as association,
aggregation and composition;
• Class B is passed as an argument to a function of
class A;
• Or class B is locally instantiated and used in a function
of class A;
• Then A is said to depend on B
Class Relationships in UML
Dependency

f(B)
B

OperationManager

Operation
Execute(opr: Operation)

CDocument

CView
AddViiew(pView: View*)
Class Relationships in UML
Inheritance
– Generalisation / Specialisation
– ‘Kind of’ relationship
– Child class shares structure and behaviour of
parent class

Shape

Circle Rectangle

Rectangle
Class Relationships in UML
Realises
– Connects a model elements that provides
implementation to a model element that
provides specifications
– Connects a class to an interface

<<Interface>>
IComm
+ fnConnect()

CSerialComm CUSBComm
+ fnConnect() + fnConnect()
Class Relationships in UML
Summary

ClassA ClassB Association

Part Whole Aggregation

Contained Container Composition

Dependent Class Dependency

Sub-class Super-class Inheritance

Implementation Specification Realises


UML Views
Different UML Views
– Structural classification
• Describes things in the system and their relationship
with other things
– Dynamic behaviour
• Describes behaviour of the system over time
– Model Management
• Describes organisation of model in to hierarchical
units
UML Views
Structural classification
– Includes classes, use cases, components and
nodes
– Includes:
• Use Case View
– Use Case Diagram
• Static View
– Class Diagram
• Implementation View
– Component Diagram
– Deployment Diagram
UML Views
Dynamic Behaviour
– Includes:
• Interaction View
– Sequence Diagram
– Collaboration Diagram
• State Machine View
– State Chart Diagram
• Activity View
– Activity Diagram
UML Views
Model Management
– Includes models, packages, sub-systems
– Crosses other views and diagrams
– Organises model for development work
– Organises model for configuration control
Use Case View
Use Case Diagram
– Behaviour of a system as it appears to an
outside user

Use Case

Customer
Withdraw Money

Actor

Maintenance Person

Display Balance

Maintain ATM
Use Case View
Use Case Diagram

Customer
Display Balance

<<include>>

Perform Transaction

Validate User
Withdraw Money <<extends>>

Maintenance Person

Maintain ATM
Money Overdrawn
Static View
Class Diagram
– Captures the object structure of the system
– Object structure is captured in terms of classes
and their relationships
– Representing classes
• Conceptual
– Represent concepts in the problem domain
– Gives overall feel of class connections
– Attributes and method of classes are not important
• Specification
– Indication about responsibilities of classes
– Attributes and method are specified
• Class diagrams can be any combination of these
Static View
Class Diagram
– Representing classes

Window Window Window


- private
position
- positi on # protected
size
- size + public

+ Windo w() Shape


- position Abstract class
+ open()
+ close() - area
# paint()
+ Draw()

Class is rendered as a
rectangle, displaying its Circle
name, attributes and methods -$ count

+ Draw()
Static View
Class Diagram: School Database
C las s ro om
P lay gro und
S tudent 1..*
1..* 1..*
1 ..*

Lab
S tu d i e d B y 1 1..*
1 0..*
0 ..*
8 1..* S c h ool
S u bjec t
1
1 ..* 1
1 ..*
Ta u g h tB y C hem ic al
1 .. * 1..*

Tea c her
1
P rinc ipa l
Static View
Class Diagram: ATM Case Study
CurrentAccount SavingsAccount

Class diagram for ATM System


Acc ount
(analysis phase)
0..1
Transaction 0..1

1 1
Validator
TransactionManager
1 0..1
1
1 1 1

Printer 1
1 1
1
display Dispenser
CardReader
Implementation View
Implementation or Physical View
– Models the physical structure of the system
– Includes physical elements as components and
or nodes which make the systems
– Shows physical packaging of reusable units of
the system into substitutable units:
components
– Includes:
• Component Diagram or Component View
• Deployment Diagram or Deployment View
Implementation View
Component Diagram
– Models executable code that resides on a
machine
– Represents functional and replaceable part of a
system
– A component may be:
• an executable
• a DLL
• a Java class
• a Java bean Component
• an EJB
• a COM component
A Component
Implementation View
Component Diagram

Offic eSuite
Spreadsheet

<<EXE>> Di ctionary
W ordEditor
ISpellCheck

IGram m er
Implementation View
Component Diagram

<<DLL>>
ScriptEngine

IScript

<<EXE>> <<DLL>>
GUI APILib

<<DLL>>
Driver

IComms
Implementation View
Deployment Diagram
– Shows how a software system is deployed
among different hardware components
– Visualises distribution of components across an
enterprise
– Shows configuration of runtime processing
elements and software processes living on
them
– Relationship among the software and hardware
components of a system
– Shows details of communications link
Implementation View
Deployment Diagram

Node: Node represents a computational resource; having


some processing capability and some memory
Server

Node

Stock
Management
Purchase

dB
Server

Order
Processing Billing
Interaction View
– Different objects interact to implement the
behaviour in a context
– Set of objects interacting to implement a
behaviour is called as ‘collaboration’
– Interaction is set of messages exchanged by
collaborating objects
– A message can be:
• Signal sent by one object to another object
• Call i.e. invocation of operation
– Diagrams:
• Sequence Diagram
• Collaboration Diagram
Interaction View
Sequence Diagram
– Shows interaction among objects as a two-
dimensional chart
• Vertical dimension is time axis; growing from top to
bottom
• Horizontal dimensions has collaborating objects
– The time axis indicates life-span of an object
• Indicated by a dashed line from the object growing
downwards
• During the life-span of the object, when a procedure
[function] is active, it is shown by a double line;
called as ‘function focus’
– A message is shown as an arrow from one
object to another
• The messages are arranged in time sequence
Withdraw Money
Perform Transaction
Interaction View
UML Message Types

A B Simple message: Message runs in a single thread of execution.


Message execution is sequential.

A B Synchronous message: Client (thread) sends a message and


waits till receiver (thread) has acted upon it.

A B Asynchronous message: Client (thread) sends a message and


continues processing, without waiting for the receiver (thread) to
process the message.

A B Timeout message: Client sends a message to the receiver and


waits for specified amount of time; if the receiver cannot
acknowledge (receive) that message within this time interval, client
abandons it.

A B Balking message: If the receiver (thread) is not immediately ready


to accept the message, the client abandons it
Interaction View
UML Message Types

T1 T2 X
Simple message

Time for which T1


and T2 execute
concurrently
Asynchronous message

Time for which


execution of T1 is
blocked while T2 is Synchronous message
executing

Time for which T1


and T2 execute
concurrently
Interaction View
Collaboration Diagram
– An interaction diagram wherein time is not
explicitly represented
– Sequence of messages is indicated by
numbering them
– Illustrates interactions among objects using
their spatial structure
– Shows object relationships clearly
– Can be thought of a sequence diagram without
time axis
Interaction View
Collaboration Diagram

: CardReader

1. cardInserted( )

1.1. readCard( )
1.2. ejectCard( )

1.3. Transaction(Long, Date, String)


: 1.4. setAccType(String)
TransactionManager
: Transaction
Interaction View
Collaboration Diagram

:T2
T2: 1: a()
T2: 2: b()
T2: 3: c()

:X

T1: 1: x()
T1: 2: y()
T1: 3: z()

:T1
Collaboration diagram can specify parallel
processing clearly, where absolute
sequence of messages relative to time
does not make sense
State Machine View
State Chart Diagram
– State chart diagram models behaviour of an
individual object
– Specifies sequence of states an object goes
through during its lifetime, in response to
various events
– It also specifies response of an object in a
certain state to various events
– State
• Related sets of attribute values
• Dictates how an object acts and reacts in response to
messages
State Machine View
State Chart Diagram

Attribute b

Attribute a
State space

Each point in the state space of an object denotes a distinct state of the objet
Each such state may be referred to as a micro-state of the object
State Machine View
State Chart Diagram

Attribute b STATE

Attribute a
State space

For a state-chart diagram, we consider equivalence class of micro-states as a ‘STATE’


Such a STATE is a conglomeration of micro-states, for which the behaviour of object is similar

An appropriate name may be given to identify such a state


State Machine View
State Chart Diagram

Stack
iMaxElements : Integer
iCount : Integer
A : Array
Empty
Push(iNumber : Integer) : Boolean
Pop() : Integer

Loaded

Full

States of a ‘Stack’ class


State Machine View
State Chart Diagram

Self transition

Starting state
Empty

Event / message /
function call

Full Loaded
State Machine View
State Chart Diagram
– It is composed of Transitions and States
– Transition
event [guard] / action

• Event
– On receiving an event by an object, a transition is fired;
provided the guard condition is satisfied
• Guard
– A logical condition, returning TRUE or FALSE
• Action
– A message dispatched to other objects visible to this
object
State Machine View
State Chart Diagram

Pop() / Throw an underflow exception

Empty

[iCount = 0]
Push(x)

Adding [iCount < iMaxElements] Loaded Pop() Removing


Push(x) [iCount > 0]

Pop()
Push(x) / Throw an overflow exception
[iCount = iMaxElements]

Full
State Machine View
State Chart Diagram
– A state may also have three parts
State Name

Entry action
Exit action
Activity

• Entry action
– An action which immediately occurs as a result of
transition into a state
• Exit action
– An action that has to happen immediately before a state
changes
• Activity
– Activities that take place inside an object while it is in a
particular state
State Machine View
State Chart Diagram

Pop() / Throw an underflow exception

Empty
exit: iCount = 0

[iCount = 0]
Push(x)

Adding [iCount < iMaxElements] Loaded Pop() Removing


entry: ++iCount Push(x) [iCount > 0] exit: --iCount
exit: A[iCount] = x entry: return A[Count]

Pop()
Push(x) / Throw an overflow exception
[iCount = iMaxElements]

Full
Activity View
Activity Diagram
– Used to model workflow and computations
– Means of modelling a business process
– Shows flow of a business process from one
activity to another
– Represents:
• A process being carried out
• Creating / destructing objects; object flow
Activity View
Activity Diagram
Receive Order

Create Order Authorize


Payment

Process Order

Assemble Generat e
Package Invoice

Dispatch
Shipment
Activity View
Activity Diagram
Activity View
Activity Diagram
Sel ect an
Order

Select first
unpreapred l ine

Check if item [an item received]


available

[ Item av ailable ]
Suspend
[all lines not checked] Update Stock Processing

[Else]
Mark the line
as prep ared

[All lines chec ked]


[E lse a nd 1st iteration of c hecking]
Create
Re-order item
[At leant one line prepared]
[E lse]
Create
[Else and 1st iteration of checking]
packing sl ip

[All lines prepared]


Create
Delivery item
Miscellaneous
Package diagram
– Capturing sub-systems: level 1

ATM System

Database

already
developed
Miscellaneous
Model organisation
– Capturing sub-systems: level 2

ATM System

UI
Business

DB Int erface
Database

already
developed
Miscellaneous
Package diagram
– Capturing sub-systems: level 3

ATM System

UI
Business
Display
cardReader TransactionManager
dispenser validator
printer transaction
account

DB Interface
DBIMgr
Database

already
developed
Extensibility Mechanisms in UML
Extending UML

rectangle

Meaning Properties Constraints


Represents a class Name Abstract class cannot
Attributes be instantiated
Operations
Extensibility Mechanisms in UML
Extending UML
– Stereotype
• Extends the vocabulary of UML
• Allows to create new building blocks, by giving them
new meaning
– A Tagged value
• Extends properties of a UML building block
• Allows to add / create new information for an element
– A Constraint
• Extends semantics of a UML entity
• Adds new rules or modifies existing rules
Extensibility Mechanisms in UML
Extending UML
T2 X

<<include>> <<SQL>>

Validate User
Meaning of the inheritance
arrow is changed from Meaning of the simple message
inheritance to ‘include’ arrow is changed to SQL query
relationship
Perform Transaction
Account
A symbol for a class is used to {version = 1.0}
represent a database Tagged {author = OSP}
values -accountNumber
- balance
-Account()
+GetBalance()
{Balance >= 5000} +Withdraw()
Constraint
+GetMinBalance()
Extensibility Mechanisms in UML
Extending UML
– Stereotypes
• Written inside the UML element and above the
element name
• Written in guillemets
– Tagged values
• Written inside the UML element and below the
element name
• Written inside curly braces
– Constraints
• Written outside the UML element and attached to the
element that has to satisfy the constraint
• Written inside curly braces
Assignment
Class Relationships in UML
Assignment: Find class relationships

A database is to be developed to store information about various schools in a city.


The information related to a school is as following.

1. Students and Teachers associated with the school with relevant details.
2. Principal of the schools and details.
3. Subjects taught in the schools (8 subjects are taught)
4. Given a subject, which Students are studying it, which Teachers are teaching it.
5. Number of classrooms and their details.
6. Number of playgrounds and their details.
7. Number of labs and details.
8. Chemicals available in the lab.

Given a school, it should be possible to access or change above mentioned


information. If a school is deleted from the database, some of the information may
still be retained while the remaining might deleted with it.
Use Case Analysis
A software is to be developed for running an ATM.

1. It should control an ATM which handles customer transactions, in addition to


providing other services to bank personnel.
2. The ATM is used by a customer to withdraw money and get his / her account
balance. These transactions initiated by an ATM card.
3. A customer can have two accounts with the bank, these being a savings or current
account. An account can be owned by more than one persons.
4. The ATM card is unique card number, which makes it a valid card for a given ATM.
The card number uniquely identifies the specific account a customer can access.
5. Only the customers having a valid card and PIN can use the ATM.
6. The transactions of opening and closing an account as well as depositing money
are beyond the scope of this ATM software.
7. A typical transaction of a customer should follow a well defined path:
a) The customer first has to insert the ATM card in a slot. This ATM card
has to be read and checked by the system.
b) ATM will have a screen through which it will ask the customer to enter
his / her PIN. The customer is allowed to proceed further if the PIN is valid.
Otherwise, ATM ejects the card.
Use Case Analysis

c) The screen will ask the customer to select a transaction, wither


Withdraw Money or Show balance on a savings or a current account.
d) In case of withdrawing, depending on the amount customer has
keyed in, ATM will dispense the cash through a dispenser, show the latest
account balance and print the transaction report and eject the ATM card.
8) The software is expected to save the information of every transaction. The
manager of the bank can fetch this information whenever required.
9) Every successful transaction results in updating of database whose contents
are fetched by an Accounting software to update bank accounts. (Both, the
database and the accounting software are developed and installed by a third
party)
10) The maintenance of ATM is done by a maintenance person. This activity
primarily involves replenishing the cash as well as servicing other hardware parts.
11) System interacts with PIN, accounts info, customer info databases external to
the system to carry out various functions such as validating a customer, handling
transactions etc.
Use Case Analysis

Assumptions

1. Customer can perform one transaction at a time.


2. All transactions have to be saved to the database. A transaction can be
successful or aborted.
3. A transaction is defined as whatever that happens between insertion and
ejection of a card.
Use Case Analysis
System and Users
– Possible users of the ATM system
• Any customer
• The Manager
• Bank Staff
• The Maintenance Person
• The Accounts System
• Database
Use Case Analysis
System and Users

Find the REAL users of the system

Customer Manager
Get data
Transaction

ATM Transactions
Software Database

Get data

Get / store data


Accounts
System

Maintenance Person Bank Staff


Use Case Analysis
System and Users

Manager: Manager may want to look at the transaction data, to know how ATM is
getting used. The manager expects ATM system to send transaction data to the
database. Manager can then access the database to see the data. The database
is connected to the system. The manager uses the database to extract the
information related to transactions.
Accounts System: This software accesses the database and updates the overall
bank accounts. The existence ATM system does not matter to this system.
Bank Staff: The bank staff is responsible for opening, closing an account and
depositing money in the customer account. They do not interact with the ATM
system.
Database: ATM directly interacts with the database and stores transaction data in
the database.
Maintenance person: The ATM software helps the maintenance person to
perform the job by indicating status of various hardware components.
Customer: Customer benefits from the system, as it allows him / her to withdraw
money or check the account balance.
Use Case Analysis
Use Cases for ATM system

Actor Use Cases

Withdraw Money

Customer
Display Balance

Maintain ATM
Maintenance Person

Save Transaction
Database
Use Case Analysis
Actors for the system
– An actor is a role a particular user plays while
interacting with the system
– An actor is a user who uses the system in a
particular way
– Actors:
• Customer
• Maintenance person
Customer (Actor)
• Database

How does the system provide services to actors?


Mr. X (User) Bank Manager (User)
What is the external behaviour of the system from point of
view of an actor?
Use Case Analysis
Use Case
– For each actor of the system, ask a question:
• Why would the actor interact with the system?
– Because the system offers certain services to the actor
– A complete and distinct service offered by the
system to an actor is called as a Use Case
– Each Use Case is an independent interaction of
an actor with the system
– A Use Case tells what an actor can expect from
the system
– Use case is invoked by an actor
Use Case Analysis
Use Case organisation

Withdraw Money Display Balance

1. Read card 1. Read card


2. Get PIN 2. Get PIN
3. Validate PIN 3. Validate PIN
4. Get account type 4. Get account type
5. Get transaction type 5. Get transaction type
6. Get amount 6. Display balance
7. Dispense money 7. Print report
8. Print report 8. Eject card
9. Eject card

Validate User Capturing common


scenarios in different Use
Case descriptions
Secondary Use Case
Use Case Analysis
Use Case Relationships
– Include
• It can be said that Use Case A includes Use Case B if:
– Use Case B narrates scenarios which are part of
scenarios of Use Case A, and
– Use Case B describes scenarios common to a set of Use
Cases A, along with A
• When Use Case A is invoked, Use Case B MUST be
invoked
• The main Use Case cannot be complete without
executing <<included>> Use Case
• Can be used only when the common scenarios to be
<<included>> are consecutive
Use Case Analysis
Use Case Relationships
– Include

A B C

---------- ---------- ----------


---------- ---------- ----------
---------- ---------- ---------- A
<<include>>

---------- ---------- ----------


---------- ---------- ----------

Common scenarios

X <<include>>
<<include>>
----------
----------
----------
X

B C
Use Case Analysis
Use Case Relationships
– Include

1. ………………………
2. ………………………
3. ………………………
4. ……………………… 1. ………………………
5. ……………………… 2. ………………………
Withdraw
Money . ……………………… 3. ………………………
Validate
. ……………………… . ……………………… User
. ……………………… . ………………………
. ……………………… 10. ………………………
19. ………………………
20. ……………………...

<<include>>

Withdraw Money Validate User


Use Case Analysis
Use Case organisation
– Taking care of exception

Part of Withdraw Money Use Case

12. …………………...
13. …………………...
14. Customer selects an account type (from the options displayed on the screen)
15. System prompts the customer to select the transaction type
16. Customer selects "Withdraw Money"
17. System prompt the customer to enter the amount to be withdrawn
18. Customer enters the amount
19. If the amount entered is invalid, take appropriate action. Else?
20. System dispenses the money through the dispenser
21. ……………………
22. ……………………
Use Case Analysis
Use Case Relationships
– Extends
• Used to show optional behaviour for a Use Case,
which is required only under certain conditions
• The Use Case which <<extends>> another Use Case,
is invoked if some condition is met in another Use
Case
• The main Use can be completed without executing the
Use Case the <<extends>> it
Use Case Analysis
Use Case Relationships
– Extends

1. ………………………
2. ………………………
3. ………………………
4. ………….[condition]… FALSE
1. ………………………
5. ……………………… 2. ………………………
Withdraw
Money . ……………………… 3. ………………………
Money
. ……………………… . ……………………… Overdrawn
. ……………………… TRUE
. ………………………
. ……………………… 10. ………………………
19. ………………………
20. ……………………...

<<extends>>

Withdraw Money Money Overdrawn


Use Case Analysis
Use Case Relationships
– Generalisation
• Use Case B is said to be inherited from Use Case A, if:
– Use Case has specific scenarios and Use Case A has
more general scenarios
– The child Use Case B inherits scenarios of the parent
Use Case A and may insert additional scenarios into it
– Use Case B can be said to be a ‘Kind of’ Use Case A

Make Payment

Pay by Cash Pay by Cheque Pay by Card


Use Case Analysis
Use Case Relationships
– Generalisation

Child Use Cases

Withdraw
1. Read cardMoney 1. ReadDisplay
card Balance
2. Get PIN 2. Get PIN
3. Validate PIN 3. Validate PIN
4. Get account type 4. Get account type
5. Get transaction type 5. Get transaction type
6. Get amount 6. Display balance
7. Dispense money 7. Print report Parent Use Case
8. Print report 8. Eject card
9. Eject card

Capturing commonality

Perform Transaction
Use Case Analysis
Use Case Relationships

Include Extend Generalisation


Main use case references Extension use case references Child use case references
the inclusion use case the main use case the parent use case

Inclusion use case may Extension use case may not be Child use case is invoked
invoked independently invoked independently independently

Inclusion use case must Extension use case is Parent is typically not
be invoked to complete conditionally invoked; main use invoked; parent use case
the main use case case can be completed without may not be well formed if the
the extension use case child use case is not invoked

Include relationship Extend relationship represents Relationship between


represents a mandatory an optional behaviour; covers abstract and concrete
flow of scenarios an alternate flow
Design
Design Phase
– Basic architectural framework

– Detail out the object interactions

– Detail out different classes


• Interfaces
• Implementation
Design
Architecture of the system

Withdraw Amount

Business layer

UI layer Transaction
manager
X X ?
X

display X
Customer X
Transaction
X

account
dB layer
Other UML Diagrams
– Business model and domain model
– Activity diagram
– Deployment diagram
– Collaboration diagram
– Component diagram
– Start chart diagram
– Summary
Other UML Diagrams
Business model and domain model
– Business model
• Modelling the actual business processes
• Helps understand the way the business is carried out
• Modelled with Business Workers, Business Entities and
Business Procedures or Activities
• Business Worker
– A Person working in a business environment and
responsible for carrying out certain defined tasks
• Business entity
– A thing used in the process of carrying out the business
• Business procedure
– An activity or set of activities carried out by the
business worker, using business entities, as a part of a
business process
Other UML Diagrams
Business model and domain model
– Domain model
• Dictionary of all the business entities / terms
• Consists of business entities, their meaning,
properties, how they are used, who uses them etc.