Chapter 5

CHAPTER – FIVE
OBJECT ORIENTED SYSTEM

ANALYSIS
1
Outline
– Introduction
– An overview of Analysis
– Analysis concepts and activities
• Entity, boundary and Control objects
• Association Multiplicity, Qualified Associations,
Generalization.
• Identifying Entity objects, Boundary objects,
Control objects
• Modeling interaction between objects
• Identifying Associations and Attributes
2
Introduction...
• In the previous chapter, we described :

– how to elicit requirements from the users and
– describe them as use cases and scenarios.
• In this chapter, we describe how to:

– refine the functional model
– derive the object and
– the dynamic model.
3
Introduction...
• In object-oriented analysis, developers build a model

describing the application domain.
• Developers use the analysis model, together with non-
functional requirements, to prepare for the architecture of
the system developed during high-level design (eg. System
design).
• In this chapter, we discuss the analysis activities in more detail:
 the identification of objects
 their behavior
 their relationships
 their classification, and
 their organization.
4
An Overview of Analysis
 Analysis focuses on producing a model of the system, called the
analysis model, which is correct, complete, and consistent.
Fig1:Products of requirements elicitation and analysis (UML activity diagram).5

An Overview of Analysis...
The analysis model is composed of three individual

models:
1-The functional model- represented by use cases and

scenarios.
2-The analysis object model- represented by class

and object diagrams.
3-The dynamic model- represented by state chart

and sequence diagrams.
6
Fig 2: The OO analysis model
7
Analysis Concepts
• In this section, we describe the main analysis
concepts used in this chapter. In particular, we
describe:
– Entity, boundary and Control objects.
– Association
– Multiplicity Have already been discussed in
modelling with UML.
– Generalization.
8
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 -represent the tasks that are
performed by the user and supported by the
system.
9
Entity, Boundary, and Control Objects
• Example 1:If you take watch:
- Year, Month, Day are entity objects;
- Button and LCDDisplay are boundary objects;
- ChangeDate is a control object that represents the
activity of changing the date by pressing combinations of
buttons.
Fig. Analysis class for watch example
10
Analysis Activities: From Use Cases to Objects
• In this section, we describe the activities that transform the use cases
and scenarios produced during requirements elicitation into an
analysis model.
• Analysis activities include:

- identifying entity objects
- identifying boundary objects
- identifying control objects
- mapping use cases to objects
- identifying associations among objects
- identifying object attributes
- modelling objects’s behavior with state charts
- modelling generalization relationships
- reviewing the analysis model
• We illustrate each activity by focusing on the ReportEmergency use
11
case of FRIEND described in Requirements Elicitation.
Identifying Entity Objects
• Participating objects form the basis of the

analysis model.
• Participating objects are found by examining
each use case and identifying candidate
objects.
• Natural language analysis [Abbott, 1983] is an
intuitive set of heuristics for:
 identifying objects,
 attributes,
and associations from a system specification.
12
Identifying Entity Objects...
• Abbott’s heuristics maps parts of speech:

– nouns,
– having verbs,
– being verbs,
– adjectives.
to model components:
• objects,
• operations,
• inheritance relationships,
• classes.
• Table 1 provides examples of such mappings by
examining the ReportEmergency use case. 13
• Use case name - ReportEmergency

• Description-Activate incident management system
whenever incident is occurred.
• Participating actors- FieldOfficer, Dispatcher
• Precondition- The FieldOfficer activates the
“ReportEmergency” function of his/her terminal.
• Postcondition - The FieldOfficer receives the
acknowledgment and the selected response.
Basic course of action:
– The FieldOfficer fills the form by selecting the emergency
level,type, location, and brief description of the situation.
14
– FieldOfficer also describes possible responses to
the emergency situation.
– Once the form is completed, the FieldOfficer
submits the form, at which point the Dispatcher is
notified.
– The Dispatcher reviews the submitted information
and creates an Incident in the database by invoking
the OpenIncident use case.
– The Dispatcher selects a response and
acknowledges the emergency report.
– The FieldOfficer receives acknowledgment.
– The Usecase ends.
15
16
• Heuristics for identifying initial analysis objects:
– frequent nouns in the use cases (e.g., Incident)

– real-world entities that the system needs to keep track
of (e.g., FieldOfficer, Dispatcher, Resource)
– real-world activities that the system needs to keep
track of (e.g., EmergencyOperationsPlan)
– use cases (e.g., ReportEmergency)
– data sources or sinks (e.g., Printer)
– interface artifacts (e.g., Station)
17
Identifying Objects…
• Objects can be:

– External Entity (e.g., other systems, devices,
people) that produce or consume information to be
used by system
– Things (e.g., reports, displays, letters, signals) that
are part of information domain for the problem
– Places (e.g., book’s room) that establish the
context of the problem and the overall function of
the system.
– Organizational units (e.g., division, group, team,
department) that are relevant to an application,
– Transaction (e.g., loan, take course, buy, order).
18
 Some of the entity objects for ReportEmergeny use
case are:
• Dispatcher -- Police officer who manages Incidents.
A Dispatcher opens documents, and closes Incidents
in response to EmergencyReports.
• EmergencyReport-- Initial report about an Incident
from a FieldOfficer to a Dispatcher.
An EmergencyReport usually triggers the creation of
an Incident by the Dispatcher.
• FieldOfficer-- Police or fire officer on duty.
• Incident -- Situation requiring attention from a
FieldOfficer.
19
Identifying Boundary Objects
• Boundary objects represent the system interface with the actors.
• The boundary object collects information from the actor and
translates it into an interface that can be used by the entity
objects and also by the control objects.
 Heuristics for identifying boundary objects

• Identify forms and windows the users needs to enter data into
the system (e.g.,EmergencyReportForm, ReportEmergencyButtonForm).
• Identify notices and messages the system uses to respond to the
user (e.g., AcknowledgmentNotice).
• Always use the user’s terms for describing interfaces as opposed
to terms from the implementation technology.
20
Identifying Boundary Objects...
• These are some of boundary objects by examining the
ReportEmergency use case:
 AcknowledgmentNotice - Notice used for displaying
the Dispatcher’s acknowledgment to the FieldOfficer.
 DispatcherStation - Computer used by the Dispatcher.
 ReportEmergencyButton- Button used by a
FieldOfficer to initiate the ReportEmergency use case.
 ReportEmergencyForm- Form used for the input of the
ReportEmergency form.
 FieldOfficerStation - Mobile computer used by the
FieldOfficer.
21
Identifying Control Objects
• Control objects are responsible for coordinating

boundary and entity objects.
– It is responsible for collecting information from the
boundary objects and dispatching it to entity objects.
• For example, control objects describe the

behaviour associated with:
1- the sequencing of forms
2- undo and history queues, and
3- dispatching information in a distributed system.
22
A control object is usually created at the
beginning of a use case and ceases to exist at its end.
 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 be extent of
the use case or the extent of a user session.
23
Identifying control objects…
• Here is the model for the control flow of the

ReportEmergency use case with a control object for
each actor;
- ReportEmergencyControl -for the FieldOfficer
and
- ManageEmergencyControl -for the Dispatcher,
respectively.
24
 ReportEmergencyControl - Manages the report
emergency reporting function on the FieldOfficerStation.
– This object is created when the FieldOfficer selects the
“Report Emergency” button.
– It then creates an EmergencyReportForm and presents it
to the FieldOfficer.
 ManageEmergencyControl - Manages the report

emergency reporting function on the DispatcherStation.
– This object is created when an EmergencyReport is
received.
– It then creates an IncidentForm and displays it to the
Dispatcher.
25
Modelling Interactions Between Objects
 Sequence Diagrams
• A sequence diagram ties use cases with objects.
– It shows how the behaviour of a use case (or scenario) is
distributed among its participating objects.
• In this section, we model the sequence of interactions

among objects needed to realize the use case.
• The following three figures show sequence diagrams
associated with the ReportEmergency use case.
26
Sequence Diagrams...
• The columns of a sequence diagram represent

the objects that participate in the use case.
• The leftmost column is the actor who initiates
the use case.
• Horizontal arrows across columns represent
messages, or stimuli, which are sent from one
object to the other.
• Time proceeds vertically from top to bottom.
27
Sequence diagram for the ReportEmergency use case
(initiation from the FieldOfficerStation side).
28
(DispatcherStation).
29
(acknowledgment on the FieldOfficerStation).
30
 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.
• Entity objects are accessed by control and boundary objects.
31
Sequence Diagrams...
 By constructing sequence diagrams:

1- we can model the order of the interaction among the
objects.
2- we also distribute the behaviour of the use case.
 In other terms, we assign to each object

responsibilities in the form of a set of operations.
 In OO analysis, sequence diagrams are used to
help identify:
1- new participating objects and
2- missing behaviour.
32
Identifying Associations
• Sequence diagrams -allow developers to represent

interactions among objects over time.
• Class diagrams- allow developers to describe the
connectivity of objects.
• In this section, we discuss the use of class diagrams for
representing associations among objects.
• In the next Section, we discuss the use of class diagrams
for representing object attributes.
• An association shows a relationship between two or
more classes.
33
Associations have several properties:
• A name, to describe the association between the two classes (e.g., Writes)
• A role at each end, identifying the function of each class with respect to the
associations (e.g., author is the role played by FieldOfficer in the Writes
association).
• A multiplicity at each end, identifying the possible number of instances
e.g.,
- * indicates a FieldOfficer may write zero or more
EmergencyReports.
- 1 indicates that each EmergencyReport has exactly one FieldOfficer
as author.
34
 Identifying Attributes
• Attributes are properties of individual objects.
• When identifying properties of objects, only the attributes relevant to the
system should be considered.
• For example,
• FieldOfficers are identified by badge number, represented by the
badgeNumber property.
Attributes of the EmergencyReport class.

35
Attributes…
 Attributes have:
• a name identifying them within an object.
 an EmergencyReport may have a
reportType attribute and an emergencyType
attribute.
• A brief description.
• A type describing the legal values it can take.
 the description attribute of an
EmergencyReport is a string.
36
Modelling the Behaviour of Individual Objects
 Sequence diagrams are used to distribute behaviour

across objects and to identify operations.
 Sequence diagrams represent the behaviour of the
system from the perspective of a single use case.
 Statechart diagrams represent behaviour from the
perspective of a single object.
• Viewing behaviour from the perspective of each object
enables the developer:
- To identify missing use cases.
- To build a more-formal description of the behavior of
the object.
37
• The following Figure displays a statechart for the
Incident class.
The examination of this statechart may help the

developer check if there are use cases for
documenting, closing, and archiving Incidents.
38
Modelling 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.
• For example,
– Dispatchers and FieldOfficers both have a
badgeNumber attribute that serves to identify them
within a city.
39
• FieldOfficers and Dispatchers are both
PoliceOfficers who are assigned different functions.
• To model explicitly this similarity, we introduce an
abstract PoliceOfficer class from which the
FieldOfficer and Dispatcher classes inherit.
fig: An example of
inheritance relationship
(UML class diagram).
40
OO Analysis Summary
• The requirements activity is highly iterative and
incremental.
• Chunks of functionality are sketched and proposed to
the users and the client.
• The client may add:
- additional requirements
- criticizes existing functionality
- modifies existing requirements.
• The following Figure depicts a typical sequence of the

analysis activities we described in this chapter.
41
Analysis activities (UML activities diagram)
42
Managing Analysis
1. first describe a document template that can be

used to document the results of analysis
2. describe the role assignment to analysis
3. then address communication issues during

analysis and
4. address management issues related to the

iterative and incremental nature of requirements
43
Documenting Analysis
• requirements elicitation and analysis activities are
documented in the Requirements Analysis
Document (RAD)
44
Assigning Responsibilities
• Analysis requires the participation of a wide range of
stakeholders.
• User:
– provides application domain knowledge
– generates information about the
• current system,
• environment of the future system, and
• the tasks it should support
• Client:
– funds the project and coordinates the user side of the effort
– serves as an integrator of application domain information and resolves
inconsistencies in user expectations
– defines the scope of the system based on user requirements
• Analyst:
– Elicits/extracts application domain knowledge and formalizes it.
– models the current system and generates information about the future
system 45
Assigning Responsibilities…
• Architect:
– plays the role of integration, unifies the use case and object models from
a system point of view
– provide a system model and identify missing informations (tasks,
behaviors, objects) in the requirements
• Developers:
– provide feedback on feasibility and cost
• project manager: coordinates the effort on the development side.
• Reviewer: validates the RAD for correctness,

completeness, consistency, realism, verifiability, and
traceability.
– Users, clients, developers, or other individuals may become reviewers
during requirements validation.
46
Assigning Responsibilities
• These individual introduce challenges for

integration and communication requirements
of the project.
• These challenges can be met by assigning well-
defined roles and scopes to individuals.
• There are three main types of roles:
– generation of information,
– integration, and
– Review
47
Communicating about Analysis
• communicating information is most challenging during
requirements elicitation and analysis
– Different background of participants
– Different expectations of stakeholders
– New teams
• team members must learn how to work together
– Existed system
• team members have experience working together
– 3 generic team organizations:

» Centralized – Control Team Organization
» Decentralized – Control Team Organization
» Mixed – Control Team Organization 48
Conflicting views
• Conflicting objectives and competition will
always be part of large development projects.
• guidelines in managing the complexity of
conflicting views of the system:
– Define clear boundaries.
– Define clear objectives and success criteria.
– Brainstorm by preparing meeting, workshop,…
49
Iterating Over the Analysis Model
• Analysis occurs iteratively and incrementally, often
in parallel with other development activities such
as
– system design and
– implementation
• Unrestricted modification and extension of the
analysis model can only result in confusion
• Iterations and increments need to be carefully
managed, otherwise it will enter into infinite list of
interests/ requirments
50
Exercise/Quiz
Software System for Library Management System
Possible requirements
The librarian can use the system in four ways. Firstly it is
possible to add a new book to the system. Secondly, if a
book is out of loan, it is possible for the librarian to make a
reservation for a customer. It should also be possible to
loan books. Finally, a librarian should also be able to
return a book to the system when a customer hands a
previously borrowed book in. Before performing anyone of
the above operation, librarian should login to the system.
Students and staff members can borrow books.
51
Exercise/Quiz
Software System for Library Management
System
 Requirements elicitation activities:
• identifying actors
• identifying scenarios
• identifying use cases
• identifying relationships among use cases
• identifying initial participating objects (class diagram)
• identifying non-functional requirements
• Sequence diagram for one use case
• State chart diagram for one object (Book)
52
Library System: UML use case diagram
53
Library System: UML class diagram
• From the problem description and use case diagrams it is easy
to identify the objects involved in the system: The library, the
books, and the librarian, and login service.
• We specify the objects by specifying the classes with their
attributes and services (methods) they provide.
• In UML this is done by a class diagram. This diagram also
includes specifications of relations between the objects.
• The next class diagram shows the four classes Book, Library,
LoginService and Librarian and how they are related to each
others.
• Internal attributes and methods are also shown in the figure.
54
Library System: UML class diagram
55
Library System: UML sequence diagram for loan book use case
56
Library System: UML state chart diagram
57
Exercise: Analyze class Model for Bank Accounts Management System
• This system provides the basic services to manage bank accounts at a

bank called OCBank. OCBank has many branches, each of which has an
address and branch number. A client opens accounts at a branch. Each
account is uniquely identified by an account number; it has a balance and
a credit or overdraft limit. There are many types of accounts, including: A
mortgage account (which has a property as collateral), a chequing
account, and a credit card account (which has an expiry date and can have
secondary cards attached to it). It is possible to have a joint account (e.g.
for a husband and wife). Each type of account has a particular interest
rate, a monthly fee and a specific set of privileges (e.g. ability to write
cheques, insurance for purchases etc. OCBank is divided into divisions
and subdivisions (such as Planning, Investments and Consumer), the
branches are considered subdivisions of the Consumer Division. Each
division has a manager and a set of other employees. Each customer is
assigned a particular employee as his or her ‘personal banker’.
58
Exercise: Analyze class Model for OCBank System
• This system provides the basic services to manage bank accounts at a bank called
OCBank. OCBank has many branches, each of which has an address and branch
number. A client opens accounts at a branch. Each account is uniquely identified
by an account number; it has a balance and a credit or overdraft limit. There are
many types of accounts, including: A mortgage account (which has a property as
collateral), a chequing account, and a credit card account (which has an expiry
date and can have secondary cards attached to it). It is possible to have a joint
account (e.g. for a husband and wife). Each type of account has a particular
interest rate, a monthly fee and a specific set of privileges (e.g. ability to write
cheques, insurance for purchases etc. OCBank is divided into divisions and
subdivisions (such as Planning, Investments and Consumer), the branches are
considered subdivisions of the Consumer Division. Each division has a manager
and a set of other employees. Each customer is assigned a particular employee as
his or her ‘personal banker’.
Marking nouns: potentially good classes, definitely bad classes,
and classes we are unsure about 59
Exercise: Analyze class Model for Bank Accounts
Management System
Client
1..2
accountHolder
Draft Class Diagram with classes Client
and Account, and their association
*
Account
accountNumber
type
x60
Draft Class Diagram with Client

Account attributes and * 1..2
accountHolder
subclasses
*
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance
creditOrOverdraftLimit
ChequingAccount MortgageAccount CreditCardAccount
61
Client
Draft Class Diagram with * 1..2
accountHolder
CreditCard and attributes of
Account subclasses
*
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
name
1..*

collateralProperty expiryDate
brand
62
Classes Associations Attributes Generalizations
• This system provides the basic services to manage bank accounts at a bank
called OCBank. OCBank has many branches, each of which has an address
and branch number. A client opens accounts at a branch. Each account is
uniquely identified by an account number; it has a balance and a credit or
overdraft limit. There are many types of accounts, including: A mortgage
account (which has a property as collateral), a chequing account, and a credit
card account (which has an expiry date and can have secondary cards attached
to it). It is possible to have a joint account (e.g. for a husband and wife). Each
type of account has a particular interest rate, a monthly fee and a specific set
of privileges (e.g. ability to write cheques, insurance for purchases etc.
OCBank is divided into divisions and subdivisions (such as Planning,
Investments and Consumer), the branches are considered subdivisions of the
Consumer Division. Each division has a manager and a set of other
employees. Each customer is assigned a particular employee as his or her
‘personal banker’. 63
Employee Client
* 1..2
Draft Class Diagram with personalBanker accountHolder
Branch and Employee

Branch
* *
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
balance CreditCard
name
1..*

brand
64
worksFor
subdivision
*
OrganizationalUnit 0..1
manager
0..1 *
0..1
Employee Client
* 1..2
personalBanker accountHolder
Branch
* *
Account
accountNumber
openedDate
closedDate
Draft Class Diagram interestRate
monthlyFee
with
balance CreditCard
name
OrganizationalUnit 1..*

brand
x66
worksFor
subdivision
*
manager
0..1 *
0..1
AccountType Employee Client
* 1..2
interestRate personalBanker
monthlyFee accountHolder
checksAllowed
insuranceAvailable
Branch *
* *
Account
accountNumber
openedDate
closedDate
interestRate
monthlyFee
Draft Class Diagram balance
CreditCard
with AccountType name

1..*

brand x69
worksFor
Person
subdivision name
*
manager
0..1 *
0..1
AccountType Employee Client
* 1..2
interestRate personalBanker
monthlyFee accountHolder
checksAllowed
insuranceAvailable
periodicFee
period
Branch *
* *
address Account
number accountNumber
openedDate
Bank Account System

closedDate
interestRate
monthlyFee
Class diagram with balance
CreditCard
final touches name

1..*

brand
x70
Company database
• The company is organized into departments. Each department has a unique
name, a unique number and a particular employee who manages the
department. We keep track of the start date when that employee began
managing the department. A department may have several locations.
• A department controls a number of projects, each of which has a unique
name, a unique number and a single location.
• An Employee can be Technician, Engineer, or typist.
• An Employee can also be salaried employee or hourly pay. employee
• We store each employee’s name, Social Security number, address, salary, sex
and birth date. An employee is assigned to one department but may work on
several projects, which are not necessarily controlled by the same
department. We keep track of the number of hours per week that an
employee works on each project. We also keep track of the direct supervisor
of each employee.
• A project can be Hydropower, Wind, and Solar Energy.
• We want to keep track of the dependents of each employee for insurance

purposes. We keep each dependent’s first name, sex, birth date and
relationship to the employee.
71
THANK YOU
?
72

Chapter 5

Uploaded by

Copyright:

Available Formats

Chapter 5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 5

Uploaded by

Copyright:

Available Formats

CHAPTER – FIVE

OBJECT ORIENTED SYSTEM

• In the previous chapter, we described :

• In this chapter, we describe how to:

• In object-oriented analysis, developers build a model

Fig1:Products of requirements elicitation and analysis (UML activity diagram).5

The analysis model is composed of three individual

1-The functional model- represented by use cases and

2-The analysis object model- represented by class

3-The dynamic model- represented by state chart

– Entity, boundary and Control objects.

• The analysis object model - consists of entity,

Fig. Analysis class for watch example

• Analysis activities include:

• Participating objects form the basis of the

• Abbott’s heuristics maps parts of speech:

• Use case name - ReportEmergency

– frequent nouns in the use cases (e.g., Incident)

• Objects can be:

 Heuristics for identifying boundary objects

• Control objects are responsible for coordinating

• For example, control objects describe the

 Heuristics for identifying control objects:

• Here is the model for the control flow of the

 ManageEmergencyControl - Manages the report

• In this section, we model the sequence of interactions

• The columns of a sequence diagram represent

• The first column should correspond to the actor who initiated

 By constructing sequence diagrams:

 In other terms, we assign to each object

• Sequence diagrams -allow developers to represent

Attributes of the EmergencyReport class.

 Sequence diagrams are used to distribute behaviour

The examination of this statechart may help the

• Generalization is used to eliminate redundancy

• The following Figure depicts a typical sequence of the

1. first describe a document template that can be

3. then address communication issues during

4. address management issues related to the

• project manager: coordinates the effort on the development side.

• Reviewer: validates the RAD for correctness,

• These individual introduce challenges for

– 3 generic team organizations:

• This system provides the basic services to manage bank accounts at a

Draft Class Diagram with Client

ChequingAccount MortgageAccount CreditCardAccount

ChequingAccount MortgageAccount CreditCardAccount

Branch and Employee

ChequingAccount MortgageAccount CreditCardAccount

ChequingAccount MortgageAccount CreditCardAccount

with AccountType name

ChequingAccount MortgageAccount CreditCardAccount

Bank Account System

final touches name

ChequingAccount MortgageAccount CreditCardAccount

• We want to keep track of the dependents of each employee for insurance

You might also like