Chapter 10: Software Engineering

Presentation slides for

Java Software Solutions

Foundations of Program Design

Third Edition

by John Lewis and William Loftus

Java Software Solutions is published by Addison-Wesley

Presentation slides are copyright 2002 by John Lewis and William Loftus. All rights reserved.

Instructors using the textbook may use and modify these slides for pedagogical purposes.

Software Engineering

The quality of the software is a direct result of the process we follow to create it

Chapter 10 focuses on:

software development models

the software life cycle and its implications

linear vs. iterative development approaches

goals and techniques of testing

an evolutionary approach to object-oriented development

a nontrivial evolutionary development example

The Software Life Cycle

The overall life cycle of a program includes use and maintenance: (Editor: can you center “Use” in the box?)

A version of the software that is made available to user is called a release

Maintenance

Maintenance tasks include any modifications to an existing program; it includes enhancements and defect removal

The characteristics of a program that make it easy to develop also make it easy to maintain

Maintenance efforts tend to far outweigh the development effort in today’s software

Small increases in effort at the development stage greatly reduce maintenance tasks

The goal is to minimize the overall effort required to create and to maintain the program

Development vs. Maintenance

Development and Maintenance Effort

Development and Maintenance Effort

Often the maintainers of a program are not the program’s original developers

Maintainers must be able to understand a program must be able to understand a program they didn’t design

The ability to read and understand a program depends on

how clearly the requirements are established

how well the program is designed

how well the program is implemented

how well the program is documented

Software Development Models

A software development model is an organized approach to creating quality software

Too many programmers follow a build-and-fix approach

They write a program and modify it until it is functional, without regard to system design

Errors are addressed haphazardly if and as they are discovered

It is not really a development model at all

The Build-and-Fix Approach

The Waterfall Model

The waterfall model was developed in the mid 1970s

Activities that must be specifically addressed during development include:

Establishing clear and unambiguous requirements

Creating a clean design from the requirements

Implementing the design

Testing the implementation

Originally it was proposed as a linear model, without backtracking

It is a nice goal, but it is generally unrealistic

The Waterfall Model

Iterative Development

Iterative development allows the developer to cycle through the different development stages

It is essentially the waterfall model with backtracking

However backtracking should not be used irresponsibly

It should be used as a technique available to the developer to deal with unexpected problems that may arise in later stages of development

(Editor: on the following slide, please make the left-pointing errors narrower than the right-pointing arrows)

An Iterative Development Process

Testing

The results of each stage should be evaluated carefully prior to going on to the next stage

Before moving on to the design, for example, the requirements should be evaluated to ensure completeness, consistency, and clarity

A design evaluation should ensure that each requirement was addressed adequately

Testing Techniques

A design or an implementation may be evaluated during a walkthrough

The goal of a walkthrough is to identify problems, not to solve them

Testing Techniques

Generally, the goal of testing is to find errors

Often it is called defect testing

A good test uncovers problems in a program

A test case includes

a set of inputs

user actions or other initial conditions

expected output

It is not feasible to test every possible case

Black-Box Testing

Black-box testing maps a set of specific inputs to a set of expected outputs

An equivalence category is a collection of input sets

Two input sets belong to the same equivalence category if there is reason to believe that if one works, it will work for the other

Therefore testing one input set essentially tests the entire category

White-Box Testing

White-box testing also is referred to as glass-box testing

It focuses on the internal logic such as the implementation of a method

Statement coverage guarantees that all statements in a method are executed

Condition coverage guarantees that all paths through a method are executed

Prototypes

A prototype is a program created to explore a particular concept

Prototyping is more useful, time-effective, and cost-effective than merely acting on an assumption that later may backfire

Usually a prototype is created to communicate to the client:

a particular task

the feasibility of a requirement

a user interface

It is a way of validating requirements

Throw-away vs. Evolutionary Prototypes

A “quick and dirty” prototype to test an idea or a concept is called a throw-away prototype

Throw-away prototypes should not be incorporated into final systems

Because it is designed more carefully, an evolutionary prototype can be incorporated into the final system

Evolutionary prototypes provide a double benefit, but at a higher cost

Evolutionary Development

Evolutionary development divides the design process into

architectural design - primary classes and interaction

detailed design - specific classes, methods, and algorithms

This allows us to create refinement cycles

Each refinement cycle focuses on one aspect of the system

As each refinement cycle is addressed, the system evolves

An Evolutionary Development Model

Refinement Cycle

First, we establish the refinement scope to define the specific nature of the next refinement

For example:

the user interface

the feasibility of a particular requirement

utility classes for general program support

Object-oriented programming is well suited to this approach

Choosing the most appropriate next refinement is important and requires experience

Refinement Cycle

Next, we identify classes and objects that relate to the current refinement

Look at the nouns in the requirements document

Candidates categories include

physical objects

people

places

containers

occurrences

information stores

Categories may overlap

Consider reusing existing classes

Refinement Cycle

Next we identify relationships among classes

general association (“uses”)

aggregation (“has-a”)

inheritance (“is-a”)

Associated objects use each other for the services they provide

Aggregation, also called composition, permits one object to become part of another object

Cardinality describes the numeric relationship between the objects

For example, a car might have four wheels associated with it

Refinement Cycle

Inheritance, discussed in detail in Chapter 7, may lead to the creation of a new class whose sole purpose is to gather common data and common methods in one place

Relationships can be described using UML class diagrams

Refinement Cycle

Finally, a refinement cycle includes detailed design, implementation, and testing

All the members of each class need to be defined

Each class must be implemented (coded)

Stubs sometimes are created to permit the refinement code to be tested

A unit test focuses on one particular component, such as a method or a class

An integration test focuses on the interaction between components

The PaintBox Project

Now we explore the evolutionary development model using a project larger than any we’ve seen so far

The PaintBox program allows the user to create drawings with various shapes and colors

After establishing the requirements, the following refinement steps are established:

create the basic user interface

allow the user to draw and fill shapes and to change color

allow the user to select, to move, and to modify shapes

allow the user to cut, copy, and paste shapes

allow the user to save and to reload drawings

allow the user to begin a new drawing at any time

The PaintBox Project

(Figure 10.8 here)

The PaintBox Project

Discussions with the client lead to additional requirements which are integrated into the requirements document

Next the architectural design is prepared

Refinement steps are determined

the basic user interface

drawing basic shapes using different stroke colors

cutting, copying, and pasting shapes

selecting, moving, and filling shapes

modifying the dimensions of shapes

saving and reloading drawings

final touches such as the splash screen

The PaintBox Project

The order of refinements is determined

(Figure 10.9 here)

PaintBox Refinement #1

The first refinement establishes the basic user interface

(Figure 10.10 here)

PaintBox Refinement #1

(Editor: please remove the underlining of “(page xxx)”)

See PaintBox.java (page xxx)

See PaintFrame.java (page xxx)

See ButtonBar.java (page xxx)

See DrawingPanel.java (page xxx)

PaintBox.java

PaintFrame.jave

ButtonBar.java

DrawingPanel.java

PaintBox Refinement #2

The second refinement allows the user to draw shapes and change colors

(Figure 10.12 here)

"(Editor:"

(Editor: please remove the underlining of “(page xxx)”)

See PaintBox.java (page xxx)

See PaintFrame.java (page xxx)

See ButtonBar.java (page xxx)

See DrawingPanel.java (page xxx)

See Shape.java (page xxx)

See Line.java (page xxx)

See BoundedShape.java (page xxx)

See Rect.java (page xxx)

See Oval.java (page xxx)

See Poly.java (page xxx)

PaintBox.java

PaintFrame.java

ButtonBar.java

DrawingPanel.java

Shape.java

Line.java

BoundedShape.java

Rect.java

Oval.java

Poly.java

Remaining PaintBox Refinements

The full implementation of the first two refinements can be downloaded

The remaining five refinements are left as programming projects

(Figure 10.14 here)

Summary

Chapter 10 has focused on:

software development models

the software life cycle and its implications

linear vs. iterative development approaches

goals and techniques of testing

an evolutionary approach to object-oriented development

a nontrivial evolutionary development example


	Presentation slides for

	Java Software Solutions
	Foundations of Program Design
	Third Edition

	by John Lewis and William Loftus

	Java Software Solutions is published by Addison-Wesley

	Presentation slides are copyright 2002 by John Lewis and William Loftus. All rights reserved.
	Instructors using the textbook may use and modify these slides for pedagogical purposes.


	The quality of the software is a direct result of the process we follow to create it

	Chapter 10 focuses on:
		software development models
		the software life cycle and its implications
		linear vs. iterative development approaches
		goals and techniques of testing
		an evolutionary approach to object-oriented development
		a nontrivial evolutionary development example


	The overall life cycle of a program includes use and maintenance: (Editor: can you center “Use” in the box?)








	A version of the software that is made available to user is called a release


	Maintenance tasks include any modifications to an existing program; it includes enhancements and defect removal

	The characteristics of a program that make it easy to develop also make it easy to maintain

	Maintenance efforts tend to far outweigh the development effort in today’s software

	Small increases in effort at the development stage greatly reduce maintenance tasks

	The goal is to minimize the overall effort required to create and to maintain the program


	Often the maintainers of a program are not the program’s original developers

	Maintainers must be able to understand a program must be able to understand a program they didn’t design

	The ability to read and understand a program depends on
		how clearly the requirements are established
		how well the program is designed
		how well the program is implemented
		how well the program is documented


	A software development model is an organized approach to creating quality software

	Too many programmers follow a build-and-fix approach

		They write a program and modify it until it is functional, without regard to system design

		Errors are addressed haphazardly if and as they are discovered

		It is not really a development model at all


	The waterfall model was developed in the mid 1970s

	Activities that must be specifically addressed during development include:
		Establishing clear and unambiguous requirements
		Creating a clean design from the requirements
		Implementing the design
		Testing the implementation

	Originally it was proposed as a linear model, without backtracking

	It is a nice goal, but it is generally unrealistic


	Iterative development allows the developer to cycle through the different development stages

	It is essentially the waterfall model with backtracking

	However backtracking should not be used irresponsibly

	It should be used as a technique available to the developer to deal with unexpected problems that may arise in later stages of development
	(Editor: on the following slide, please make the left-pointing errors narrower than the right-pointing arrows)


	The results of each stage should be evaluated carefully prior to going on to the next stage

	Before moving on to the design, for example, the requirements should be evaluated to ensure completeness, consistency, and clarity

	A design evaluation should ensure that each requirement was addressed adequately


	A design or an implementation may be evaluated during a walkthrough

	The goal of a walkthrough is to identify problems, not to solve them


	Generally, the goal of testing is to find errors

	Often it is called defect testing

	A good test uncovers problems in a program

	A test case includes
		a set of inputs
		user actions or other initial conditions
		expected output

	It is not feasible to test every possible case


	Black-box testing maps a set of specific inputs to a set of expected outputs

	An equivalence category is a collection of input sets

	Two input sets belong to the same equivalence category if there is reason to believe that if one works, it will work for the other

	Therefore testing one input set essentially tests the entire category


	White-box testing also is referred to as glass-box testing

	It focuses on the internal logic such as the implementation of a method

	Statement coverage guarantees that all statements in a method are executed

	Condition coverage guarantees that all paths through a method are executed


	A prototype is a program created to explore a particular concept

	Prototyping is more useful, time-effective, and cost-effective than merely acting on an assumption that later may backfire

	Usually a prototype is created to communicate to the client:
		a particular task
		the feasibility of a requirement
		a user interface

	It is a way of validating requirements


	A “quick and dirty” prototype to test an idea or a concept is called a throw-away prototype

	Throw-away prototypes should not be incorporated into final systems

	Because it is designed more carefully, an evolutionary prototype can be incorporated into the final system

	Evolutionary prototypes provide a double benefit, but at a higher cost


	Evolutionary development divides the design process into
		architectural design - primary classes and interaction
		detailed design - specific classes, methods, and algorithms

	This allows us to create refinement cycles

	Each refinement cycle focuses on one aspect of the system

	As each refinement cycle is addressed, the system evolves


	First, we establish the refinement scope to define the specific nature of the next refinement

	For example:
		the user interface
		the feasibility of a particular requirement
		utility classes for general program support

	Object-oriented programming is well suited to this approach

	Choosing the most appropriate next refinement is important and requires experience


	Next, we identify classes and objects that relate to the current refinement

	Look at the nouns in the requirements document

	Candidates categories include
		physical objects
		people
		places
		containers
		occurrences
		information stores

	Categories may overlap


	Consider reusing existing classes


	Next we identify relationships among classes
		general association (“uses”)
		aggregation (“has-a”)
		inheritance (“is-a”)

	Associated objects use each other for the services they provide

	Aggregation, also called composition, permits one object to become part of another object
		Cardinality describes the numeric relationship between the objects
		For example, a car might have four wheels associated with it


	Inheritance, discussed in detail in Chapter 7, may lead to the creation of a new class whose sole purpose is to gather common data and common methods in one place

	Relationships can be described using UML class diagrams


	Finally, a refinement cycle includes detailed design, implementation, and testing
		All the members of each class need to be defined
		Each class must be implemented (coded)
		Stubs sometimes are created to permit the refinement code to be tested

	A unit test focuses on one particular component, such as a method or a class

	An integration test focuses on the interaction between components


	Now we explore the evolutionary development model using a project larger than any we’ve seen so far

	The PaintBox program allows the user to create drawings with various shapes and colors

	After establishing the requirements, the following refinement steps are established:
		create the basic user interface
		allow the user to draw and fill shapes and to change color
		allow the user to select, to move, and to modify shapes
		allow the user to cut, copy, and paste shapes
		allow the user to save and to reload drawings
		allow the user to begin a new drawing at any time


	Discussions with the client lead to additional requirements which are integrated into the requirements document

	Next the architectural design is prepared

	Refinement steps are determined
		the basic user interface
		drawing basic shapes using different stroke colors
		cutting, copying, and pasting shapes
		selecting, moving, and filling shapes
		modifying the dimensions of shapes
		saving and reloading drawings
		final touches such as the splash screen


	The first refinement establishes the basic user interface

	(Figure 10.10 here)


	(Editor: please remove the underlining of “(page xxx)”)
	See PaintBox.java (page xxx)
	See PaintFrame.java (page xxx)
	See ButtonBar.java (page xxx)
	See DrawingPanel.java (page xxx)


	The second refinement allows the user to draw shapes and change colors

	(Figure 10.12 here)


	The full implementation of the first two refinements can be downloaded

	The remaining five refinements are left as programming projects

	(Figure 10.14 here)


	Chapter 10 has focused on:
		software development models
		the software life cycle and its implications
		linear vs. iterative development approaches
		goals and techniques of testing
		an evolutionary approach to object-oriented development
		a nontrivial evolutionary development example