6.1 The Object Discovery Process

In this chapter, we discuss object and class identification and how to infer relationships and associations among them. Chapter 7 deals with the definition and elaboration of object behavior and state. The topics covered in the two chapters form the basis of all object-oriented analysis.

The use case and context diagrams constructed in the previous step provide a starting point for object-oriented analysis per se. The end result will be a structural model of the system that includes the objects and classes identified within the system, their relationships, and generalization hierarchies. This structural model will be complemented by the behavioral model (see Chapter 7) and the entire analysis model will be elaborated in design.

Chapter 1 discussed, among other things, the lifecycles of the ROPES process. Remember that the ROPES process exists simultaneously on three timescales macro (the entire project), micro (the production of a single prototype or system "increment") and nano (the minute-to-minute development steps). The nanocycle is very akin to the Extreme Programming or Agile Methods approach^[1] the idea is to construct aspects of the system with a philosophy of continual testing and validation. Object collaborations are constructed to realize the use cases, but these collaborations themselves are constructed iteratively in very rapid cycles of object identification class specification collaboration validation. This is the essence of the nanocycle shown in Figure 6-1.

^[1] The usage of the nanocycle in the context of larger-scoped timeframes is why I consider XP or AM to be "one third of a good process."

Figure 6-1. ROPES Nanocycle for Domain Analysis

This chapter focuses on the microcycle phase of object domain analysis. The task is to take the requirements (captured in the requirements phase of the microcycle), possibly in the context of the systems architecture (specified in the optional systems engineering phase of the microcycle), and construct the essential or domain model. The domain model identifies the key concepts from the application domain necessary to realize the use case requirements and refine them in various ways. Figure 6-1 shows how the nanocycle proceeds. Object domain analysis is a process of discovery that works as much by free association as by sequential processes, but the key is continual validation. If a use case will ultimately be realized by a collaboration of 50 objects instantiated from a set of 35 classes, what we do not want to do is put down 50 objects or 35 classes and then beat on them until it more or less works.^[2] Instead we want to construct the collaboration in very small pieces, validating each portion of the collaboration before we move on to the next.

^[2] Or, even worse, let the customers beat on it until you fix it.

It has been said that the best way not to have defects in a system is to not put them in the system in the first place. The nanocycle typically proceeds by identifying one or two objects, getting them to work in isolation, refactoring and refining them as necessary through testing and debugging, then moving on and adding the next object or class, validating the expanded collaboration, refactoring and refining as necessary, then adding the next object or two, and so on. In this way, we construct a system from pieces that are known (and demonstrated!) early to be of high quality and with few, if any, defects. By the time the entire collaboration is constructed, it typically works very well. Compare that with the more common approach of drawing a diagram with the 50 objects and then beating on it for days or weeks until it seems to work, only to discover later all the defects that had not been uncovered.