Identifying Classes
Role of the UML Class Diagram
The class diagram will eventually become the most important UML artifact we produce. By eventually, I mean that initially it will be somewhat sparse and lacking in anything of significant value. With each iteration, however, as we learn more about the static and dynamic features of the application, it will begin to evolve into the pivotal diagram from which all else going forward is derived. Even the UML component and deployment diagrams depict how classes will be packaged and ultimately delivered in runtime form.
Chapter 2 noted that the majority of visual modeling tools today generate their code structures directly from the class diagram. Tools that support reverse engineering derive their diagrammatic elements from the classes built by the specific language environment (e.g., header files in C++, .java files in Java, class modules in Visual Basic).
What Makes a Good Class?
Selecting classes requires skill; it can be difficult and tricky at times. The next several sections provide guidelines to help you learn how. With a little practice, you will see that there is a methodology to the madness of selecting classes.
The class is the key entity in the application domain. It represents an interesting abstraction of something that contains structure (attributes), as well as behavior (operations). Often a project team, depending on the level of its familiarity with an application domain, initially comes up with the classes just by using facilitated sessions to produce a list of entities.
Another, more methodical approach that has its roots in the relational modeling world is to review the source of the requirements produced thus far and simply extract the nouns. In the context of UML, the source for this noun extraction exercise consists of the completed use-cases. In a very quick and unstructured manner, you simply scan the use-cases and pull out all of the nouns. As you improve at the exercise, you should begin to apply some noun filtering to eliminate nouns that obviously will not make good classes. The most common nouns filtered out are those that represent domain attributes, which are characteristics of another class in the application. I find it is beneficial to put this initial list on Post-it notes. Then as you weed them out, those that become attributes of a class can be appended to the back of the owning Post-it note.
With Remulak Productions, for instance, detailed description of the use-cases produced the noun credit card number. Although this is undoubtedly a noun, ask yourself if it is something that will have both structure and behavior. Probably not. It is an attribute of another class (e.g., Order, Customer, or both) that might not have been identified yet. My rule of thumb, however, is not to filter out anything on the first iteration of the exercise. I just create a list.
A third mechanism for identifying classes is to hold a CRC session, where CRC stands for Classes, Responsibilities, Collaborations. CRC is a role-playing exercise used to identify classes and their individual roles in an application's life. See, for example, The CRC Card Book by Bellin and Simone (published by Addison-Wesley, 1997). On occasion, I use CRC sessions as an icebreaker for people new to object-oriented techniques. However, my only concern with CRC sessions is that they require a strong facilitator and the team must be agreeable to role-playing. For very complex interactions, CRC sessions can get really out of hand. In general, people seem to find CRC sessions just a bit too touchy-feely.
Applying Filter Rules
Once we have completed the initial list of nouns, we apply simple filtering rules to whittle it down. Seven different filters can be applied to the domain of nouns. We remove candidate classes that have any of the following characteristics:
Irrelevance: Nouns that have nothing to do with the problem domain are irrelevant. They might be valid classes, but not within the scope of the current project. For example, employee performance rating is a noun, but Remulak's system will not measure or track performance, so it is irrelevant for this project. Any temptation to include it might be an indication of scope creep. If anyone debates the exclusion of a class that appears to be out of scope, perhaps they need to reaffirm what was agreed upon in the prior deliverable.
An attribute: Nouns that really describe the structure of another class are attributes. This is the most common filter applied in most domains. Be careful not to completely remove these nouns, however, because they will end up as attributes in a class. Credit card number is a noun that describes something else in the system. However, it is not a class.
Be careful with attribute recognition versus class recognition, especially in the context of the application domain. For example, a common noun, ZIP code, is usually thought of as an attribute of an address class. Depending on the domain, however, it might be a class. For example, to the postal service the noun ZIP code is a class because it contains both attributes (geographic location, census, rate structures, and shipping information) and behavior (routing and scheduling of deliveries).
A role: A noun describing the state of a particular entity or its classification is likely not a class; it is a role. For example, preferred customer is the state of a customer at a given time. Customer is actually the class, and the fact that a customer is preferred is probably indicated by an attribute within Customer (status).
A word of caution when dealing with roles: Often roles that are removed return later when the concept of class generalization and specialization (a.k.a. inheritance) is reviewed. If it is known up-front that the role has unique structural and behavioral elements that the domain is interested in tracking, don't be too hasty to remove the role. If removed, however, the role will be addressed later as the class diagram is iteratively refined.
An event: Nouns that describe a particular time frequency usually depict a dynamic element that the domain must support. Print invoices once a week is a timer-oriented event that the system must support. Week is not a candidate class.
In some real-time, embedded applications, events are in fact classes. If an event has some interesting structural elements or behavior that is important to the domain, it might be a class.
An implementation construct: A noun that depicts a hardware element (e.g., printer) or an algorithm (e.g., compound interest) is best dealt with by being removed and assigned as an operation of another class.
In many real-time, embedded applications, hardware components are classes (controller, servo). They have attributes (current position, head) and behavior (seek, set position) that meet all the criteria of a class. The act of creating a class out of an inanimate object and assigning structure and behavior to it is called reification.
When selecting the final name for a class, always use clear and concise terms. Favor the singular tense (Customer, Order) over the plural (Customers, Orders). Also note that class names are always capitalized when used on diagrams or in other documentation.
Types of Classes
Many people confuse classes with database entities. Database entities have the sole mission of recording only structural (persistent) elements of the application. Classes are very similar. In fact, they are a superset of what is provided by the database entity. However, classes also have behavioral characteristics that entities don't have. The project is very concerned about the data attributes, and that's where traditional entity data modeling ends—capturing the data structures.
Classes bring much more to the understanding of the application in the form of behavior (operations) that the class is responsible for implementing. The operations represent the services that the class is committed to carrying out when requested by other classes in the application domain. From a relational perspective, entities have been said not to have any class or to know how to behave.
In object systems, and through our modeling efforts, classes must be categorized into groups. Ivar Jacobson groups classes into three groups, or what UML refers to as stereotypes. Think of a stereotype as being a “flavor” of something:
Entity: Entity classes represent the core of the application domain (e.g., Customer, Order). They are meant to keep information about the persistent application entities over time, as well as to capture the services that drive the majority of interactions in the application. Don't confuse the term entity as used here with the more traditional use of the word when describing a relational entity. An entity class may not become a relational entity. Some practitioners use the term domain class to provide a better distinction (which I personally prefer). These classes will eventually end up as either JavaBeans or entity-type Enterprise JavaBeans (EJB).
Boundary: Boundary classes serve as a boundary between the external actors wishing to interact with the application and the entity classes. Typically, boundary classes are meant as a shield, or go-between of sorts, that segregates much of the interaction details of how to reach services offered by the application. Most boundary classes are user interface components, which take the shape of forms and screens used to interact with the application. Boundary classes can also be found in messaging to external application systems or as wrappers around existing legacy components.
Note that not long ago, this category of classes was called interface classes. Now that the notion of interfaces has become much more popular and flexible, especially with Java, boundary classes is the name used in this text. For Remulak Productions, these classes will be JavaServer Pages, which are compiled into servlets at runtime. So, we could indirectly say that boundary classes will be Java classes implementing the servlet interface.
Control: Control classes are coordinators of activity in the application domain. Sometimes called controllers, they are repositories of both structure and behavior that aren't easily placed in either of the other two types of classes. These classes will eventually end up as JavaBeans or session-type Enterprise JavaBeans (EJB). Typically, a control class can play any of several roles:
As transaction-related behavior
As a control sequence that is specific to one or a few use-cases (or pathways through a use-case)
As a service that separates the entity objects from the boundary objects
Categorizing the classes into these three types makes the application less fragile to change. These changes may result from the business's evolution in a dynamic marketplace or because individuals want to view information in the application differently. Figure 5-2 shows the three types of classes in action, and the subsections that follow discuss each one in more detail.
Figure 5-2. Entity, boundary, and control types of classes
Entity Classes
For Remulak Productions, the following list identifies the potential entity classes (with filters applied) for the application. It covers all of the use-cases documented so far (all of the use-cases of Increment 1, and the happy pathways of the remaining use-cases):
Address
Customer
Order
Invoice
Product
OrderLine
OrderSummary
Payment
Shipment
Guitar
Supplies
SheetMusic
Entity objects usually provide some very specific services, typically operations that do any of the following:
Store and retrieve entity attributes.
Create and remove the entity.
Provide behavior that may need to change as the entity changes over time.
Most visual modeling tools generate these class structures for you. Entity classes are also used to derive the first cut of the implementation for the physical database. If the persistent storage mechanism will be a relational database, these classes may not map one to one with database tables.
Boundary Classes
Boundary classes are the viewport into the application, as well as application insulators to the outside. Consider the Order class. It probably won't change much over time; it might undergo some behavioral changes (e.g., how pricing discounts are applied), but probably not many structural changes (attributes). Likely to change are the following:
How people (actors) want to place orders (e.g., via telephone response systems, via the Internet)
How other systems (actors) want to interface with the order application and how the order application will be expected to interface with other systems (actors)
How people (actors) want to view information from a reporting and decision support perspective
To facilitate these trends better and to insulate the entity classes, you should place all behavior relating to interfacing with the application into boundary classes. Also place in boundary classes all functionality that is specified in the use-case descriptions pertaining to user interface and that depends directly on the system environment.
The easiest way to identify boundary classes is to focus on the actors in the system. Each actor will need its own interface into the system. The classes can be further refined from information found in the use-case description and the use-case pathway details. A boundary class will usually exist for each screen-oriented form and each report, as well as for each interface to an external system (e.g., accounting, billing, credit card authorization). The following list shows the potential boundary classes for Remulak Productions.
MaintainOrderPanel
InquireOrderPanel
ProcessOrderPanel
MaintainRelationshipsPanel
CreditCardInterface
AccountingSystemInterface
Control Classes
One excellent use of control classes is to act as the conductor of the work necessary to implement the pathways through the use-cases. Control classes are usually transient (not persisted to external storage). Their lifecycle is only as long as it takes the interaction to complete or as long as a user session is active.
For example, where do we place the tasks necessary to orchestrate messaging for the happy pathway (Customer calls and orders a guitar and supplies, and pays with a credit card) for the use-case Process Orders? We'll place such “scripting” tasks in a control class. So we create one control class for each use-case. In addition, another pattern will emerge in that each happy and alternate path will have a corresponding operation in the control class that houses these scripting tasks.
The following list shows the potential control classes for Remulak's Increment 1:
Process Orders controller
Maintain Orders controller
Maintain Relationships controller
Architecture Infrastructure controller