Class Event Table

From EUDP
Jump to: navigation, search

What

Class Event table

How

The dish

Class Event table

Ingredients

Process

Assessment of the class candidates:

For each class candidate ask the following questions:

  • Is it possible to identify objects from the class?
  • Does the class contain unique information?
  • Does the class include more objects?
  • Does the class have some events?

If two or more of the answers to the questions are positive, the candidate is a class that should be included in the domain model.


Assessment of the event candidates:

For each event candidate ask the following questions:

  • Is the event instantaneous?
  • Is the event indivisible, i.e. it cannot be divided into more parts?
  • Can it be identified when it occurs?

If the answers to the questions are positive, the candidate is an event that should be included in the domain model.

Set up a table with the events listed vertically and the classes horizontally. Mark each intersection where the event involves a class.

Inspect the table and reconsider the classes with no events marked. There can be classes with no events attached, but they are seldom in this stage.

Classes with many events involved may have too high responsibility and may therefore be divided into two or more classes.

Why

Definition: Domain Model - An object model of the domain that incorporates both behavior and data.

Classes and events from the candidate list should be assessed as part of the selection process. The most important assessment to be done is simple:

A class or an event shall be part of the domain model, if, and only if, they provide information for the functions of the system.

Class candidate assessment

This leads to the following questions about each class candidate:

  • Is it possible to identify objects from the class?
  • Does the class contain unique information?
  • Does the class include more objects?
  • Does the class have some events?

If it is impossible to identify objects from the class, it is most certainly not the right candidate - another candidate should be selected.

During the analysis of the problem domain each class should represent a certain amount of unique information. If the information can be found in other classes we are modelling functionality and the class should be abandoned. It may be taken into consideration again at a later stage in the design phase.

Normally, there should be more than one object of a class, though single object classes do occur.

After building the class event table it is possible to see if a class do have events. If it does not have any events it is possible that it should probably not be included in the model.

Event candidate assessment

Like classes events should be assessed by asking the following questions:

  • Is the event instantaneous?
  • Can the event be divided into more parts?
  • Can it be identified when it occurs?

It is important that the event can be identified as instantaneous. If an event does have a timespan, it might be necessary to divide the event into more parts, for instance the start and the end of the event. On the other hand, if only the end of the time span is interesting to the system, it should be chosen by renaming the event accordingly.

An event is always undividable. If we want to describe part-events we should do so by selecting and naming the parts rather than the whole.

Finally, it is important that we can identify when the event occurs. If it is not possible to identify the exact time, try to see if another approach to the event may lead to an alternative event. As an example: If a customer should fill in an application form, the event FormFilled cannot be identified - we do not know when the customer really filled in the form. Another event like FormReceived might be a better choice because we know when we receive the form in the company.

Class Event Table

Having assessed the class and event candidates those selected should be compiled into a table.

When you select a class you should identify the events, objects of this class is involved in. Likewise, when you select an event you should identify the involved objects of the event.

  • Which events are this class involved in?
  • Which classes are this event involved in?

After the classes and events are compiled into a table where the intersections between class and related event are marked, it is now time to look at the result. If a class does not have any events, reconsider if it should be part of the domain model - it may still have a valuable place in the model. If a class has many events, it might indicate that the class has a high responsibility in the system and that it has a low mutuality with other classes. If an event is marked with many classes, it indicates that the event ties the highly coupled classes together.

Example

Class Event Table.png


Used In

The Class Event Table is used throughout the following design of the domain model. The Class Event Table is an important input when designing the Class Diagram as well as when designing the State Machine Diagrams for the classes.