Software Engineering

1
Software Engineering

• Object Oriented Analysis

2
Objectives

1. To explain Class-Responsibility-Collaborator
   Modelling.
2. To provide an example of CRC modelling in action

3
Analysis Process Models
Process Model Output
1. Elicit customer requirements and identify use-cases Use-Case Diagrams
2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy Class Responsibility Collaborator (CRC) Cards
3. Build an object-relationship model Class Diagram
4. Build an object-behaviour model Interaction Diagram
4
Class-Responsibility-Collaborator Modelling

• A simple means of identifying and organizing
  classes
• Not an official part of UML
• A CRC model is a collection of index cards that
  represent classes
• Each CRC card contains
• Class name, type, characteristic
• Responsibilities
• Collaborations
• Index cards because they can only hold a limited
  amount of information ? enforces high-level
  analysis
• Steps in CRC modelling Identify 1 Classes, 2
  Responsibilities, 3 Collaborators, 4 Review
  the Model

5
CRC Benefits

• They are portable. No computers are required so
  they can be used anywhere. Even away from the
  office.
• They allow the participants to experience first
  hand how the system will work.

6
CRC Cards
class name
class type (e.g., device, property, role,
event, ...)
class characteristics (e.g., tangible, atomic,
concurrent, ...)
responsibilities
collaborators
7
1 Identifying Classes

• Classes and Objects are extracted from the
  Use-Cases by doing a grammatical parse
• Grammatical Parse
• Underline nouns or noun clauses (these describe
  candidate objects)
• Enter the candidate objects (and their associated
  classes) into a table
• Remove synonyms
• Solution Space objects required to implement the
  solution
• Problem Space objects required to describe the
  problem
• The really hard problem in OO is discovering
  what are the right objects in the first place

8
Accepting Classes

• Objects are accepted if they satisfy all (or
  almost all) of the following requirements
• Retained Information the system needs to
  remember data about the object
• Needed Services the object must have an
  identifiable set of operations
• Multiple Attributes during analysis we focus on
  major information only. Objects should have many
  attributes
• Common Attributes A set of attributes apply to
  all occurrences of the object
• Common Operations A set of operations apply to
  all occurrences of the object
• Essential Requirements external entities that
  produce or consume essential information

9
Class Types

• Accepted classes are assigned a type
• External entities - other systems, devices,
  people
• Things - reports, displays, signals
• Occurrences or events - property transfer,
  completion of a series of robot movements
• Roles - manager, engineer, sales person
• Organizational Units - division, group, team
• Places - manufacturing floor, loading dock
• Devices - four-wheeled vehicles, computers
• Property - of the problem, e.g. credit rating
• Interaction - model interaction that occur among
  other objects, e.g. a purchase or a license

10
Class Characteristics

• Accepted classes are assigned a set of
  characteristics
• Tangibility does the class represent a tangible
  (physical) or abstract (information) entity?
• Inclusiveness is the class atomic (includes no
  other classes) or aggregate (has at least one
  nested object)?
• Sequentiality is the class concurrent (has its
  own thread of control) or sequential (scheduled
  by outside resources)?
• Persistence is the class transient (created and
  removed during program operation), temporary
  (created during program operation and removed at
  termination) or permanent (stored in a database)?
• Integrity is the class corruptible (does not
  protect its resources from outside influence) or
  guarded (the class enforces access control)?

11
Example Identifying Classes

• Narrative
• SafeHome software enables the homeowner to
  configure the security system when it is
  installed, monitors all sensors connected to the
  security system, and interacts with the homeowner
  through a keypad and function keys contained in
  the SafeHome control panel.
• During installation, the SafeHome control panel
  is used to program and configure the system.
  Each sensor is assigned a number and type, a
  master password is programmed for arming and
  disarming the system, and telephone number(s) are
  input for dialing when a sensor event occurs.
• Potential Objects/Classes
• Homeowner, sensor, control panel, installation,
  system (alias security system), number, type,
  master password, telephone number, sensor event,

12
Example Accepting Classes
Potential Object/Class Class requirements
Homeowner Rejected 1, 2 (retained information, needed service) fail
Sensor Accepted all apply
Control Panel Accepted all apply
Installation rejected
System Accepted all apply
Number and Type Rejected 3 (multiple attributes) fails, attribute of sensor
Master Password Rejected 3 fails
Telephone Number Rejected 3 fails
Sensor Event Accepted all apply
13
Example CRC Header
14
2 Identifying Responsibilities

• Responsibilities (attributes and methods) are
  extracted from the Use-Cases descriptions
• Attributes
• Describe the object
• Select those things that reasonably belong to an
  object
• Question What data items fully define this
  object in the context of the particular use-case?
• Methods (Operations)
• Define the behaviour of the object and alter the
  objects attributes
• Types of operations data manipulation,
  computation, event monitoring
• Do a grammatical parse of the Use-Case
  description and isolate verbs

15
Guidelines for Allocating Responsibilities to
Classes

• System intelligence should be evenly distributed.
  
• Each responsibility should be stated as generally
  as possible.
• Information and the behavior that is related to
  it should reside within the same class.
• Information about one thing should be localized
  with a single class, not distributed across
  multiple classes.
• Responsibilities should be shared among related
  classes, when appropriate.

16
Example Identifying Responsibilities

• Narrative
• SafeHome software enables the homeowner to
  configure the security system when it is
  installed, monitors all sensors connected to the
  security system, and interacts with the homeowner
  through a keypad and function keys contained in
  the SafeHome control panel.
• During installation, the SafeHome control panel
  is used to program and configure the system.
  Each sensor is assigned a number and type, a
  master password is programmed for arming and
  disarming the system, and telephone number(s) are
  input for dialing when a sensor event occurs.
• Example Operations
• Assign (belongs to Sensor)
• Program (belongs to System)
• Arm/Disarm (belong to System)

17
Example CRC Responsibilities

• Example Attributes
• sensor information sensor number sensor type
  alarm threshold

class name Sensor
class type external entity
class characteristics tangible, atomic,
concurrent, guarded
responsibilities
collaborators
keep sensor information
assign sensor information
signal sensor event
18
3 Identifying Collaborators

• Collaborations represent requests from a client
  to a server in fulfillment of a client
  responsibility
• One object collaborates with another if it needs
  to send a message
• Relationships
• is-part-of (classes that are contained within an
  aggregate class as attributes)
• has-knowledge-of (one class must acquire
  information from another)
• depends-upon (dependency not covered by part-of
  or knowledge-of)

19
4 Reviewing the CRC Model

• All participants in the review (of the CRC model)
  are given a subset of the CRC model index cards.
• All use-case scenarios (and corresponding
  use-case diagrams) should be organized into
  categories.
• 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.
• 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.
• If the responsibilities and collaborations noted
  on the index cards cannot accommodate the
  use-case, modifications are made to the cards.

20
Example CRC Review

• Use-Case Narrative
• The homeowner observes the control panel to
  determine if the system is ready for input. If
  the system is not ready, the homeowner must
  physically close window/doors so that the ready
  indicator is present a not ready indicator
  implies that a sensor is open.
• When review leader comes to control panel token
  is passed to the person holding the control panel
  CRC card.
• Phrase implies that a sensor is open means a
  responsibility must validate this.
• The control panel CRC card has sensor as a
  collaborator
• The token is next passed to the sensor CRC card.

21
CRC Tips

1. Dont generate long lists of responsibilities.
   This is missing the point. The responsibilities
   should easily fit on a card.
2. The review stage is crucial. Spend a lot of time
   here.