CHAPTER SIX

Analysis

Analysis model
Entity, boundary and control class/object
Dynamic model/ state chart
 An Overview of Analysis
• Analysis results in a model of the system that aims to be correct, complete,
consistent, and unambiguous.

• Developers formalize the requirements specification produced during requirements

elicitation and examine in more detail boundary conditions and exceptional cases.

• Developers validate, correct and clarify the requirements specification if any errors
or ambiguities are found.

• The client and the user are usually involved in this activity when the requirements
specification must be changed and when additional information must be gathered.
 An Overview of Analysis
• The analysis workflow of the Unified Process has two overall aims.

• From the viewpoint of the requirements workflow (the preceding workflow), the
aim of the analysis workflow is to obtain a deeper understanding of the
requirements.

• From the viewpoint of the design and implementation workflows (the workflows
that follow the analysis workflow), the aim of the analysis workflow is to
describe those requirements in such a way that the resulting design
and implementation are easy to maintain.
 An Overview of 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.

• 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 diagrams, and
• the dynamic model, represented by state machine and sequence diagrams.
An Overview of Analysis

Products of requirements elicitation and analysis (UML activity

diagram).
Analysis Models
 Analysis Object Models and
Dynamic Models
• Analysis object model is a part of the analysis model and focuses on the individual
concepts that are manipulated by the system, their properties and their
relationships.

• Depicted with UML class diagrams, includes classes, attributes, and operations.

• Is a visual dictionary of the main concepts visible to the user.

 Analysis Object Models and Dynamic Models
• The dynamic model focuses on the behavior of the system. The dynamic model is
depicted with sequence diagrams and with state machines.

• Sequence diagrams represent the interactions among a set of objects during a

single use case.

• State machines represent the behavior of a single object (or a group of very tightly
coupled objects).

• The dynamic model serves to assign responsibilities to individual classes and, in

the process, to identify new classes, associations, and attributes to be added to
the analysis object model.
• Both models represent user-level concepts, not actual software classes or
components.

• For example, classes such as Database, Session Manager, Network should not
 Entity, Boundary, and Control Objects
• The analysis object model consists of entity, boundary, and control objects.

• Entity objects represent the persistent information tracked by the system.

• Boundary objects represent the interactions between the actors and the system.

• Control objects are in charge of realizing use cases.

Generalization and
Specialization
• Inheritance 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.
 Analysis Activities: From Use Cases to Objects

• The following are the activities that transform the use cases and scenarios
produced during requirements elicitation into an analysis model. Generally
analysis activities include:
• Identifying Entity Objects
• Identifying Boundary Objects
• Identifying Control Objects
• Mapping Use Cases to Objects with Sequence Diagrams
• Modeling Interactions among Objects with CRC Cards
• Identifying Associations
• Identifying Aggregates
• Identifying Attributes
• Modeling State-Dependent Behavior of Individual Objects
• Modeling Inheritance Relationships
• Reviewing the Analysis Mode
 Identifying Entity Objects
• Noun extraction / natural language analysis
• found by examining each use case and identifying candidate objects.
 Using natural language analysis
• Pioneered by Russell Abbott (1983), popularized by Grady Booch
• Not perfect, but coupled with other techniques, it's a good start
• This can be done from a general problem description, or better, from a use
case or scenario
• Map parts of speech to object model components.
• nouns usually map to classes, objects, or attributes
• verbs usually map to operations or associations
Using natural language analysis
 Identifying Entity Objects
• Heuristics for identifying entity objects
• Terms that developers or users need to clarify in order to understand the use
case
• Recurring nouns in the use cases
• Real-world entities that the system needs to track
• Real-world activities that the system needs to track
• Data sources or sinks
 Identifying Boundary Objects
• Heuristics for identifying boundary objects
• Identify user interface controls that the user needs to initiate the use case (e.g.,
Report Emergency Button).
• Identify forms the users needs to enter data into the system (e.g., Emergency
Report Form).
• Identify notices and messages the system uses to respond to the user (e.g.,
Acknowledgment Notice).
• When multiple actors are involved in a use case, identify actor terminals (e.g.,
Dispatcher Station) to refer to the user interface under consideration.
• Do not model the visual aspects of the interface with boundary objects.
• Always use the end user’s terms for describing interfaces; do not use terms from
the solution or implementation domains.
 Identifying Control Objects
• Heuristics for identifying control objects
• Identify one control object per use case.
• Identify one control object per actor in the use case.
• The life span of a control object should cover the extent of the use case or the
extent of a user session. If it is difficult to identify the beginning and the end of a
control object activation, the corresponding use case probably does not have well-
defined entry and exit conditions.

• Ex: report emergency control and manage emergency control.

Mapping Use Cases to Objects with 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.
• Sequence diagrams are usually not as good a medium for communication with
the user as use cases are, since sequence diagrams require more background
about the notation.

• Sequence diagrams represent another shift in perspective and allow the

developers to find missing objects or grey areas in the requirements
specification.
Mapping Use Cases to Objects with 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 a 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
 Modeling Interactions among Objects with CRC Cards

• A class responsibility collaborator model is a collection of standard index

cards that have been divided into three sections.

• A class represents a collection of similar objects, a responsibility is something that

a class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities.

• For each class, the software development team fills in a card showing the name
of the class, its functionality (responsibility), and a list of the other
classes it invokes to achieve that functionality (collaboration).
Introduction to CRC

Example CRC card

Introduction to CRC

CRC cards model for Process new order use case

Introduction to CRC

Examples of CRC cards for the ReportEmergencyControl and the

Incident classes.
Introduction to CRC
• CRC models are an incredibly effective tool for conceptual modeling as well as
for detailed design.

• The strength of CRC cards is that, when utilized by a team, the interaction
among the members can highlight missing or incorrect fields in a class,
whether attributes or methods.

• Also, the relationships between classes are clarified when CRC cards are used.

• One especially powerful technique is to distribute the cards among the team
members, who then act out the responsibilities of their classes.
Introduction to CRC
• A weakness of CRC cards is that this approach generally is not a good way of
identifying entity classes unless the team members have considerable
experience in the relevant application domain.

• On the other hand, once the developers have determined many of the classes
and have a good idea of their responsibilities and collaborations, CRC cards
can be an excellent way of completing the process and making sure that
everything is correct.
Introduction to CRC
• So how do you create CRC models? Iteratively perform the following steps:

• Find classes
• Find responsibilities.
• Define collaborators.
• Move the cards around.
 Mapping Use Cases to Objects with Sequence Diagrams

• CRC cards and sequence diagrams are two different representations for supporting
the same type of activity.

• Sequence diagrams are a better tool for a single modeler or for documenting a
sequence of interactions, because they are more precise and compact.

• CRC cards are a better tool for a group of developers refining and iterating over an
object structure during a brainstorming session, because they are easier to create
and to modify
 Identifying Associations
• class diagrams allow developers to describe the interdependencies 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 must be clarified in the model.
• Name, role and multiplicity are properties of association.
• Initially, the associations between entity objects are the most important, as they
reveal more information about the application domain.
 Identifying Associations
• associations can be identified by examining verbs and verb phrases denoting a
state
(e.g., has, is part of, manages, reports to, is triggered by, is contained in, talks to,
includes).
• Every association should be named, and roles should be assigned to each end.
 Identifying Aggregates
• Aggregations are special types of associations denoting a whole–part relationship.

• A State is composed of a number of Counties that are, in turn, composed of a

number of Townships.

• An aggregation is shown as a association with a diamond on the side of the whole

part.

• A composition aggregation indicates that the existence of the parts depends on

the whole. For example, a County is always part of exactly one State, a Township is
always part of a County.
 Identifying Attributes
• Attributes are properties of individual objects.
• When identifying properties of objects, only the attributes relevant to the system
should be considered.
• Developers should identify as many associations as possible before identifying
attributes to avoid confusing attributes and objects.
• Attributes have a name and type.
• Often, attributes are discovered or added late in the development when the
system is evaluated by the users. Unless the added attributes are associated with
additional functionality, the added attributes do not entail major changes in the
object (and system) structure.
Identifying Attributes
• Heuristics for identifying attributes
• Examine possessive phrases.
• Represent stored state as an attribute of the entity object.
• Describe each attribute.
• Do not represent an attribute as an object; use an association instead.
• Do not waste time describing fine details be
 Modeling State-Dependent
Behavior of Individual Objects
• Sequence diagrams are used to distribute behavior across objects and to identify
operations.

• It represent the behavior of the system from the perspective of a single use case.

• State machine diagrams represent behavior from the perspective of a single

object.

• Viewing behavior from the perspective of each object enables the developer to
build a more formal description of the behavior of the object, and consequently,
to identify missing use cases.
 Modeling Inheritance 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.
 Reviewing the Analysis Model
• The analysis model is built incrementally and iteratively.
• The analysis model is not often correct or even complete on the first pass.
• Several iterations with the client and the user are necessary before the analysis
model converges toward a correct specification usable by the developers for design
and implementation.
• Once the number of changes to the model are minimal and the scope of the
changes
localized, the analysis model becomes stable.
• Then 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 requirements specification is correct,
complete, consistent, and unambiguous.
 Reviewing the Analysis Model
• 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?
 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 a 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?
Reviewing the Analysis Model
• 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 concepts?
• Are there objects with similar attributes and associations that are not in the
same generalization hierarchy
Analysis Summary