Notes

Outline

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