Lecture 2: Models of Software Development

How do people develop software? Don't ask. A recently published book says that making software reminds him of what Bismarck (some old German politician) said about sausages: You want to eat them but you don't want to know how they are made.

How do people think other people should develop software? For a long time, people developed software in an ad hoc manner. Eventually they realized that finding and eliminating errors late in the game is extremely expensive (see Barry Boehm's influential article) and that they should create a systematic process.

The waterfall model

What they came up with is the waterfall model of software development. According to this model, software companies

determine the needs and requirements for the software
translate the requirements into specifications
code implementations for the specifications
test the code: find mistakes
debug: eliminate the mistakes
deploy: insert the software into the context where it is supposed to work, which implies installing hardware and software, testing in context, training users, assisting users (help desk), etc.
maintain the code: port to new hardware, to new operating systems, fix errors, add functionality, and more

In its pure form, the process is linear. One stage concludes, the other one starts, though coders may move into the debugging stage and requirements engineer may be involved in the deployment process.

People have tried to develop according to this model, but they now understand that this model doesn't work. Can you imagine why?

To this day, large companies stick to some variant of this process. In detail, however, the process is much more feedback oriented and is close to the scientific process of discovering the proper (in the sense of predictive) scientific model of the world.

The iterative refinement model

This iterative process works roughly like that:

write up the story of the software
find the use cases end to end interactions between the desired system and users and other contexts
pick a central/important use case and implement it to the point where it is useful
deploy and observe consumers/clients' reactions
go back to the first or second step; check whether the preliminary product affects your customer's story; or find the next use cases to extend the product

For a company, the customer is the paying entity or a representative example of some segment of the mass market consumer. For you, the customer is your boss and in reality the person to whom your boss delivers the software in a working context.

Where do all the requirement engineering, specification writing, etc. go?

It is still there, but it is a part of a cycle. Specifically:

"writing up the story of software" means writing up what the customer tells you so that the customer understands what you wrote and you can use your story to guide your efforts -- this is informal communication about requirements and specifications;

"extracting/writing use cases" from the stories means to break up your story into small doable tasks, which are specifications of what you want, not how you want them solved with a program;

"implementing" in (2) means that not just writing some code and hoping for the best; it means

to lay out the concepts of the story and the use case
to formulate the kind of data this involves
to illustrate the desired use case with behavioral examples
to turn the examples into tests (code)
to design and write code that passes all these tests

One big difference between "waterfall" and "iterative refinement" is that you get to code much sooner and that you have a much closer interaction with your customer.

Please compare this with the design recipe process advocated in How to Design Programs.

One recent evolution of iterative refinement is extreme programming, a sellable buzzword-compliant version of the idea. While "iterative refinement" has evolved in the prototype-oriented academic community -- think Scheme and Prolog and similar languages -- the extreme programming community evolved in the academic fringe of industry, again fostered in an interactive language community (Smalltalk, now known as Squeak).

In this course, I want to practice iterative refinement with you and some people-based techniques that make it feasible. Let's start with reading stories and teasing out the essential elements.

From Stories to Concepts

Consider this story:

A Homework Submission Server
A professor would like to have a homework submission server for his courses. He expects to assign weekly projects to his classes during a semester. For each project, he would like his students to upload a text file as th solution. Indeed, since students can make mistakes, they should be able to upload solution files up to the time of the deadline, but not afterwards.

To provide some basic protection against malicious users and abuse, the professor expects that each submitter has an account on the submission server. His TA will enter the names and student id numbers of all enrolled students and will send the students an initial password for accessing their submission account. Naturaly the students are expected to change their password early and often.

The professor would like to specify the titles and deadlines for each project himself. He is willing to enter this information into some text file; naturally your professor can't program.

Let's identify the concepts that show up. To do so, look out for actors and information:

TA (= professor), course
homework assignment, deadline, homework solution
student, name, id
account, password
storage on computer

The students, the TA, and the storage are actors; the remaining concepts are pieces of information.

Draw lines between the concepts that are related. Here is an excerpt for the above concepts:

          +--------------------+
          | TEACHING ASSISTANT |
          +--------------------+
                   |
          +------------+         +----------+
          | assignment | ------- | deadline |
          +------------+         +----------+
              |          \-----\     |
           +----------+        +---------+
           | solution | ------ | STORAGE |
           +----------+        +---------+

It does show two actors and three pieces of information. It omits such things as students, student accounts, etc.

To check your thinking, consider adding numeric quantities on each end of a link that show how a pair of concepts relates to each other:

            +--------------------+
            | TEACHING ASSISTANT |
            +--------------------+
                     |1
                     |
                     |n
            +------------+ 1     1 +----------+
            | assignment | ------- | deadline |
            +------------+         +----------+
                | 1        \n        | n
                |           \        |
                |            \       |
                | n           \1     | 1
             +----------+ n    1 +---------+
             | solution | ------ | STORAGE |
             +----------+        +---------+

Here we see that one TA controls many assignments, but each assignment comes with a unique deadline.

Identify the system and the outside. This may actually identify several systems and several "outsides":

            +--------------------+
            | TEACHING ASSISTANT |
            +--------------------+
                     |1
                 ====|===================================
                     |n
            +------------+ 1     1 +----------+
            | assignment | ------- | deadline |
            +------------+         +----------+
                | 1        \n        | n
                |           ============================ 
                |          # \       |
                | n        #   \1     | 1
             +----------+ n#   1 +---------+
             | solution | -#---- | STORAGE |
             +----------+  #     +---------+

The redrawn picture identifies the two actors as being outside the system and the information as being a part of the system. This doesn't have to be the case as the next example shows.

The Monopoly Game
The Hasbro Company would like to create an on-line version of Monopoly. The idea is that players can sign up for a game and play a game against others over the Web. When enough players have signed up for a game, they play for a set amount of time with equal time slices per player. At the end the company's game program totals up the score and identifies the winner. Every game also comes with one automated player from the company.

Some of the concepts of this "story" are:

player, token
gameboard, properties, houses and hotels, chance cards, dice
money, banker

Identify the remaining concepts, draw a concept graph, and draw a line around the system to identify the interface between it and the world.

Stories Change, Promised!

When the story changes, you can identify the changes in concepts, their relationships, and even the system boundaries.

Postscript: A Homework Submission Server
Your professor has recently discovered pair programming so he introduces it in some of his courses. Specifically, he would like to enforce pair programming by not allowing individuals to submit projects at all. Instead, each submitter account must relate to at least two individual students who can only jointly submit a project file. The professor can count, and he will therefore allow students to submit work in triples.

Naturally this leads to new concepts and new and modified relationships:

     +---------+ 2,3     1 +---------+ 1    n +----------+
     | STUDENT | --------- | account | ------ | solution |
     +---------+           +---------+        +----------+
       | 1
       |
       | 1
     +----------+
     | password |
     +----------+

Here we see that 2 or 3 students relate to an account now, yet each student still has one password. Furthermore, students are no longer directly related to homework solutions; instead, the account has become an important intermediary.

From Concepts to Use Cases

Drawing the system boundary identifies events and triggers that cause the pieces of the world to interact. Imagine those interactions and write them down. Turn the big story into little stories. Describe what happens not how.

The descriptions of use cases are like the descriptions of dialogs in novels. You identify a dialog by an entry point into the system and an exit point.

Example:

the TA sets a deadline for a homework:

TA logs on

TA chooses a course

TA specifies new assignment and its deadline

system checks that the title is new and the deadline in the future

system stores the assignment/deadline pair

a title for the use case

the TA is on the outside
we need TA accounts (new concept!)

the system is on the outside again

Note working our way through potential interactions identifies new concepts. We had overlooked that we needed to give the TA a special form of access to the homework submission server because not everyone should be able to add homework assignments and set deadlines. Even if in the end we re-use accounts and privileges from the underlying system, we now know that we need some form of separation.

Practice writing use cases with both examples. Can you identify concepts in the monopoly game that are not needed in a game that only people play?

Bibliography

Beck. Extreme Programming Explained. Addison-Wesley, 2000.

Fowler, Scott. UML Distilled. Addison-Wesley, 1997.

Larman, Applying UML and Patterns. Prentice Hall, 1998.