Supplementary Slides for

Software Engineering:
A Practitioner's Approach, 5/e

copyright © 1996, 2001

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
hen used in conjunction with Software Engineering: A Practitioner's Appro
Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used for

short courses, industry seminars, or consulting purposes.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
 Chapter 20
Object-Oriented Concepts
and Principles

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
 The OO Process Model
identify
candidate
classes
Pla n n in g
Risk Ana lysis construct look-up
nth iteration classes
C usto m e r of system in library
C o m m unic a tio n

put new extract

classes classes
in library if available

engineer
classes
C usto m e r Eng ine e ring , if unavailable
Eva lua tio n C o nstruc tio n & Re le a se
OO analysis
OO design
OO programming
OO testing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
 The OO Mindset

objects

problem domain

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
 Key Concepts
• classes and class hierarchies
– instances
– inheritance
– abstraction and hiding
• objects
– attributes
– methods
– encapsulation
– polymorphism
• messages

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
 Classes
• object-oriented thinking begins with
the definition of a class often defined
as:
– template
– generalized description
– pattern
– “blueprint” ... describing a collection of
similar items
• a metaclass (also called a superclass)
is a collection of classes
• once a class of items is defined, a
specific instance of the class can be
defined

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
 Building a Class
class name

attributes:

operations

attributes:
operations:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
 What is a Class?
occurrences roles
things organizational units
places
external entities
structures

class name

attributes:

operations:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
 Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
manipulate the data method method
#1 #2
data

method
#6

method method
#5 #4

Achieves “information hiding”

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
 Class Hierarchy
furniture (superclass)

table chair desk "chable"

subclasses of the
furniture superclass

instances of chair
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
 Methods
(a.k.a. Operations, Services)
An executable procedure that is
encapsulated in a class and is
designed to operate on one or
more data attributes that are
defined as part of the class.
A method is invoked
via message passing.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
 Messages
sender object

attributes:

receiver object

attributes:
operations:

operations:

message:
[sender, return value(s)]

message: [receiver, operation, parameters]

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
 Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e

copyright © 1996, 2001

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
hen used in conjunction with Software Engineering: A Practitioner's Appro
Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used for

short courses, industry seminars, or consulting purposes.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
 Chapter 21
Object-Oriented Analysis

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
 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

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
 OOA- A Generic View
• define use cases
• extract candidate classes
• establish basic class relationships
• define a class hierarchy
• identify attributes for each class
• specify methods that service the attributes
• indicate how classes/objects are related
• build a behavioral model
• iterate on the first five steps

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
 Use Cases
 a scenario that describes a “thread of usage” for a
system
 actors represent roles people or devices play as the
system functions
 users can play a number of different roles for a
given scenario

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
 Developing a Use Case
 What are the main tasks or functions that are
performed by the actor?
 What system information will the the actor
acquire, produce or change?
 Will the actor have to inform the system about
changes in the external environment?
 What information does the actor desire from the
system?
 Does the actor wish to be informed about
unexpected changes?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
 Selecting Classes—Criteria

retained information
needed services
multiple attributes
common attributes
common operations
essential requirements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
Unified Modeling Language (UML)
User model view. This view represents the system
(product) from the user’s (called “actors” in UML)
perspective.
Structural model view. Data and functionality is
viewed from inside the system. That is, static
structure (classes, objects, and relationships) is
modeled.
Behavioral model view. This part of the analysis
model represents the dynamic or behavioral aspects
of the system.
Implementation model view. The structural and
behavioral aspects of the system are represented as
they are to be built.
Environment model view. The structural and
behavioral aspects of the environment in which the
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
withsystem
permission by R.S.is to &be
Pressman implemented
Associates, are represented.
Inc., copyright © 1996, 2001
20
 UML: Use-Case Diagram

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
 CRC Modeling
class name:

class type: (e.g., device, property, role, event, ...)

class characterisitics: (e.g., tangible, atomic, concurrent, ...)

responsibilities: collaborators:

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
 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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
 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
These are
courseware materials are to be used made
in conjunction withto the
Software cards.
Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24
 UML: Class Diagrams

Generalizatio
n- Composite
specialization aggregates

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
25
 UML: Package Reference

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
26
 Relationships between Objects

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
27
 Object-Behavior Model
1. Evaluate all use-cases to fully understand
the sequence of interaction within the system.
2. Identify events that drive the interaction
sequence and understand how these events
relate to specific objects.
3. Create an event trace [RUM91] for each use-
case.
4. Build a state transition diagram for the
system
5. Review the object-behavior model to verify
accuracy and consistency

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
28
 UML: State
Transition

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
29
 UML: Event
Trace

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
30
 Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e

copyright © 1996, 2001

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
hen used in conjunction with Software Engineering: A Practitioner's Appro
Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used for

short courses, industry seminars, or consulting purposes.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
31
 Chapter 22
Object-Oriented Design

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
32
 Object-Oriented Design

responsibilities
design

message
design

class and object

design

subsystem
design

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
33
 OOA and OOD

Attributes, operations,
collaborators responsibilities
Object- design
CRC relationship
Index Cards model

message
Use cases design

Class and object

Object-Behavior
design
Model

subsystem
design

THE ANALYSIS MODEL THE DESIGN MODEL

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
34
 OOA and OOD

Analysis Model Design Model

classes objects
attributes data structures
methods algorithms
relationships messaging
behavior control

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
35
 Design Issues
 decomposability—the facility with which a design method helps the
designer to decompose a large problem into subproblems that are
easier to solve;
 composability—the degree to which a design method ensures that
program components (modules), once designed and built, can be
reused to create other systems;
 understandability—the ease with which a program component can
be understood without reference to other information or other
modules;
 continuity—the ability to make small changes in a program and
have these changes manifest themselves with corresponding changes
in just one or a very few modules;
 protection—a architectural characteristic that will reduce the
propagation of side affects if an error does occur in a given module.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
36
 Generic Components for OOD
 Problem domain component—the subsystems that are responsible
for implementing customer requirements directly;
 Human interaction component —the subsystems that implement the
user interface (this included reusable GUI subsystems);
 Task Management Component—the subsystems that are responsible
for controlling and coordinating concurrent tasks that may be
packaged within a subsystem or among different subsystems;
 Data management component—the subsystem that is responsible for
the storage and retrieval of objects.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
37
 Process Flow for OOD

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
38
 System Design Process
• Partition the analysis model into subsystems.
• Identify concurrency that is dictated by the
problem.
• Allocate subsystems to processors and tasks.
• Develop a design for the user interface.
• Choose a basic strategy for implementing
data management.
• Identify global resources and the control
mechanisms required to access them.
• Design an appropriate control mechanism for
the system, including task management.
• Consider how boundary conditions should be
handled.
• courseware
These Review materials areand consider
to be used in trade-offs.
conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
39
 System Design
client request server
subsystem subsystem

contract

request
peer peer
subsystem subsystem
request
contract contract

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
40
 Subsystem Example

Control Sensor
request for status
panel assign to zone subsystem
subsystem test status

request for system status request for alarm notification

specification of type of alarm periodic check-in
periodic status check require for configuration update

Central
communication
subsystem

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
41
 Subsystem Design Criteria
• The subsystem should have a well-
defined interface through which all
communication with the rest of the
system occurs.
• With the exception of a small number of
“communication classes,” the classes
within a subsystem should collaborate
only with other classes within the
subsystem.
• The number of subsystems should be
kept small.
• A subsystem can be partitioned
internally to help reduce complexity.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
42
 Subsystem Collaboration Table

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
43
 Object Design
 A protocol description establishes the interface of an object
by defining each message that the object can receive and the
related operation that the object performs
 An implementation description shows implementation details
for each operation implied by a message that is passed to an
object.
 information about the object's private part
 internal details about the data structures that describe the object’s
attributes
 procedural details that describe operations

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
44
 Design Patterns
... you’ll find recurring patterns of
classes and communicating objects in
many object-oriented systems. These
patterns solve specific design
problems and make object-oriented
design more flexible, elegant, and
ultimately reusable. They help
designers reuse successful designs by
basing new designs on prior
experience. A designer who is familiar
with such patterns can apply them
immediately to design problems
without having to rediscover them.
Gamma and his colleagues [GAM95]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
45
 Design Pattern Attributes
 The design pattern name is an abstraction that conveys significant
meaning about it applicability and intent.
 The problem description indicates the environment and conditions
that must exist to make the design pattern applicable.
 The pattern characteristics indicate the attributes of the design that
may be adjusted to enable the pattern to accommodate into a variety
of problems.
 The consequences associated with the use of a design pattern
provide an indication of the ramifications of design decisions.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
46
 Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e

copyright © 1996, 2001

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
hen used in conjunction with Software Engineering: A Practitioner's Appro
Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used for

short courses, industry seminars, or consulting purposes.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
47
 Chapter 23
Object-Oriented Testing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
48
 Object-Oriented Testing
 begins by evaluating the correctness and
consistency of the OOA and OOD models
 testing strategy changes
 the concept of the ‘unit’ broadens due to encapsulation
 integration focuses on classes and their execution across a
‘thread’ or in the context of a usage scenario
 validation uses conventional black box methods
 test case design draws on conventional methods,
but also encompasses special features

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
49
 Broadening the View of “Testing”
It can be argued that the review of OO analysis and
design models is especially useful because the same
semantic constructs (e.g., classes, attributes, operations,
messages) appear at the analysis, design, and code level.
Therefore, a problem in the definition of class attributes
that is uncovered during analysis will circumvent side
effects that might occur if the problem were not
discovered until design or code (or even the next iteration
of analysis).

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
50
 Testing the CRC Model
1. Revisit the CRC model and the object-relationship
model.
2. Inspect the description of each CRC index card to
determine if a delegated responsibility is part of the
collaborator’s definition.
3. Invert the connection to ensure that each
collaborator that is asked for service is receiving
requests from a reasonable source.
4. Using the inverted connections examined in step 3,
determine whether other classes might be required or
whether responsibilities are properly grouped among
the classes.
5. Determine whether widely requested
responsibilities might be combined into a single
responsibility.
6. Steps 1 to 5 are applied iteratively to each class
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
and through each evolution of the OOA model.
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
51
 OOT Strategy
 class testing is the equivalent of unit testing
 operations within the class are tested
 the state behavior of the class is examined
 integration applied three different strategies
 thread-based testing—integrates the set of classes required to
respond to one input or event
 use-based testing—integrates the set of classes required to
respond to one use case
 cluster testing—integrates the set of classes required to
demonstrate one collaboration

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
52
 OOT—Test Case Design
Berard [BER93] proposes the following approach:
1. Each test case should be uniquely identified and should be
explicitly associated with the class to be tested,
2. The purpose of the test should be stated,
3. A list of testing steps should be developed for each test and
should contain [BER94]:
a. a list of specified states for the object that is to be tested
b. a list of messages and operations that will be exercised as
a consequence of the test
c. a list of exceptions that may occur as the object is tested
d. a list of external conditions (i.e., changes in the environment
external to the software that must exist in order to
properly conduct the test)
e. supplementary information that will aid in understanding or
implementing the test.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
53
 OOT Methods: Random Testing
 Random testing
 identify operations applicable to a class
 define constraints on their use
 identify a miminum test sequence
 an operation sequence that defines the minimum life
history of the class (object)
 generate a variety of random (but valid) test sequences
 exercise other (more complex) class instance life histories

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
54
 OOT Methods: Partition Testing
 Partition Testing
 reduces the number of test cases required to test a class in much
the same way as equivalence partitioning for conventional
software
 state-based partitioning
 categorize and test operations based on their ability to
change the state of a class
 attribute-based partitioning
 categorize and test operations based on the attributes that
they use
 category-based partitioning
 categorize and test operations based on the generic function
each performs

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
55
 OOT Methods: Inter-Class Testing
 Inter-class testing
 For each client class, use the list of class operators to generate a
series of random test sequences. The operators will send
messages to other server classes.
 For each message that is generated, determine the collaborator
class and the corresponding operator in the server object.
 For each operator in the server object (that has been invoked by
messages sent from the client object), determine the messages
that it transmits.
 For each of the messages, determine the next level of operators
that are invoked and incorporate these into the test sequence

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
56
 Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e

copyright © 1996, 2001

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
hen used in conjunction with Software Engineering: A Practitioner's Appro
Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used for

short courses, industry seminars, or consulting purposes.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
57
 Chapter 24
Technical Metrics for
Object-Oriented Systems

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
58
 Distinguishing Characteristics
Berard [BER95] argues that the following characteristics require
that special OO metrics be developed:
 Localization—the way in which information is concentrated in a
program
 Encapsulation—the packaging of data and processing
 Information hiding—the way in which information about
operational details is hidden by a secure interface
 Inheritance—the manner in which the responsibilities of one class
are propagated to another
 Abstraction—the mechanism that allows a design to focus on
essential details

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
59
 Class-Oriented Metrics
Proposed by Chidamber and Kemerer:
 weighted methods per class
 depth of the inheritance tree
 number of children
 coupling between object classes
 response for a class
 lack of cohesion in methods

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
60
 Class-Oriented Metrics
Proposed by Lorenz and Kidd [LOR94]:

 class size
 number of operations overridden by a subclass
 number of operations added by a subclass
 specialization index

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
61
 Class-Oriented Metrics
The MOOD Metrics Suite
 Method inheritance factor
 Coupling factor
 Polymorphism factor

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
62
 Operation-Oriented Metrics
Proposed by Lorenz and Kidd [LOR94]:
 average operation size
 operation complexity
 average number of parameters per operation

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
63
 Testability Metrics
Proposed by Binder [BIN94]:
 encapsulation related
 lack of cohesion in methods
 percent public and protected
 public access to data members
 inheritance related
 number of root classes
 fan in
 number of children and depth of inheritance tree

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
64
 OO Project Metrics
Proposed by Lorenz and Kidd [LOR94]:
 number of scenario scripts
 number of key classes
 number of subsystems

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
65