ISBN 0-13-146913-4Prentice-Hall, 2006
Chapter 6
ConsideringObjects
Copyright 2006 Pearson/Prentice Hall. All rights reserved.
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.2© 2006 Pearson/Prentice Hall
Contents
6.1 What is OO?6.2 The OO Development Process6.3 Use Cases6.4 Representing OO: An Example Using UML6.5 OO System Design6.6 OO Program Design6.7 OO Measurement6.8 Information System Example6.9 Real Time Example6.10 What this Chapter Means for You
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.3© 2006 Pearson/Prentice Hall
Chapter 6 Objectives
• The special nature of object-oriented development
• Use cases• Using UML• Object-oriented system design• Object-oriented program design• Object-oriented measurement
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.4© 2006 Pearson/Prentice Hall
6.1 What is OO?
• Object-orientation is an approach to software development that organizes both the problem and its solution as a collection of discrete objects– Data structure– Behavior
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.5© 2006 Pearson/Prentice Hall
6.1 What is OO?Sidebar 6.1 Royal Service Station Requirements
• Royal Service station provides three types of services• The system must track bills, the product, and services• System to control inventory• The system to track credit history, and payments overdue• The system applies only to regular repeat customers• The system must handle the data requirements for interfacing with other systems• The system must record tax and related information• The station must be able to review tax record upon demand• The system will send periodic message to customers• Customers can rent parking space in the station parking lot • The system maintains a repository of account information• The station manager must be able to review accounting information upon demand• The system can report an analysis of prices and discounts• The system can not be unavailable for more than 24 hours• The system must protect customer information from unauthorized access• The system will automatically notify the owners of dormant accounts
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.6© 2006 Pearson/Prentice Hall
6.1 What is OO?Object-Orientation Characteristics
• Identity• Abstraction• Classification• Encapsulation• Inheritance• Polymorphism• Persistence
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.7© 2006 Pearson/Prentice Hall
6.1 What is OO?Objects and Classes
• Reference or handle: name of object• Objects can have
– attributes (such as color, size, location)– operations or behaviors (such as takeoff, land,
repair)
• Each object is an instance of a class• Class: group of objects that have attributes
and behaviors in common• Method: a specific implementation of an
operation for a certain class
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.8© 2006 Pearson/Prentice Hall
6.1 What is OO?Objects and Classes (continued)
• Examples of objects grouped into classes
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.9© 2006 Pearson/Prentice Hall
6.1 What is OO?Objects and Classes (continued)
• We can represent a class using a box• Box represents
– object’s name– attributes– behaviors
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.10© 2006 Pearson/Prentice Hall
6.1 What is OO?Classes Hierarchy
• A class hierarchy is organized according to the sameness or differences among classes– Exhibits OO classes’ inheritance structure
• A class is refined into subclasses• Subclasses may inherit the structure as well
as the behavior and attributes of its superclass
• Abstract class is used to simplify the hierarchy– No objects of the abstract class may be defined
except as instances of a subclass
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.11© 2006 Pearson/Prentice Hall
6.1 What is OO?Classes Hierarchy (continued)
• Example of forming a hierarchy
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.12© 2006 Pearson/Prentice Hall
6.2 The OO Development Process
• One advantage of OO development is its consistency of language
• Describing classes using OO representation requires three perspectives– Static views: descriptions of the object,
attributes, behaviors, and relationships– Dynamic views: describe communication,
control/timing, and the state and changes in state
– Restrictions: describe constraints on the structure
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.13© 2006 Pearson/Prentice Hall
6.2 The OO Development ProcessTendency of Change when Using OO Paradigm
Characteristic of Software Product/Project
Probability for Change
Objects derived from application Low
Long-lived information structures
Low
Passive object’s attributes Medium
Sequences of behavior Medium
Interface with outside world High
Functionality High
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.14© 2006 Pearson/Prentice Hall
6.2 The OO Development ProcessOO Requirements
• Usually done in user’s language and discusses the concepts and scenarios likely in the application domain
• The concepts include information services and responsibilities
• Domain knowledge enables the developers – to understand the context in which the system
will be used– to describe the requirements in a way that the
user will understand
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.15© 2006 Pearson/Prentice Hall
6.2 The OO Development ProcessOO Design
• Usually uses an OO requirements representation• System design identifies and represents objects
and classes, plus details of each object’s attributes and behaviors
• System design also identifies interactions and relationships
• Program design inserts computational features in the models
• Program design inserts class library details• Program design considers nonfunctional
requirements to enhance design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.16© 2006 Pearson/Prentice Hall
6.2 The OO Development ProcessOO Coding and Testing
• Coding proceeds by translating the models to an OO programming language
• It is necessary to refine the hierarchical structures and make adjustments as the requirements grow and mature
• Testing involves some of the same activities that are performed when testing any kind of system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.17© 2006 Pearson/Prentice Hall
6.2 The OO Development ProcessOO Coding and Testing (continued)
• Graphical representation of how the abstraction level relates to various types of tests that are performed
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.18© 2006 Pearson/Prentice Hall
6.3 Use Cases
• Describes particular functionality that a system is supposed to perform or exhibit by modeling the dialog that a user, external system, or other entity will have with the system to be developed
• Diagrams have four elements– actors– cases– extensions– uses
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.19© 2006 Pearson/Prentice Hall
6.3 Use CasesExample of Use Cases
• High-level view of Royal Service Station requirements
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.20© 2006 Pearson/Prentice Hall
6.3 Use CasesExample of Use Cases (continued)
• First extension part of the use case diagram of Royal Service Station requirements to include preventive maintenance
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.21© 2006 Pearson/Prentice Hall
6.3 Use CasesExample of Use Cases (continued)
• Second extension of Royal Service Station diagram to include credit card system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.22© 2006 Pearson/Prentice Hall
6.3 Use CasesExample of Use Cases (continued)
• Third extension of Royal Service Station diagram to include inventory and accounting
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.23© 2006 Pearson/Prentice Hall
6.3 Use CasesIdentifying Participants
• What users or groups use the system to perform a task?
• What users or groups are needed so that the system can perform its functions?
• What external systems use the system to perform a task?
• What external systems, users, or groups send information to the system?
• What external systems, users, or groups receive information from the system?
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.24© 2006 Pearson/Prentice Hall
6.4 Representing OO: An Example Using UML UML in the OO Process
• Workflow diagrams• Object model• Sequence diagrams• Collaboration diagrams• Package diagrams• Component diagrams• Deployment diagrams
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.25© 2006 Pearson/Prentice Hall
6.4 Representing OO: An Example Using UML UML in the OO Process (continued)
• How UML can be used in requirements specification, design, and coding
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.26© 2006 Pearson/Prentice Hall
6.5 OO System DesignFirst Cut at Object Classes
• Structures• External systems• Devices• Roles• Operating procedures• Places• Organizations• Things that are manipulated by the system
to be built
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.27© 2006 Pearson/Prentice Hall
6.5 OO System DesignGuidelines for Building Classes
• What needs to be “processed” in some way?
• What items have multiple attributes?• When do you have more than one object in
a class?• What is based on the requirements
themselves, not derived from your understanding of the requirements?
• What attributes and operations are always applicable to a class or object?
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.28© 2006 Pearson/Prentice Hall
6.5 OO System DesignFirst Grouping of Attributes and Classes: Step 1
Attributes Classes
personal check customer
tax maintenance
price services
cash parking
credit card fuel
discount bill
purchase
station manager
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.29© 2006 Pearson/Prentice Hall
6.5 OO System DesignFirst Grouping of Attributes and Classes: Step 2
Attributes Classes
personal check
tax
price
cash
credit card
discount
birthdate
name
address
customer
maintenance
services
parking
fuel
bill
purchase
periodic message
station manager
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.30© 2006 Pearson/Prentice Hall
6.5 OO System DesignFirst Grouping of Attributes and Classes: Step 3
Attributes Classespersonal check
tax
price
cash
credit card
discount
birthdate
name
address
customer
maintenance
services
parking
fuel
bill
purchase
periodic message
station manager
warning letter
parts
accounts
inventory
credit card system
part-ordering system
fuel-ordering system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.31© 2006 Pearson/Prentice Hall
6.5 OO System DesignGuidelines for Identifying Behaviors
• Imperative verbs• Passive verbs• Actions• Things or reminded events• Roles• Operating procedures• Services provided by an organization
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.32© 2006 Pearson/Prentice Hall
6.5 OO System DesignUML Diagram
• A UML box used to illustrate the component of a class
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.33© 2006 Pearson/Prentice Hall
6.5 OO System DesignUML Diagram to Describe Relationship
• Inheritance relationship (is-a relationship): lower box inherits the attributes and behaviors of the upper box
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.34© 2006 Pearson/Prentice Hall
6.5 OO System DesignUML Diagram to Describe Relationship (continued)
• Each order is associated with salesperson (associated)
• The order item is part of the order (aggregation)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.35© 2006 Pearson/Prentice Hall
6.5 OO System DesignUML Diagram to Describe Relationship (continued)
• Graphical representation of several other ways of denoting relationships between classes
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.36© 2006 Pearson/Prentice Hall
6.5 OO System DesignUML Notation for Notes and Qualifiers
• The picture shows how class association can be enhanced with notes and qualifiers
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.37© 2006 Pearson/Prentice Hall
6.5 OO System DesignFirst Cut at Royal Service Station Design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.38© 2006 Pearson/Prentice Hall
6.5 OO System DesignSecond Cut at Royal Service Station Design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.39© 2006 Pearson/Prentice Hall
6.5 OO System DesignThird and Final Cut at Royal Service Station Design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.40© 2006 Pearson/Prentice Hall
6.5 OO System DesignA Class Description Template
• Describes class in more detail• Tells us
– the position of the class (in terms of inheritance) in the overall hierarchy
– the export controls– the cardinality– association with other classes
• Specifies the operations in the class and the public interface to the class
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.41© 2006 Pearson/Prentice Hall
6.5 OO System DesignExample of a Class Description Template
Class name: refuelCategory: serviceExternal documents:Export control: PublicCardinality: nHierarchy:
Superclasses: servicesAssociations:
fuel in association <name>
Operation name: pricePublic member of: refuelDocumentation:
// Calculates fuel final pricePreconditions:
gallons > 0Object diagram: (unspecified)
Semantics:final_price = gallons * priceObject diagram: (unspecified)
Concurrency: sequential
Public interface:Operations:
pricePrivate interface:
Attributes:gallonsprice
Implementation:Attributes:
gallonsprice
State machine: noConcurrency: sequentialPersistence: transient
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.42© 2006 Pearson/Prentice Hall
6.5 OO System DesignPackage Diagram
• View the system as a small collection of packages, which can be expanded to a larger set of classes
• Show the dependencies among classes as they belong to different packages
• Two items are dependent if changes to the definition of one may cause changes to the other
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.43© 2006 Pearson/Prentice Hall
6.5 OO System DesignPackage Diagram for the Royal Service Station
• There are four major packages
• The service package consists of five key classes
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.44© 2006 Pearson/Prentice Hall
6.5 OO System DesignInteraction Diagram
• Describe how operations and behaviors are handled by the objects in the design
• Two kinds of interaction diagrams– Sequence diagram: shows the sequence in
which activities or behaviors occur– Collaboration diagram: shows how the objects
are connected statically
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.45© 2006 Pearson/Prentice Hall
6.5 OO System DesignSequence Diagram for the Royal Service Station
• Showing the use case of the refuel class
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.46© 2006 Pearson/Prentice Hall
6.5 OO System DesignCollaboration Diagram for the Royal Service Station
• Shows the parking use case
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.47© 2006 Pearson/Prentice Hall
6.5 OO System DesignState Diagram
• To document a dynamic model of the system
• Shows – the possible states an object can take– the events that trigger the transition from one
state to the next– the actions that result from each state change
• Needed only for classes where the objects exhibit dynamic behavior, with many attribute values and messages
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.48© 2006 Pearson/Prentice Hall
6.5 OO System DesignState Diagram Example
• Black dot: start node
• Smaller black dot inside a white dot: end node
• Rectangle: a state
• Arrow: transition
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.49© 2006 Pearson/Prentice Hall
6.5 OO System DesignState Diagram for the Royal Service Station System
• State diagrams for the fuel and parts classes
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.50© 2006 Pearson/Prentice Hall
6.5 OO System DesignState Diagram for the Royal Service Station System
• State diagram for the inventory class, orders parts or fuel: a different condition triggers each state
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.51© 2006 Pearson/Prentice Hall
6.5 OO System DesignActivity Diagram
• To model the flow of procedures or activities in a class
• A decision node is used to represent a choice of which activity to invoke
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.52© 2006 Pearson/Prentice Hall
6.5 OO System DesignActivity Diagram for the Royal Service Station
• An activity diagram for the inventory class
• It may have two decisions– to verify that there is
enough fuel– to verify that a part is in
stock
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.53© 2006 Pearson/Prentice Hall
6.6 OO Program Design
• Begins with the objects and classes from the system design
• During program design– Make more detailed decisions about the data structures– Specify the features of each object’s interface– Need to know the operation signature
• name each operation• the objects it takes as parameters• The values returned by the operation
• An object’s interface: the collection of all its operation’s signature
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.54© 2006 Pearson/Prentice Hall
6.6 OO Program DesignProgram Design Considerations
• Nonfunctional requirements• Reused components• Reusable components• User interface requirements• Data structure and management details
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.55© 2006 Pearson/Prentice Hall
6.6 OO Program DesignConstruction Paradigms
• White-box reuse: one class inherits properties from another class– Gives us a static view of the system at compile time– Modification is easier and more straightforward– The inheritance can not easily be changed at runtime
• Black-box reuse: built up from component classes– Enforces the encapsulation built into the system design– Allows easy replacement of one component with other– Not always clear which objects reference to other
objects
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.56© 2006 Pearson/Prentice Hall
6.6 OO Program DesignDesign Aids
• A toolkit: a set of related, reusable classes• A pattern: a template of abstract
architectural elements– Context: explains the situations in which pattern
would be appropriate– Forces: elements of the context
• A framework: a reuse part of a domain-specific design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.57© 2006 Pearson/Prentice Hall
6.6 OO Program DesignSidebar 6.2 Approaches to Creating Patterns
• Abstract factory• Builder• Factory method• Prototype• Singleton
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.58© 2006 Pearson/Prentice Hall
6.6 OO Program DesignUser Interface Design
• Defining the humans who will interact with the system
• Developing scenarios for each way that the system can perform a task
• Designing hierarchy of user commands• Refining sequence of user interactions with
the system• Designing relevant classes in the hierarchy to
implement the user interface design decision• Integrating the user interface classes in the
overall system class hierarchy
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.59© 2006 Pearson/Prentice Hall
6.6 OO Program DesignUser Interface Design (continued)
• The first step in user interface design is to lay out the interaction on paper
• The left-hand side of the picture shows the paper bill, the right-hand side shows a screen of automated billing process
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.60© 2006 Pearson/Prentice Hall
6.6 OO Program DesignUser Interface Design Example
• Possible design for new billing screen of the Royal Service Station system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.61© 2006 Pearson/Prentice Hall
6.6 OO Program DesignData Management Design
• Four steps– Identify the data, data structure, and relationships among
them– Design services to manage the data structures and
relationships– Find tools, such as database management systems, to
implement some of the data management tasks– Design classes and class hierarchies to oversee the data
management functions
• An OO solution can use conventional files or relational databases, but it interfaces most easily with OO databases
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.62© 2006 Pearson/Prentice Hall
6.6 OO Program DesignData Management Design: Using a Relational Database
• Database to track vehicle maintenance and parts
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.63© 2006 Pearson/Prentice Hall
6.6 OO Program DesignTask Management Design
• A task: a process in the system– Event-driven task: initiated when a particular
event occurs– Time-driven task: invoked at a particular time
• Four steps– Identify the task to be performed– Determine priorities for the tasks– Create a task to coordinate all other tasks– Design objects for each task, and define the
relationships among them
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.64© 2006 Pearson/Prentice Hall
6.6 OO Program DesignTask Management Design: A Task Definition Example
Task name: order parts
Description: Purpose is to order new parts automatically when there are not enough parts already in stock
Priority: High. It must be activated when the inventory warns the parts in stock are low
Included services: Verify inventory
Managed by/Manager: Service Station System
Communicates by: modem with the order_parts system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.65© 2006 Pearson/Prentice Hall
6.6 OO Program DesignSidebar 6.3 Gamma et. al’s Pattern for Task Management
• Chain of responsibility• Command• Interpreter• Iterator• Mediator• Memento• Observer• State• Strategy• Template Method• Visitor
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.66© 2006 Pearson/Prentice Hall
6.6 OO Program DesignTask Management Design: The Observer Pattern
• Useful when an abstraction has at least two aspects, and some are dependent on the others– One-to-many dependency
• Involves four major constructs– Subject– Observer– Concrete subject– Concrete observer
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.67© 2006 Pearson/Prentice Hall
6.6 OO Program DesignThe Observer Pattern (continued)
• Graphical representation of relationship among observer pattern constructs
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.68© 2006 Pearson/Prentice Hall
6.6 OO Program DesignThe Observer Pattern (continued)
• Sequence diagram to show how the four constructs interact
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.69© 2006 Pearson/Prentice Hall
6.7 OO MeasurementOO Size Measure
• Pfleeger (1991): used objects and methods as a basic size measure
• Lorenz and Kidd’s nine aspects of size– Number of scenario script (NSS)– Number of key classes– Number of support classes– The average number of support classes per key classes– Number of subsystems– Class size– Number of operations overridden by a subclass (NOO)– Number of operations added by a subclass– Specialization index
• SI = (NOO X level) / (total class methods)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.70© 2006 Pearson/Prentice Hall
6.7 OO MeasurementLorenz and Kidd Metrics Collection in Different Phases of Development
MetricRequirements Description
System Design
Program Design Coding Testing
Number of scenario script X
Number of key classes X X
Number of support classes X
Average number of support classes per key class
X
Number of subsystem X X
Class size X X X
Number of operations overridden by a subclass
X X X X
Number of operations added by a subclass
X X X
Specialization index X X X X
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.71© 2006 Pearson/Prentice Hall
6.7 OO MeasurementOO Size Measure of the Royal Service Station• Using Lorenz and Kidd’s metrics, the number of
scenario scripts is equal to six
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.72© 2006 Pearson/Prentice Hall
6.7 OO MeasurementClass Hierarchy for the Royal Service Station, plus Lorenz and Kidd Measures
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.73© 2006 Pearson/Prentice Hall
6.7 OO MeasurementOO Design Measures
• Chidamber and Kemerer have also devised a suite of metrics for object-oriented development – Weighted methods per class =
nci
i=1
– Depth of inheritance– Number of children– Coupling between objects– Response for a class– Lack of cohesion of methods
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.74© 2006 Pearson/Prentice Hall
6.7 OO MeasurementChidamber and Kemerer Metrics Collection in Different Phases of Development
MetricSystem Design
Program Design Coding Testing
Weighted methods per class X X X
Depth of inheritance X X X
Number of children X X X
Coupling between objects X X
Response for a class X X
Lack of cohesion of methods X X X
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.75© 2006 Pearson/Prentice Hall
6.7 OO MeasurementChidamber-Kemerer Metrics Applied to the Royal Service Station’s System Design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.76© 2006 Pearson/Prentice Hall
6.7 OO MeasurementCalculating the Lack of Cohesion
• Given class C with n methods, M1 through Mn
• Suppose {Ijj} is the set of instance variables used by the method M
• We can define P to be collection of pairs (Ir , Is) where Ir and Is, share no common members– P = {(Ir , Is) | Ir ∩ Is = Ø}
• Q is the collection of pairs (Ir , Is) where Ir and Is, share at least one common member– Q = {(Ir , Is) | Ir ∩ Is ≠ Ø}
• Lack of cohesion in methods for C to be – |P|-|Q| if |P| > |Q|– Zero if otherwise
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.77© 2006 Pearson/Prentice Hall
6.7 OO MeasurementChidamber-Kemerer Metrics applied to the Royal Service Station’s Program Design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.78© 2006 Pearson/Prentice Hall
6.7 OO MeasurementOther Metrics
• Li and Henry (1993): metrics to predict the size of changes in classes during maintenance– Message-passing coupling– Data abstraction coupling
• Travassos (1999)– The average operation size– The average number of parameters per operation
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.79© 2006 Pearson/Prentice Hall
6.7 OO MeasurementTravassos Metrics Applied to the Royal Service Station’s Sequence Diagram
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.80© 2006 Pearson/Prentice Hall
6.7 OO MeasurementWhere to Do OO Measurement
Metric Use casesClass diagram
Interaction diagram
Class description
State diagram
Package diagram
Number of scenario scripts XNumber of key classes XNumber of support classes XAverage number of support classes per key class
X
Number of subsystems XClass size X XNumber of operation overridden by a subclass X
Number of operation added by a subclass X
Specialization index XWeighted methods in class XDepth of inheritance XNumber of children XCoupling between objects XResponse for a class XLack of cohesion in methods XAverage operation size XAverage number of parameters per operation X
Operation complexity XPercent public and protected XPublic access to data members XNumber of root classes XFan-in/fan-out X
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.81© 2006 Pearson/Prentice Hall
6.8 Information System ExampleData Flow Diagram as Basis for Use Cases for the Piccadilly System
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.82© 2006 Pearson/Prentice Hall
6.8 Information System ExampleClass Diagram for the Advertising Campaign
• First cut at two classes to deal with ratings prediction
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.83© 2006 Pearson/Prentice Hall
6.9 Real-Time Example
• Had Ariane-5 been implemented using an object-oriented approach, the reuse would have been either in terms of composition or inheritance
• In composition approach: the SRI is viewed as a black box and called from the main system
• In inheritance approach: the SRI structure and behavior are open to view, inheriting as much structure and behavior from parent classes as possible
Pfleeger and Atlee, Software Engineering: Theory and Practice
Page 6.84© 2006 Pearson/Prentice Hall
6.10 What This Chapter Means for You
• Use cases are embellished to generate a system design, painting a high-level portrait of how the system will solve problem at hand
• Program design implements nonfunctional requirements
• UML is becoming a de facto standard way of describing OO system
• There are several metrics that are commonly used to measure size and characteristic of OO artifacts
Top Related