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 behavior, ClassName
common relationships and
common semantics
Attributes
 Classes should be named
using the vocabulary of the Operations
domain
Naming standards should be
Responsibiliti

created
 e.g., all classes are singular es
nouns starting with a capital
letter
 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
 Aggregation: 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”.

 Composition : This specifies that the lifetime of the

part classifier is dependent on the lifetime of the whole
classifier

 Inheritance : There are two ways to find

inheritance:
 Generalization: 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.
 Specialization: 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 a relationship Indicato Meaning
 Multiplicity is the number of
instances of one class related to r
ONE instance of the other class
 For each association and 0..1 Zero or one
aggregation, there are two
multiplicity decisions to make: 1 One only
one for each end of the
relationship 0..* Zero or more
1..* One or more
 If navigation is restricted, an n Only n (n > 1)
arrowhead is added to indicate the
direction of the navigation 0..n Zero to n (n> 1)

1..n One to n (n > 1)

 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 the
business goal of the use case.
 Instead of saying “the user presses the
enter button”, we say “the user
confirms their choice”, for example.
 split the actions into columns, one
•select withdrawal option
for each actor and one for the •display withdrawal
system. Then we can see at a options
glance not only the order of events
in a use case scenario, but also •specify amount
exactly who is doing what.
 An essential use case clearly shows •check card holder
the order of events and the has
responsibilities of the actor(s)
actor(s) and
system in a single use case scenario, Sufficient funds
without committing to technical •eject card
design decisions
•prompt cardholder to take
card
•take card
•dispense amount
•prompt cardholder to take
•take cash cash
•debit cardholder’s
account
•thank cardholder
•display welcome and await
next holder
 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
 Including Use Cases: When <<includes
two or more use cases >>
include the flow of another
use case, they are said to Check tutor availab
include that use case's flow.
Extending Use Cases: <<includes

<<extend>> relationship
Book lesson
>>
means that the flow of the
extending use case is only
included under specific
conditions
View Product
<<extends
>>

Check Login

Review Product <<extends

>>
 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 else" logic
Life lines Guards

Messages
Alternative
 A small Work out

 Try to make Sequence diagram for a

banking system ?????????

NOW