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
One of the first tasks is to create a model of the environment. Not all the environment, but those parts that is needed in order to fulfil the what the system-to-be is required to do. We will do this by analysing the Problem Domain.
Taking the system-to-be's point of view we need a representation of the environment in the system, often called an abstraction of the environment. Only those parts of the environment should be represented that makes sense for the system-to-be. If for example the system-to-be shall control a heating system a representation of the outdoor and indoor temperature is good representatives from the environment to be candidates in the system-to-be. Early in the process the temperature is fine to note. At the end of the Launch Phase considerations about how to measure and represent the temperature will be done possibly leading to extra classes some of which may be hardware.
Definition: Object - A run-time entity that packages both data and the procedures that operate on that data. But also something physical or artificial existing in the environment.
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.
In EUDP in the early phases of the analysis, a class (or object) can represent anything regardless if it is going to be implemented in mechanics, hardware or software. Basically the early classes are blocks of related functionality.
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
IndoorTemperature
OutdoorTemperature
SupplyPipeTemperature
HotWaterTemperature
Boiler
OilBurner
HeatingSupplyPump
HotWaterSupplyPump
HotWaterElectricHeater
MixerMotor
TheSun
Oil
Water
MainsSupply
BoilerTemperature
HotWaterUnit
BoilerUnit
Used In
The Class Candidates is used in combination with the Event Candidates to form a Class Event Table
