BACHELOR OF SCIENCE IN COMPUTER SCIENCE

YEAR 2 SEMESTER 2
CCS 206: SOFTWARE ENGINEERING
NOTES 2

Process and Project Metrics

 Introduction
 Metrics in the Process Domain
 Metrics in the Project Domain
 Software Measurement
 Integrating Metrics within the Software Process

Introduction

What are Metrics?

• Software process and project metrics are quantitative measures
• They are a management tool
• They offer insight into the effectiveness of the software process and the projects that are
conducted using the process as a framework
• Basic quality and productivity data are collected
• These data are analyzed, compared against past averages, and assessed
• The goal is to determine whether quality and productivity improvements have occurred
• The data can also be used to pinpoint problem areas
• Remedies can then be developed and the software process can be improved

Uses of Measurement
• Can be applied to the software process with the intent of improving it on a continuous basis
• Can be used throughout a software project to assist in estimation, quality control, productivity
assessment, and project control
• Can be used to help assess the quality of software work products and to assist in tactical decision
making as a project proceeds

Reasons to Measure
• To characterize in order to
 Gain an understanding of processes, products, resources, and environments
 Establish baselines for comparisons with future assessments
• To evaluate in order to
 Determine status with respect to plans
• To predict in order to
 Gain understanding of relationships among processes and products
 Build models of these relationships
• To improve in order to

57
  Identify roadblocks, root causes, inefficiencies, and other opportunities for improving
product quality and process performance

Metrics in the Process Domain

• Process metrics are collected across all projects and over long periods of time
• They are used for making strategic decisions
• The intent is to provide a set of process indicators that lead to long-term software process
improvement
• The only way to know how/where to improve any process is to
 Measure specific attributes of the process
 Develop a set of meaningful metrics based on these attributes
 Use the metrics to provide indicators that will lead to a strategy for improvement
• We measure the effectiveness of a process by deriving a set of metrics based on outcomes of the
process such as
 Errors uncovered before release of the software
 Defects delivered to and reported by the end users
 Work products delivered
 Human effort expended
 Calendar time expended
 Conformance to the schedule
 Time and effort to complete each generic activity

Etiquette of Process Metrics

• Use common sense and organizational sensitivity when interpreting metrics data
• Provide regular feedback to the individuals and teams who collect measures and metrics
• Don’t use metrics to evaluate individuals
• Work with practitioners and teams to set clear goals and metrics that will be used to achieve them
• Never use metrics to threaten individuals or teams
• Metrics data that indicate a problem should not be considered “negative”
 Such data are merely an indicator for process improvement
• Don’t obsess on a single metric to the exclusion of other important metrics

Metrics in the Project Domain

• Project metrics enable a software project manager to

 Assess the status of an ongoing project
 Track potential risks
 Uncover problem areas before their status becomes critical
 Adjust work flow or tasks
 Evaluate the project team’s ability to control quality of software work products
• Many of the same metrics are used in both the process and project domain
• Project metrics are used for making tactical decisions
 They are used to adapt project workflow and technical activities

58
Use of Project Metrics

• The first application of project metrics occurs during estimation

 Metrics from past projects are used as a basis for estimating time and effort
• As a project proceeds, the amount of time and effort expended are compared to original estimates
• As technical work commences, other project metrics become important
 Production rates are measured (represented in terms of models created, review hours,
function points, and delivered source lines of code)
 Error uncovered during each generic framework activity (i.e, communication, planning,
modeling, construction, deployment) are measured
• Project metrics are used to
 Minimize the development schedule by making the adjustments necessary to avoid delays
and mitigate potential problems and risks
 Assess product quality on an ongoing basis and, when necessary, to modify the technical
approach to improve quality
• In summary
 As quality improves, defects are minimized
 As defects go down, the amount of rework required during the project is also reduced
 As rework goes down, the overall project cost is reduced

Software Measurement

Categories of Software Measurement

• Two categories of software measurement
 Direct measures of the
• Software process (cost, effort, etc.)
• Software product (lines of code produced, execution speed, defects reported over
time, etc.)
 Indirect measures of the
• Software product (functionality, quality, complexity, efficiency, reliability,
maintainability, etc.)
• Project metrics can be consolidated to create process metrics for an organization

Size-oriented Metrics
• Derived by normalizing quality and/or productivity measures by considering the size of the
software produced
• Thousand lines of code (KLOC) are often chosen as the normalization value
• Metrics include
 Errors per KLOC - Errors per person-month
 Defects per KLOC - KLOC per person-month
 Dollars per KLOC - Dollars per page of documentation
 Pages of documentation per KLOC

59
 • Size-oriented metrics are not universally accepted as the best way to measure the software
process
• Opponents argue that KLOC measurements
 Are dependent on the programming language
 Penalize well-designed but short programs
 Cannot easily accommodate nonprocedural languages
 Require a level of detail that may be difficult to achieve

Function-oriented Metrics
• Function-oriented metrics use a measure of the functionality delivered by the application as a
normalization value
• Most widely used metric of this type is the function point:

FP = count total * [0.65 + 0.01 * sum (value adj. factors)]

• Material in Chapter 15 covered this in more detail
• Function point values on past projects can be used to compute, for example, the average number
of lines of code per function point (e.g., 60)

Function Point Controversy

• Like the KLOC measure, function point use also has proponents and opponents
• Proponents claim that
 FP is programming language independent
 FP is based on data that are more likely to be known in the early stages of a project,
making it more attractive as an estimation approach
• Opponents claim that
 FP requires some “sleight of hand” because the computation is based on subjective data
 Counts of the information domain can be difficult to collect after the fact
 FP has no direct physical meaning…it’s just a number

Reconciling LOC and FP Metrics

• Relationship between LOC and FP depends upon

 The programming language that is used to implement the software
 The quality of the design
• FP and LOC have been found to be relatively accurate predictors of software development effort
and cost
 However, a historical baseline of information must first be established
• LOC and FP can be used to estimate object-oriented software projects
 However, they do not provide enough granularity for the schedule and effort adjustments
required in the iterations of an evolutionary or incremental process

60
 • The table on the next slide provides a rough estimate of the average LOC to one FP in various
programming languages

LOC Per Function Point

Language Average Median Low High

Ada 154 -- 104 205

Assembler 337 315 91 694

C 162 109 33 704

C++ 66 53 29 178

COBOL 77 77 14 400

Java 55 53 9 214

PL/1 78 67 22 263

Visual 47 42 16 158
Basic

Object-oriented Metrics
• Number of scenario scripts (i.e., use cases)
 This number is directly related to the size of an application and to the number of test
cases required to test the system
• Number of key classes (the highly independent components)
 Key classes are defined early in object-oriented analysis and are central to the problem
domain
 This number indicates the amount of effort required to develop the software
 It also indicates the potential amount of reuse to be applied during development
• Number of support classes
 Support classes are required to implement the system but are not immediately related to
the problem domain (e.g., user interface, database, computation)
 This number indicates the amount of effort and potential reuse
• Average number of support classes per key class
 Key classes are identified early in a project (e.g., at requirements analysis)
 Estimation of the number of support classes can be made from the number of key classes
 GUI applications have between two and three times more support classes as key classes
 Non-GUI applications have between one and two times more support classes as key
classes
• Number of subsystems
 A subsystem is an aggregation of classes that support a function that is visible to the end
user of a system

Metrics for Software Quality

• Correctness

61
  This is the number of defects per KLOC, where a defect is a verified lack of conformance
to requirements
 Defects are those problems reported by a program user after the program is released for
general use
• Maintainability
 This describes the ease with which a program can be corrected if an error is found,
adapted if the environment changes, or enhanced if the customer has changed
requirements
 Mean time to change (MTTC) : the time to analyze, design, implement, test, and
distribute a change to all users
• Maintainable programs on average have a lower MTTC

Defect Removal Efficiency

• Defect removal efficiency provides benefits at both the project and process level
• It is a measure of the filtering ability of QA activities as they are applied throughout all process
framework activities
 It indicates the percentage of software errors found before software release
• It is defined as DRE = E / (E + D)
 E is the number of errors found before delivery of the software to the end user
 D is the number of defects found after delivery
• As D increases, DRE decreases (i.e., becomes a smaller and smaller fraction)
• The ideal value of DRE is 1, which means no defects are found after delivery
• DRE encourages a software team to institute techniques for finding as many errors as possible
before delivery

Integrating Metrics within the Software Process

Arguments for Software Metrics

• Most software developers do not measure, and most have little desire to begin
• Establishing a successful company-wide software metrics program can be a multi-year effort
• But if we do not measure, there is no real way of determining whether we are improving
• Measurement is used to establish a process baseline from which improvements can be assessed
• Software metrics help people to develop better project estimates, produce higher-quality systems,
and get products out the door on time

Establishing a Metrics Baseline

• By establishing a metrics baseline, benefits can be obtained at the software process, product, and
project levels
• The same metrics can serve many masters
• The baseline consists of data collected from past projects
• Baseline data must have the following attributes
– Data must be reasonably accurate (guesses should be avoided)
– Data should be collected for as many projects as possible
– Measures must be consistent (e.g., a line of code must be interpreted consistently across
all projects)
– Past applications should be similar to the work that is to be estimated
• After data is collected and metrics are computed, the metrics should be evaluated and applied
during estimation, technical work, project control, and process improvement

62
Software Metrics Baseline Process

Getting Started with Metrics

1) Understand your existing process

2) Define the goals to be achieved by establishing a metrics program
3) Identify metrics to achieve those goals
 Keep the metrics simple
 Be sure the metrics add value to your process and product
4) Identify the measures to be collected to support those metrics
5) Establish a measurement collection process
 What is the source of the data?
 Can tools be used to collect the data?
 Who is responsible for collecting the data?
 When are the data collected and recorded?
 How are the data stored?
 What validation mechanisms are used to ensure the data are correct?
6) Acquire appropriate tools to assist in collection and assessment
7) Establish a metrics database
8) Define appropriate feedback mechanisms on what the metrics indicate about your process so that
the process and the metrics program can be improved

System Engineering
 Computer-based system
 System engineering process
 “Business process” engineering
 Product engineering

63
Computer-based System

Introduction

System
• System (Webster)
 A set or arrangement of things so related as to form a unity or organic whole
 A set of facts, principles, rules. etc., … to show a logical plan linking the various parts
 A method or plan of classification or arrangement
 An established way of doing something such as a method or procedure

Computer-based System
• Defined: A set or arrangement of elements that are organized to accomplish some predefined goal
by processing information
• The goal may be to support some business function or to develop a product that can be sold to
generate business revenue
• A computer-based system makes use of system elements
• Elements constituting one system may represent one macro element of a still larger system
• Example
 A factory automation system may consist of a numerical control machine, robots, and
data entry devices; each can be its own system
 At the next lower hierarchical level, a manufacturing cell is its own computer-based
system that may integrate other macro elements
• The role of the system engineer is to define the elements of a specific computer-based system in
the context of the overall hierarchy of systems
• A computer-based system makes use of the following four system elements that combine in a
variety of ways to transform information
 Software: computer programs, data structures, and related work products that serve to
effect the logical method, procedure, or control that is required
 Hardware: electronic devices that provide computing capability, interconnectivity
devices that enable flow of data, and electromechanical devices that provide external
functions
 People: Users and operators of hardware and software
 Database: A large, organized collection of information that is accessed via software and
persists over time
• The uses of these elements are described in the following:
 Documentation: Descriptive information that portrays the use and operation of the
system
 Procedures: The steps that define the specific use of each system element or the
procedural context in which the system resides

System Engineering Process

• The system engineering process begins with a world view; the business or product domain is
examined to ensure that the proper business or technology context can be established
• The world view is refined to focus on a specific domain of interest
• Within a specific domain, the need for targeted system elements is analyzed
• Finally, the analysis, design, and construction of a targeted system element are initiated
• At the world view level, a very broad context is established
• At the bottom level, detailed technical activities are conducted by the relevant engineering
discipline (e.g., software engineering)

64
System Engineering Hierarchy

System Modeling (at each view level)

• Defines the processes (e.g., domain classes in OO terminology) that serve the needs of the view
under consideration
• Represents the behavior of the processes and the assumptions on which the behavior is based
• Explicitly defines intra-level and inter-level input that form links between entities in the model
• Represents all linkages (including output) that will enable the engineer to better understand the
view
• May result in models that call for one of the following
 Completely automated solution
 A semi-automated solution
 A non-automated (i.e., manual) approach

Factors to Consider when Constructing a Model

• Assumptions
 These reduce the number of possible variations, thus enabling a model to reflect the
problem in a reasonable manner
• Simplifications
 These enable the model to be created in a timely manner
• Limitations
 These help to bound the maximum and minimum values of the system
• Constraints

65
  These guide the manner in which the model is created and the approach taken when the
model is implemented
• Preferences
 These indicate the preferred solution for all data, functions, and behavior
 They are driven by customer requirements

System Modeling with UML

• The Uniform Modeling Language (UML) provides diagrams for analysis and design at both the
system and software levels
• Examples
 Use case diagrams
 Activity diagrams
 Class diagrams
 State diagrams

Business Process Engineering

• “Business process” engineering defines architectures that will enable a business to use
information effectively
• It involves the specification of the appropriate computing architecture and the development of the
software architecture for the organization's computing resources
• Three different architectures must be analyzed and designed within the context of business
objectives and goals
 The data architecture provides a framework for the information needs of a business (e.g.,
ERD)
 The application architecture encompasses those elements of a system that transform
objects within the data architecture for some business purpose
 The technology infrastructure provides the foundation for the data and application
architectures
• It includes the hardware and software that are used to support the applications
and data

Product Engineering
• Product engineering translates the customer's desire for a set of defined capabilities into a
working product
• It achieves this goal by establishing a product architecture and a support infrastructure
 Product architecture components consist of people, hardware, software, and data
 Support infrastructure includes the technology required to tie the components together
and the information to support the components
• Requirements engineering elicits the requirements from the customer and allocates function and
behavior to each of the four components
• System component engineering happens next as a set of concurrent activities that address each of
the components separately
 Each component takes a domain-specific view but maintains communication with the
other domains
 The actual activities of the engineering discipline takes on an element view
• Analysis modeling allocates requirements into function, data, and behavior
• Design modeling maps the analysis model into data/class, architectural, interface, and component
design

66
Product Engineering Hierarchy

Requirements Engineering
 Problems with requirements practices
 Requirements engineering tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements management
 Many software developers argue that
 Building software is so compelling that we want to jump right in (before having a clear
understanding of what is needed)
 Things will become clear as we build the software
 Project stakeholders will be able to better understand what they need only after
examining early iterations of the software
 Things change so rapidly that requirements engineering is a waste of time
 The bottom line is producing a working program and that all else is secondary
 All of these arguments contain some truth, especially for small projects that take less than one
month to complete
 However, as software grows in size and complexity, these arguments begin to break down and
can lead to a failed software project

67
A Solution: Requirements Engineering
• Begins during the communication activity and continues into the modeling activity
• Builds a bridge from the system requirements into software design and construction
• Allows the requirements engineer to examine
 the context of the software work to be performed
 the specific needs that design and construction must address
 the priorities that guide the order in which work is to be completed
 the information, function, and behavior that will have a profound impact on the resultant
design

Requirements Engineering Tasks

• Seven distinct tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of the software

Inception Task
• During inception, the requirements engineer asks a set of questions to establish…
 A basic understanding of the problem
 The people who want a solution
 The nature of the solution that is desired
 The effectiveness of preliminary communication and collaboration between the customer
and the developer

68
 • Through these questions, the requirements engineer needs to…
 Identify the stakeholders
 Recognize multiple viewpoints
 Work toward collaboration
 Break the ice and initiate the communication

The First Set of Questions

These questions focus on the customer, other stakeholders, the overall goals, and the benefits
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

The Next Set of Questions

These questions enable the requirements engineer to gain a better understanding of the problem and allow
the customer to voice his or her perceptions about a solution
• How would you characterize "good" output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is approached?

The Final Set of Questions

These questions focus on the effectiveness of the communication activity itself
• Are you the right person to answer these questions? Are your answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

Elicitation Task
• Eliciting requirements is difficult because of
 Problems of scope in identifying the boundaries of the system or specifying too much
technical detail rather than overall system objectives
 Problems of understanding what is wanted, what the problem domain is, and what the
computing environment can handle (Information that is believed to be "obvious" is often
omitted)
 Problems of volatility because the requirements change over time
• Elicitation may be accomplished through two activities
 Collaborative requirements gathering
 Quality function deployment

Basic Guidelines of Collaborative Requirements Gathering

• Meetings are conducted and attended by both software engineers, customers, and other interested
stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important points but informal enough to
encourage the free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls the meeting

69
 • A "definition mechanism" is used such as work sheets, flip charts, wall stickers, electronic
bulletin board, chat room, or some other virtual forum
• The goal is to identify the problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements

Quality Function Deployment

• This is a technique that translates the needs of the customer into technical requirements for
software
• It emphasizes an understanding of what is valuable to the customer and then deploys these values
throughout the engineering process through functions, information, and tasks
• It identifies three types of requirements
 Normal requirements: These requirements are the objectives and goals stated for a
product or system during meetings with the customer
 Expected requirements: These requirements are implicit to the product or system and
may be so fundamental that the customer does not explicitly state them
 Exciting requirements: These requirements are for features that go beyond the customer's
expectations and prove to be very satisfying when present

Elicitation Work Products

The work products will vary depending on the system, but should include one or more of the following
items
• A statement of need and feasibility
• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders who participated in requirements elicitation
• A description of the system's technical environment
• A list of requirements (organized by function) and the domain constraints that apply to each
• A set of preliminary usage scenarios (in the form of use cases) that provide insight into the use of
the system or product under different operating conditions
• Any prototypes developed to better define requirements

Elaboration Task
• During elaboration, the software engineer takes the information obtained during inception and
elicitation and begins to expand and refine it
• Elaboration focuses on developing a refined technical model of software functions, features, and
constraints
• It is an analysis modeling task
 Use cases are developed
 Domain classes are identified along with their attributes and relationships
 State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional, informational, and behavioral
domains of the problem

Developing Use Cases

• Step One – Define the set of actors that will be involved in the story
 Actors are people, devices, or other systems that use the system or product within the
context of the function and behavior that is to be described
 Actors are anything that communicate with the system or product and that are external to
the system itself

70
 • Step Two – Develop use cases, where each one answers a set of questions

Questions Commonly Answered by a Use Case

• Who is the primary actor(s), the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the scenario begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the scenario is described?
• What variations in the actor’s interaction are possible?
• What system information will 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?

Elements of the Analysis Model

• Scenario-based elements
 Describe the system from the user's point of view using scenarios that are depicted in use
cases and activity diagrams
• Class-based elements
 Identify the domain classes for the objects manipulated by the actors, the attributes of
these classes, and how they interact with one another; they utilize class diagrams to do
this

• Behavioral elements
 Use state diagrams to represent the state of the system, the events that cause the system to
change state, and the actions that are taken as a result of a particular event; can also be
applied to each class in the system
• Flow-oriented elements
 Use data flow diagrams to show the input data that comes into a system, what functions
are applied to that data to do transformations, and what resulting output data are produced

Negotiation Task
• During negotiation, the software engineer reconciles the conflicts between what the customer
wants and what can be achieved given limited business resources
• Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders
• Risks associated with each requirement are identified and analyzed
• Rough guesses of development effort are made and used to assess the impact of each requirement
on project cost and delivery time
• Using an iterative approach, requirements are eliminated, combined and/or modified so that each
party achieves some measure of satisfaction

The Art of Negotiation

• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit

71
Specification Task
• A specification is the final work product produced by the requirements engineer
• It is normally in the form of a software requirements specification
• It serves as the foundation for subsequent software engineering activities
• It describes the function and performance of a computer-based system and the constraints that
will govern its development
• It formalizes the informational, functional, and behavioral requirements of the proposed software
in both a graphical and textual format

Typical Contents of a Software Requirements Specification

• Requirements
 Required states and modes
 Software requirements grouped by capabilities (i.e., functions, objects)
 Software external interface requirements
 Software internal interface requirements
 Software internal data requirements
 Other software requirements (safety, security, privacy, environment, hardware, software,
communications, quality, personnel, training, logistics, etc.)
 Design and implementation constraints
• Qualification provisions to ensure each requirement has been met
 Demonstration, test, analysis, inspection, etc.
• Requirements traceability
 Trace back to the system or subsystem where each requirement applies

Validation Task
• During validation, the work products produced as a result of requirements engineering are
assessed for quality
• The specification is examined to ensure that
 all software requirements have been stated unambiguously
 inconsistencies, omissions, and errors have been detected and corrected
 the work products conform to the standards established for the process, the project, and
the product
• The formal technical review serves as the primary requirements validation mechanism
 Members include software engineers, customers, users, and other stakeholders

Questions to ask when Validating Requirements

• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be essential
to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific individual)
noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable, once implemented?

72
 • Approaches: Demonstration, actual test, analysis, or inspection
• Does the requirements model properly reflect the information, function, and behavior of the
system to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more detailed
information about the system?

Requirements Management Task

• During requirements management, the project team performs a set of activities to identify,
control, and track requirements and changes to the requirements at any time as the project
proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more traceability tables
• These tables may be stored in a database that relate features, sources, dependencies, subsystems,
and interfaces to the requirements
• A requirements traceability table is also placed at the end of the software requirements
specification

Analysis Modeling
 Requirements analysis
 Flow-oriented modeling
 Scenario-based modeling
 Class-based modeling
 Behavioral modeling

Goals of Analysis Modeling

• Provides the first technical representation of a system
• Is easy to understand and maintain
• Deals with the problem of size by partitioning the system
• Uses graphics whenever possible
• Differentiates between essential information versus implementation information
• Helps in the tracking and evaluation of interfaces
• Provides tools other than narrative text to describe software logic and policy

A Set of Models
• Flow-oriented modeling – provides an indication of how data objects are transformed by a set of
processing functions
• Scenario-based modeling – represents the system from the user's point of view
• Class-based modeling – defines objects, attributes, and relationships
• Behavioral modeling – depicts the states of the classes and the impact of events on these states

Requirements Analysis

Purpose
• Specifies the software's operational characteristics
• Indicates the software's interfaces with other system elements
• Establishes constraints that the software must meet
• Provides the software designer with a representation of information, function, and behavior

73
 – This is later translated into architectural, interface, class/data and component-level
designs
 Provides the developer and customer with the means to assess quality once the software is built

Overall Objectives
• Three primary objectives
 To describe what the customer requires
 To establish a basis for the creation of a software design
 To define a set of requirements that can be validated once the software is built
• All elements of an analysis model are directly traceable to parts of the design model, and some
parts overlap

Analysis Rules of Thumb

• The analysis model should focus on requirements that are visible within the problem or business
domain
 The level of abstraction should be relatively high
• Each element of the analysis model should add to an overall understanding of software
requirements and provide insight into the following
 Information domain, function, and behavior of the system
• The model should delay the consideration of infrastructure and other non-functional models until
the design phase
 First complete the analysis of the problem domain
• The model should minimize coupling throughout the system
 Reduce the level of interconnectedness among functions and classes
• The model should provide value to all stakeholders
• The model should be kept as simple as can be

Domain Analysis
• Definition
 The identification, analysis, and specification of common, reusable capabilities within a
specific application domain
 Do this in terms of common objects, classes, subassemblies, and frameworks
• Sources of domain knowledge
 Technical literature
 Existing applications
 Customer surveys and expert advice
 Current/future requirements
• Outcome of domain analysis
 Class taxonomies
 Reuse standards
 Functional and behavioral models

74
  Domain languages

Analysis Modeling Approaches

• Structured analysis
 Considers data and the processes that transform the data as separate entities
 Data is modeled in terms of only attributes and relationships (but no operations)
 Processes are modeled to show the 1) input data, 2) the transformation that occurs on
that data, and 3) the resulting output data
• Object-oriented analysis
 Focuses on the definition of classes and the manner in which they collaborate with one
another to fulfill customer requirements

Elements of the Analysis Model

Flow-oriented Modeling

Data Modeling
• Identify the following items
 Data objects (Entities)
 Data attributes
 Relationships
 Cardinality (number of occurrences)

75
Data Flow and Control Flow

• Data Flow Diagram

– Depicts how input is transformed into output as data objects move through a system
• Process Specification
– Describes data flow processing at the lowest level of refinement in the data flow
diagrams
• Control Flow Diagram
 Illustrates how events affect the behavior of a system through the use of state diagrams

Diagram Layering and Process Refinement

Scenario-based Modeling

Writing Use Cases

• Writing of use cases was previously described in
Chapter 7 – Requirements Engineering
• It is effective to use the first person “I” to describe how the actor interacts with the software

76
 • Format of the text part of a use case

Example Use Case Diagram

Activity Diagrams
• Supplements the use case by providing a graphical representation of the flow of interaction within
a specific scenario
• Uses flowchart-like symbols
– Rounded rectangle - represent a specific system function/action

77
 – Arrow - represents the flow of control from one function/action to another
– Diamond - represents a branching decision
– Solid bar – represents the fork and join of parallel activities

Example Activity Diagram

Class-based Modeling

Identifying Analysis Classes

1) Perform a grammatical parse of the problem statement or use cases

2) Classes are determined by underlining each noun or noun clause
3) A class required to implement a solution is part of the solution space
4) A class necessary only to describe a solution is part of the problem space
5) A class should NOT have an imperative procedural name (i.e., a verb)
6) List the potential class names in a table and "classify" each class according to some taxonomy
and class selection characteristics
7) A potential class should satisfy nearly all (or all) of the selection characteristics to be considered a
legitimate problem domain class

Potential classes General classification Selection Characteristics

78
 • General classifications for a potential class
 External entity (e.g., another system, a device, a person)
 Thing (e.g., report, screen display)
 Occurrence or event (e.g., movement, completion)
 Role (e.g., manager, engineer, salesperson)
 Organizational unit (e.g., division, group, team)
 Place (e.g., manufacturing floor, loading dock)
 Structure (e.g., sensor, vehicle, computer)
• Six class selection characteristics
 Retained information
• Information must be remembered about the system over time
 Needed services
• Set of operations that can change the attributes of a class
 Multiple attributes
• Whereas, a single attribute may denote an atomic variable rather than a class
 Common attributes
• A set of attributes apply to all instances of a class
 Common operations
• A set of operations apply to all instances of a class
 Essential requirements
• Entities that produce or consume information

Defining Attributes of a Class

• Attributes of a class are those nouns from the grammatical parse that reasonably belong to a class
• Attributes hold the values that describe the current properties or state of a class
• An attribute may also appear initially as a potential class that is later rejected because of the class
selection criteria
• In identifying attributes, the following question should be answered
 What data items (composite and/or elementary) will fully define a specific class in the
context of the problem at hand?
• Usually an item is not an attribute if more than one of them is to be associated with a class

Defining Operations of a Class

• Operations define the behavior of an object
• Four categories of operations
 Operations that manipulate data in some way to change the state of an object (e.g., add,
delete, modify)
 Operations that perform a computation
 Operations that inquire about the state of an object
 Operations that monitor an object for the occurrence of a controlling event
• An operation has knowledge about the state of a class and the nature of its associations
• The action performed by an operation is based on the current values of the attributes of a class

79
 • Using a grammatical parse again, circle the verbs; then select the verbs that relate to the problem
domain classes that were previously identified

Example Class Box

Association, Generalization and Dependency

• Association
 Represented by a solid line between two classes directed from the source class to the
target class
 Used for representing (i.e., pointing to) object types for attributes
 May also be a part-of relationship (i.e., aggregation), which is represented by a diamond-
arrow
• Generalization
 Portrays inheritance between a super class and a subclass
 Is represented by a line with a triangle at the target end
• Dependency
 A dependency exists between two elements if changes to the definition of one element
(i.e., the source or supplier) may cause changes to the other element (i.e., the client)
 Examples
• One class calls a method of another class
• One class utilizes another class as a parameter of a method

80
Example Class Diagram

Behavioral Modeling

Creating a Behavioral Model

1) Identify events found within the use cases and implied by the attributes in the class diagrams
2) Build a state diagram for each class, and if useful, for the whole software system

Identifying Events in Use Cases

• An event occurs whenever an actor and the system exchange information
• An event is NOT the information that is exchanged, but rather the fact that information has been
exchanged
• Some events have an explicit impact on the flow of control, while others do not
 An example is the reading of a data item from the user versus comparing the data item to some
possible value

Building a State Diagram

• A state is represented by a rounded rectangle

• A transition (i.e., event) is represented by a labeled arrow leading from one state to another
 Syntax: trigger-signature [guard]/activity
• The active state of an object indicates the current overall status of the object as is goes through
transformation or processing
 A state name represents one of the possible active states of an object
• The passive state of an object is the current value of all of an object's attributes
 A guard in a transition may contain the checking of the passive state of an object

81
Example State Diagram

Design Engineering
 Introduction
 Design quality
 Design concepts
 The design model

Introduction

Purpose of Design
• Design is where customer requirements, business needs, and technical considerations all come
together in the formulation of a product or system
• The design model provides detail about the software data structures, architecture, interfaces, and
components
• The design model can be assessed for quality and be improved before code is generated and tests
are conducted
 Does the design contain errors, inconsistencies, or omissions?
 Are there better design alternatives?
 Can the design be implemented within the constraints, schedule, and cost that have been
established?
• A designer must practice diversification and convergence
 The designer selects from design components, component solutions, and knowledge
available through catalogs, textbooks, and experience
 The designer then chooses the elements from this collection that meet the requirements
defined by requirements engineering and analysis modeling
 Convergence occurs as alternatives are considered and rejected until one particular
configuration of components is chosen
• Software design is an iterative process through which requirements are translated into a blueprint
for constructing the software

82
  Design begins at a high level of abstraction that can be directly traced back to the data,
functional, and behavioral requirements
 As design iteration occurs, subsequent refinement leads to design representations at much
lower levels of abstraction

From Analysis Model to Design Model

• necessary to create the four design models
 The data/class design transforms analysis classes into design classes along with the data
structures required to implement the software
 The architectural design defines the relationship between major structural elements of the
software; architectural styles and design patterns help achieve the requirements defined
for the system
 The interface design describes how the software communicates with systems that
interoperate with it and with humans that use it
 The component-level design transforms structural elements of the software architecture
into a procedural description of software components

Task Set for Software Design

1) Examine the information domain model and design appropriate data structures for data objects
and their attributes
2) Using the analysis model, select an architectural style (and design patterns) that are appropriate
for the software
3) Partition the analysis model into design subsystems and allocate these subsystems within the
architecture
a) Design the subsystem interfaces
b) Allocate analysis classes or functions to each subsystem
4) Create a set of design classes or components
a) Translate each analysis class description into a design class
b) Check each design class against design criteria; consider inheritance issues
c) Define methods associated with each design class

83
 d) Evaluate and select design patterns for a design class or subsystem
5) Design any interface required with external systems or devices
6) Design the user interface
7) Conduct component-level design
a) Specify all algorithms at a relatively low level of abstraction
b) Refine the interface of each component
c) Define component-level data structures
d) Review each component and correct all errors uncovered
8) Develop a deployment model
a) Show a physical layout of the system, revealing which components will be located where
in the physical computing environment

Design Quality

Quality's Role
• The importance of design is quality
• Design is the place where quality is fostered
 Provides representations of software that can be assessed for quality
 Accurately translates a customer's requirements into a finished software product or
system
 Serves as the foundation for all software engineering activities that follow
• Without design, we risk building an unstable system that
 Will fail when small changes are made
 May be difficult to test
 Cannot be assessed for quality later in the software process when time is short and most
of the budget has been spent
• The quality of the design is assessed through a series of formal technical reviews or design
walkthroughs

Goals of a Good Design

• The design must implement all of the explicit requirements contained in the analysis model
 It must also accommodate all of the implicit requirements desired by the customer
• The design must be a readable and understandable guide for those who generate code, and for
those who test and support the software
• The design should provide a complete picture of the software, addressing the data, functional, and
behavioral domains from an implementation perspective

Design Quality Guidelines

1) A design should exhibit an architecture that
a) Has been created using recognizable architectural styles or patterns
b) Is composed of components that exhibit good design characteristics
c) Can be implemented in an evolutionary fashion, thereby facilitating implementation and
testing
2) A design should be modular; that is, the software should be logically partitioned into elements or
subsystems
3) A design should contain distinct representations of data, architecture, interfaces, and components
4) A design should lead to data structures that are appropriate for the classes to be implemented and
are drawn from recognizable data patterns
5) A design should lead to components that exhibit independent functional characteristics
6) A design should lead to interfaces that reduce the complexity of connections between components
and with the external environment

84
 7) A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis
8) A design should be represented using a notation that effectively communicates its meaning

Design Concepts
• Abstraction
 Procedural abstraction – a sequence of instructions that have a specific and limited
function
 Data abstraction – a named collection of data that describes a data object
• Architecture
 The overall structure of the software and the ways in which the structure provides
conceptual integrity for a system
 Consists of components, connectors, and the relationship between them
• Patterns
 A design structure that solves a particular design problem within a specific context
 It provides a description that enables a designer to determine whether the pattern is
applicable, whether the pattern can be reused, and whether the pattern can serve as a
guide for developing similar patterns
• Modularity
 Separately named and addressable components (i.e., modules) that are integrated to
satisfy requirements (divide and conquer principle)
 Makes software intellectually manageable so as to grasp the control paths, span of
reference, number of variables, and overall complexity
• Information hiding
 The designing of modules so that the algorithms and local data contained within them are
inaccessible to other modules
 This enforces access constraints to both procedural (i.e., implementation) detail and local
data structures
• Functional independence
 Modules that have a "single-minded" function and an aversion to excessive interaction
with other modules
 High cohesion – a module performs only a single task
 Low coupling – a module has the lowest amount of connection needed with other
modules
• Stepwise refinement
 Development of a program by successively refining levels of procedure detail
 Complements abstraction, which enables a designer to specify procedure and data and yet
suppress low-level details
• Refactoring
 A reorganization technique that simplifies the design (or internal code structure) of a
component without changing its function or external behavior
 Removes redundancy, unused design elements, inefficient or unnecessary algorithms,
poorly constructed or inappropriate data structures, or any other design failures

85
 • Design classes
 Refines the analysis classes by providing design detail that will enable the classes to be
implemented
 Creates a new set of design classes that implement a software infrastructure to support the
business solution

Types of Design Classes

• User interface classes – define all abstractions necessary for human-computer interaction
(usually via metaphors of real-world objects)
• Business domain classes – refined from analysis classes; identify attributes and services
(methods) that are required to implement some element of the business domain
• Process classes – implement business abstractions required to fully manage the business domain
classes
• Persistent classes – represent data stores (e.g., a database) that will persist beyond the execution
of the software
• System classes – implement software management and control functions that enable the system
to operate and communicate within its computing environment and the outside world

Characteristics of a Well-Formed Design Class

• Complete and sufficient
 Contains the complete encapsulation of all attributes and methods that exist for the class
 Contains only those methods that are sufficient to achieve the intent of the class
• Primitiveness
 Each method of a class focuses on accomplishing one service for the class
• High cohesion
 The class has a small, focused set of responsibilities and single-mindedly applies
attributes and methods to implement those responsibilities
• Low coupling
 Collaboration of the class with other classes is kept to an acceptable minimum
 Each class should have limited knowledge of other classes in other subsystems

The Design Model

86
Dimensions of the Design Model

Introduction
• The design model can be viewed in two different dimensions
 (Horizontally) The process dimension indicates the evolution of the parts of the design
model as each design task is executed
 (Vertically) The abstraction dimension represents the level of detail as each element of
the analysis model is transformed into the design model and then iteratively refined
• Elements of the design model use many of the same UML diagrams used in the analysis model
 The diagrams are refined and elaborated as part of the design
 More implementation-specific detail is provided
 Emphasis is placed on
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architecture
• Design model elements are not always developed in a sequential fashion
 Preliminary architectural design sets the stage
 It is followed by interface design and component-level design, which often occur in
parallel
• The design model has the following layered elements
 Data/class design
 Architectural design
 Interface design
 Component-level design
• A fifth element that follows all of
the others is deployment-level design

87
Design Elements
• Data/class design
 Creates a model of data and objects that is represented at a high level of abstraction
• Architectural design
 Depicts the overall layout of the software
• Interface design
 Tells how information flows into and out of the system and how it is communicated
among the components defined as part of the architecture
 Includes the user interface, external interfaces, and internal interfaces
• Component-level design elements
 Describes the internal detail of each software component by way of data structure
definitions, algorithms, and interface specifications
• Deployment-level design elements
 Indicates how software functionality and subsystems will be allocated within the
physical computing environment that will support the software

Pattern-based Software Design

• Mature engineering disciplines make use of thousands of design patterns for such things as
buildings, highways, electrical circuits, factories, weapon systems, vehicles, and computers
• Design patterns also serve a purpose in software engineering
• Architectural patterns
 Define the overall structure of software
 Indicate the relationships among subsystems and software components
 Define the rules for specifying relationships among software elements
• Design patterns
 Address a specific element of the design such as an aggregation of components or solve
some design problem, relationships among components, or the mechanisms for effecting
inter-component communication
 Consist of creational, structural, and behavioral patterns
• Coding patterns
 Describe language-specific patterns that implement an algorithmic or data structure
element of a component, a specific interface protocol, or a mechanism for communication
among components

Architectural Design
 Introduction
 Data design
 Software architectural styles
 Architectural design process
 Assessing alternative architectural designs

Definitions
• The software architecture of a program or computing system is the structure or structures of the
system which comprise
 The software components
 The externally visible properties of those components
 The relationships among the components

88
 • Software architectural design represents the structure of the data and program components that
are required to build a computer-based system
• An architectural design model is transferable
 It can be applied to the design of other systems
 It represents a set of abstractions that enable software engineers to describe architecture
in predictable ways

Architectural Design Process

• Basic Steps
 Creation of the data design
 Derivation of one or more representations of the architectural structure of the system
 Analysis of alternative architectural styles to choose the one best suited to customer
requirements and quality attributes
 Elaboration of the architecture based on the selected architectural style
• A database designer creates the data architecture for a system to represent the data components
• A system architect selects an appropriate architectural style derived during system engineering
and software requirements analysis

Emphasis on Software Components

• A software architecture enables a software engineer to

 Analyze the effectiveness of the design in meeting its stated requirements
 Consider architectural alternatives at a stage when making design changes is still
relatively easy
 Reduce the risks associated with the construction of the software
• Focus is placed on the software component
 A program module
 An object-oriented class
 A database
 Middleware

Importance of Software Architecture

• Representations of software architecture are an enabler for communication between all

stakeholders interested in the development of a computer-based system
• The software architecture highlights early design decisions that will have a profound impact on
all software engineering work that follows and, as important, on the ultimate success of the
system as an operational entity
• The software architecture constitutes a relatively small, intellectually graspable model of how the
system is structured and how its components work together

89
Example Software Architecture Diagram

Data Design
Purpose of Data Design
• Data design translates data objects defined as part of the analysis model into
– Data structures at the software component level
– A possible database architecture at the application level
• It focuses on the representation of data structures that are directly accessed by one or more
software components
• The challenge is to store and retrieve the data in such way that useful information can be
extracted from the data environment
• "Data quality is the difference between a data warehouse and a data garbage dump"

Data Design Principles

• behavior should also be applied to data
• All data structures and the operations to be performed on each one should be identified
• A mechanism for defining the content of each data object should be established and used to
define both data and the operations applied to it
• Low-level data design decisions should be deferred until late in the design process
• The representation of a data structure should be known only to those modules that must make
direct use of the data contained within the structure
• A library of useful data structures and the operations that may be applied to them should be
developed
• A software programming language should support the specification and realization of abstract
data types

Software Architectural Styles

• The software that is built for computer-based systems exhibit one of many architectural styles
• Each style describes a system category that encompasses
 A set of component types that perform a function required by the system
 A set of connectors (subroutine call, remote procedure call, data stream, socket) that
enable communication, coordination, and cooperation among components
 Semantic constraints that define how components can be integrated to form the system

90
  A topological layout of the components indicating their runtime interrelationships
A Taxonomy of Architectural Styles

Data Flow Style

• Has the goal of modifiability

• Characterized by viewing the system as a series of transformations on successive pieces of input
data
• Data enters the system and then flows through the components one at a time until they are
assigned to output or a data store
• Batch sequential style
 The processing steps are independent components
 Each step runs to completion before the next step begins
• Pipe-and-filter style
 Emphasizes the incremental transformation of data by successive components
 The filters incrementally transform the data (entering and exiting via streams)
 The filters use little contextual information and retain no state between instantiations
 The pipes are stateless and simply exist to move data between filters
• Advantages
 Has a simplistic design in the limited ways in which the components interact with the
environment

91
  Consists of no more and no less than the construction of its parts
 Simplifies reuse and maintenance
 Is easily made into a parallel or distributed execution in order to enhance system
performance
• Disadvantages
 Implicitly encourages a batch mentality so interactive applications are difficult to create
in this style
 Ordering of filters can be difficult to maintain so the filters cannot cooperatively interact
to solve a problem
 Exhibits poor performance
• Filters typically force the least common denominator of data representation
(usually ASCII stream)
• Filter may need unlimited buffers if they cannot start producing output until they
receive all of the input
• Each filter operates as a separate process or procedure call, thus incurring
overhead in set-up and take-down time
• Use this style when it makes sense to view your system as one that produces a well-defined easily
identified output
 The output should be a direct result of sequentially transforming a well-defined easily
identified input in a time-independent fashion

Call-and-Return Style

• Has the goal of modifiability and scalability

• Has been the dominant architecture since the start of software development
• Main program and subroutine style
 Decomposes a program hierarchically into small pieces (i.e., modules)

92
  Typically has a single thread of control that travels through various components in the
hierarchy
• Remote procedure call style
 Consists of main program and subroutine style of system that is decomposed into parts
that are resident on computers connected via a network
 Strives to increase performance by distributing the computations and taking advantage of
multiple processors
 Incurs a finite communication time between subroutine call and response
• Object-oriented or abstract data type system
 Emphasizes the bundling of data and how to manipulate and access data
 Keeps the internal data representation hidden and allows access to the object only
through provided operations
 Permits inheritance and polymorphism
• Layered system
 Assigns components to layers in order to control inter-component interaction
 Only allows a layer to communicate with its immediate neighbor
 Assigns core functionality such as hardware interfacing or system kernel operations to the
lowest layer
 Builds each successive layer on its predecessor, hiding the lower layer and providing
services for the upper layer
 Is compromised by layer bridging that skips one or more layers to improve runtime
performance
• Use this style when the order of computation is fixed, when interfaces are specific, and when
components can make no useful progress while awaiting the results of request to other
components

Data-Centered Style

• Has the goal of integrating the data

• Refers to systems in which the access and update of a widely accessed data store occur

93
 • A client runs on an independent thread of control
• The shared data may be a passive repository or an active blackboard
 A blackboard notifies subscriber clients when changes occur in data of interest
• At its heart is a centralized data store that communicates with a number of clients
• Clients are relatively independent of each other so they can be added, removed, or changed in
functionality
• The data store is independent of the clients
• Use this style when a central issue is the storage, representation, management, and retrieval of a
large amount of related persistent data
• Note that this style becomes client/server if the clients are modeled as independent processes

Virtual Machine Style

• Has the goal of portability

• Software systems in this style simulate some functionality that is not native to the hardware
and/or software on which it is implemented
– Can simulate and test hardware platforms that have not yet been built
– Can simulate "disaster modes" as in flight simulators or safety-critical systems that would
be too complex, costly, or dangerous to test with the real system
• Examples include interpreters, rule-based systems, and command language processors
• Interpreters
– Add flexibility through the ability to interrupt and query the program and introduce
modifications at runtime
– Incur a performance cost because of the additional computation involved in execution
• Use this style when you have developed a program or some form of computation but have no
make of machine to directly run it on

94
Independent Component Style

• Consists of a number of independent processes that communicate through messages

• Has the goal of modifiability by decoupling various portions of the computation
• Sends data between processes but the processes do not directly control each other
• Event systems style
 Individual components announce data that they wish to share (publish) with their
environment
 The other components may register an interest in this class of data (subscribe)
 Makes use of a message component that manages communication among the other
components
 Components publish information by sending it to the message manager
 When the data appears, the subscriber is invoked and receives the data
 Decouples component implementation from knowing the names and locations of other
components
• Communicating processes style
 These are classic multi-processing systems
 Well-know subtypes are client/server and peer-to-peer
 The goal is to achieve scalability
 A server exists to provide data and/or services to one or more clients
 The client originates a call to the server which services the request
• Use this style when
 Your system has a graphical user interface
 Your system runs on a multiprocessor platform
 Your system can be structured as a set of loosely coupled components
 Performance tuning by reallocating work among processes is important
 Message passing is sufficient as an interaction mechanism among components

95
Heterogeneous Styles
• Systems are seldom built from a single architectural style
• Three kinds of heterogeneity
 Locationally heterogeneous
• The drawing of the architecture reveals different styles in different areas (e.g., a
branch of a call-and-return system may have a shared repository)
 Hierarchically heterogeneous
• A component of one style, when decomposed, is structured according to the rules
of a different style
 Simultaneously heterogeneous
• Two or more architectural styles may both be appropriate descriptions for the
style used by a computer-based system

Architectural Design Process

Architectural Design Steps
1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system

1. Represent the System in Context

96
 • Use an architectural context diagram (ACD) that shows
 The identification and flow of all information into and out of a system
 The specification of all interfaces
 Any relevant support processing from/by other systems
• An ACD models the manner in which software interacts with entities external to its boundaries
• An ACD identifies systems that interoperate with the target system
 Super-ordinate systems
• Use target system as part of some higher level processing scheme
 Sub-ordinate systems
• Used by target system and provide necessary data or processing
 Peer-level systems
• Interact on a peer-to-peer basis with target system to produce or consume data
 Actors
• People or devices that interact with target system to produce or consume data

2. Define Archetypes

• Archetypes indicate the important abstractions within the problem domain (i.e., they model
information)
• An archetype is a class or pattern that represents a core abstraction that is critical to the design of
an architecture for the target system
• It is also an abstraction from a class of programs with a common structure and includes class-
specific design strategies and a collection of example program designs and implementations
• Only a relatively small set of archetypes is required in order to design even relatively complex
systems
• The target system architecture is composed of these archetypes
 They represent stable elements of the architecture
 They may be instantiated in different ways based on the behavior of the system
 They can be derived from the analysis class model
The archetypes and their relationships can be illustrated in a UML class diagram

97
Example Archetypes in Software Architecture

Archetypes – their attributes

98
Archetypes – their methods

3. Refine the Architecture into Components

• Based on the archetypes, the architectural designer refines the software architecture into
components to illustrate the overall structure and architectural style of the system
• These components are derived from various sources
 The application domain provides application components, which are the domain classes
in the analysis model that represent entities in the real world
 The infrastructure domain provides design components (i.e., design classes) that enable
application components but have no business connection
• Examples: memory management, communication, database, and task
management

99
  The interfaces in the ACD imply one or more specialized components that process the
data that flow across the interface
 A UML class diagram can represent the classes of the refined architecture and their relationships
4. Describe Instantiations of the System

• An actual instantiation of the architecture is developed by applying it to a specific problem

• This demonstrates that the architectural structure, style and components are appropriate
• A UML component diagram can be used to represent this instantiation

Assessing Alternative Architectural Designs

Various Assessment Approaches

A. Ask a set of questions that provide the designer with an early assessment of design quality and lay
the foundation for more detailed analysis of the architecture
• Assess the control in an architectural design (see next slide)
• Assess the data in an architectural design (see upcoming slide)
B. Apply the architecture trade-off analysis method
C. Assess the architectural complexity

Approach A: Questions -- Assessing Control in an Architectural Design

• How is control managed within the architecture?
• Does a distinct control hierarchy exist, and if so, what is the role of components within this
control hierarchy?
• How do components transfer control within the system?
• How is control shared among components?
• What is the control topology (i.e., the geometric form that the control takes)?
• Is control synchronized or do components operate asynchronously?

Approach A: Questions -- Assessing Data in an Architectural Design

• How are data communicated between components?
• Is the flow of data continuous, or are data objects passed to the system sporadically?
• What is the mode of data transfer (i.e., are data passed from one component to another or are data
available globally to be shared among system components)
• Do data components exist (e.g., a repository or blackboard), and if so, what is their role?
• How do functional components interact with data components?
• Are data components passive or active (i.e., does the data component actively interact with other
components in the system)?
• How do data and control interact within the system?

Approach B: Architecture Trade-off Analysis Method

1) Collect scenarios representing the system from the user's point of view
2) Elicit requirements, constraints, and environment description to be certain all stakeholder
concerns have been addressed
3) Describe the candidate architectural styles that have been chosen to address the scenarios and
requirements
4) Evaluate quality attributes by considering each attribute in isolation (reliability, performance,
security, maintainability, flexibility, testability, portability, reusability, and interoperability)
5) Identify the sensitivity of quality attributes to various architectural attributes for a specific
architectural style by making small changes in the architecture
6) Critique the application of the candidate architectural styles (from step #3) using the sensitivity
analysis conducted in step #5

100
Approach C: Assessing Architectural Complexity
• The overall complexity of a software architecture can be assessed by considering the
dependencies between components within the architecture
• These dependencies are driven by the information and control flow within a system
• Three types of dependencies
– Sharing dependency U      V
• Represents a dependency relationship among consumers who use the same
source or producer
– Flow dependency  U  V 
• Represents a dependency relationship between producers and consumers of
resources
– Constrained dependency U “XOR” V
• Represents constraints on the relative flow of control among a set of activities
such as mutual exclusion between two components

Component-Level Design
 Introduction
 The software component
 Designing class-based components
 Designing conventional components

Introduction

Background

• Component-level design occurs after the first iteration of the architectural design
• It strives to create a design model from the analysis and architectural models
 The translation can open the door to subtle errors that are difficult to find and correct later
 “Effective programmers should not waste their time debugging – they should not
introduce bugs to start with.” Edsgar Dijkstra
• A component-level design can be represented using some intermediate representation (e.g.
graphical, tabular, or text-based) that can be translated into source code
• The design of data structures, interfaces, and algorithms should conform to well-established
guidelines to help us avoid the introduction of errors

The Software Component

• A software component is a modular building block for computer software
 It is a modular, deployable, and replaceable part of a system that encapsulates
implementation and exposes a set of interfaces
• A component communicates and collaborates with
 Other components
 Entities outside the boundaries of the system
• Three different views of a component
 An object-oriented view
 A conventional view
 A process-related view

101
Object-oriented View
• A component is viewed as a set of one or more collaborating classes
• Each problem domain (i.e., analysis) class and infrastructure (i.e., design) class is elaborated to
identify all attributes and operations that apply to its implementation
 This also involves defining the interfaces that enable classes to communicate and
collaborate
• This elaboration activity is applied to every component defined as part of the architectural design
• Once this is completed, the following steps are performed
 Provide further elaboration of each attribute, operation, and interface
 Specify the data structure appropriate for each attribute
 Design the algorithmic detail required to implement the processing logic associated with
each operation
 Design the mechanisms required to implement the interface to include the messaging that
occurs between objects

Conventional View
• A component is viewed as a functional element (i.e., a module) of a program that incorporates
 The processing logic
 The internal data structures that are required to implement the processing logic
 An interface that enables the component to be invoked and data to be passed to it
• A component serves one of the following roles
 A control component that coordinates the invocation of all other problem domain
components
 A problem domain component that implements a complete or partial function that is
required by the customer
 An infrastructure component that is responsible for functions that support the processing
required in the problem domain
• Conventional software components are derived from the data flow diagrams (DFDs) in the
analysis model
 Each transform bubble (i.e., module) represented at the lowest levels of the DFD is
mapped into a module hierarchy
 Control components reside near the top
 Problem domain components and infrastructure components migrate toward the bottom
 Functional independence is strived for between the transforms
• Once this is completed, the following steps are performed for each transform
 Define the interface for the transform (the order, number and types of the parameters)
 Define the data structures used internally by the transform
 Design the algorithm used by the transform (using a stepwise refinement approach)

Process-related View
• Emphasis is placed on building systems from existing components maintained in a library rather
than creating each component from scratch
• As the software architecture is formulated, components are selected from the library and used to
populate the architecture
• Because the components in the library have been created with reuse in mind, each contains the
following:
 A complete description of their interface
 The functions they perform
 The communication and collaboration they require

102
Designing Class-Based Components

Component-level Design Principles

• Open-closed principle
 A module or component should be open for extension but closed for modification
 The designer should specify the component in a way that allows it to be extended without
the need to make internal code or design modifications to the existing parts of the
component
• Liskov substitution principle
 Subclasses should be substitutable for their base classes
 A component that uses a base class should continue to function properly if a subclass of
the base class is passed to the component instead
• Dependency inversion principle
 Depend on abstractions (i.e., interfaces); do not depend on concretions
 The more a component depends on other concrete components (rather than on the
interfaces) the more difficult it will be to extend
• Interface segregation principle
 Many client-specific interfaces are better than one general purpose interface
 For a server class, specialized interfaces should be created to serve major categories of
clients
 Only those operations that are relevant to a particular category of clients should be
specified in the interface

Component Packaging Principles

• Release reuse equivalency principle
 The granularity of reuse is the granularity of release
 Group the reusable classes into packages that can be managed, upgraded, and controlled
as newer versions are created
• Common closure principle
 Classes that change together belong together
 Classes should be packaged cohesively; they should address the same functional or
behavioral area on the assumption that if one class experiences a change then they all will
experience a change
• Common reuse principle
 Classes that aren't reused together should not be grouped together
 Classes that are grouped together may go through unnecessary integration and testing
when they have experienced no changes but when other classes in the package have been
upgraded

Component-Level Design Guidelines

• Components
 Establish naming conventions for components that are specified as part of the
architectural model and then refined and elaborated as part of the component-level model
 Obtain architectural component names from the problem domain and ensure that they
have meaning to all stakeholders who view the architectural model (e.g., Calculator)

103
  Use infrastructure component names that reflect their implementation-specific meaning
(e.g., Stack)
• Dependencies and inheritance in UML
 Model any dependencies from left to right and inheritance from top (base class) to bottom
(derived classes)
 Consider modeling any component dependencies as interfaces rather than representing
them as a direct component-to-component dependency

Cohesion
• Cohesion is the “single-mindedness’ of a component
• It implies that a component or class encapsulates only attributes and operations that are closely
related to one another and to the class or component itself
• The objective is to keep cohesion as high as possible
• The kinds of cohesion can be ranked in order from highest (best) to lowest (worst)
 Functional
• A module performs one and only one computation and then returns a result
 Layer
• A higher layer component accesses the services of a lower layer component
 Communicational
• All operations that access the same data are defined within one class
 Sequential
• Components or operations are grouped in a manner that allows the first to
provide input to the next and so on in order to implement a sequence of
operations
 Procedural
• Components or operations are grouped in a manner that allows one to be invoked
immediately after the preceding one was invoked, even when no data passed
between them
 Temporal
• Operations are grouped to perform a specific behavior or establish a certain state
such as program start-up or when an error is detected
 Utility
• Components, classes, or operations are grouped within the same category
because of similar general functions but are otherwise unrelated to each other

Coupling
• As the amount of communication and collaboration increases between operations and classes, the
complexity of the computer-based system also increases
• As complexity rises, the difficulty of implementing, testing, and maintaining software also
increases
• Coupling is a qualitative measure of the degree to which operations and classes are connected to
one another
• The objective is to keep coupling as low as possible
• The kinds of coupling can be ranked in order from lowest (best) to highest (worst)
• Data coupling
• Operation A() passes one or more atomic data operands to operation B(); the less
the number of operands, the lower the level of coupling
• Stamp coupling
• A whole data structure or class instantiation is passed as a parameter to an
operation
• Control coupling

104
 • Operation A() invokes operation B() and passes a control flag to B that directs
logical flow within B()
• Consequently, a change in B() can require a change to be made to the meaning of
the control flag passed by A(), otherwise an error may result
• Common coupling
• A number of components all make use of a global variable, which can lead to
uncontrolled error propagation and unforeseen side effects
• Content coupling
• One component secretly modifies data that is stored internally in another
component

• Other kinds of coupling (unranked)

 Subroutine call coupling
• When one operation is invoked it invokes another operation within side of it
 Type use coupling
• Component A uses a data type defined in component B, such as for an instance
variable or a local variable declaration
• If/when the type definition changes, every component that declares a variable of
that data type must also change
 Inclusion or import coupling
• Component A imports or includes the contents of component B
 External coupling
• A component communicates or collaborates with infrastructure components that
are entities external to the software (e.g., operating system functions, database
functions, networking functions)

Conducting Component-Level Design

1) Identify all design classes that correspond to the problem domain as defined in the analysis model
and architectural model
2) Identify all design classes that correspond to the infrastructure domain
• These classes are usually not present in the analysis or architectural models
• These classes include GUI components, operating system components, data management
components, networking components, etc.
3) Elaborate all design classes that are not acquired as reusable components
• Specify message details (i.e., structure) when classes or components collaborate
• Identify appropriate interfaces (e.g., abstract classes) for each component
• Elaborate attributes and define data types and data structures required to implement them
(usually in the planned implementation language)
• Describe processing flow within each operation in detail by means of pseudocode or
UML activity diagrams
4) Describe persistent data sources (databases and files) and identify the classes required to manage
them
5) Develop and elaborate behavioral representations for a class or component
• This can be done by elaborating the UML state diagrams created for the analysis model
and by examining all use cases that are relevant to the design class
6) Elaborate deployment diagrams to provide additional implementation detail
• Illustrate the location of key packages or classes of components in a system by using
class instances and designating specific hardware and operating system environments
7) Factor every component-level design representation and always consider alternatives

105
 • Experienced designers consider all (or most) of the alternative design solutions before
settling on the final design model
• The final decision can be made by using established design principles and guidelines
Designing Conventional Components

Introduction

• Conventional design constructs emphasize the maintainability of a functional/procedural program

 Sequence, condition, and repetition
• Each construct has a predictable logical structure where control enters at the top and exits at the
bottom, enabling a maintainer to easily follow the procedural flow
• Various notations depict the use of these constructs
 Graphical design notation
• Sequence, if-then-else, selection, repetition (see next slide)
 Tabular design notation (see upcoming slide)
 Program design language
• Similar to a programming language; however, it uses narrative text embedded
directly within the program statements

Graphical Design Notation

Tabular Design Notation

1) List all actions that can be associated with a specific procedure (or module)
2) List all conditions (or decisions made) during execution of the procedure
3) Associate specific sets of conditions with specific actions, eliminating impossible combinations
of conditions; alternatively, develop every possible permutation of conditions
4) Define rules by indicating what action(s) occurs for a set of conditions

106
 Rules

Conditions 1 2 3 4

Condition A T T F

Condition B F T
Condition C T T

Actions
Action X  

Action Y 

Action Z   

Software Testing Strategies

 A strategic approach to testing
 Test strategies for conventional software
 Test strategies for object-oriented software
 Validation testing
 System testing
 The art of debugging

Introduction
• A strategy for software testing integrates the design of software test cases into a well-planned
series of steps that result in successful development of the software
• The strategy provides a road map that describes the steps to be taken, when, and how much effort,
time, and resources will be required
• The strategy incorporates test planning, test case design, test execution, and test result collection
and evaluation
• The strategy provides guidance for the practitioner and a set of milestones for the manager
• Because of time pressures, progress must be measurable and problems must surface as early as
possible

A Strategic Approach to Testing

General Characteristics of Strategic Testing

• To perform effective testing, a software team should conduct effective formal technical reviews

107
 • Testing begins at the component level and work outward toward the integration of the entire
computer-based system
• Different testing techniques are appropriate at different points in time
• Testing is conducted by the developer of the software and (for large projects) by an independent
test group
• Testing and debugging are different activities, but debugging must be accommodated in any
testing strategy

Verification and Validation

• Software testing is part of a broader group of activities called verification and validation that are
involved in software quality assurance
• Verification (Are the algorithms coded correctly?)
 The set of activities that ensure that software correctly implements a specific function or
algorithm
• Validation (Does it meet user requirements?)
 The set of activities that ensure that the software that has been built is traceable to
customer requirements

Organizing for Software Testing

• Testing should aim at "breaking" the software

• Common misconceptions
 The developer of software should do no testing at all
 The software should be given to a secret team of testers who will test it unmercifully
 The testers get involved with the project only when the testing steps are about to begin
• Reality: Independent test group
 Removes the inherent problems associated with letting the builder test the software that
has been built
 Removes the conflict of interest that may otherwise be present
 Works closely with the software developer during analysis and design to ensure that
thorough testing occurs

A Strategy for Testing Conventional Software

108
Levels of Testing for Conventional Software

• Unit testing
 Concentrates on each component/function of the software as implemented in the source
code
• Integration testing
 Focuses on the design and construction of the software architecture
• Validation testing
 Requirements are validated against the constructed software
• System testing
 The software and other system elements are tested as a whole

Testing Strategy applied to Conventional Software

• Unit testing
 Exercises specific paths in a component's control structure to ensure complete coverage
and maximum error detection
 Components are then assembled and integrated
• Integration testing
 Focuses on inputs and outputs, and how well the components fit together and work
together
• Validation testing
 Provides final assurance that the software meets all functional, behavioral, and
performance requirements
• System testing
 Verifies that all system elements (software, hardware, people, databases) mesh properly
and that overall system function and performance is achieved

Testing Strategy applied to Object-Oriented Software

• Must broaden testing to include detections of errors in analysis and design models
• Unit testing loses some of its meaning and integration testing changes significantly
• Use the same philosophy but different approach as in conventional software testing
• Test "in the small" and then work out to testing "in the large"
 Testing in the small involves class attributes and operations; the main focus is on
communication and collaboration within the class
 Testing in the large involves a series of regression tests to uncover errors due to
communication and collaboration among classes
• Finally, the system as a whole is tested to detect errors in fulfilling requirements

When is Testing Complete?

• There is no definitive answer to this question
• Every time a user executes the software, the program is being tested
• Sadly, testing usually stops when a project is running out of time, money, or both
• One approach is to divide the test results into various severity levels
 Then consider testing to be complete when certain levels of errors no longer occur or have
been repaired or eliminated

109
Ensuring a Successful Software Test Strategy

• Specify product requirements in a quantifiable manner long before testing commences

• State testing objectives explicitly in measurable terms
• Understand the user of the software (through use cases) and develop a profile for each user
category
• Develop a testing plan that emphasizes rapid cycle testing to get quick feedback to control quality
levels and adjust the test strategy
• Build robust software that is designed to test itself and can diagnose certain kinds of errors
• Use effective formal technical reviews as a filter prior to testing to reduce the amount of testing
required
• Conduct formal technical reviews to assess the test strategy and test cases themselves
• Develop a continuous improvement approach for the testing process through the gathering of
metrics

Test Strategies for Conventional Software

Unit Testing

• Focuses testing on the function or software module

• Concentrates on the internal processing logic and data structures
• Is simplified when a module is designed with high cohesion
 Reduces the number of test cases
 Allows errors to be more easily predicted and uncovered
• Concentrates on critical modules and those with high cyclomatic complexity when testing
resources are limited

Targets for Unit Test Cases

• Module interface
 Ensure that information flows properly into and out of the module
• Local data structures
 Ensure that data stored temporarily maintains its integrity during all steps in an algorithm
execution
• Boundary conditions
 Ensure that the module operates properly at boundary values established to limit or
restrict processing
• Independent paths (basis paths)
 Paths are exercised to ensure that all statements in a module have been executed at least
once
• Error handling paths
 Ensure that the algorithms respond correctly to specific error conditions

Common Computational Errors in Execution Paths

• Mixed mode operations (e.g., int, float, char)
• Incorrect initialization of values
• Precision inaccuracy and round-off errors
• Incorrect symbolic representation of an expression (int vs. float)

110
Other Errors to Uncover

• Comparison of different data types

• Incorrect logical operators or precedence
• Expectation of equality when precision error makes equality unlikely (using == with float types)
• Incorrect comparison of variables
• Improper or nonexistent loop termination
• Failure to exit when divergent iteration is encountered
• Improperly modified loop variables
• Boundary value violations

Problems to uncover in Error Handling

• Error description is unintelligible or ambiguous

• Error noted does not correspond to error encountered
• Error condition causes operating system intervention prior to error handling
• Exception condition processing is incorrect
• Error description does not provide enough information to assist in the location of the cause of the
error

Drivers and Stubs for Unit Testing

• Driver
 A simple main program that accepts test case data, passes such data to the component
being tested, and prints the returned results
• Stubs
 Serve to replace modules that are subordinate to (called by) the component to be tested
 It uses the module’s exact interface, may do minimal data manipulation, provides
verification of entry, and returns control to the module undergoing testing
• Drivers and stubs both represent overhead
 Both must be written but don’t constitute part of the installed software product

Integration Testing

• Defined as a systematic technique for constructing the software architecture

 At the same time integration is occurring, conduct tests to uncover errors associated with
interfaces
• Objective is to take unit tested modules and build a program structure based on the prescribed
design
• Two Approaches
 Non-incremental Integration Testing
 Incremental Integration Testing

Non-incremental Integration Testing

• Commonly called the “Big Bang” approach

• All components are combined in advance
• The entire program is tested as a whole
• Chaos results
• Many seemingly-unrelated errors are encountered
• Correction is difficult because isolation of causes is complicated

111
 • Once a set of errors are corrected, more errors occur, and testing appears to enter an endless loop

Incremental Integration Testing

• Three kinds
 Top-down integration
 Bottom-up integration
 Sandwich integration
• The program is constructed and tested in small increments
• Errors are easier to isolate and correct
• Interfaces are more likely to be tested completely
• A systematic test approach is applied

Top-down Integration

• Modules are integrated by moving downward through the control hierarchy, beginning with the
main module
• Subordinate modules are incorporated in either a depth-first or breadth-first fashion
 DF: All modules on a major control path are integrated
 BF: All modules directly subordinate at each level are integrated
• Advantages
 This approach verifies major control or decision points early in the test process
• Disadvantages
 Stubs need to be created to substitute for modules that have not been built or tested yet;
this code is later discarded
 Because stubs are used to replace lower level modules, no significant data flow can occur
until much later in the integration/testing process

Bottom-up Integration
• Integration and testing starts with the most atomic modules in the control hierarchy
• Advantages
 This approach verifies low-level data processing early in the testing process
 Need for stubs is eliminated
• Disadvantages
 Driver modules need to be built to test the lower-level modules; this code is later
discarded or expanded into a full-featured version
 Drivers inherently do not contain the complete algorithms that will eventually use the
services of the lower-level modules; consequently, testing may be incomplete or more
testing may be needed later when the upper level modules are available

Sandwich Integration

• Consists of a combination of both top-down and bottom-up integration

• Occurs both at the highest level modules and also at the lowest level modules
• Proceeds using functional groups of modules, with each group completed before the next
 High and low-level modules are grouped based on the control and data processing they
provide for a specific program feature
 Integration within the group progresses in alternating steps between the high and low
level modules of the group

112
  When integration for a certain functional group is complete, integration and testing
moves onto the next group
• Reaps the advantages of both types of integration while minimizing the need for drivers and stubs
• Requires a disciplined approach so that integration doesn’t tend towards the “big bang” scenario

Regression Testing
• Each new addition or change to baselined software may cause problems with functions that
previously worked flawlessly
• Regression testing re-executes a small subset of tests that have already been conducted
 Ensures that changes have not propagated unintended side effects
 Helps to ensure that changes do not introduce unintended behavior or additional errors
 May be done manually or through the use of automated capture/playback tools
• Regression test suite contains three different classes of test cases
 A representative sample of tests that will exercise all software functions
 Additional tests that focus on software functions that are likely to be affected by the
change
 Tests that focus on the actual software components that have been changed

Smoke Testing
• Taken from the world of hardware
 Power is applied and a technician checks for sparks, smoke, or other dramatic signs of
fundamental failure
• Designed as a pacing mechanism for time-critical projects
 Allows the software team to assess its project on a frequent basis
• Includes the following activities
 The software is compiled and linked into a build
 A series of breadth tests is designed to expose errors that will keep the build from
properly performing its function
• The goal is to uncover “show stopper” errors that have the highest likelihood of
throwing the software project behind schedule
 The build is integrated with other builds and the entire product is smoke tested daily
• Daily testing gives managers and practitioners a realistic assessment of the
progress of the integration testing
 After a smoke test is completed, detailed test scripts are executed

Benefits of Smoke Testing

• Integration risk is minimized
 Daily testing uncovers incompatibilities and show-stoppers early in the testing process,
thereby reducing schedule impact
• The quality of the end-product is improved
 Smoke testing is likely to uncover both functional errors and architectural and
component-level design errors
• Error diagnosis and correction are simplified
 Smoke testing will probably uncover errors in the newest components that were
integrated
• Progress is easier to assess
 As integration testing progresses, more software has been integrated and more has been
demonstrated to work
 Managers get a good indication that progress is being made

113
Test Strategies for Object-Oriented Software

• With object-oriented software, you can no longer test a single operation in isolation (conventional
thinking)
• Traditional top-down or bottom-up integration testing has little meaning
• Class testing for object-oriented software is the equivalent of unit testing for conventional
software
 Focuses on operations encapsulated by the class and the state behavior of the class
• Drivers can be used
 To test operations at the lowest level and for testing whole groups of classes
 To replace the user interface so that tests of system functionality can be conducted prior
to implementation of the actual interface
• Stubs can be used
 In situations in which collaboration between classes is required but one or more of the
collaborating classes has not yet been fully implemented

• Two different object-oriented testing strategies

 Thread-based testing
• Integrates the set of classes required to respond to one input or event for the
system
• Each thread is integrated and tested individually
• Regression testing is applied to ensure that no side effects occur
 Use-based testing
• First tests the independent classes that use very few, if any, server classes
• Then the next layer of classes, called dependent classes, are integrated
• This sequence of testing layer of dependent classes continues until the entire
system is constructed

Validation Testing

Background

• Validation testing follows integration testing

• The distinction between conventional and object-oriented software disappears
• Focuses on user-visible actions and user-recognizable output from the system
• Demonstrates conformity with requirements
• Designed to ensure that
 All functional requirements are satisfied
 All behavioral characteristics are achieved
 All performance requirements are attained
 Documentation is correct
 Usability and other requirements are met (e.g., transportability, compatibility, error
recovery, maintainability)
• After each validation test
 The function or performance characteristic conforms to specification and is accepted
 A deviation from specification is uncovered and a deficiency list is created

 A configuration review or audit ensures that all elements of the software configuration have been
properly developed, cataloged, and have the necessary detail for entering the support phase of the
software life cycle

114
Alpha and Beta Testing

• Alpha testing
 Conducted at the developer’s site by end users
 Software is used in a natural setting with developers watching intently
 Testing is conducted in a controlled environment
• Beta testing
 Conducted at end-user sites
 Developer is generally not present
 It serves as a live application of the software in an environment that cannot be controlled
by the developer
 The end-user records all problems that are encountered and reports these to the
developers at regular intervals
 After beta testing is complete, software engineers make software modifications and prepare for
release of the software product to the entire customer base

System Testing

Different Types

• Recovery testing
 Tests for recovery from system faults
 Forces the software to fail in a variety of ways and verifies that recovery is properly
performed
 Tests reinitialization, checkpointing mechanisms, data recovery, and restart for
correctness
• Security testing
 Verifies that protection mechanisms built into a system will, in fact, protect it from
improper access
• Stress testing
 Executes a system in a manner that demands resources in abnormal quantity, frequency,
or volume
• Performance testing
 Tests the run-time performance of software within the context of an integrated system
 Often coupled with stress testing and usually requires both hardware and software
instrumentation
 Can uncover situations that lead to degradation and possible system failure

The Art of Debugging

Debugging Process
• Debugging occurs as a consequence of successful testing
• It is still very much an art rather than a science
• Good debugging ability may be an innate human trait
• Large variances in debugging ability exist
• The debugging process begins with the execution of a test case
• Results are assessed and the difference between expected and actual performance is encountered
• This difference is a symptom of an underlying cause that lies hidden
• The debugging process attempts to match symptom with cause, thereby leading to error
correction

115
Why is Debugging so Difficult?

• The symptom and the cause may be geographically remote

• The symptom may disappear (temporarily) when another error is corrected
• The symptom may actually be caused by non-errors (e.g., round-off accuracies)
• The symptom may be caused by human error that is not easily traced
• problems
• It may be difficult to accurately reproduce input conditions, such as asynchronous real-time
information
• The symptom may be intermittent such as in embedded systems involving both hardware and
software
• The symptom may be due to causes that are distributed across a number of tasks running on
different processes

Debugging Strategies

• Objective of debugging is to find and correct the cause of a software error

• Bugs are found by a combination of systematic evaluation, intuition, and luck
• Debugging methods and tools are not a substitute for careful evaluation based on a complete
design model and clear source code
• There are three main debugging strategies
 Brute force
 Backtracking
 Cause elimination

Strategy #1: Brute Force

• Most commonly used and least efficient method

• Used when all else fails
• Involves the use of memory dumps, run-time traces, and output statements
• Leads many times to wasted effort and time

Strategy #2: Backtracking

• Can be used successfully in small programs

• The method starts at the location where a symptom has been uncovered
• The source code is then traced backward (manually) until the location of the cause is found
• In large programs, the number of potential backward paths may become unmanageably large

Strategy #3: Cause Elimination

• binary partitioning
 Induction (specific to general): Prove that a specific starting value is true; then prove the
general case is true
 Deduction (general to specific): Show that a specific conclusion follows from a set of
general premises
• Data related to the error occurrence are organized to isolate potential causes
• A cause hypothesis is devised, and the aforementioned data are used to prove or disprove the
hypothesis

116
 • Alternatively, a list of all possible causes is developed, and tests are conducted to eliminate each
cause
• If initial tests indicate that a particular cause hypothesis shows promise, data are refined in an
attempt to isolate the bug

Three Questions to ask Before Correcting the Error

• Is the cause of the bug reproduced in another part of the program?

 Similar errors may be occurring in other parts of the program
• What next bug might be introduced by the fix that I’m about to make?
 The source code (and even the design) should be studied to assess the coupling of logic
and data structures related to the fix
• What could we have done to prevent this bug in the first place?
 This is the first step toward software quality assurance
 By correcting the process as well as the product, the bug will be removed from the
current program and may be eliminated from all future programs

Software Testing Techniques

 Testing fundamentals
 White-box testing
 Black-box testing
 Object-oriented testing methods

Characteristics of Testable Software

• Operable
 The better it works (i.e., better quality), the easier it is to test
• Observable
 Incorrect output is easily identified; internal errors are automatically detected
• Controllable
 The states and variables of the software can be controlled directly by the tester
• Decomposable
 The software is built from independent modules that can be tested independently
• Simple
 The program should exhibit functional, structural, and code simplicity
• Stable
 Changes to the software during testing are infrequent and do not invalidate existing tests
• Understandable
 The architectural design is well understood; documentation is available and organized

117
Test Characteristics
• A good test has a high probability of finding an error
 The tester must understand the software and how it might fail
• A good test is not redundant
 Testing time is limited; one test should not serve the same purpose as another test
• A good test should be “best of breed”
 Tests that have the highest likelihood of uncovering a whole class of errors should be
used
• A good test should be neither too simple nor too complex
 Each test should be executed separately; combining a series of tests could cause side
effects and mask certain errors

Two Unit Testing Techniques

• Black-box testing
 Knowing the specified function that a product has been designed to perform, test to see if
that function is fully operational and error free
 Includes tests that are conducted at the software interface
 Not concerned with internal logical structure of the software
• White-box testing
 Knowing the internal workings of a product, test that all internal operations are
performed according to specifications and all internal components have been exercised
 Involves tests that concentrate on close examination of procedural detail
 Logical paths through the software are tested
 Test cases exercise specific sets of conditions and loops

White-box Testing
• Uses the control structure part of component-level design to derive the test cases
• These test cases
 Guarantee that all independent paths within a module have been exercised at least once
 Exercise all logical decisions on their true and false sides
 Execute all loops at their boundaries and within their operational bounds
 Exercise internal data structures to ensure their validity

Basis Path Testing

• White-box testing technique proposed by Tom McCabe

• Enables the test case designer to derive a logical complexity measure of a procedural design
• Uses this measure as a guide for defining a basis set of execution paths
• Test cases derived to exercise the basis set are guaranteed to execute every statement in the
program at least one time during testing

Flow Graph Notation

• A circle in a graph represents a node, which stands for a sequence of one or more procedural
statements
• A node containing a simple conditional expression is referred to as a predicate node
 Each compound condition in a conditional expression containing one or more Boolean
operators (e.g., and, or) is represented by a separate predicate node
 A predicate node has two edges leading out from it (True and False)
• An edge, or a link, is a an arrow representing flow of control in a specific direction

118
  An edge must start and terminate at a node
 An edge does not intersect or cross over another edge
• Areas bounded by a set of edges and nodes are called regions
• When counting regions, include the area outside the graph as a region, too

Flow Graph Example

Black-box Testing
• Complements white-box testing by uncovering different classes of errors
• Focuses on the functional requirements and the information domain of the software
• Used during the later stages of testing after white box testing has been performed
• The tester identifies a set of input conditions that will fully exercise all functional requirements
for a program
• The test cases satisfy the following:
 Reduce, by a count greater than one, the number of additional test cases that must be
designed to achieve reasonable testing
 Tell us something about the presence or absence of classes of errors, rather than an error
associated only with the specific task at hand

Black-box Testing Categories

• Incorrect or missing functions
• Interface errors
• Errors in data structures or external data base access
• Behavior or performance errors
• Initialization and termination errors

119
Questions answered by Black-box Testing

• How is functional validity tested?

• How are system behavior and performance tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundary values of a data class isolated?
• What data rates and data volume can the system tolerate?
• What effect will specific combinations of data have on system operation?

Equivalence Partitioning
• A black-box testing method that divides the input domain of a program into classes of data from
which test cases are derived
• An ideal test case single-handedly uncovers a complete class of errors, thereby reducing the total
number of test cases that must be developed
• Test case design is based on an evaluation of equivalence classes for an input condition
• An equivalence class represents a set of valid or invalid states for input conditions
• From each equivalence class, test cases are selected so that the largest number of attributes of an
equivalence class are exercise at once

Guidelines for Defining Equivalence Classes

• If an input condition specifies a range, one valid and two invalid equivalence classes are defined
 Input range: 1 – 10 Eq classes: {1..10}, {x < 1}, {x > 10}
• If an input condition requires a specific value, one valid and two invalid equivalence classes are
defined
 Input value: 250 Eq classes: {250}, {x < 250}, {x > 250}
• If an input condition specifies a member of a set, one valid and one invalid equivalence class are
defined
 Input set: {-2.5, 7.3, 8.4} Eq classes: {-2.5, 7.3, 8.4}, {any other x}
• If an input condition is a Boolean value, one valid and one invalid class are define
 Input: {true condition} Eq classes: {true condition}, {false condition}

Boundary Value Analysis

• A greater number of errors occur at the boundaries of the input domain rather than in the "center"
• Boundary value analysis is a test case design method that complements equivalence partitioning
 It selects test cases at the edges of a class
 It derives test cases from both the input domain and output domain

Guidelines for Boundary Value Analysis

• 1. If an input condition specifies a range bounded by values a and b, test cases should be
designed with values a and b as well as values just above and just below a and b
• 2. If an input condition specifies a number of values, test case should be developed that exercise
the minimum and maximum numbers. Values just above and just below the minimum and
maximum are also tested
• Apply guidelines 1 and 2 to output conditions; produce output that reflects the minimum and the
maximum values expected; also test the values just below and just above

120
 • If internal program data structures have prescribed boundaries (e.g., an array), design a test case
to exercise the data structure at its minimum and maximum boundaries

Object-Oriented Testing Methods

Introduction

• It is necessary to test an object-oriented system at a variety of different levels

• The goal is to uncover errors that may occur as classes collaborate with one another and
subsystems communicate across architectural layers
 Testing begins "in the small" on methods within a class and on collaboration between
classes
 As class integration occurs, use-based testing and fault-based testing are applied
 Finally, use cases are used to uncover errors during the software validation phase
• Conventional test case design is driven by an input-process-output view of software
• Object-oriented testing focuses on designing appropriate sequences of methods to exercise the
states of a class

Testing Implications for Object-Oriented Software

• Because attributes and methods are encapsulated in a class, testing methods from outside of a
class is generally unproductive
• Testing requires reporting on the state of an object, yet encapsulation can make this information
somewhat difficult to obtain
• Built-in methods should be provided to report the values of class attributes in order to get a
snapshot of the state of an object
• Inheritance requires retesting of each new context of usage for a class
 If a subclass is used in an entirely different context than the super class, the super class
test cases will have little applicability and a new set of tests must be designed

Applicability of Conventional Testing Methods

• White-box testing can be applied to the operations defined in a class
 Basis path testing and loop testing can help ensure that every statement in an method has
been tested
• Black-box testing methods are also appropriate
 Use cases can provide useful input in the design of black-box tests

Fault-based Testing
• The objective in fault-based testing is to design tests that have a high likelihood of uncovering
plausible faults
• Fault-based testing begins with the analysis model
 The tester looks for plausible faults (i.e., aspects of the implementation of the system that
may result in defects)
 To determine whether these faults exist, test cases are designed to exercise the design or
code
• If the analysis and design models can provide insight into what is likely to go wrong, then fault-
based testing can find a significant number of errors
• Integration testing looks for plausible faults in method calls or message connections (i.e.,
client/server exchange)
• Three types of faults are encountered in this context

121
  Unexpected result
 Wrong method or message used
 Incorrect invocation
• The behavior of a method must be examined to determine the occurrence of plausible faults as
methods are invoked
• Testing should exercise the attributes of an object to determine whether proper values occur for
distinct types of object behavior
• The focus of integration testing is to determine whether errors exist in the calling code, not the
called code

Fault-based Testing vs. Scenario-based Testing

• Fault-based testing misses two main types of errors
 Incorrect specification: subsystem doesn't do what the user wants
 Interactions among subsystems: behavior of one subsystem creates circumstances that
cause another subsystem to fail
• A solution to this problem is scenario-based testing
 It concentrates on what the user does, not what the product does
 This means capturing the tasks (via use cases) that the user has to perform, then applying
them as tests
 Scenario-based testing tends to exercise multiple subsystems in a single test

Random Order Testing (at the Class Level)

• Certain methods in a class may constitute a minimum behavioral life history of an object (e.g.,
open, seek, read, close); consequently, they may have implicit order dependencies or expectations
designed into them
• Using the methods for a class, a variety of method sequences are generated randomly and then
executed
The goal is to detect these order dependencies or expectations and make appropriate adjustments to the
design of the methods

Partition Testing (at the Class Level)

• Similar to equivalence partitioning for conventional software
• Methods are grouped based on one of three partitioning approaches
• State-based partitioning categorizes class methods based on their ability to change the state of the
class
 Tests are designed in a way that exercise methods that change state and those that do not
change state
• Attribute-based partitioning categorizes class methods based on the attributes that they use
 Methods are partitioned into those that read an attribute, modify an attribute, or do not
reference the attribute at all
• Category-based partitioning categorizes class methods based on the generic function that each
performs
 Example categories are initialization methods, computational methods, and termination
methods

122
Multiple Class Testing
• testing
• The following sequence of steps can be used to generate multiple class random test cases
1) For each client class, use the list of class methods to generate a series of random test
sequences; use these methods to send messages to server classes
2) For each message that is generated, determine the collaborator class and the
corresponding method in the server object
3) For each method in the server object (invoked by messages from the client object),
determine the messages that it transmits
4) For each of these messages, determine the next level of methods that are invoked and
incorporate these into the test sequence

Tests Derived from Behavior Models

• The state diagram for a class can be used to derive a sequence of tests that will exercise the
dynamic behavior of the class and the classes that collaborate with it
• The test cases should be designed to achieve coverage of all states
 Method sequences should cause the object to transition through all allowable states
• More test cases should be derived to ensure that all behaviors for the class have been exercised
based on the behavior life history of the object
• The state diagram can be traversed in a "breadth-first" approach by exercising only a single
transition at a time
 When a new transition is to be tested, only previously tested transitions are used

123