[T.6.1] After you have determined your organization’s needs, the next step in your analysis is to find the classes of objects described in your use cases and workflow.
One of the best places to begin looking for classes is to examine the nouns in your use case descriptions. Look for nouns and noun phrases such as change request, product, title, version, build, and product. It sounds too simple, we know. Once you have all of your nouns, you then need to classify them into as few classes as you can. Finally, you will throw out any classes that will not be useful for the implementation.
For those of you new to this process, don’t worry—we’re about to provide some explanations of how your classes are constructed and how they fit into your overall system design.
What is a class, anyway? Well, a class is a collection of objects that have the same characteristics, including structure and behavior. An object that belongs to a particular class is often referred to as an instance of that class. One might think of a class as an abstraction of a particular group of real-world things or concepts and an object as the concrete manifestation of that abstraction. (Within the ClearQuest database, classes map to record types.)
The standard UML notation for a class is a box with three compartments, as shown in Figure 6-1. For more information about the UML in general, we recommend reading UML Distilled Second Edition by Martin Fowler with Kendall Scott, Unified Modeling Language User Guide, Second Edition by Grady Booch, James Rumbaugh, and Ivar Jacobson, or Visual Modeling with Rational Rose 2002 and UML by Terry Quatrani.
The top compartment contains the name of the class. The middle compartment contains the attributes—in other words, the data values—of the class. The bottom compartment contains the class’s operations—the functions that the class can perform.
You can show a class without its attributes or its operations; the name of the class can appear by itself. Later in this chapter, we’ll show some example classes whose operations compartments have been suppressed.
Classes, by themselves, aren’t particularly useful. Instead, the relationships among classes provide the foundation for the structure of a new system.
The most common type of relationship among classes is the association. This is a simple structural connection among two or more classes; an association between a pair of classes is by far the most common form.
An association is represented by a straight line between the classes, as shown in Figure 6-2.
This example also provides information about the multiplicity of the association. A multiplicity value indicates how many objects that belong to each class can be present within the association. In the example, Class A has a relationship that involves zero or more objects belonging to Class B. (You can use the ReferenceList attribute within ClearQuest Designer to map this kind of design element to your implementation.)
The first step in designing the structure of your ClearQuest system involves finding the classes of objects described within your use cases and workflows, which we addressed in Chapter 5. Look for the nouns in your use case descriptions. Once you have all of your nouns, make decisions as to which nouns should be classes and which nouns should represent attributes on those classes. These are the prime guiding principles: If a noun has interesting characteristics, it’s a good candidate to be a class. If a noun is really more of a description of a characteristic of something else, it’s a good candidate to be an attribute.
Let’s combine these simple graphical elements to form a working example for a defect-tracking system, as shown in Figure 6-3.
There are four classes in this example: Defect, Enhancement, Customer, and Change Request. Attributes are defined for each class, and we’ve also defined some relationships. Notice that the Enhancement class has two relationships with the Customer class, one named “primary” and the other unnamed. This allows an Enhancement object to have a primary Customer object and also a list of other Customer objects that require the Enhancement object. Additionally, Enhancement and Defect objects have zero to many associated Change Request objects; this arrangement allows for multiple changes against the same defect or enhancement.
Knowing the possible states in which your objects can reside is important with regard to your ClearQuest implementation, as ClearQuest allows for direct mapping from state nets to implementation. You should coordinate your state nets with your workflows so you can implement how changes in state affect other objects in your system.
A state is a condition in which an object can be at some point during its lifetime, for some finite amount of time.
An object can do any or all of the following while it’s in a particular state:
Perform some activity
Wait for some event
Satisfy one or more conditions
Figure 6-4 shows the notations for a regular state and for two special kinds of states: the start state, which represents the initial conditions in effect when the object is created, and the end state, which represents the conditions in effect when the object is terminated.
A transition is a change of an object from one state to another. A transition “fires” when an event of interest to the given object occurs. A directed line between the “from” state to the “to” state represents a transition, as shown in Figure 6-5.
A transition may have a label on it that shows the action that “triggers” the transition. It can also have a guard, which is a Boolean expression that must evaluate to True before the transition can fire. Adding this kind of information to transitions usually proves highly useful in making design decisions.
States and transitions appear on statechart diagrams. Figure 6-6 illustrates the lifecycle of a typical change request.
ClearQuest has a mechanism to view the same state and transition information in a matrix. While the matrix form can show only part of the information that a statechart diagram can show, it’s easier to see what is going on.
Table 6-1 illustrates an additional way to show the same state net represented within Figure 6-6.
You need to know when and how your users will work with the classes that you specified in your design. Where do you find this information? Look at your use cases. Specifically, look closely at any use cases that involve a human actor. If you have a human actor interacting with an object of a specific class, you will need to design a user interface form for that class. In fact, you may need to supply more than one interface.
Let’s look at our use cases and see what we can find.
To understand how you are going to deploy the tool, you need to have some concept of who is going to use it and where. For example, does it need to be accessed remotely? Do you need Windows or UNIX support? Do you need both? If so, you need to understand all of the available deployment options.
To understand the different deployment options, you first must understand how ClearQuest is architected. As we showed at a high level in Chapter 4, ClearQuest uses a three-tier architecture. Table 6-2 takes this a step further, showing each of the deployment options for each tier.
Table 6-2. ClearQuest Tier Deployment Options
Layer | Components |
|---|---|
Client layer | ClearQuest client (both Windows and UNIX) |
ClearQuest Web (both) | |
ClearQuest Designer (Windows) | |
ClearQuest Maintenance Tool (Windows) | |
ClearQuest Import Tool (Windows) | |
ClearQuest Export Tool (Windows) | |
ClearQuest User Administration (Windows) | |
ClearQuest API (both) | |
ClearQuest MultiSite (both) | |
ClearQuest Eclipse plug-in (both) | |
Command Utilities (both) | |
Rational E-Mail Reader (Windows) | |
Business Flow layer | ClearQuest core |
Database layer | Microsoft Access |
SQL Anywhere | |
Microsoft SQL Server | |
Oracle RDBMS | |
IBM DB2 | |
ODBC drivers |
The Client layer of the ClearQuest architecture includes a variety of modules and tools for entering and viewing data, creating and managing schema and databases, importing and exporting data from other environments, and replicating data across multiple locations. It also includes the ClearQuest API.
The Business Flow layer, or the ClearQuest core, is the layer where application logic and business rules are stored and executed. The ClearQuest core communicates with the database layer using Open Database Connectivity (ODBC) drivers. The ClearQuest core also exposes a limited amount of core functionality through the ClearQuest API for hook-scripting purposes.
The Database layer contains the database management system or systems that physically manage the information in the schemas and user databases.
In the Windows environment, the database management system can be any of the following:
Microsoft Access (small installations, fewer than five users)
SQL Anywhere (small or medium-sized installations)
Microsoft SQL Server, Oracle RDBMS, or IBM DB2 (large installations)
You need the correct Windows software to design and maintain your ClearQuest installation. Unfortunately, because the UNIX version does not contain the designer or maintenance tools, you must install the Windows version of the toolkit. If you can avoid using ClearQuest on UNIX and just have a Windows installation, your life will be much easier.
There are also options for your users to use the web interface on UNIX and Windows with a pure Windows version. The only reasons to stick with UNIX on any of the layers, in our view, would be as follows:
Client layer: Users need to use the API, or ClearQuest itself, natively on a UNIX platform. If your users want to use the native tool but do not have a requirement to use the API, then offer them ClearQuest Web.
Database layer: If you have a very large installation, you might want to use a UNIX box over a Windows box.
If you can avoid a UNIX installation of any sort, you will be better off. The simple fact is that it is always more difficult to manage multiplatform deployments than a single platform. So stick with Windows if at all possible.