CSC 241- Lec 1 (July 1st 1996)

1. Software life cycle

a. Analysis/Specification -

1. define the problem (i.e. what are we building, if anything!)
2. set budget
3. set milestones
4. Choose hardware/software
5. Build a prototype

b. Design - How do we build the specified system?

Object Oriented design requires identification of objects, their relationships and communications. Use of nouns and verbs found in specifications in determining objects, their state and methods is one of the techniques employed in this process. It is critical to design clean and coherent classes of objects that encapsulate a state and a set of methods that operate on that state. Hiding the details from the other components of a system is critical here. Objects must act as black boxes wherever we use them. A class must be highly cohesive, all of its pieces, be it, the elements that constitute the state of its objects, or its methods must fit together perfectly--they must make sense. Classes must be loosely coupled, the communication between objects must be clear and minimal.

Probably, the single most important difference between the traditional top-down approach to design and object oriented design is in the level of software reuse. A good Object designer looks for existing classes of objects. He/she employs inheritance to extend classes to make them meet his/her needs. The designer is keen on writing polymorphic functions that operate on supper classes. To see some examples of nicely defined classes, check out: Java Package Documentation

c. Validation/Verification of the design -

• ensure that the solution fits the problem--you have built the right thing! This is validation.
• ensure that design is correct and has no inconsistencies, all pieces must fit together. This is verification.

d. Coding -

e. Code verification -

Testing of all parts with drivers and stubs must occur as the classes are being developed. But, integrating the various components and testing their interaction is critical here. The sensitive components of a system may need to go through a rigorous mathematical proof to ensure their correctness.

f. Submit to production -

let users use it. They may have already played with a prototype, but this is for real. Todays industry seems to advocate alpha and beta releases. Although there are some advantages to this, broad-based releases of incomplete with most likely incorrect components does not make sense to me! But, its the way things are today.

g. Maintenance -

make corrections, make additions, and may be even redesign some parts.

2. Writing Pre/Post conditions

I don't except you to develop mathematically complete pre and post conditions for your methods. It is, however, important to learn about pre/post conditions. A pre condition is a clear statement of a method's assumptions at the start. A post condition is a clear statement and promise about what a method will do by the time it reaches its end. Here is an example:

Suppose that we have a container class that keeps a list of integer values (l). We want a method that sorts l, either in ascending or descending order. So, the method has an integer parameter that is suppose to be either 1 or 0. If its 1, we sort in ascending order, otherwise, we sort the values in descending order. Assume that last_cell is the index for the last value in the list. Here is a reasonable pre/post condition:

          void sort (int a_or_d)
		  /** Precondition: 
                  (a_or_d == 0) ||  (a_or_d == 1)

		      Postcondition: 
                  ((a_or_d == 1) && (l[0] <= l[1] <= ... <= l[last_cell])) ||
                  ((a_or_d == 0) && (l[0] >= l[1] >= ... >= l[last_cell]))
          **/

3. Tank example.

We began to look at the Tank example. Copy the .java files from ~mohammad/public-html/classes/Tank and ~mohammad/public-html/classes/Tank/testTank or find the Tank example here