Analysis
• Unit 1
• CS 387T
• Dr. Doaa Sami Khafaga
• These slides are based on Chapter 5 from the course main textbook:
Bernd Bruegge and Allen H. Dutoit. Object-Oriented Software
Engineering Using UML, Patterns, and Java, 3rd Edition, Prentice Hall,
2010.
1
Object-oriented software
engineering
Technical Activities:
Requirements Elicitation
Analysis
System Design
Object Design
Implementation
Testing
An Overview of
Analysis
3
An Overview of Analysis
Analysis focuses on producing a model of the system.
The model is called the analysis model.
Analysis is a stage in software development that comes after
Requirements Elicitation.
Analysis aims to translate a requirements specification into a formal or
semiformal model that is useful for developers to identify and resolve
problems early in the development.
Requirements elicitation and analysis are iterative and
incremental activities that occur concurrently.
4
Products of Requirements
Specification and Analysis
5
The Analysis Model
6
The Analysis Model
The analysis model represents the system under development
from the user’s point of view.
The analysis model is composed of:
The functional model (represented by use cases and scenarios)
The analysis object model (represented by class and object diagrams)
The dynamic model (represented by state machine and sequence
diagrams)
7
The Analysis Model
8
Analysis Concepts
Analysis Object Models
Entity, Boundary, and Control Objects
Generalization and Specialization
9
1- Analysis Object Model
The analysis object model focuses on the individual concepts that are
manipulated by the system, their properties, and their relationships.
When depicted with UML class diagrams, it includes classes, attributes, and
operations.
The analysis object model should only include user-level concepts,
not actual software classes or components.
Classes such as Database, Subsystem, SessionManager, Network should not
appear in the analysis model.
Most classes in the analysis object model will correspond to one or more
software classes in the source code. However, the software classes will include
many more attributes and associations than their analysis counterparts.
10
Example
SatWatch, a watch that resets itself without user intervention
11
Analysis Object Model
12
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.
This three-object-type approach leads to models that are more
resilient to change:
The interface to the system (represented by the boundary objects) is
more likely to change than its basic functionality (represented by the
entity and control objects).
13
Example
2Bwatch.
Consider a watch with two buttons (hereafter called 2Bwatch). Setting the
time on 2Bwatch requires the actor 2BWatchOwner to first press both buttons
simultaneously, after which 2Bwatch enters the set time mode. In the set time
mode, 2Bwatch blinks the number being changed (e.g., the hours, minutes,
seconds, day, month, or year). Initially, when the 2BWatchOwner enters the
set time mode, the hours blink. If the actor presses the first button, the next
number blinks (e.g, if the hours are blinking and the actor presses the first
button, the hours stop blinking and the minutes start blinking). If the actor
presses the second button, the blinking number is incremented by one unit. If
the blinking number reaches the end of its range, it is reset to the beginning
of its range (e.g., assume the minutes are blinking and its current value is 59,
its new value is set to 0 if the actor presses the second button). The actor exits
the set time mode by pressing both buttons simultaneously.
14
Entity, Boundary, and Control
Objects
2Bwatch example
15
Naming Conventions
Control objects should have the suffix Control appended to
their name.
Boundary objects should be named such that it is clear that
they represent an interface feature e.g., by including the suffix
Form, Button, Display, Page, or Boundary appended to
their name.
Entity objects usually do not have any suffix appended to their
name.
16
3- Generalization and
Specialization
Using inheritance we can organize concepts into hierarchies:
At the top of the hierarchy is a general concept.
The most specialized concepts are at the bottom of the hierarchy.
Generalization is the modeling activity that identifies abstract
concepts from lower-level ones.
Specialization is the modeling activity that identifies more
specific concepts from a high-level one.
Generalization and specialization result in the specification of
inheritance relationships between concepts.
17
Generalization and Specialization
18
Analysis Activities: From Use
Cases to Objects
19
Analysis Activities
These activities transform the use cases and scenarios produced
during requirements elicitation into an analysis model:
Identifying Entity Objects
Identifying Boundary Objects
Identifying Control Objects
Mapping Use Cases to Objects with Sequence Diagrams
Identifying Associations
Identifying Aggregations
Identifying Attributes
Modeling State-Dependent Behavior of Individual Objects
Modeling Inheritance Relationships
20
1- Identifying Entity Objects
Entity objects represent the persistent information tracked by the system.
Each use case is examined to identify candidate objects.
Abbot’s heuristic is a natural language analysis technique that
maps parts of text or speech (e.g., nouns) to model
components (e.g., objects).
21
Example
22
Abbot’s Heuristic
23
Limitations of Natural Language
Analysis
The quality of the object model depends highly on the style
of writing of the analyst.
Natural language is an imprecise tool.
There are many more nouns than relevant classes.
Many nouns can be synonyms for other nouns.
24
Heuristics for Identifying Entity
Objects
Recurring nouns in the use cases (e.g., Student)
Real-world entities that the system needs to track (e.g.,
Course)
Real-world activities that the system need to track (e.g.,
PaymentRecord, TravelPlan)
Data sources or sinks (e.g., Printer)
Actors (e.g., Student)
25
Identifying Boundary Objects
Boundary objects represent the system interface with the
actors.
In each use case, each actor interacts with at least one
boundary object.
The boundary object collects the information from the actor
and translates it into a form that can be used by both entity
and control objects.
Boundary objects model the user interface at a coarse level.
They do not describe in detail the visual aspects of the user
interface.
Boundary objects such as “menu item” or “scroll bar” should be
avoided.
26
Heuristic for Identifying Boundary
Objects
Identify forms through which the users need to enter data into
the system (e.g., CourseSelectionForm)
Identify notices and messages that the system uses to respond
to the user (e.g., AcknowledgementNotice)
One boundary object is needed for each actor in a use case.
Always use the end user’s terms for referring to interfaces. Do
not use terms from the solution or implementation domains.
27
Example
28
3-Identifying Control Objects
Control objects are responsible for coordinating boundary and
entity objects.
There is a close relationship between a use case and a control
object:
A control object is usually created at the beginning of a use case and
ceases to exist at its end.
A control object manages the order of the interactions between the
actors and the system in the use case.
A control object collects information from the boundary objects and
dispatches it to entity objects.
29
Heuristics for Identifying Control
Objects
Identify one control object per use case.
The life span of a control object should cover the extent of the
use case.
30
Example
31
4-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 a scenario) is
distributed among participating objects.
Sequence diagrams help to model the order of the interaction
among the objects in a use case.
Sequence diagrams help to assign responsibilities to each
object in the form of a set of operations.
32
Example
33
the ReportEmergency use case is clarified to
include the additional information
37
Heuristics for Drawing Sequence
Diagrams
The first column should correspond to the actor who initiated the
user case (the use case’s primary actor).
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.
38
6- Identifying Associations
As association shows a relationship between two or more
classes.
For example, a FieldOfficer writes an EmergencyReport
Associations have several properties:
A name
A role at each end
A multiplicity at each end
39
Heuristics for Identifying
Associations
Examine verb phases.
Name associations and roles precisely.
Eliminate any association that can be derived from other
associations.
Too many associations make a model unreadable.
40
7- Identifying Aggregates
Aggregations are special types of associations denoting a whole-part
relationship.
E.g, a FireStation consists of a number of FireFighters, FireEngines, Ambulances,
and a LeadCar. A State is composed of a number of Counties that are, in turn,
composed of a number of Townships.
There are two types of aggregation:
Shared aggregation relationship: the whole and the part can exist independently.
E.g, although a FireEngine is part of at most one FireStation at the time, it can be reassigned to a
different FireStation during its life time.
Composition aggregation relationship: the existence of the parts depends on the
whole.
E.g, a County is always part of exactly one State, As political boundaries do not change
often.
41
Composition and Shared
Aggregations
42
8- Identifying Attributes
Attributes are properties of individual objects.
Attributes have:
A name.
A type.
43
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 (see Section Association).
Do not waste time describing fine details before the object
structure is stable.
44
Modeling State-Dependent
Behavior of Individual Objects
State machine diagrams represent behavior of the system from
the perspective of a single object.
Do not build state machines for every class in the system.
Rather, only objects with an extended lifespan and state-dependent
behavior are worth considering.
State machine diagrams are useful to identify missing use cases.
45
UML State Machine Diagrams
A state is a condition satisfied by the attributes of an object.
E.g., an Incident object in FRIEND can exist in four states: Active,
Inactive, Closed, and Archived.
We can represent these states with a single attribute in the Incident
class—a status attribute that can take any of four values: Active,
Inactive, Closed, and Archived.
A transition represents a change of state triggered by events,
conditions, or time.
E.g., the Incident class depicts three transitions: from the Active state
into the Inactive state, from the Inactive state to the Closed state, and
from the Closed state to the Archived state.
46
UML State Machine Diagrams
A state is depicted by a rounded rectangle.
A transition is depicted by an open arrow connecting two states.
States are labeled with their name.
A small solid black circle indicates the initial state.
A circle surrounding a small solid black circle indicates a final
state.
47
State
An abstraction of the attributes of a
classState is the aggregation of several attributes a class
A state is an equivalence class of all those attribute values and
links that do no need to be distinguished
Example: State of a bank
State has duration
State machine for the SetTime use
case
49
State machine for the Incident
class
50
State Chart Diagram vs Sequence
Diagram
State chart diagrams help to identify:
Changes to an individual object over time
Sequence diagrams help to identify:
The temporal relationship of between objects over time
Sequence of operations as a response to one ore more events.
Important to Remember!!
The analysis model is built incrementally and iteratively
Several iterations with the client and the end user are necessary before
the analysis model converges toward a correct specification usable by
the developers for design and implementation.
The analysis model needs to be reviewed:
First, by developers (internal reviews).
Then, jointly by the developers and the client.
The review can be facilitated by a checklist or a list of questions.
The analysis model needs to be correct, complete, consistent,
unambiguous, realistic, and verifiable.
52
Object-Oriented Analysis and
Design
There are three main Object-Oriented (OO)
principles:
Encapsulation (information hiding): By hiding the
implementation details that are likely to change,
encapsulation allows for flexibility in design.
Inheritance: allows software reuse.
Polymorphism: an object can behave differently and
assume different forms based on its inheritance hierarchy.
53
OO analysis and Design
When identifying the classes, it is important to take the
following Design Principles into consideration:
Principle of Decoupling
Ensuring Cohesion
Open-Closed Principle
54
Principle of Decoupling
A system with a set of highly interdependent classes is very
hard to maintain because a change in one class may result in
cascading updates of other classes.
55
Principle of Decoupling
GraphicDisplaySystem
GraphicDisplaySystem
-drawCicle()
-drawRectange()
-drawTriangle()
+drawShapes()
+drawShapes()
Shape
Shape
+draw()
Rectangle
Triangle
(a)
56
Circle
Rectangle
Triangle
+draw()
+draw()
(b)
Circle
+draw()
Ensuring Cohesion
A cohesive class is one that performs a set of closely related
operations.
Less-cohesive systems are hard to manage, expand, maintain, and
modify.
57
Ensuring Cohesion
RegistrarOffice
AppForGraduation
Assignment
58
Professor
-studentRecords : object
-courseMaterials : object
+prepareGradApp() : object
-verifyDegree() : object
-adviseCurriculum() : object
+getLectureNotes() : object
+getAssignment() : object
CourseMaterials
Student
StudentRecords
LectureNote
Ensuring Cohesion
«interface»
Advisor
+prepareGradApp() : object
RegistrarOffice
AppForGraduation
Assignment
59
Professor
-studentRecords : object
-courseMaterials : object
+prepareGradApp() : object
-verifyDegree() : object
-adviseCurriculum() : object
+getLectureNotes() : object
+getAssignment() : object
CourseMate
rials
«interface»
Instructor
+getLectureNotes() : object
+getAssignments() : object
Student
StudentRecords
LectureNote
Open-Closed Principle
The system should have the ability to be extended to meet new
requirements (Open to extension)
The existing design and code of the system should not be
modified as a result of system expansion (Closed to
Modification)
60
Open-Closed Principle
Implications:
Separate interface and implementation
Keep attributes private
Minimize the use of global variables
Separate entity, boundary, and control classes.
61
The End for Unit I
62