Software Engineering

Chapter 4
Object Oriented Analysis
 Object Oriented Analysis
 In object-oriented analysis, developers build a model describing
the application domain.
 For example, the analysis model of a watch describes how the
watch represents time (e.g., Does the watch know about leap years?
Does it know about the day of the week? Does it know about time zone?)
 The analysis model is then extended to describe how the
actors and the system interact to manipulate the application
domain model (e.g., How does the watch owner reset the
time? How does the watch owner reset the day of the week?).
 Developers use the analysis model, together with nonfunctional
requirements, to prepare for the architecture of the system
developed during high-level design
 Object Oriented Analysis
 Motivation
◦ What do you see?

Two faces looking at each other? If you focus more

closely on the white area, you can see a vase instead. Once you
are able to perceive both shapes individually, it is easier to switch
back and forth between the vase and the faces.
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
 Object Oriented Analysis
 Motivation
 Formalization helps identify areas of ambiguity
as well as inconsistencies and omissions in a
system specification.
 Once developers identify problems with the
specification, they address them by eliciting
more information from the users and the client.
 Requirements elicitation and analysis are
iterative and incremental activities that occur
 WHAT IS ANALYSIS?
 The process of studying and analyzing the customer and the user
needs to arrive at a definition of the problem domain and system
requirements
 Objectives
 Discover the boundaries of the new system (or software) and how it must
interact with its environment within the new problem domain
 Detect and resolve conflicts between (user) requirements
 Negotiate priorities of stakeholders
 Elaborate system requirements, defined in the requirement
specification document, such that managers can give realistic
project estimates and developers can design, implement, and test
 Evaluate requirements for desirable qualities
6
 WHAT IS ANALYSIS?
 Analysis focuses on producing a model of the system, called the
analysis model, which is correct, complete, consistent, and
verifiable.
 Analysis is different from requirements elicitation in that
developers focus on structuring and formalizing the
requirements elicited from users
 Translating a system specification into a formal or semiformal
model forces developers to identify and resolve difficult issues
early in the development.
 The analysis model is composed of three individual models:
the functional model , represented by use cases and scenarios,
the analysis object model , represented by class and object
7 diagrams, and the dynamic model, represented by statechart
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
Object Oriented Analysis Concepts
 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.
Analysis Rules of Thumb
 The model should focus on requirements that are visible
within the problem or business domain.
 Each element of the requirements model should add to
an overall understanding of software requirements and
provide insight into the information domain, function,
and behavior of the system.
 Minimize coupling throughout the system.
 Be certain that the requirements model provides value to
all stakeholders.
 Keep the model as simple as it can be
Object Oriented Analysis (functional
model )
 There are two basic flavors of use case models: essential
use case models and system use case models. An essential
use case model—often referred to as a task case model
or an abstract use case model—models a technology-
independent view of your behavioral requirements.
 System use case models, also known as concrete use case
models or detailed use case models, model your analysis
of your behavioral requirements, describing in detail
how users will work with your system, including
references to its user-interface aspects.
Object Oriented Analysis (functional
model )
 A system use case model is composed of a use case
diagram and the accompanying documentation
describing the use cases, actors, and associations.
 During your analysis efforts you make decisions
regarding what will be built, information reflected in
your use cases
System Use Case model )

 A system use case model is composed of a use case

diagram and the accompanying documentation
describing the use cases, actors, and associations.
 During your analysis efforts you make decisions
regarding what will be built, information reflected in
your use cases
 System Use Case Description
Name: Enroll in Seminar
Identifier UC 17:
Description:
Enroll an existing student in a seminar for which she is eligible.
Preconditions: The Student is registered at the University.
Postconditions:
The Student will be enrolled in the course she wants if she is eligible and room is available.
Basic Course of Action:
1.The use case begins when a student indicates they want to enroll in a seminar.
2.The student inputs her name and student number into the system via UI23 Security Log-in Scre
3.The system verifies the student is eligible to enroll in seminars at the university according to bus
rule BR129 Determine Eligibility to Enroll. [Alt Course A]
4.The system displays UI32 Seminar Selection Screen, which indicates the list of available semin
5.The student indicates the seminar in which she wants to enroll. [Alt Course B: The Student Dec
to Enroll]
6.The system validates the student is eligible to enroll in the seminar according to the business ru
BR130 Determine Student Eligibility to Enroll in a Seminar. [Alt Course C]
7.The system validates the seminar fits into the existing schedule of the student according to the
business rule BR143 Validate Student Seminar Schedule.
Alternate Course A: The Student is Not Eligible to Enroll in Seminars.
A.3. The registrar determines the student is not eligible to enroll in seminars.
A.4. The registrar informs the student he is not eligible to enroll.
A.5. The use case ends.
Alternate Course B: The Student Decides Not to Enroll in an Available Seminar
System Use Case scenarios
 Name: Enroll in Seminar
 Description:
A student wants to enroll in a seminar so he submits his name and student
number to the registrar; therefore, he may be validated to become an eligible
student at the university. Once the registrar verifies him, the student indicates
the seminar he wants to enroll in from the list of those available. The registrar
validates the student is eligible to enroll in the seminar and that the seminar fits
into the student's existing schedule. The registrar calculates the fees for the
seminar—based on the fee published in the course catalog, applicable student
fees, and applicable taxes—and informs the student. The registrar verifies with
the student that he still wants to enroll in the seminar, and then enrolls the
student in the seminar. The registrar adds the appropriate fees to the student's
bill and provides the student with a confirmation that he is enrolled.
Reuse in Use Case Models: <<extend>>,
<<include>>, and Inheritance
 Potential reuse can be modeled through four relationships supported by UML
use case models: extend relationships between use cases, include relationships
between use cases, inheritance between use cases, and inheritance between
actors.
Use Case Modeling Tips
 Associations between actors and use cases indicate the need for
interfaces
 Write use cases under the assumption that you can exit at any time
 Write scenario text, not functional requirements (It does not describe
what the UI looks like or how it works)
 Remember the system responses to the actions of actors.
 Alternate courses of action are important.
 Organize your use case diagrams consistently.
 Create a use case template
 Object Oriented Analysis Concepts
analysis object model
 Class-based modeling represents the objects that the
system will manipulate, the operations that will be applied
to the objects to effect the manipulation, relationships
between the objects, and the collaborations that occur
between the classes that are defined.
 The elements of a class-based model include classes and
objects, attributes, operations, class responsibility
 Analysis Concepts
 entity, boundary, and control objects
 association multiplicity
 qualified associations
 Identifying Analysis Classes
 Classes are determined by underlining each noun or noun
phrase and entering it into a simple table
 Analysis classes manifest themselves in one of the following
ways:
 External entities that produce or consume information to
be used by a computer-based system.
 Things (e.g., reports, displays, letters, signals) that are
part of the information domain for the problem.
 Structures (e.g., sensors, four-wheeled vehicles, or
computers) that define a class of objects or related classes
of objects.
 Identifying Analysis Classes
 Analysis classes manifest themselves in one of the following
ways:
 Occurrences or events (e.g., a property transfer or the
completion of a series of robot movements) that occur within
the context of system operation.
 Roles (e.g., manager, engineer, salesperson) played by
people who interact with the system.
 Organizational units (e.g., division, group, team) that are
relevant to an application.
 Places (e.g., manufacturing floor or loading dock) that
establish the context of the problem and the overall function
of the system.
 Analysis Activities: class modeling
Identifying Attributes
 Attributes are properties of individual objects.
 When identifying properties of objects, only the attributes relevant to the
system should be considered
 Attributes have:
 a name identifying them within an object.
 A brief description
 A type describing the legal values it can take.
Defining Operations: Operations define the behavior of an object.
Although many different types of operations exist, they can generally be
divided into four broad categories:
 (1) operations that manipulate data in some way.
 (2) operations that perform a computation,
 (3) operations that inquire about the state of an object, and
 (4) operations that monitor an object for the occurrence of a controlling
 Object Oriented Analysis Concepts
Entity, Boundary, and Control class
 The analysis object model consists of entity, boundary, and
control class
 Entity classes: also called model or business classes, are extracted
directly from the statement of the problem These classes typically represent
things that are to be stored in a database and persist throughout the
duration of the application.
 Boundary classes : are used to create the interface (e.g., interactive screen
or printed reports) that the user sees and interacts with as the software is used.
Entity objects contain information that is important to users, but they do not
display themselves. Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
 Control classes: manage a “unit of work” from start to finish. That
is, controller classes can be designed to manage (1) the creation or
update of entity objects, (2) the instantiation of boundary objects as
they obtain information from entity objects, (3) complex
 Analysis Activities:
Identifying Associations
 class diagrams allow developers to describe the spatial
connectivity of objects.
 An association shows a relationship between two or more classes.
 Identifying associations has two advantages.
 First, it clarifies the analysis model by making relationships between objects
explicit.
 Second, it enables the developer to discover boundary cases associated
with links.
 Boundary cases are exceptions that need to be clarified in the model
 Analysis Activities: From Use Cases to Objects
Identifying Associations
Associations have several properties:
 A name, to describe the association between the two classes. Association
names are optional and need not be unique globally.
 A role at each end, identifying the function of each class with respect to
the associations.
 A multiplicity at each end, identifying the possible number of instances .
Heuristics for identifying associations
 Examine verb phrases.
 Name associations and roles precisely.
 Use qualifiers as often as possible to identify namespaces and key attributes.
 Eliminate any association that can be derived from other associations.
 Do not worry about multiplicity until the set of associations is stable.
 Avoid ravioli models: Too many associations make a model unreadable.
Analysis Activities: From Use Cases to Objects
Identifying Associations
 Object Oriented Analysis Concepts
Association Multiplicity Revisited
 As we saw in Chapter 2, Modeling with UML, the end of an
association can be labeled by a set of integers called multiplicity
 The multiplicity indicates the number of links that can legitimately
originate from an instance of the class connected to the association
end .
 In UML, an association end can have an arbitrary set of integers
as a multiplicity
 In practice, however, most of the associations we encounter
belong to one of the following three types
 Object Oriented Analysis Concepts
Association Multiplicity Revisited
 A one-to-one association : has a multiplicity 1 on each end.
A one-to-one association between two classes, means that
exactly one link exists between instances of each class.
 A one-to-many association : has a multiplicity 1 on one end
and 0..n (also represented by a star) or 1..n on the other. A one-
to-many association between two classes (e.g., Person and Car )
denotes composition.
 A many-to-many association has a multiplicity 0..n or 1..n
on both ends. A many-to many association between two classes
denotes that an arbitrary number of links can exist between
instances of the two classes.
 Object Oriented Analysis Concepts
Association Multiplicity Revisited

Examples of multiplicity (UML class diagram). The association between

Person and SocialSecurityNumber is one-to-one. The association between
Person and Car is one-to-many. The association between Person and
Company is many-to-many.

Adding multiplicity to associations increases the amount of information we

capture from the application or the solution domain.
 Object Oriented Analysis Concepts
Qualified Associations

 Qualification: is a technique for reducing multiplicity by

using keys class. Often, in the case of a one-to-many
association, objects on the “many” side can be distinguished from
one another using a name.
 For example, in a hierarchical file system, each file belongs to
exactly one directory. Each file is uniquely identified by a name
in the context of a directory. Many files can have the same name
in the context of the file system; however, two files cannot share
the same name within the same directory.
 Without qualification , the association between Directory and
File has a one multiplicity on the Directory side and a zero-to-
many multiplicity on the File side.
 Object Oriented Analysis Concepts
Qualified Associations
 We reduce the multiplicity on the File side by using the
filename attribute as a key, also called a qualifier.
 The relationship between Directory and File is called a
qualified association.

 Reducing multiplicity is always preferable, as the model

becomes clearer and fewer cases have to be taken into account.
 Developers should examine each association that has a one-to
many or many-to-many multiplicity and check if a qualifier can
be added.
 Object Oriented Analysis Concepts
Generalization
 As we saw in Chapter 2, Modeling with UML, generalization
enables us to organize concepts into hierarchies.
 At the top of the hierarchy is a general concept, and at the
bottom of the hierarchy are the most specialized concepts.
 There may be any number of intermediate levels in between,
covering more-or-less generalized concepts.
 inheritance is a reusability technique. If a class Child inherits
from a class Parent, all the attributes and methods available on
Parent are automatically available on Child.
 During analysis, we only focus on the organization of concepts
into generalization relationships and should not be interpreted
in terms of reuse (in object design).
 Modeling Generalization Relationships Between Objects
 Generalization is used to eliminate redundancy from the analysis model. If two or more
classes share attributes or behavior, the similarities are consolidated into a superclass
 Analysis Activities: CREATING A BEHAVIORAL
MODEL
 We can represent the behavior of the system as a function of
specific events and time.
 The behavioral model indicates how software will respond to
external events or stimuli.
 To create the model, you should perform the following steps:
 Evaluate all use cases to fully understand the sequence of
interaction within the system.
 Identify events that drive the interaction sequence and
understand how these events relate to
 specific objects.
 Create a sequence for each use case.
 Build a state and activity diagram for the system.
 Review the behavioral model to verify accuracy and
consistency.
 Analysis Activities: From Use Cases to Objects
 Identifying Events with the Use Case:
 The use case represents a sequence of activities that involves
actors and the system. In general, an event occurs whenever the
system and an actor exchange information. A use case is
examined for points of information exchange
 The underlined portions of the use case scenario indicate
events.
 An actor should be identified for each event; the information
that is exchanged should be noted, and any conditions or
constraints should be listed.
 Once all events have been identified, they are allocated to the
objects involved. Objects can be responsible for generating
events or recognizing events that have occurred elsewhere.
 Analysis Activities: From Use Cases to Objects
 State Representations:
 In the context of behavioral modeling, two different
characterizations of states must be considered:
 (1) The state of each class as the system performs its function
and
 (2) The state of the system as observed from the outside as the
system performs its function.
 Analysis Activities: From Use Cases to Objects
Modeling Interactions Between Objects: Sequence Diagrams
 A sequence diagram ties use cases with objects. It shows how the behavior
of a use case (or scenario) is distributed among its participating objects.
 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
 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
 Analysis Activities: From Use Cases to Objects
Modeling Interactions Between Objects: Sequence Diagrams
 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 model the diagrams from the main flow of events,
or the alternate flow of events, or the scenarios, of each
use case
 Analysis Activities: From Use Cases to Objects
Modeling Interactions Between Objects: Sequence Diagrams
Heuristics for drawing sequence diagrams

 The first column should correspond to the actor who initiated

the use case.
 The second column should be an boundary object (that the
actor used to initiate the use case).
 The third column should be the control object that manages
the rest of the use case.
 Control objects are created by boundary objects initiating use
cases.
 Boundary objects are created by control objects.
 Entity objects are accessed by control and boundary objects.
 Entity objects never access boundary or control objects, this makes it
easier to share entity objects across use cases.
In analysis, sequence diagrams are used to help identify new
 Analysis Activities: From Use Cases to Objects
Modeling the Montrivial Behavior of Individual Objects: state chart
 Sequence diagrams are used to distribute behavior across objects and to
identify operations. Sequence diagrams represent the behavior of the
system from the perspective of a single use case.
 Statechart diagrams represent behavior from the perspective of a single
object.
 Viewing behavior from the perspective of each object enables the
developer, on the one hand, to identify missing use cases, and, on the other
hand, to build a more-formal description of the behavior of the object.
 Note that it is not necessary to build statecharts for every class in the
system.
 Analysis Activities: From Use Cases to Objects
Reviewing the Analysis Model
 The analysis model is built incrementally and iteratively. The analysis model is seldom
correct or even complete on the first pass.
 Once the analysis model becomes stable (i.e., when the number of changes to the model
are minimal and the scope of the changes localized), the analysis model is reviewed, first
by the developers (i.e., internal reviews), then jointly by the developers and the client
 The goal of the review is to make sure that the system specification is correct, complete,
consistent, and realistic.
 The review can be facilitated by a checklist or a list of questions
 The following questions should be asked to ensure that the model is correct:
 Is the glossary of entity objects understandable by the user?
 Do abstract classes correspond to user-level concepts?
 Are all descriptions in accordance with the users’ definitions?
 Do all entity and boundary objects have meaningful noun phrases as names?
 Do all use cases and control objects have meaningful verb phrases as names?
 Are all error cases described and handled?
 Are the start-up and the shut-down phases of the system described?
 Are the administration functions of the system described?
 Analysis Activities: From Use Cases to Objects
Reviewing the Analysis Model
 The following questions should be asked to ensure that the model is complete:
 For each object: Is it needed by any use case? In which use case is it created? modified?
destroyed? Can it be accessed from an boundary object?
 For each attribute: When is it set? What is its type? Should it be a qualifier?
 For each association: When is it traversed? Why was the specific multiplicity chosen? Can associations with
one-to-many and many-to-many multiplicities be qualified?
 For each control object: Does it have the necessary associations to access the objects participating in its
corresponding use case?

 The following questions should be asked to ensure that the

model is consistent:
 Are there multiple classes or use cases with the same name?
 Do entities (e.g., use cases, classes, attributes) with similar names denote similar phenomena?
 Are all entities described at the same level of detail?
 Are there objects with similar attributes and associations that are not in the same generalization hierarchy?
 Analysis Activities: From Use Cases to Objects
Reviewing the Analysis Model
 The following questions should be asked to ensure that the
system described by the analysis model is realistic:
 Are there any novel features in the system? Were there any
studies or prototypes built to ensure their feasibility?
 Can the performance and reliability requirements be met?
Were these requirements verified by any prototypes running
on the selected hardware?
Analysis Summary Basic Tasks
 The requirements activity is highly iterative and
incremental
 Developing and validating
 (System) Use case model
 Sequence Diagram
 Conceptual Class Model (analysis level)
 State chart/Activity Diagram
 UI prototyping
 Documenting Analysis
 As we saw in the previous chapter, the requirements elicitation
and analysis activities are documented in the Requirements
Analysis Document (RAD).
 We have already been written during requirements elicitation.
During analysis, we revise these sections as ambiguities and new
functionality is discovered.
 Documenting Analysis
Requirements Analysis Document
 1. Introduction
 2. Current system
 3. Proposed system
 3.1 Overview
 3.2 Functional requirements
 3.3 Nonfunctional requirements
 3.4 Pseudo requirements
 3.5 System models
 3.5.1 Scenarios
 3.5.2 Use case model
 3.5.3 Object model
 3.5.3.1 Data dictionary
 3.5.3.2 Class diagrams
 3.5.4 Dynamic models
 3.5.5 User interface—navigational paths and screen mock-ups
End of the chapter