Object Oriented

Analysis And
design Through
UML
 This session

 Introduction to modeling
 Class diagrams

 Use case diagrams

 Sequence Diagrams
Introduction to Modeling

What is a model?
A model is a simplification of realty.
Why do we model?
We build models so that we can better
understand the system we are
developing
How can you realize the
benefits of modeling?
 What is the UML…

 The UML is the standard language for

 Visualizing,
 Specifying,

 Constructing, and

 Documenting

the artifacts of a software-intensive

system
 DIAGRAMS
THINGS
RELATIONSHIPS
1. CLASS
2. OBJECT
DEPENDENCY 3. COMPONANT
STRUCTURAL
4. USE CASE
BEHAVIORAL ASSOCIATION 5. SEQUENCE
6. COLLOBORATION
GENARALIZATION
GROUPING 7. ACTIVITY
8. AND OTHERS
ANNOTATIONAL REALIZATION
All the modeling techniques

in brief
Use case
diagrams
Sequence Class
Diagrams diagrams

Collaboration Object
diagrams UML Diagrams
MODELS

State
Component
Machine
Diagrams
Diagrams
Activity Deployment
Diagrams Diagrams
Classification of UML
 Structural model view
1) class diagrams
2) object diagrams

 user model view

1) use case diagrams

 Behavioral model view

1) sequence diagrams
2) collaboration diagrams
3) state machine diagrams
4) activity diagrams

 Implementation model view

1)component diagrams

 Environment model view

1) deployment diagrams
Structural model
view
ClassDiagrams
Object Diagrams
 Class diagram

Structure &
Relationships Multiplicity &
behavior Navigation

DEPENDENCY GENARALIZATION

REALIZATION ASSOCIATION
Relationship between
One Class uses the General kind of class
nformation of otherOne class specifies And a more specific
Objects of one thing are Kind of class
A contract that other Connected to objects
Class will carru out Of another
 Structure of a Class
 A class is a collection of
objects with common
structure, common ClassName
behavior, common
relationships and Attributes
common semantics
Operations
 Classes should be named
using the vocabulary of Responsibili
the domain ties
 Naming standards should
be created
 e.g., all classes are
 Operations and
Attributes
 Operations :The behavior of a class is
represented by its operations

 Attributes :The structure of a class is

represented by its attributes

 Responsibilities: It is a contract or an
obligation of a class.
 Advanced Relationships
 Ag gregatio n : It is a special kind of association and is used when one
class (whole) consists of 1 or more smaller classes (parts). It shows has-a
relationship between the ”whole” and its “parts”.

 Com pos iti on : This specifies that the lifetime of the part
classifier is dependent on the lifetime of the whole
classifier

 Inh eri tan ce : There are two ways to find

inheritance:
 Gene rali zatio n : As you move "up" the hierarchy, you achieve
greater generalization . You move up toward Mammal to generalize that
dogs, cats, and horses all bear live young.
 Sp eci aliz ati on : As you move "down" the hierarchy you specialize.
Thus, the cat specializes Mammal in having claws (a characteristic) and
purring (a behavior
 Multiplicity and Navigation

 Multiplicity defines how

many objects participate in Indicat Meaning
a relationship or
0..1 Zero or one
 Multiplicity is the
number of instances of 1 One only
one class related to
ONE instance of the
other class 0..* Zero or more
 For each association
and aggregation, there 1..* One or more
are two multiplicity
decisions to make: one n Only n (n > 1)
for each end of the
relationship 0..n Zero to n (n>
1)

 If navigation is restricted, 1..n One to n (n >

an arrowhead is added to 1)
indicate the direction of
the navigation
 A small Work out

 Try to make Class diagram for a

banking system ?????????

NOW
Building a system
user model view

Use case Diagrams

 What's up in
usecases??????
Use Case
Diagrams

Relationships
Behavior or Between Actors
Actor USE CASE & usecases

An actor is a
person,
organization,
or external
system that
plays a role in
one or more
interactions
with your
 Introduction to USE CASE
diagrams
What is a use case diagram??
A use case diagram is a type of behavioral diagram.
whose purpose is to present a graphical overview of the
functionality provided by a system in terms of actors, their
goals (represented as use cases), and any dependencies
between those use cases

What do they represent?

They represent the functionality of the system from user’s
point of view

who will be using the system?

ACTOR

what will they be using it to do? ?

USECASE
 Who is an actor???
 For example, a bank cardholder might need to use an ATM to get
cash out of their account. It is as simple as that.
 Actors don't have to be people. They can be other systems. For
example, the ATM may need to connect to the cardholder's bank.
External systems that interact in a use case are also actors.

actor system goal

What Is A Use Case Scenario?

 Some examples of use case scenarios.

 When a cardholder tries to withdraw cash
from an ATM, it doesn't always necessarily
turn out the same way.
 Sometimes he gets his money.
 Other times he might have insufficient funds.
 Or the ATM may be out of cash

The outcome is different, depending on

circumstances, but they all relate to the same
functional goal . that is, they're all triggered by
the same need and all have the same starting
point.
 Capturing Use Case Scenarios with
Essential Use Case Descriptions
 Don’t go into technical
aspect of the design
 We first need to
understand what the
business logic of the
interactions are, so we
can focus on satisfying •select withdrawal option
the business goal of the •display
use case. withdrawal
 Instead of saying “the •specify options
user presses the enter amount
•check card holder
button”, we say “the user has
confirms their choice”, for Sufficient funds
example. •eject card
 split the actions into
columns, one for each •prompt cardholder to take
actor and one for the card
system. Then we can •take card
see at a glance not •dispense
only the order of amount
events in a use case •prompt cardholder to take
•take cash cash
scenario, but also •debit cardholder’s
exactly who is doing account
what. •thank cardholder
 An essential use case •display welcome and await
clearly shows the order next holder
of events and the
 Depiction of actor and usecase

Usecase1

Usecase2

actor
 WARNING
 Remember that use case designs
aren't the same thing as
requirements. These are high-
level interaction designs. if we
mix them up with real
requirements stuff the system
really has to do ,then we can get
bogged down in the design
decisions we make early on.
 Documenting Use Cases

 A flow of events document is

created for each use cases Written
from an actor point of view
 Details what the system must
provide to the actor when the use
cases is executed
 Typical contents
 How the use case starts and ends
 Normal flow of events
 Alternate flow of events
 Exceptional flow of events
 Relationships Between
Use Cases
Book assesment
<<includes
 Including Use >>
Cases: When two
Check tutor availab
or more use cases
include the flow of Book lesson <<includes
another use case, >>
they are said to
include that use
case's flow. View Product
<<extends
 Extending Use >>
Cases:
Check Login
<<extend>>
relationship Review Product <<extends
>>
means that the
flow of the
extending use
 Summary of use cases
1. Identify your actors: who will be using the system?
2. Identify their goals: what will they be using the
system to do?
3. Identify key scenarios: in trying to achieve a specific
goal, what distinct outcomes or workflows might we
need to consider?
4. Describe in business terms the interactions between
the actor(s) and the system for a specific scenario
5. Create a UI prototype that clearly communicates the
scenario to technical and
6. non-technical stakeholders
7. Do a high-level OO design for the scenario
8. Implement the design in code
9. Get feedback from your users . ideally through
structured acceptance testing
10. Move on to the next scenario or use case (.rinse and
repeat.)
 A small Work out

 Try to make Use case diagram for a

banking system ?????????

NOW
Behavioral Model
View
1. Sequence Diagrams
2. Collaboration Diagrams
3. State Machine Diagrams
4. Activity Diagrams
 Sequence Diagrams
 The sequence diagram is used primarily to
show the interactions between objects in
the sequential order that those
interactions occur.
 useful to communicate how the business
currently works by showing how various
business objects interact.
 business-level sequence diagram can be
used as a requirements document to
communicate requirements for a future
system implementation.
 Notation Basics
 Lifelines: Lifelines are drawn as a box with a dashed line
descending from the center of the bottom edge .The lifeline's
name is placed inside the box.
 Messages: The first message of a sequence diagram
always starts at the top and is typically located on the left side of
the diagram for readability. Subsequent messages are then added
to the diagram slightly lower then the previous message.
 Guards: Guards are used throughout UML diagrams to
control flow. When modeling object interactions, there will be
times when a condition must be met for a message to be sent to
the object.

 Alternatives : Alternatives are used to designate a

mutually exclusive choice between two or more message
sequences. Alternatives allow the modeling of the classic "if then
Life lines Guards

Messages
Alternative
 A small Work out

 Try to make Sequence diagram for a

banking system ?????????

NOW