Update Our Use Case Diagram
The thing about customers is that they always change their minds. Let’s see what the librarians would like us to change. Watch the video and see if you can pinpoint the additional functionality:
Couldn't they have told us this before? 😦 Well, that's how customers work, so you might as well get used to it. 😉 It's only a couple of new items:
Putting a book on hold.
Increasing the fine for a popular book.
How does this impact you? You need to update your documentation!
You need to determine if anything is an entirely new use case or a modification of an existing one. The idea of putting a book on hold is not related to any of the previous use cases. So, go back to the diagram and add an oval.
See how easy that was? That's the beauty of domain-driven design!
Update Our Class Diagram
You should now generate a new use case description. This will indicate whether any new classes or attributes need to be added. Here's the new use case description:
User searches for a book.
The system shows the book's information:
Including the fact is is currently checked out by another patron.
The user selects the hold book option.
The system prompts for the patron's information.
The user enters the patron's name or library Id number.
The system validates the patron exists.
The system adds the patron's Id to the book's hold list.
The new nouns have been highlighted. You can generate a class diagram to show the new and existing concepts associated with this use case:
Add the following to the existing diagram:
A Hold List class, which is related to the Book class. A book has only one entry on the hold list, but the hold list can have many books.
A relationship between the Patron class and the Hold List class. A patron can only be entered once on the hold list, but a hold list can have many patrons on it.
Attributes in the Patron class for the patron's first and last name, as well as a unique Id number.
What about doubled fines for popular books?
The "fines doubled for popular books" is just an extension of the fine patron use case. There is no need to add that detail to the use case diagram. However, you'll need to add a definition of what a popular book is to the domain model, since that is a new concept. In this case, add "Popular book" to the Book class:
Does moving or adding an attribute mean we made a mistake earlier?
No, it just means the system needs to behave differently now, and it makes more sense to have the attribute in a new or different concept. The important thing is that you keep the model up to date. You don’t want any new concept to go by the wayside. If you get into the habit of not updating your model, you will slide back into the "system first" approach.
Try It Out for Yourself!
Sometimes you have to modify your documentation to accommodate new ideas - and sometimes you don't! Check out the following challenge and make your own decision:
Let's imagine that in a later conversation, you find out that a popular book is any book that has been requested to be put on hold by three or more patrons in one week. Decide if you need to modify your existing documentation to capture this definition. If you do, propose an appropriate solution.
Scroll past the image to find the solution.
You have captured the concept of a popular book. How it becomes popular may change over time, but the idea of being popular doesn't. So you don't have to change your diagram!
This is a little tricky. The rules (business logic) aren't shown on a class diagram. Of course, you'll have to have some code that will look through the list of books on hold and see if there are any that appear three or more times, but again, that's business logic, and not shown on a class diagram.
Let's Recap!
You've seen a user request for a feature get integrated into a use case diagram, and expanded into a use case description. You used the description to generate a class diagram.
When clients ask for changes, be sure to:
Generate new use case descriptions.
Repeat the process of searching for classes and attributes.
If needed, modify the existing model to incorporate the new ideas.
In the next chapter, we will look at categorizing these classes, and how they may be implemented in code.
