Class Candidates
What
Candidates for Classes
How
The Dish
Class candidates
Ingredients
Process
In the pre-project phase several of the Ingredients may have been produced and from the content we can extract class candidates. Typically, objects which are instances of classes can be described by a noun.
In the Rich Picture there may be a number of objects represented.
In a Story or on Storycards we can find objects that should be represented in the system-to-be.
On Storyboard sketches we find a number of objects as well.
In the Preliminary Use Cases we find a number of objects represented.
In the System Overview Diagram there are typically represented a number of objects and interfaces.
Compile those objects or class candidates into a table. Do not evaluate the candidates yet - include any possible candidate in the table.
Name the class candidates with a singular noun (e.g. Boiler). Sometimes you put two or more nouns together into one word. There will be no spaces between them, but each independent noun should start with a capital letter (e.g.OutdoorTemperatureSensor).
Why
Definition: Object - A run-time entity that packages both data and the procedures that operate on that data.
Definition: Class - A class defines an object's interface and implementation. It specifies the object's internal representation and defines the operations the object can perform.
Definition: Problem Domain: The part of the system-to-be should control or administer.
Definition: Usage Domain: The users and other systems that controls or administers a problem domain.
From the definitions above you can see that in order to describe the objects in the system-to-be, you need to describe the classes from which the objects instantiate. If, for instance, a class Customer is found, it describes all objects of the type Customer regardless whether the actual customer pays by cash, credit card or has credit for a longer period. The Customer class describes the attributes, i.e. the data, and the operations, i.e. the functions or procedures that objects of this class adds to the system. Each object has its own set of data that can be manipulated by the operations. The operations are typically loaded only once in the running system and the code can operate on all objects' data.
The classes found are organised into a class diagram, which gives the developer an overview of the system. When working in the analysis phases the classes represent "real" world objects, whereas in the design phase classes may differ from the analysis view due to reorganisation.
In order to compose a class diagram you need class candidates. During the pre-project activities a lot of objects in the problem domain will be discovered. They may not be obvious at first glance. You can get inspiration to identify the objects by looking at the nouns presented in the story told in cooperation with the customer, in the figures represented in the rich picture, or on the story cards.
It is important to be open-minded in the process of finding candidates. Do not judge the candidates while collecting them from the sources. The judgement will be relevant later when you compose the actual class diagram.
The result is a list or a table with candidates, of which some may not survive in the final class diagram. Bear in mind that if you do not have enough candidates from the beginning, you may not have enough of them later in the development process.
Example
Inverter
IndoorTemperatureSensor
OutdoorTemperatureSensor
SupplyPipeTemperatureSensor
HotWaterTemperatureSensor
Boiler
OilBurner
HeatingSupplyPump
HotWaterSupplyPump
HotWaterElectricHeater
MixerMotor
TheSun
Oil
Water
MainsSupply
BoilerTemperatureSensor
HotWaterUnit
BoilerUnit
Used In
The Class Candidates is used in combination with the Event Candidates to form a Class Event Table
