Creating Class Diagrams

---

Pausing to Consider Design Issues

Now that the use cases for both the user and programmer perspectives are complete it would be nice if the modeling tool could interpret them and, on its own, offer one or more suitable architectures for you to consider. This is not likely to happen anytime soon so here we experience head-on the limitations of modeling tools. They help, they assist, they enable, but they do not do the design for you. How then to best proceed with the robot rat application design?

Here is where you do lots of thinking, thinking, and more thinking. In fact, if you observed most software engineers in the process of designing a system you would easily convince yourself they are doing nothing but just sitting in their offices daydreaming. Not true. A lot of the design process involves pure brain power, augmented by pencil and paper.

Taking our pencil and paper we could do an analysis of the robot rat project and identify key components that are in need of designing. Table 20-1 lists the results of a first attempt.

Table 20-1: Robot Rat Project Design Considerations

Design Artifact	Consideration
User Interface Class	The user interface class will handle all user input and output using iostreams. The user interface class will also be responsible for printing the floor pattern. **If the user interface prints the floor then it probably contains and manages the floor array, since the floor array for an iostream representation may be different than a GUI floor representation.
Robot Rat Manager Class	The robot rat manager class will keep track of and control all robot rat objects. Any command the user wants to execute from the user interface will be sent to the robot rat manager class. **The robot rat manager class must be able to add more rats to the floor. **Should it also be able to delete robot rat objects? **How will it manage multiple robot rat objects? With an array?
Controller Class	The controller class will handle all message passing between the user interface class and the robot rat manager class.
Remote Controlled Objects	A remote controlled object is any object that will ultimately be controlled by the user in its movement around an imaginary floor. Remote controlled objects must have some knowledge of the notion of their position upon the floor and the direction they are facing. Remote controlled objects will also be able to mark their position on the floor in some way. **Do remote controlled objects mark the floor directly or is the floor marked based on the position of a remote controlled object's marker? **Do remote controlled objects consist of a position and a marker? **Does a remote controlled object have knowledge of a floor? Or, rather, just knowledge of some notion of a boundary?
Robot Rat	A robot rat is an instance of a remote controlled object. A robot rat has a tail that can be set up or down.
Floor	The imaginary surface the remote controlled objects move upon. The 'floor' the user sees, with pattern marking created by robot rats, may be represented by a two-dimensional array. **Where does the floor reside? In the user interface? In the robot rat manager class?
Position	A remote controlled object has a position upon the floor. The position consists of the current row, current column, and heading or direction (NORTH, SOUTH, EAST, or WEST).
Marker	A remote controlled object has a marker. The marker can be set to either the UP or DOWN position.

Table 20-1 provides enough information to begin a more detailed design, but one more use case diagram may prove helpful. I like to model application artifacts in a use case diagram. This use of a use case diagram may be considered by some as unorthodox, but I find any picture that helps you to better understand your design is worth the time it takes to draw.

Figure 20-11 shows a use case diagram with multiple actors. In this diagram each actor represents a potential design artifact and its associated attributes. The actors are arranged in an inheritance hierarchy complete with generalization arrows.

Figure 20-11: Partial Application Architecture Use Case Diagram

As figure 20-11 illustrates, a RemoteControlledObject is a software entity that has a marker and a position attribute. The position attribute is further decomposed into direction, row, and column attributes.

The inheritance hierarchy shown in figure 20-11 is one of several possible alternatives. An AbstractControlledObject entity sits at the root of the hierarchy. It may very well be implemented as an abstract base class containing pure virtual functions existing only to publish an interface to the RemoteControlledObject class and further subclasses. The AbstractControlledRodent entity inherits its functionality from the RemoteControlledObject entity. The RobotRat entity then inherits from AbstractControlledRodent. This will enable the addition of different types of remote controlled objects. For instance, if you needed to add a different type of AbstractControlledRodent, such as a mouse, the you would simply extend the AbstractControlledRodent entity and name the new class RobotMouse. A RobotMouse may very well have different behavior than a RobotRat.

Entirely different types of remote controlled objects besides rodents could be added as well. For example, an AbstractControlledPerson entity could inherit from RemoteControlledObject. This would facilitate the addition of a RobotMan or RobotWoman entity.

The inheritance hierarchy depicted in figure 20-11 seems to support the addition of new types of remote controlled objects as required by the robot rat project specification. This looks like a good place to begin a more detailed model design.

---