Event Candidates
What
Candidates for Events
How
The dish
Event Candidates
Ingredients
Process
As for class candidates a gross list containing all possible events in the problem domain should be found.
Where objects often are characterized by nouns, events are characterized by verbs.
Be aware that some of the verbs found will characterise how the user does hers or his work. They do not belong to the problem domain, but to the usage domain. They should be ignored in this situation. Instead concentrate on the process in the problem domain.
Use simple, readable names for the events. Ensure that the event comes from the problem domain and not the usage domain and make sure that the event describes one single event.
Why
Definition: Event - An instantaneous occurrence that will influence on one or more objects.
Events are the dynamics of the system. Events describe the behaviour of the objects. In the definition it is defined that an event is instantaneous. Many of the events that we see in the problem domain are not truly instantaneous. The event may take some time to complete. In object oriented modelling we will ignore the timespan from when the event starts until it ends and define the event to occur for instance when the event ends.
An example: When a customer wants to open an account in a shop this can be a lengthy process. The customer fills in an application form. The shop processes the form in two steps. Step one is manual control of the form. If certain information is correct and within specific requirements, the form is accepted for further processing. Step two is entering of the data into the system, which may occur anytime from minutes to days later. From the system point of view the event CustomerCreated occurs only when the data from the form has been entered . In this case the system is not interested in the validation of the form.
If on the other hand the system-to-be was a new system which included the validation of the data on the form, we would have seen the event CustomerCreated and possibly another event: ValidateCustomer. But in this case ValidateCustomer is a usage domain event, so it must be ignored.
A third event one might see is CustomerValidated. This is an event that should be included in the event list because it is an event that comes from the problem domain. CustomerValidated is a result of the validation process which the system user has initiated. The event brings the customer object into the validated state.
Events are often characterised by verbs, so by looking at verbs in the problem domain it is fairly easy to get a number of event candidates. It may not be possible to list every event in the system at the first shot, but the work later on in the process will usually inspire to more events.
Example
ElectricPowerProductionStart
ElectricPowerProductionStop
IndoorTemperatureBelowLimit
IndoorTemperatureAboveLimit
OutdoorTemperatureAboveLimit
OutdoorTemperatureBelowLimit
HotWaterTankTemperatureBelowLimit
HotWaterTankTemperatureAboveLimit
SupplyTemperatureBelowLimit
SupplyTemperatureAboveLimit
MixerMotorAtEnd
MixerMotorAtBegin
BoilerTemperatureAboveMax
BoilerTemperatureBelowMax
Used In
Event Candidates are used together with Class Candidates to form a Class Event Table.
