Discovering Classes

I l @ ve RuBoard

A cookbook for finding classes does not exist. As Grady Booch has been known to say, "This is hard!" The Rational Unified Process advocates finding the classes for a system under development by looking for boundary, control, and entity classes. These three stereotypes conform to a "model-view-controller" point of view and allow the analyst to partition the system by separating the view from the domain from the control needed by the system.

Since the analysis and design process is iterative, the list of classes will change as time moves on. The initial set of classes probably will not be the set of classes that eventually gets implemented. Thus, the term candidate class is often used to describe the first set of classes found for a system.

Entity Classes

An entity class models information and associated behavior that is generally long lived. This type of class may reflect a real-world entity or it may be needed to perform tasks internal to the system. They are typically independent of their surroundings; that is, they are not sensitive to how the surroundings communicate with the system. Many times, they are application independent, meaning that they may be used in more than one application.

The first step is to examine the responsibilities documented in the flow of events for the identified use cases (i.e., what the system must do). Entity classes typically are classes that are needed by the system to accomplish some responsibility. The nouns and noun phrases used to describe the responsibility may be a good starting point. The initial list of nouns must be filtered because it could contain nouns that are outside the problem domain, nouns that are just language expressions, nouns that are redundant, and nouns that are descriptions of class structures.

Entity classes typically are found early in the Elaboration Phase. They are often called "domain" classes since they usually deal with abstractions of real-world entities.

Boundary Classes

Boundary classes handle the communication between the system surroundings and the inside of the system. They can provide the interface to a user or another system (i.e., the interface to an actor). They constitute the surroundings-dependent part of the system. Boundary classes are used to model the system interfaces.

Each physical actor/scenario pair is examined to discover boundary classes. The boundary classes chosen in the Elaboration Phase of development are typically at a high level. For example, you may model a window but not model each of its dialogue boxes and buttons . At this point, you are documenting the user interface requirements, not implementing the interface.

User interface requirements tend to be very vaguethe terms user-friendly and flexible seem to be used a lot. But user-friendly means different things to different people. This is where prototyping and storyboarding techniques can be very useful. The customer can get the "look and feel" of the system and truly capture what user-friendly means. The what is then captured as the structure and behavior of the boundary class. During design these classes are refined to take into consideration the chosen user interface mechanismshow they are to be implemented.

Boundary classes are also added to facilitate communication with other systems. During design, these classes are refined to take into consideration the chosen communication protocols.

Control Classes

Control classes model sequencing behavior specific to one or more use cases. Control classes coordinate the events needed to realize the behavior specified in the use case. You can think of a control class as "running" or "executing" the use casethey represent the dynamics of the use case. Control classes typically are application-dependent classes.

In the early stages of the Elaboration Phase, a control class is added for each actor/use case pair. The control class is responsible for the flow of events in the use case.

The use of control classes is very subjective . Many authors feel that the use of control classes results in behavior being separated from data. This can happen if your control classes are not chosen wisely. If a control class is doing more than sequencing, then it is doing too much! For example, in the Course Registration System, a student selects course offerings and if the course offering is available, the student is added to it. Who knows how to add the studentthe control class or the course offering? The right answer is the course offering. The control class knows when the student should be added; the course offering knows how to add the student. A bad control class would not only know when to add the student but how to add the student.

The addition of a control class per actor/use case pair is only an initial cutas analysis and design continues, control classes may be eliminated, split up, or combined.

CREATING STEREOTYPES FOR CLASSES IN RATIONAL ROSE

1. Right-click to select the class in the browser and make the shortcut menu visible.

2. Select the Open Specification menu choice.

3. Select the General tab.

4. Click the arrow in the Stereotype field to make the drop-down menu visible and select the desired stereotype or, to create a new stereotype, enter the name of the stereotype in the Stereotype field.

5. Click the OK button to close the Specification.

The Specification for the Student class is shown in Figure 4-5. If the default language for a model is set to a language other than analysis (Tools: Options menu choice, Notation tab), then a tab for that language will be added to the class specification.

Figure 4-5. Setting a Class Stereotype

I l @ ve RuBoard