Dealing with Changing Requirements

To figure out a way around the problem of changing requirements and to see if there is an alternative to functional decomposition, let's look at how people do things. Let's say that you were an instructor at a conference. People in your class had another class to attend following yours, but didn't know where it was located. One of your responsibilities is to make sure everyone knows how to get to their next class.

If you were to follow a structured programming approach, you might do the following:

1.	Get list of people in the class.
2.	For each person on this list: a. Find the next class they are taking. b. Find the location of that class. c. Find the way to get from your classroom to the person's next class. d. Tell the person how to get to their next class.

To do this would require the following procedures:

1.	A way of getting the list of people in the class
2.	A way of getting the schedule for each person in the class
3.	A program that gives someone directions from your classroom to any other classroom
4.	A control program that works for each person in the class and does the required steps for each person

I doubt that you would actually follow this approach. Instead, you would probably post directions to go from this classroom to the other classrooms and then tell everyone in the class, “I have posted the locations of the classes following this in the back of the room, as well as the locations of the other classrooms. Please use them to go to your next classroom.” You would expect that everyone would know what their next class was, that they could find the classroom they were to go to from the list, and could then follow the directions for going to the classrooms themselves.

What is the difference between these approaches?

• In the first one—giving explicit directions to everyone—you have to pay close attention to a lot of details. No one other than you is responsible for anything. You will go crazy!

• In the second case, you give general instructions and then expect that each person will figure out how to do the task himself or herself.

The biggest difference is this shift of responsibility. In the first case, you are responsible for everything; in the second case, students are responsible for their own behavior. In both cases, the same things must be implemented, but the organization is very different.

What is the impact of this?

To see the effect of this reorganization of responsibilities, let's see what happens when some new requirements are specified.

Suppose I am now told to give special instructions to graduate students who are assisting at the conference. Perhaps they need to collect course evaluations and take them to the conference office before they can go to the next class. In the first case, I would have to modify the control program to distinguish the graduate students from the undergraduates, and then give special instructions to the graduate students. It's possible that I would have to modify this program considerably.

However, in the second case—where people are responsible for themselves—I would just have to write an additional routine for graduate students to follow. The control program would still just say, “Go to your next class.” Each person would simply follow the instructions appropriate for himself or herself.

This is a significant difference for the control program. In one case, it would have to be modified every time there was a new category of students with special instructions that they might be expected to follow. In the other one, new categories of students have to be responsible for themselves.

There are three different things going on that make this happen. They are:

• The people are responsible for themselves, instead of the control program being responsible for them. (Note that to accomplish this, a person must also be aware of what type of student he or she is.)

• The control program can talk to different types of people (graduate students and regular students) as if they were exactly the same.

• The control program does not need to know about any special steps that students might need to take when moving from class to class.

To fully understand the implications of this, it's important to establish some terminology. In UML Distilled, Martin Fowler describes three different perspectives in the software development process.^[3] These are described in Table 1-1.

^[3] Fowler, M., Scott, K., UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd Edition, Reading, Mass.: Addison-Wesley, 1999, pp. 51–52.

Table 1-1. Perspectives in the Software Development Process

Perspective	Description
Conceptual	This perspective “represents the concepts in the domain under study… . a conceptual model should be drawn with little or no regard for the software that might implement it …”
Specification	“Now we are looking at software, but we are looking at the interfaces of the software, not the implementation.”
Implementation	At this point we are at the code itself. “This is probably the most often-used perspective, but in many ways the specification perspective is often a better one to take.”

Look again at the previous example of “Go to your next class.” Notice that you—as the instructor—are communicating with the people at the conceptual level. In other words, you are telling people what you want, not how to do it. However, the way they go to their next class is very specific. They are following specific instructions and in doing so are working at the implementation level.

Communicating at one level (conceptually) while performing at another level (implementation) results in the requestor (the instructor) not knowing exactly what is happening, only knowing conceptually what is happening. This can be very powerful. Let's see how to take these notions and write programs that take advantage of them.