You have spent quite a bit of time already designing algorithms so you should have some sense of how to handle the sixth step. Remember to apply all that you have already learned as we proceed into this new territory. In this chapter we will spend a lot of time focusing on steps one through five, as they are fundamental to a successful object-based programming effort. The key to these steps is that they describe what is required of the program without saying anything about how. It is important not to worry about how you are going to accomplish a task until you are sure you know what it is you are trying to accomplish. Even step six which does focus on the 'how' of each function member does so at a high level - the algorithmic level - and there is still little concern with the syntactic details of a specific programming language.

Once the analysis and design of the various classes required for a program are complete, one must still determine how the instances of the various classes, that is, the actual objects, are to be used. As we saw in the last chapter, each program must have a function called 'main'. Object-oriented purists design their programs to have very small 'main' functions and let the objects in the program handle everything. That approach, however, requires that the programmer truly understand and be comfortable with the object-oriented paradigm. For beginners this is a lot to ask and therefore in this text we will allow 'main' and the other functions associated with it to take on more of the load. That means that we will also need to perform an analysis and design of 'main' and the other functions that are not part of any class.

Designing functions that are not part of any class is pretty much what we have been doing all along. Using the tools of chapters two and three, one must determine the variables and functions required to actually use the objects found in the problem and design algorithms for any of those functions that are complex. Since these functions do not belong to a specific class, they are referred to as "non-member functions". All the functions we have worked with so far have been 'non-member' functions. Since we were not using classes and had no idea what 'member' functions were, there was no reason to use the term "non-member function."

Sometimes the challenge in object-oriented analysis and design is in discovering the classes necessary for a program. Sometimes the challenge is in finding appropriate properties of the class(es) (What should an instance of class 'person' include - a name property? an age property? a date of birth property?, the grandfather's name? ....). Sometimes the challenge is in determining the correct set of actions (member functions/methods) the class(es) should be capable of handling. Most often the challenge is in all of these.

Although the five steps of the object oriented analysis and design process are described separately below, they often come together in the actual process of designing a program. And, as with functional decomposition, it is important that you complete the analysis and design before proceeding to the code. In other words, when you first start the analysis and design process, be careful to focus only on what objects are involved and what the program is to do. Don't worry about the how of the programming problem and certainly don't ask yourself if you know how. All that comes later.

It's been said that what distinguishes the program analyst from the program designer is that the analyst focuses on the user's needs while the designer focuses on the what the program must to do to meet those needs. What we learned of analysis in chapter three certainly supports this. We wrote a problem narrative to describe what users expect of can expect of the program being built. We then performed an interface analysis to determine how users will interact with the program and what the outputs will be.

As our programs become more complex and as we move to the object-oriented approach, the analysis phase becomes more complex. Part of the task is now to discover what objects exist in the 'world' being modeled by the program, how those objects can be grouped into classes based on common behaviors and properties, and how the objects interact with each other.

We can use the problem narrative to start this effort. Make sure that your problem narrative is detailed enough and describes all the aspects of the programming problem. Once you have carefully crafted this narrative, examine it, underlining all important nouns and circling all important verbs.

The words you underline in the narrative represent possible classes, objects and properties as well as elements that are not part of any particular class/object. Our task is to decide which of the underlined nouns represent objects (or classes of objects),which nouns represent properties of these objects or classes (the member data), and which nouns represent elements that are not part of any class.

For example, consider a problem narrative that includes the sentences:

"Fred, John, and Mary are 3 of the total of 10 persons involved in the project. Each person has a name and address."

It would be logical, given our common sense understanding of persons, names, and addresses, to say that the word person represents a class , that Fred, John, and Mary are objects (instances of the class 'person'), and that name and address are properties of the same class. It would also be logical to say that 'total' is not part of the class 'person' but it may be an important part or element of the problem.

Not all cases are as easy as this one but you should use your common sense and understanding of the world you are trying to model (write a program for) to help you distinguish between objects, classes and properties of objects.

Note that a class is a general description of an object or set of objects. In the example above, the sentences talk about a number of individuals. We then have a number of objects but each can be represented by the same class, Person. Our goal then is to use the discovery of the objects that exist in a program to discover the classes necessary to represent all the objects involved.

The words circled in the problem narrative represent possible member or non-member functions. To find member functions, look for verbs describing actions required of an object or class. As a general rule, these include actions that ask for, change, or use the values of the properties of a class.