Chapter 4Object Oriented Analysis

Object-Oriented System Analysis and Design

Recall thatRequirement gathering/elicitationTraditional methods (interview, questionnaire, observation….)

Essential modeling Essential use caseDomain modeling using CRCEssential UI Prototype

Object Oriented AnalysisMotivation

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

4

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 isAnalysis 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.

Object Oriented AnalysisThe 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..

Essential Use Case Model

Business Rules

CRC Model

User Interface Flow Diagram

Essential User Interface Prototype

User Interface Prototype

Class Model (Analysis Level)

Sequence Diagram

Use Case Model

Activity Diagram

Requirement Artifacts Analysis Artifacts

11

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.

12

ANALYZING REQUIREMENTSIdentify 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

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 TasksDeveloping and validating

(System) Use case modelSequence DiagramConceptual Class Model (analysis level)

Activity DiagramUI prototypingEvolving Supplementary specifications

System Use case ModelingThe 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 ActorsList 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 documentationName Sell ItemIdentifier UC-008

Description Sell available items in a store to a customerActor Sales Clerk

Pre Condition nonePost Condition The sales clerk will sell the item if available in store

Extends noneIncludes UC-001

Basic Course of Action1.The Sales Clerk want to sell an item2.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 Menu5.The system displays the Sell interface “UI-006: Sell Item”6.The Sales Clerk selects the items and quantity he want to sell7.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 voucher11.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 store8.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 modelingIdentify use cases

Already covered under essential use case modelingDefine relationshipsDraw the diagram using tools like Ms-Visio or

Rational RoseDocument each use case

19

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

20

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 objectMost objects will be in existence for the

duration of the interactionObjects may also be created during the

interaction, or destroyed

Cont…A focus of control, which is a tall thin rectangle that sits on top of an object’s lifelineIt 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

22

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

23

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 interactionPlace them from left-to-right, at the top of the

diagramSet the lifeline for each objectStarting with the message that initiates the

interaction, layout each subsequent message from top to bottom between each lifelines

Activity ModelingActivity 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.

18-27

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-28

Creating Activity DiagramsAsk what happens first, second, and so on.

Determine if the activities happen in sequence or parallel.

Examine all the scenarios for a use case.

Draw an Activity Diagram to depict (show) the major

processes/tasks in the effort of developing system/software.

Activity Diagram: Example

Analysis level Class DiagramAlso called conceptual modelFocused on identification of the

vocabulary of the systemClasses and objects

Classes for completeness and objects for understanding

RelationshipsList 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 – AbebeCommon noun- class – customerDoing verb- (operations)method- login, creates, selectsAdjectives- attributes – order descriptionHaving 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 4 Cs (completeness, correctness

and consistency, clearness)

Example: A case

Class Diagram

Mapping exampleUsing 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 prototypingIs an iterative analysis task in which users

are actually participating in mocking up of the UI for a system

StepsDetermine the need (from essential UI

model which was on a paper)Build the prototype using UI Design

tools. Consider the platform (web based – HTML or

Window based – VB)Evaluate the prototype

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