Object-Oriented Software

engineering

Chapter 4
Object Oriented
Analysis
Recall
Requirement
gathering/elicitation
Traditional methods (interview,
questionnaire, observation….)
Essential modeling
Essential use case
Domain modeling using CRC
Essential UI Prototype
Supplementary Specification
Object Oriented Analysis
Motivation
Although our requirement
elicitation model are effective in
understanding what our users
want to have built, it is not
effective in understanding what
will be built.
Needs formalization and
structuring
 WHAT IS ANALYSIS?
Analysis is a process of separating a whole into its
component parts. Understanding the
requirements.
Analysis is about: problems rather than solutions ,
What rather than how , discovery rather than invention ,
decomposition rather than recombination
Present the problem as it is
Analysis must discover and understand
requirements including decisions on the system’s
scope and how it should behave.
OOA:A method of analysis that examines
requirements from the perspective of the classes and
objects found in the vocabulary of the problem
domain.
4
Object Oriented Analysis
The analysis phase will be used to understand
what to build.
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.
Cont…
Requirements analysis in systems
engineering and software engineering,
encompasses those tasks that go into
determining the needs or conditions to
meet for a new or altered product, taking
account of the possibly conflicting
requirements of the various stakeholders,
such as beneficiaries or users.
Requirements analysis is critical to the
success of a development project.
Cont…
Requirements must be
actionable, measurable,
testable, related to identified
business needs or opportunities,
and defined to a level of detail
sufficient for system design.
Requirements can be functional
and non-functional.
 Cont…
Object-oriented analysis (OOA) looks at the
problem domain, with the aim of producing
a conceptual model of the information that
exists in the area being analyzed.
Analysis models do not consider any
implementation constraints that might
exist.
The result of object-oriented analysis is a
description of what the system is
functionally required to do, in the form of a
conceptual model.
Cont…
The artifacts used in the requirement gathering
phase will be used to provide the starting idea to
the analysis phase artifacts.
The following diagram shows which artifact is
related or need information from which one.
System developers need to consult the connected
artifacts in the following diagram during the
usage of the artifacts in the analysis phase.
As an example, while developing analysis level
class diagram, one has to take information from
the list of business rules, the CRC Model and the
User Interface flow diagram.
Requirement gathering and analysis
linked..
Requirement Artifacts Analysis Artifacts

Essential Use Case Model Use Case Model

Sequence Diagram
Business Rules Activity Diagram

CRC Model Class Model (Analysis

Level)

User Interface Flow User Interface Prototype

Diagram

Essential
User Interface Prototype
 THE GOALS OF ANALYSIS
To understand the problem or problems that
the eventual system should solve.
To prompt relevant questions about the
problem and the system.
To provide a basis for answering questions
about specific properties of the problem and
system
To decide what the system should do and To
decide what the system should not do
To ascertain that the system will satisfy the
needs of its users, and define acceptance
criteria.
To provide a basis for the development of
the system.
11
 ANALYZING REQUIREMENTS
Identify all the use cases of the system
Identify all of the actors, and their
relevance to your work
Identify the primary, secondary and
exception pathways through each use
case
Identify the main system classes,
objects and relationships (or
interactions)
List the technological options available
for the project
12
Cont…
Identify the navigation required within
and between use cases from the point
of view of the actors
Create rough mockups of the user
interfaces - if there are any
Identify the intended deliverables of
the project
Create a list of the terms used, and
the definition of any data items so far
discovered. In a large project, or an
ongoing one, these definitions will be
recorded in a data dictionary.
Basic Tasks
Developing and validating
(System) Use case model
Sequence Diagram
Conceptual Class Model (analysis
level)
Activity Diagram
UI prototyping
Evolving Supplementary
specifications
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.
The use case diagram and the documentation
will have same components as the essential use
case model with little technology influence.
Cont…
The Use Case documentation needs
information like:
List of Actors
List of Business Rules (BR)
List of User Interfaces (UI)
 The template will be the same as the essential
use case documentation except that the
“Include” and “Extend” part will be exercised
(included) at this level.
The following example describes one of the
use cases from the previous use case diagram.
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
How?
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
Sequence diagram
 A sequence diagram is an interaction
diagram that emphasizes the time
ordering of messages
 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
A sequence diagram has four
key elements: -
Objects appear along the top
margin
Each object has a lifeline, which is
a dashed line that represent the life
and perhaps death of the object
Most objects will be in existence for the
duration of the interaction
Objects may also be created during the

20
interaction, or destroyed
Cont…
A focus of control, which is a tall thin
rectangle that sits on top of an
object’s lifeline
It shows the period of time during which
an object is performing an action, either
directly or through subordinate procedure
The bottom part of a focus of control can
be marked by a return message
Messages show the actions that
objects perform on each other and on
themselves
You built sequence diagrams or collaboration
diagrams from the use-case and class
diagrams that were built before.
Each use cases in a use-case diagram has
its corresponding sequence or collaboration
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 or collaboration diagram, MUST
have its corresponding class in the class
diagram
22
To model a sequence diagram: -
Set the context for the interaction
Whether it is a system, subsystem, operation,
class or a scenario of a use case or collaboration
Identify which objects play a role in the
interaction
Place them from left-to-right, at the top of the
diagram
Set the lifeline for each object
Starting with the message that initiates the
interaction, layout each subsequent message
from top to bottom between each lifelines

23
Activity Modeling
Activity diagrams describe the
workflow behavior of a system.
They are typically used for
business process modeling, for
modeling the logic captured by a
single use case or usage
scenario, or for modeling the
detailed logic of a business rule.
Cont…
UML activity diagrams could
potentially model the internal
logic of a complex operation.
In many ways UML activity
diagrams are the object-
oriented equivalent of flow
charts.
Cont…
Activity diagrams do not give detail
about how objects behave or how
objects collaborate.
Diagrams are read from top to bottom
and have branches and forks to
describe conditions and parallel
activities.
A fork is used when multiple activities
are occurring at the same time.
 Cont…
Activity diagrams show the
sequence of activities in a process,
including sequential and parallel
activities.
Symbols are used for activities,
decisions and so on.
Arrows represent events that
connect the activities.

18-27
 Creating Activity Diagrams
Ask what happens first,
second, and so on.
Determine if the activities
happen in sequence or
parallel.
Examine all the scenarios
for a use case.
18-28
Activity Diagram: Example

Draw an Activity Diagram to

depict (show) the major
processes/tasks in the effort of
developing system/software.
Analysis level Class Diagram
Also called conceptual model
Focused on identification of the
vocabulary of the system
Classes and objects
Classes for completeness and
objects for understanding
Relationships
List attributes and methods
 Cont…
How?
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
Cont…
Extract attributes and methods
from responsibilities
Review the model with
stakeholders (users)
For 3 Cs (completeness, correctness
and consistency)
Class Diagram

Example: A case
Mapping example
Using backward engineering, model what
the following code is representing?
 class School {
Name name;
String address;
Number phone;
void addStudent() {}
void removeStudent() {}
void getStudent() {}
void getAllStudents() {}
void addDepartment() {}
void removeDepartment() {}
void getDepartment() {}
void getAllDepartments() {}}
UI prototyping
Is an iterative analysis task in which users
are actually participating in mocking 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
Evolving Supplementary
specifications
It is to be recalled you have
indentified Supplementary
specifications at the elicitation stage
Now at the analysis stage you are
required to evolve it by adding
more and clarifying the existing
one.
End of the chapter