Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
Parts Four & Five

Chapter 20
Object-Oriented Concepts
and Principles

The OO Process Model

The OO Mindset

Key Concepts
classes and class hierarchies
instances
inheritance
abstraction and hiding
objects
attributes
methods
encapsulation
polymorphism
messages

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

Building a Class

What is a Class?

Encapsulation/Hiding

Class Hierarchy

Methods
(a.k.a. Operations, Services)

Messages

Chapter 21
Object-Oriented Analysis

Domain Analysis

OOA- A Generic View

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

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?

Selecting Classes—Criteria

Unified Modeling Language (UML)

UML:  Use-Case Diagram

CRC Modeling

Guidelines for Allocating
Responsibilities to Classes

Reviewing the CRC Model

UML:  Class Diagrams

UML: Package Reference

Relationships between Objects

Object-Behavior Model

UML: State Transition

UML: Event Trace

Chapter 22
Object-Oriented Design

Object-Oriented Design

OOA and OOD

OOA and OOD

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.

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.

Process Flow for OOD

System Design Process

System Design

Subsystem Example

Subsystem Design Criteria

Subsystem Collaboration Table

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

Design Patterns

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.

Chapter 23
Object-Oriented Testing

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

Broadening the View of “Testing”

Testing the CRC Model

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

OOT—Test Case Design

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

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

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

Chapter 24
Technical Metrics for
Object-Oriented Systems

Distinguishing Characteristics
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

Class-Oriented Metrics
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

Class-Oriented Metrics
class size
number of operations overridden by a subclass
number of operations added by a subclass
specialization index

Class-Oriented Metrics
Method inheritance factor
Coupling factor
Polymorphism factor

Operation-Oriented Metrics
average operation size
operation complexity
average number of parameters per operation

Testability Metrics
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

OO Project Metrics
number of scenario scripts
number of key classes
number of subsystems

Chapter 25
Formal Methods

Problems with
Conventional Specification
contradictions
ambiguities
vagueness
imcompleteness
mixed levels of abstraction

Formal Methods Concepts
data invariant—a condition that is true throughout the execution of the system that contains a collection of data
 state—the stored data which a system accesses and alters
operation—an action that takes place in a system and reads or writes data to a state
precondition defines the circumstances in which a particular operation is valid
postcondition  defines what happens when an operation has completed its action

An Example—Print Spooler

States and Data Invariant

Operations
An operation which adds a new output device to the spooler together with its associated print limit
An operation which removes a file from the queue associated with a particular output device
An operation which adds a file to the queue associated with a particular output device
An operation which alters the upper limit of print lines for a particular output device
An operation which moves a file from a queue associated with an output device to another queue associated with a second output device

Pre- & Postconditions

Mathematical Concepts
sets and constructive set specification
set operators
logic operators
e.g.,     i, j:     • i > j  i2 => j2
which states that, for every pair of values in the set of natural numbers, if i is greater than j, then i2 is greater than j2.
sequences

The Z Language
organized into schemas
defines variables
establishes relationships between variables
the analog for a “module” in conventional languages
notation described in Table 25.1, SEPA, 5/e

Chapter 26
Cleanroom Software Engineering

The Cleanroom Process Model

The Cleanroom Strategy-I

The Cleanroom Strategy-II

Box Structure Specification

Box Structures

Design Refinement & Verification

Advantages of Design Verification
It reduces verification to a finite process.
It lets cleanroom teams verify every line of design and code.
It results in a near zero defect level.
It scales up.
It produces better code than unit testing.

Cleanroom Testing
statistical use testing
tests the actual usage of the program
determine a “usage probability distribution”
analyze the specification to identify a set of stimuli
stimuli cause software to change behavior
create usage scenarios
assign probability of use to each stimuli
test cases are generated for each stimuli according to the usage probability distribution

Certification

Certification Models

Chapter 27
Component-Based
Software Engineering

The Key Questions
When faced with the possibility of reuse, the software team asks:
Are commercial off-the-shelf (COTS) components available to implement the requirement?
Are internally-developed reusable components available to implement the requirement?
Are the interfaces for available components compatible within the architecture of the system to be built?
At the same time, they are faced with the following impediments to reuse ...

Impediments to Reuse
Few companies and organizations have anything that even slightly resembles a comprehensive software reusability plan.
Although an increasing number of  software vendors currently sell tools or components that provide direct assistance for software reuse, the majority of software developers do not use them.
Relatively little training is available to help software engineers and managers understand and apply reuse.
Many software practitioners continue to believe that reuse is “more trouble than it’s worth.”
Many companies continue to encourage of software development methodologies which do not facilitate reuse
Few companies provide an incentives to produce reusable program components.

The CBSE Process

Domain Engineering

Identifying Reusable Components

Structural Modeling
every application has structural patterns that have the potential for reuse
a “structure point” is a construct with the structure
A structure point is an abstraction that should have a limited number of instances. Restating this in object-oriented jargon , the size of the class hierarchy should be small.
The rules that govern the use of the structure point should be easily understood. In addition, the interface to the structure point should be relatively simple.
The structure point should implement information hiding by hiding all complexity contained within the structure point itself. This reduces the perceived complexity of the overall system.

Component-Based Development
a library of components must be available
components should have a consistent structure
a standard should exist, e.g.,
OMG/CORBA
MS COM
JavaBeans

CBSE Activities
Component qualification
Component adaptation
Component composition
Component update

Qualification

Adaptation

Composition
An infrastructure must be established to bind components together
Architectural ingredients for composition include:
Data exchange model
Automation
Structured storage
Underlying object model

Classification
Enumerated classification—components are described by defining a hierarchical structure in which classes and varying levels of subclasses of software components are defined
Faceted classification—a domain area is analyzed and a set of basic descriptive features are identified
Attribute-value classification—a set of attributes are defined for all components in a domain area

Chapter 28
Client/Server Software Engineering

C/S Architectures

Architecture Options

Software Components
User Interaction/Presentation Component—implements all functions associated with a graphical user interface (GUI).
Application Component—implements the requirements defined by the application within the context of the domain in which the application operates.
Database Management—performs the data manipulation and management required by an application.  Data manipulation and management may be as simple as the transfer of a record or as complex the processing of sophisticated SQL transactions.
Middleware—comprises software elements that exist on both the client and the server
elements of network operating systems
software that supports database specific applications
object-request broker (ORB) standards
groupware technologies
communication management
other features that facilitate the client-server connection

Object-Request Brokers

C/S Software Engineering
conventional and/or OO analysis methods are generally applicable
basic design principles and methods can be applied but
data design dominates
event driven paradigm is chosen
GUI design is almost always requireder suited to C/S
specialized construction tools are desirable
testing strategy differs

C/S Testing
Application function tests. The functionality of client applications is tested using conventional methods
Server tests.  The coordination and data management functions of the server are tested. Server performance (overall response time and data throughput) is also considered.
Database tests.  The accuracy and integrity of data stored by the server is tested. Archiving is also tested.
Transaction testing.  A series of tests are created to ensure that each class of transactions is processed according to requirements.
Network communication testing. These tests verify the communication among the nodes of the network occurs correctly and that message passing, transactions, and related network traffic occur without error. Network security tests may also be conducted as part of this testing activity.

Chapter 29
Web Engineering

Attributes of
Web-Based Applications

WebApp Characteristics

WebApp Quality Factors

The WebE Process

Formulation
Allows the customer and developer to establish a common set of goals
Address three questions:
What is the main motivation for the WebApp?
Why is the WebApp needed?
Who will use the WebApp?
Defines two categories of goals”
Informational goals—indicate an intention to provide specific content and/or information the the end user
Applicative goals—indicate the ability to perform some task within the WebApp

Analysis for WebE

Design for WebE
Architectural design — laying out the page structure of the WebApp
Navigation design — defining the manner in which pages will be navigated
Interface design — establishing consistent and effective user interaction mechanisms

Architectural Styles

Navigation Design
identify the semantics of navigation for different users of the site
User roles must be defined
Semantics of navigation for each role must be identified
A semantic navigation unit (SNU) should be defined for each goal associated with each user
Ways of navigating (WoN) are defined
define the mechanics (syntax) of achieving the navigation
options are text-based links, icons, buttons and switches, and graphical metaphors

Interface Design Guidelines

Testing for WebE – I

Testing for WebApps – II

Project Management for WebE
Initiate the project
Many of the analysis activities should be performed internally even if the project is outsourced
A rough design for the WebApp should be developed internally.
A rough project schedule, including not only final delivery dates, but also milestone dates should be developed.
The degree of oversight and interaction by the contractor with the vendor should be identified.

Project Management for WebE
Select candidate outsourcing vendors
interview past clients to determine the Web vendor’s professionalism, ability to meet schedule and cost commitments, and ability to communicate effectively:
 determine the name of the vendor’s chief Web engineer(s) for successful past projects (and later, be certain that this person is contractually obligated to be involved in your project
 carefully examine samples of the vendor’s work that are similar in look and feel (and business area) to the WebApp that is to be contracted.

Project Management for WebE
Assess the validity of price quotes and the reliability of estimates
Does the quoted cost of the WebApp provide a direct or indirect return-on-investment that justifies the project?
Does the vendor that has provided the quote exhibit the professionalism and experience we require?
Establish the degree of project management expected from both parties
Assess the development schedule
WBS should have high granularity
Milestones should be defined at tight intervals

SCM for WebE
WebApp content is extremely varied
SCO’s must be defined
The “longevity of the SCO must be identified
Many different people participate in content creation
Determine who “owns” the WebApp
Establish who can make changes and who approves them
Manage scale
As a small WebApp grows, the impact of an seemingly insignificant change can be magnified

Chapter 30
Reengineering

Business Process Reengineering (BPR)

BPR Principles
Organize around outcomes, not tasks.
Have those who use the output of the process perform the process.
Incorporate information processing work into the real work that produces the raw information.
Treat geographically dispersed resources as though they were centralized.
Link parallel activities instead of integrated their results.   When different
Put the decision point where the work is performed, and build control into the process.
Capture data once, at its source.

Software Reengineering

Inventory Analysis
build a table that contains all applications
establish a list of criteria, e.g.,
name of the application
year it was originally created
number of substantive changes made to it
total effort applied to make these changes
date of last substantive change
effort applied to make the last change
system(s) in which it resides
applications to which it interfaces, ...
analyze and prioritize to select candidates for reengineering

Restructuring
Document Restructuring
options range from doing nothing to regeneration of all documentation for critical system
Reverse Engineering
the intent here is to achieve design recovery
Code Restructuring
rebuild spaghetti bowl code
Data Restructuring
data architecture

Reverse Engineering

Forward Engineering

Chapter 31
Computer-Aided Software Engineering

CASE

CASE Environment Model

The Challenge: Putting it Together

An Integration Framework

Data Integration:
The CASE Repository

A Taxonomy of CASE Tools

Chapter 32
The Road Ahead

An Information Spectrum

Software: The Road Ahead