Software Development Process

page last updated 1/16/07

Features of software

Complexity

size
interconnectedness

Fragility

relatively minor bugs can cause the entire software product to be useless
testing is hard -- we cannot guarantee that the software is error free
not all factors may be taken into account

Malleability

how easy is it to change the software
end users are notorious in wanting changes

Object-Oriented Programming

Classes -- define the structure of a set of objects

instance variables
what are the methods shared by the objects
class variables

Objects

instance of a class
messages--calls to the methods (actions ->behavior)
state--contents of instance variables
attributes

Polymorphism -- different classes can respond to the same message

Encapsulation

Information Hiding

Server -- receiver of the message

Client -- sender of the message

Inheritance

superclass
subclass

Extended UML class diagram showing Date objects

Date myDate = new Date (6, 24, 1951);
Date yourDate = new date (10, 11, 1953);
Date ourDate = new Date (6, 15, 1985);

Applications

An object-oriented application is a set of objects working together, by sending each other messages, to solve a problem.

In object-oriented programming a key step is identifying classes that can be used to help solve a problem.

An example – using our Date class to solve the problem of calculating the number of days between two dates

DaysBetween Design

display instructions
prompt for and read in info about the first date
create the date1 object
prompt for and read in info about the second date
create the date2 object
if dates entered are too early
   print an error message
else 
   use the date.lilian method to obtain the  Lilian Day Numbers
   compute and print the number of days between the dates

The complete code: DaysBetween.Java

Organizing Classes

During object-oriented development hundreds of classes can be generated or reused to help build a system.

The task of keeping track of these classes would be impossible without organizational structure.

Two of the most important ways of organizing Java classes are

inheritance: classes are organized in an “is-a” hierarchy
package: lets us group related classes together into a single named unit

Inheritance

Allows programmers to create a new class that is a specialization or an enhancement of an existing class.

The new class is called a subclass of the existing class; the existing class is the superclass of the new class.

Code to Create IncDate in Java

public class IncDate extends Date
{
    public IncDate (int newMonth, int newDay, int newYear){
        super(newMonth, newDay, newYear);
    }

   public void increment () 
     // Increments this IncDate to represent the next day.
     // For example if this = 6/30/2005 then this becomes 7/1/2005.
   {
      // increment to next day with month and  year rollover goes here
   }
}

Program Segment Using Date and IncDate

Date myDate = new Date (6,  24, 1951);
IncDate aDate = new incDate(1,31,2002);
System.out.println("myDate day is "myDate.day(); --> myDate day is 24
System.out.println("aDate day is: "+ aDate.day(); --> aDate day is 31
aDate.increment();
System.out.println("aDate day is: "+aDate.day() --> aDate day is 1

Extended UML Class Diagram Showing Inheritance

Inheritance UML

Object-Oriented Design

Identify classes
Organize classes in an inheritance hierarchy
Find prewritten classes

Identifying Classes

Start brainstorming ideas.
Identify objects in the problem.
Objects are usually nouns and operations are usually verbs.
Filter the classes.
Consider some scenarios in which the objects interact to accomplish a task.
CRC cards help us enact such scenarios.

Summary: Approaches to Identifying Classes

Start with the major classes and refine the design.
Hide important design decisions and requirements likely to change within a class.
Brainstorm with a group of programmers.
Make sure each class has one main responsibility.
Use CRC cards to organize classes and identify holes in the design.
Walk through user scenarios.
Look for nouns and verbs in the problem description.

Types of Errors

Specification
Design
Coding
Input

Controlling Errors

Robustness The ability of a program to recover following an error; the ability of a program to continue to operate within its environment

Preconditions Assumptions that must be true on entry into an operation or method for the postconditions to be guaranteed.

Postconditions Statements that describe what results are to be expected at the exit of an operation or method, assuming that the preconditions are true.

Pre- and Post- Conditions

Pre- and post-conditions are contracts between the designer and user of a module.

These assertions should be applied both at the class level and each method.

Precondition - What has to be true regarding the input parameters. The user must ensure that the preconditions hold. If not, the implementer is not bound to produce correct output.

Postcondition - If the preconditions were true then the user of the module can be sure the postconditions hold. This is what the implementer promises to do.

Usually these are stated in the opening comments of each module (class or method)

Ideally the preconditions should be enforced with code at the beginning.

Design Review Activities

Desk checking Tracing an execution of a design or program on paper

Walk-through A verification method in which a team performs a manual simulation of the program or design

Inspection A verification method in which one member of a team reads the program or design line by line and others point out errors

Testing

Testing during analysis and design is typically done by a structured walk-through.

Unit testing - test each class in isolation
Integration testing - add each class to the system and test their integration and its affect within
Acceptance testing - demonstrate the system to the client (users) for acceptance
Haphazard testing - random input without any methodology
Black-box testing - choose data to test clusters of data. You know what the class does but not necessarily how it's implemented
White-box testing - you know how the module was implement, so choose data that will exercise all sequences of code
Regression testing - a set of test data in which you know the results; upon any change to the software, run the regression data and compare the results to previous run to ensure nothing else was "broken"

For Each Test Case

Determine inputs.
Determine the expected behavior of the program.
Run the program and observe the resulting behavior.
Compare the expected behavior and the actual behavior.

Test Plans

Document showing the test cases planned for a program or module, their purposes, inputs, expected outputs, and criteria for success
For program testing to be effective, it must be planned.
Start planning for testing before writing a single line of code.

Pursuing Correctness

These suggestions are typical of industry standards for both C++ and Java or most OOP languages.

Capitalize methodically
- variable - capitalize the first letter of each word of the variable name except the first "nameOfVariable"
- functions - capitalize the first letter of each word including the first "NameOfFunction"
- constants - capitalize all letters and use underscores "MAXIMUM_STUDENTS"

Grammatical parallelisms to identifiers
- value returning functions - use nouns or noun phrases "SizeOfList"
- boolean functions - use adjectives "Odd" or "IsOdd"
- void functions - use imperative verbs "Process"

Comments should contribute to the understanding, not be there for comments sake

One statement, one declaration per line

Indent consistently (4 spaces per level -- configure your editor)

Keep segments/functions short (don't exceed 50 lines, one printed page)