Object-Oriented System Analysis

and Design
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 interaction, or
destroyed

20
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