isbn 0-13-146913-4 prentice-hall, 2006 chapter 6 considering objects copyright 2006 pearson/prentice...

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



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



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



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


.6© 2006 Pearson/Prentice Hall

6.1 What is OO?Object-Orientation Characteristics

• Identity• Abstraction• Classification• Encapsulation• Inheritance• Polymorphism• Persistence



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



6.1 What is OO?Objects and Classes (continued)

• Examples of objects grouped into classes



6.1 What is OO?Objects and Classes (continued)

• We can represent a class using a box• Box represents

– object’s name– attributes– behaviors



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



6.1 What is OO?Classes Hierarchy (continued)

• Example of forming a hierarchy



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



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



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



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



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



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



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



6.3 Use CasesExample of Use Cases

• High-level view of Royal Service Station requirements



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




• Second extension of Royal Service Station diagram to include credit card system




• Third extension of Royal Service Station diagram to include inventory and accounting



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?



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



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



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



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?



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




Attributes Classes

personal check

tax

price

cash

credit card

discount

birthdate

name

address

customer

maintenance

services

parking

fuel

bill

purchase

periodic message

station manager




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



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



6.5 OO System DesignUML Diagram

• A UML box used to illustrate the component of a class



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



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)



6.5 OO System DesignUML Diagram to Describe Relationship (continued)

• Graphical representation of several other ways of denoting relationships between classes



6.5 OO System DesignUML Notation for Notes and Qualifiers

• The picture shows how class association can be enhanced with notes and qualifiers



6.5 OO System DesignFirst Cut at Royal Service Station Design



6.5 OO System DesignSecond Cut at Royal Service Station Design



6.5 OO System DesignThird and Final Cut at Royal Service Station Design



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



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



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



6.5 OO System DesignPackage Diagram for the Royal Service Station

• There are four major packages

• The service package consists of five key classes



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



6.5 OO System DesignSequence Diagram for the Royal Service Station

• Showing the use case of the refuel class



6.5 OO System DesignCollaboration Diagram for the Royal Service Station

• Shows the parking use case



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



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



6.5 OO System DesignState Diagram for the Royal Service Station System

• State diagrams for the fuel and parts classes



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



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



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



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



6.6 OO Program DesignProgram Design Considerations

• Nonfunctional requirements• Reused components• Reusable components• User interface requirements• Data structure and management details



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



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



6.6 OO Program DesignSidebar 6.2 Approaches to Creating Patterns

• Abstract factory• Builder• Factory method• Prototype• Singleton



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



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



6.6 OO Program DesignUser Interface Design Example

• Possible design for new billing screen of the Royal Service Station system



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



6.6 OO Program DesignData Management Design: Using a Relational Database

• Database to track vehicle maintenance and parts



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



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



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



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



6.6 OO Program DesignThe Observer Pattern (continued)

• Graphical representation of relationship among observer pattern constructs



6.6 OO Program DesignThe Observer Pattern (continued)

• Sequence diagram to show how the four constructs interact



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)



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



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



6.7 OO MeasurementClass Hierarchy for the Royal Service Station, plus Lorenz and Kidd Measures



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



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



6.7 OO MeasurementChidamber-Kemerer Metrics Applied to the Royal Service Station’s System Design



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



6.7 OO MeasurementChidamber-Kemerer Metrics applied to the Royal Service Station’s Program Design



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



6.7 OO MeasurementTravassos Metrics Applied to the Royal Service Station’s Sequence Diagram



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



6.8 Information System ExampleData Flow Diagram as Basis for Use Cases for the Piccadilly System



6.8 Information System ExampleClass Diagram for the Advertising Campaign

• First cut at two classes to deal with ratings prediction



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



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

isbn 0-13-146913-4 prentice-hall, 2006 chapter 6 considering objects copyright 2006 pearson/prentice...

Documents

oo system design

services system

software engineering

information system example

pearsonprentice hall

oo measurement

pearsonprentice hall

oo program design