12. Analysis and Design

Key concepts

1. The design process and software lifecycle
2. Extended example: The Music Collection domain

Introduction

The Lifecycle

Stage	Artifacts Created
Analysis	Requirements
Design	Functional Specification
Implementation	Source code
Testing	Test cases, bug reports, certification
Maintenence	bug reports, feature requests

The first stage involves an analysis of the problem domain, which requires careful thinking and investigation of the problem to be solved. It usually results in a requirements document, which is a description of what problem is being solved. The design phase starts with this document and sketches out a design, a blueprint, for a system that should be able to solve the stated problem. Given a design specification, programmers write source code, during the implementation phase of a project. This source code can then be tested, to help assure that it meets the original specification. Finally, if the program is deemed to behave correctly during the test phase, it is released into the field, at which point maintenence begins. Problems may arise in practice that were not discovered in testing, or perhaps users want small features to be added to the program.

This model of the software lifecycle was originally known as the waterfall model, because information and workflow was seen to move in one direction only -- from analysis through to deployment and maintinence. This unidirectional flow and rigid reliance on sharp boundaries between the various phases has been shown to be unworkable and ineffective in practice, especially with large scale software projects. We'll explore some of the reasons for its failure and improvements to the process in a later lesson. For now, however, it is still worth knowing the basic stages of the software lifecycle because it gives us a language for discussing the software development process.

Introductory programming courses typically focus primarily on the implementation phase of a piece of software. Usually, a specification is provided in the form of a homework assignment ("Write a program that does this and that. It should have the following pieces. Etc.") and the end goal is to produce a program that meets the given specification. This is unfortunate because it makes programming seem like an incredibly boring and uncreative task. Further, it seems to suggest that the programmers responsibilities begin with the specification and end with the testing phase. In reality, good programmers must understand the practices and issues faced by all phases of the lifecycle, even if they don't actively participate in those phases.

An Extended Example

Let's think about compact disks for a moment. What are their properties? Here are a few: total running time, artist, year published, and the songs themselves. Let's go a level deeper. What about songs? Each song has some properties: the music (which is some sort of audio data), the name of the song, the length of the song.

Without knowing it, we've just done an analysis of the music collection domain. If we want to model it we need to define some objects for each of the main concepts. What are the concepts? Finding the right concepts takes experience and practice, but by and large, they fall directly out of our above analysis. Look at the nouns (objects) in the analysis:

Music collection, CD, time, artist name, date, audio data.

Song has a running time.
Song has a name.
Song has an audio data sample.
   
CD has a collection of Songs.
CD has a running time.
CD has a name.
CD has an artist.

MusicCollection has a collection of CDs

The analysis will often hint at both the representation as well as the interface of the classes we want to define. It's usually a good strategy to delay worrying about representation and implementation as long as possible. Sketching the behavior of objects and imagining their interactions is much easier and flexible than actually writing the actual code for them. Good programmers build worlds in their imaginations before building them in a program.

Let's imagine some of the operations that our Song class should support. Again, let's think about what we can do with real world songs.

1. create new songs
2. get their running time
3. get their title
4. play a song (on an audio player of some sort)

public class Song {

  // Create a new song

  // Get the running time of this song

  // Get the title of this song

  // Play this song onto an audio player
}

public class Song {
  private int seconds;
  private Sound sound;
  private String name;

  // Create a new song

  // Get the running time of this song

  // Get the title of this song

  // Play this song onto an audio player
}

public class Song {
  private int seconds;
  private Sound sound;
  private String name;

  // Create a new song
  public Song(String title, String lengthInSeconds, Sound theSound) {
    this.seconds = lengthInSeconds;
    this.sound = theSound;
    this.name = title;
  }

  // Get the running time of this song
  public int getLength() {
    return this.seconds;
  }

  // Get the title of this song
  public String getTitle() {
    return this.name;
  }

  // Play this song onto an audio player
}

class AudioPlayer {
  ...
  // Play the provided sound onto the audio device.
  public void playSound(Sound aSound);
}

public class Song {
  private int seconds;
  private Sound sound;
  private String name;

  // Create a new song
  public Song(String title, String lengthInSeconds, Sound theSound) {
    this.seconds = lengthInSeconds;
    this.sound = theSound;
    this.name = title;
  }

  // Get the running time of this song
  public int getLength() {
    return this.seconds;
  }

  // Get the title of this song
  public String getTitle() {
    return this.name;
  }

  // Play this song onto an audio player
  public void play(AudioPlayer player) {
    player.play(sound);
  }
}