Chapter 4

Object Oriented Analysis

1
Basic Stages of Developing any Software Product
 Requirement gathering

 Analysis

 Design

 Implementation

 Testing

 Maintenance
What are the deliverables from
Requirement elicitation phase?

List?

3
 Recall that
• Requirement gathering/elicitation
– Traditional methods (interview,
questionnaire, observation….)
– Essential Modeling
• Essential use case
• Domain modeling using CRC
• Essential UI Prototype

4
 Object Oriented Analysis
• The purpose of requirements analysis is to define what
the new system should do.
• It is quite clear that both the requirement gathering and
analysis phase deal about what to build.
• The main difference is that
– The requirement gathering phase tries to understand
what the user needs and their usage of the system.
– The analysis phase will be used to understand the
system itself in addition to the user usage.

5
 Requirement gathering and analysis linked..
Requirement Artifacts Analysis Artifacts

Essential Use
Case Model System Use
Case Model

Business
Rules Sequence
Diagram
Activity
CRC Model Diagram

Class Model

User Interface
Flow Diagram

Essential User User Interface

Interface Prototype
6
Prototype
 Basic Tasks in analysis phase
• Developing and validating
– (System) Use case model
– Sequence Diagram
– Conceptual Class Model (analysis level)
– Activity Diagram
– UI prototyping

7
 System Use case Modeling
• The system use case talks more about more or
less same concept like the essential use case
with some details of the implementation.
• The modeling will be influenced by the
technology to be used for the systems
development.
• System use case model is composed of the
system use case diagram and its corresponding
documentation.
8
 Components of system use case
• Diagram with the following components
– Actors
– Use cases
– Boundary
– Relationship (inheritance, include and
Extend)
• Documentation
– For each use case using the standard
template
9
 Use case Description
• The template will be the same as the essential
use case documentation except that the
“Include” and “Extend” part will be included at
this level.
• The following example describes one of the use
cases of a certain use case diagram.

10
 Use case documentation
Name Sell Item
Identifier UC-008
Description Sell available items in a store to a customer
Actor Sales Clerk
Pre Condition none
Post Condition The sales clerk will sell the item if available in store

Extends none
Includes UC-001
Basic Course of Action
1.The Sales Clerk want to sell an item
2.The Sales Clerk logs into the system using “UC-001: Login”
3.The system displays the main Window “UI-002: Main Menu”
4.The Sales Clerk selects “Sell” from the Main Menu
5.The system displays the Sell interface “UI-006: Sell Item”
6.The Sales Clerk selects the items and quantity he want to sell
7.The system check the availability of the items according to the business rule “BR-012: check availability of item”
8.The system displays the total amount of money to be paid with the item list via “UI-013: Payment Voucher”
9.The Sales Clerk indicates he want to print the payment voucher.
10.The system prints the payment voucher
11.The use case ends when the Sales clerk receive the money and give the payment voucher to customer.

Alternative Course of Action A: The item is not available in store

8.The system determines that the item is not available.
9.The system informs the Sales Clerk that the transaction can not be completed via “UI-014: Item Quantity not Available”
10.The use cases resumes at step 6 of the basic course of action
11
 How to model system use case?
• Start with your essential use case diagram and modify them to
reflect high-level implementation issues and opportunities for
reuse, applying the UML stereotypes of <<extend>>,
<<include>> as well as the object oriented concept of
inheritance.
– Identify actors
• Already covered under essential use case modeling
– Identify use cases
• Already covered under essential use case modeling
– Define relationships
– Draw the diagram using tools like Ms-Visio or Rational Rose
– Document each use case

12
Reuse in Use Case Models

<<extend>>, <<include>> and

inheritance

13
 Extend Associations between use cases
• The <<extend>> stereotype is used to indicate an extend
association
• It is a generalization relationship where an extending use case
continues the behavior of a base use case.
• Accomplishes this by conceptually inserting additional action
sequences into the base use case sequence
• Extension points are placed in base use cases to indicate where
the logic of the extending use case replaces that of the base use
case
• One use case extends the behavior of another use case at a
specific point. Example: make repeated payment and make one
payment extend make payments use case.

14
 Include Associations between Use Cases
• Generalization relationship denoting the inclusion of
the behavior described by another use case
• Invocation of a use case by another one
• Denoted by the <<include>> stereotype
• One use case includes the behavior of another
use case at specific point.
• Example: make payment includes check funds
availability.

15
include vs extend use case

16
 Example on System Use Case
• Hospital Management System is a large system including
several subsystems or modules providing variety of
functions. Hospital Reception subsystem or module
supports some of the many job duties of hospital
receptionist. Receptionist schedules patient's
appointments and admission to the hospital, collects
information from patient upon patient's arrival and/or by
phone. For the patient that will stay in the hospital
(inpatient) s/he should have a bed allotted in a ward.
Receptionists might also receive patient's payments,
record them in a database and provide receipts, file
insurance claims and medical reports.

17
18
 Sequence diagram
• The Sequence Diagram models the collaboration of
objects based on a time sequence.
• It shows how the objects interact with others in a
particular scenario of a use case.
• It shows a set of objects and the messages sent and
received by those objects.
• Build for each use cases but if you think that some use
cases are clear to understand you may not need to
develop a sequence diagram. But you need to explain
this explicitly
• Used to visualize the logic in side use cases
19
 Notations in sequence diagrams
• Actors – format – “ActorName”, <<actor>>
• Objects – format – “name: Classname”
• Classes – format – “ClassName”
• User Interface elements - <<UI>>
• Dashed lines – object lifelines
• Long thin boxes – method invocation boxes indicating that processing is
being performed by the target object/class to fulfill a message
• X at the bottom of a method invocation box – object have been removed
• Messages – labeled arrows
• When the source and target of a message is an object or class the label is
the signature of the method invoked in response to the message
• If either the source or target is a human actor, then the message is labeled
with brief text describing the information being communicated

20
 Cont…
• Each use cases in a use-case diagram has its
corresponding sequence diagram
• You model the diagrams from the main flow of
events, or the alternate flow of events, or the
scenarios, of each use case
• Every object that you have identified in the
sequence diagram MUST have its corresponding
Class in the class diagram

21
 Cont…
• Steps to draw sequence diagram
– Identify which objects play a role in the
interaction
• Place them from left-to-right, at the top of the
diagram
– Define who will initiate the interaction
– draw the first message to a sub system
– Set the lifeline for each object
– Draw message to other sub system
– Draw return message to actor
22
Sequence diagram for Withdrawing money
from an ATM

23
 Activity Diagramming
• An activity diagram is essentially a flowchart, showing the flow
of control from activity to activity.
• Used to model the logic of a
– single operation/method
– Single use case
– Flow of logic of a business process
• Starting point = filled circle
• Ending point = filled circle with a border
• Processes = Rounded rectangle
• Decision point = Diamond
• Transitions between activities = Arrows
• Start and End of Parallel processes = Thick bars
• In many ways UML activity diagrams are the object-oriented
equivalent of flow charts. 24
Activity Diagram notation

25
 Activity Diagram notation
• Fork and join nodes – Fork and join nodes either
split actions, or bring them together, and both are represented
with thick, horizontal lines. Fork nodes split one action flow
into multiple outgoing flows, and a join node combines
multiple incoming flows into one outgoing flow. When both
are used together, it is referred to as ‘synchronization’.

26
27
 Analysis level Class Diagram
• Class Diagram is a UML diagram where you can
visualize those classes, along with their attributes,
operations and the inter-relationship.
• Class diagram Focuses on identification of the
vocabulary of the system
– Classes and objects
• Classes for completeness and objects for
understanding
– Relationships (with some common mechanisms)
– List attributes and methods (methods are Optional)

28
 Cont…
• How to model Class Diagram?
– You can start from CRC or follow the heuristics in
identifying classes.(Abbott’s heuristics- natural
language analysis): Example
• Proper noun- object – Abebe
• Common noun- class – customer
• Doing verb- (operations)method- login, creates, selects
• Adjectives- attributes – order description
• Having verb- aggregation- has, consists of,
• Being verb – inheritance (generalization) – is a kind
of, is one of
29
 Cont…
– Extract attributes and methods from
responsibilities
– Review the model with stakeholders (users)
• For 3 Cs (completeness, correctness and
consistency)

30
 Cont…
• To start with class modeling, identify objects
and classes, prepare a data dictionary, identify
associations between objects, identify class
attributes and initial set of operations and then
organize object classes using inheritance.
• This process can be initiated from CRC model.

31
Cont…

32
Modeling Classes, Methods and Attributes
• Representation of an object, template of which objects are
created
• Modeled as rectangle with three sections
• Model your classes to an appropriate level of detail
– Eg. Take out address as a class

Name

Attributes

Methods

33
 Modeling Relationship
• Most common types of relationships between classes
– Associations(has-a)
• represents the relationships between two classes. It can be
unidirectional or bi-directional.
– Aggregation
• Implies a relationship where the child can exist
independently of the parent
– Composition
• implies a relationship where the child cannot exist
independent of the parent.
– Inheritance
• represents is-a relation ship among classes
• Each of these relationships provides a different way of combining
our abstractions (classes)

34
UML symbol for each relationship

35
 Association
• An association is a generic relationship between two
classes, and is modelled by a line connecting the two
classes. It may contain multiplicity of the objects.
• we can navigate from an object of one class to an
object of the other class, and vice versa
• Types of association: -
– Unary association
• where both ends of an association circle back to the same
class
– Binary association
• connects exactly two classes
– N-ary association
• connects more than two classes
36
• Graphically, an association is shown as a solid
line connecting the same or different classes

37
• There are 4 adornments that apply to
associations: -
– Name
• An association can have a name to describe
the nature of the relationship
• A direction can also be given to the name by
providing a direction triangle that points in
the direction intended (to read the name)
name Name Direction

Works for
Person Company

association
38
– Role
• When a class participates in an association, it has
a specific role that it plays in the relationship
• A role is just the face that the class at the near end
of the association presents to the class at the
other end of the association
• An explicit name can be given to the role a class
plays in an association

association

Person Company
employee employer

role name 39
– Multiplicity
• It is important to state how many objects may be
connected across an instance of an association
• This “how many” is called multiplicity of an association’s
role
• It is written as an expression that evaluates to a range of
values or an explicit value
• Multiplicity can be written as multiplicity of
– exactly one (1) • one or more (1..*)
– zero or one (0..1) • exact numbers, i.e
3
– many (*)
multiplicity

1..* *
Person Company
employee employer

40
Inheritance

41
Inheritance

42
 Inheritance

Public class Checkingaccount extends BankAccount {

//Functionalities unique to Checkingaccount
//Modifications
}
43
 – Aggregation
• is a “whole-part” relationship within which one or more smaller class
are “part” of a larger “whole”
• represents a “has-a” relationship, whereby an object of the whole class
has objects of the part
• It is a kind of relationship in which the child is independent of its parent.

aggregation
whole

Engine
Car
Transmission

part 44
 Composition : If a class can not exist by itself , and instead
must be a member of another class , then that class has a
composition relationship with the containing class.

45
Class diagram for student enrolment in university

46
Class diagram for online shopping

47
class diagram for student cafeteria management system
(Inheritance)

48
 User Interface Prototyping
• Is an iterative analysis task in which users are
actually participating in making up of the UI for a
system
• Steps
– Determine the need (from essential UI model
which was on a paper)
– Build the prototype using tools like HLL
• Consider the platform (web based – HTML or Window
based – VB)
– Evaluate the prototype
• By the SME
49
Got Questions?

50