Object-Oriented Analysis

Domain Analysis

class taxononmies
techncial literature
SOURCES OF reuse standards DOMAIN
DOMAIN existing applications DOMAIN ANALYSIS
KNOWLEDGE ANALYSIS functional models MODEL
customer surveys
domain languages
expert advice

current/future requirements
 Domain analysis is performed when an
organization wants to create library of
reusable components that will broadly
applicable to an entire category of
applications
Reuse and domain analysis

 Two teams
 Team A does not have class library
 Team B uses robust class library
Domain analysis process

 Define the domain to be investigated

 Categorize the items extracted from the
domain
 Collect a representative sample
 Analyze each application in the sample
 Develop an analysis model for the objects
Three ways to do Object Oriented Analysis
 Conceptual model (Larman)
 Produce a “light” class diagram.
 CRC cards (Beck, Cunningham)
 Index cards and role playing.
 Analysis model with stereotypes (Jacobson)
 Boundaries, entities, control.
What is CRC card?
 An effective way to analyze scenarios
 First was proposed by Beck & Cunningham as a tool for
teaching OO programming.
 As a development tool that facilitates brainstorming &
enhances communication among developers.
 The cards are arranged to show the flow of messages among
instances of each class.
 As team members walk through the scenario,
 they may assign new responsibilities to an existing class,
 group certain responsibilities to form a new class or
 divide responsibilities of one class into more fine grained ones
 Perhaps distribute these responsibilities to a different class.
Why CRC Cards?

 Help you identify objects and their

responsibilities
 Help you understand how the objects interact
 Cards form a useful record of design activity
 Cards work well in group situations and are
understandable by non-technical stakeholders.

Object-Oriented Analysis
 CRC Cards
CRC cards rely on small pieces of paper (approx 15cm x 8cm)
used by members of a team to identify classes.

Class Name:

Responsibilities Collaborations

Responsibilities of a class Collaborations with other

are listed in this section. classes are listed here,
together with a brief
description of the purpose of
the collaboration.

12/08/2021 9
CRC definitions

 responsibility: knowledge class maintains or

service class provides

 collaborator: a class whose knowledge or

services are needed to fulfill a responsibility
Too many responsibilities – low cohesion;
too many collaborations – high coupling.
CRC cards are not part of UML notation.
CRC Cards © Wolfgang Pelz 2000-04
Scenario 1: The Ticker Ticks

 The SecondsTicker
pulses the Clock

Object-Oriented Analysis
Scenario 1: The Ticker Ticks

 The SecondsTicker
pulses the Clock
 The Clock updates
Time

Object-Oriented Analysis
 Scenario 1: The Ticker Ticks

• The SecondsTicker
pulses the Clock
• The Clock updates
Time
• Time updates itself

Object-Oriented Analysis
Scenario 2: Clock Responds with the
Time
 Display the time

Object-Oriented Analysis
Scenario 2: Clock Responds with the
Time
 Display the time
 Return hours,
minutes, & seconds

Object-Oriented Analysis
Scenario 2: Clock Responds with the
Time
 Display the time
 Return hours,
minutes, & seconds
 Translate the time
into the display
format

Object-Oriented Analysis
Testing during the OOA Phase
 CRC cards are an excellent testing technique

CS540 Software Design Lecture 14 & 15 19

CRC Cards
 Consider responsibility
 1. Turn on elevator button
 Totally unacceptable for object-oriented
paradigm
 Responsibility-driven design ignored
 Information hiding ignored
 Responsibility
1. Turn on elevator button
should be
1. Send message to Elevator Button to turn itself on

CS540 Software Design Lecture 14 & 15 20

CRC Cards (contd)

 A class has been overlooked

 Elevator doors have a state that changes during
execution (class characteristic)
 Add class Elevator Doors
 Safety considerations
 Reconsider class model
 Then reconsider dynamic model, use-case
model

CS540 Software Design Lecture 14 & 15 21

Second Iteration of CRC Card

CS540 Software Design Lecture 14 & 15 22

Third Iteration of Class Diagram

CS540 Software Design Lecture 14 & 15 23

 ATM – provisional classes
Class candidates:

card
bank account
(ATM) dispenser

&
session – vague (it might become of interest)

Data associated

PIN - attribute of card

current balance - attribute of bank account
amount – attribute in various classes
overdraft limit – attribute of bank account
card limit per day – attribute of card
dispenser amount – attribute of ATM dispenser

COM6030 Systems Analysis and

Design © University of Sheffield 2005
ATM - CRC cards

Card class:

Card
Responsibilities Collaborations
Manage (validate, change) PIN. Bank account provides bank details.

Bank account provides balance and

Initiate withdrawal. overdraft.
Dispenser provides amount requested.

COM6030 Systems Analysis and Design © University of Sheffield 2005

ATM - CRC cards
BankAccount
Responsibilities Collaborations
Provide balance.
Check if amount available in the current
balance and overdraft.
Update balance.

Dispenser
Responsibilities Collaborations
Check if cash available.

Update cash available.

COM6030 Systems Analysis and Design © University of Sheffield 2005

 Guidelines for Allocating
Responsibilities to Classes
1. System intelligence should be evenly distributed.
2. Each responsibility should be stated as generally as possible.
3. Information and the behavior that is related to it should
reside within the same class.
4. Information about one thing should be localized with a
single class, not distributed across multiple classes.
5. Responsibilities should be shared among related classes,
when appropriate.
1. System intelligence should be evenly
distributed.
 Problem: concentrate all intelligence within few
classes making change more difficult
 Solution : intelligence should be evenly distributed.
Each object does about and knows only few things
therefore cohesiveness of the system is improved

Note : if class has long list of responsibilities, then it

indicates a concentration of intelligence
In addition to that each class should exhibit the same
level of abstraction
2. Each responsibility should be stated as
generally as possible.

 General responsibilities (both attribute and

operations) should reside high in the class
hierarchy (because they are generic and they
apply to all sub class)
 In addition polymorphism should be used to
define operations that generally apply to all
super classes but are implemented differently
in each of the subclasses.
3. Information and the behavior that is related to
it should reside within the same class.

 Data and operation that manipulate the data

should be packaged as cohesive unit
4. Information about one thing should be
localized with a single class, not distributed
across multiple classes.

 A single class should take on responsibility for

storing and manipulating a specific
information.
 This information should not be shared across
multiple classes.
 If information is distributed, software
becomes more difficult to maintain and more
challenging to test
5. Responsibilities should be shared among
related classes, when appropriate.

 Many cases where the variety of related

objects must all exhibit the same behavior.

 Consider the video game which must display

the following objects: player, player-body,
player-arm etc. and all must be updated and
displayed as user manipulates joystick.
 Application; the system itself. ⇒ Discard.
 Operations; irrelevant noise. ⇒ Discard.
 Technical library; the system itself? No. In
this case, we refer to the stock or collection
of things available for lending in the library.
In our system, we would need a class
responsible for keeping track of the stock ⇒
OK: Library.
 Books, videos, technical journals, software, and music;

the objects in the library that represent books, videos, etc.

Do they differ sufficiently to justify the definition of different
classes? Our problem lists two differences; overdue fines
and lending periods are different depending on the kind of
object. But there are further (subtle) differences.
 Videos and music for example have playing times.
Software has system requirements as
 an important property. ⇒ OK: Book, Video, Journal,
Software, and Music.
 Library items;
general term for books, videos, etc.
Useful for handling books, videos, etc.
when we do not want/need to know the actual
kind of object.
Here we can keep the responsibilities that are
common for all library items irrespective of
their kind. ⇒ OK:
 Library Item (superclass of Book, Video, etc.).
 Registration code, research area code, and
running number;
 they are needed in our system, but are there any
specific responsibilities connected to them?
Probably not,
 they are simple properties of Library Items. This
might however be different, if our system
should be responsible for assigning these codes in
some automatic way. Currently, this is
 not the case. ⇒ Discard.
 Employee;
 longer down in our list of candidates we also have borrower and
users.
 What is the difference between those three? Our system is only
interested of users that actually borrow or are allowed to borrow
books. It is not clear from the problem statement whether it is the
responsibility of our system to check, if a borrower actually is an
employee.
 For now, we assume that this is outside the scope of our library
system and our system only needs information about actual
borrowers.
 In this case, borrower would be the best and most specific term to
name a class responsible for borrower information
 and activities. ⇒ OK: Borrower.
 Type of library item; irrelevant.
This information is encoded in the different
classes for the different types of library items
available. ⇒ Discard.
 Period of time; the maximum time a
certain type of library item can be
borrowed. This is a simple property of library
items. ⇒ Discard.
 Due date; same as period of time?
No, hold on.
There are actual responsibilities for due dates. Somehow,
we need to check whether a due date has been passed.
 We do also need a class responsible for the generation of
due dates, when library items are checked out from the
library. ⇒ OK: Date.
 Borrower; see Employee.
 Users; see Employee.
 Overdue lendables; having or not having overdue
lendables is a simple property of borrowers. ⇒ Discard.
 Fine;
 there are different kinds of fines. Each type of library item has a
fine per day to
 compute the fine for late returns. Borrowers have a total fine that
must not exceed a certain amount. This amount is another kind of
fine. However, all these fines are simple properties in different
classes and do not have any specific responsibilities on their own.
 ⇒ Discard.
 Articles; used here as a synonym for library items. ⇒ Discard.
 Librarian;
 this would be the class responsible for taking user requests,
like checking in, checking out, and searching for library items.
But hold on.
 Isn't that the same as Library?
 No. We said that Library is responsible for the stock of library
items. But if Librarian is responsible for checking in, checking
out, and searching, then there is nothing left for
 Library? On the other hand, if we merge Library and Librarian
into one class this class
 will probably have too many responsibilities. ⇒ Let's see.
 University department; outside the
problem. ⇒ Discard.
 • Searching and lending; verbs used as
nouns. ⇒ responsibilities ⇒ Discard.
 • Technical library materials; stock of the
library. We have already chosen Library as
 responsible for that. ⇒ Discard.
 Reviewing the CRC Model
1. All participants in the review (of the CRC model) are given a subset
of the CRC model index cards.
2. All use-case scenarios (and corresponding use-case diagrams)
should be organized into categories.
3. The review leader reads the use-case deliberately. As the review
leader comes to a named object, she passes the token to the person
holding the corresponding class index card.
4. When the token is passed, the holder of the class card is asked to
describe the responsibilities noted on the card. The group determines
whether one (or more) of the responsibilities satisfies the use-case
requirement.
5. If the responsibilities and collaborations noted on the index cards
cannot accommodate the use-case, modifications are made to the
cards.