Now that we have our first use case, it’s time to do a little design work. The first task we have to complete is to identify object candidates, that is things that might be coded up as objects in our solution. The easiest way, I find, to do that is to list the nouns in the use case, so let’s do that now.
The nouns are:
- Administrator
- Diary
- Course
- Booking
- Outage
Examining the list above it is clear that the nouns 2 through 5 are good candidates for objects but Administrator is not so clear because, at this point, it is not obvious if Administrator should be an object or if it is an attribute of another, as yet undefined, object (Employee say). So, for now, we’ll not include it as an object, safe in the knowledge that if we change our minds, we can fix it during the refactoring phase.
Booking too, though an obvious candidate, is not really part of this use case. Certainly both Diary and Outage objects have a dependency on Booking, as we’ll see later, but this dependency can be mocked during testing of this use case solution and so, for now, we can afford to ignore it.
The next task we have to complete is to decide what behaviour our objects are going to have. A good way to get a “first pass” at object behaviour is to look at the verbs in the use case, so we’ll go ahead and do that.
The verbs are:
- Select
- Create
- Logs on
- Edit
- Delete
Now that we can see them clearly, we notice that we don’t have to pay them a lot of notice as the CRUD will be handled by XPO (the orm tool under XAF) and the “logs on” element we can assume we can handle via the security module (again safe in the knowledge that if we are wrong we can fix it in the refactoring phase).
Now we need to look at what constraints we have on our objects. From the use case we can see that we have a constraint around tee-time bookings with regard to the fact that we can’t create or edit an outage, nor can we edit a diary if it is going to invalidate a tee-time booking. So let’s decide that we are not going to allow those processes to occur and let’s document that decision.
Business Rule: 001
Use Case Reference
001 paragraphs 2.1.4, 2.3.3 and 2.4.4
Rule
Tee-time bookings cannot be invalidated by the creation or editing of an outage, nor by the editing of a diary.
Action to be Taken
On the aforementioned events a search will be made for affected bookings, if there are any then an error message will be presented to the user and the event cancelled.
There is also a constraint around the deletion of course diaries in as much as they cannot be deleted if they are assigned to a course, so let’s go ahead and document that decision too.
Business Rule: 002
Use Case Reference
001 paragraph 2.2.4
Rule
A course diary cannot be deleted if it is currently assigned to a course.
Action to be Taken
On the aforementioned event a search will be made for affected courses and if any are found then an error message will be presented to the user and the event cancelled.
Having identified the objects, their knowledge (the properties they have) and their behaviour (the functions that can be called on them) and having documented certain business rules, the above post, along with the Use Case, represents a minimal set of documentation that an agile team (in this case us) can use to go ahead and create some code. And that is just what we’ll do in the next post.