Photo by Brands&People on Unsplash. This article is originally published on dev.to on 28 Feb 2021.
A class diagram could play a key role in a solid software design. However, I hardly knew where to start when it comes to the class diagram even though I take the time to analyze requirements.
In this article, we will discuss steps to discover the path to create a class diagram from a scenario.
To summerise, we will go through these steps:
0️⃣ Our scenario
2️⃣ Create CRC cards
3️⃣ Translate CRC cards into a class diagram
4️⃣ Conclusion
Let's get started 😊
O. Our scenario
Assuming we have a client who owns 5 cafes and a kitchen where kitchen staff make food items every morning for all shops. The system they need is food ordering software where each shop manager submits food orders for the next few days and the kitchen staff view them. We have a report that summarises objectives, criteria, all the requirements and limitations.
Our goal, for now, is to create a class diagram. But can we start drawing by looking at the report? As long as the report is well organized already aiming to create a class diagram, or if we are experienced, I assume we can. Otherwise, we may want to start by writing user stories that help us ensure to meet each requirement.
1. Write user stories
A user story looks like this:
As an admitted user, I want to add an item with quantity to my order list so that an admitted user can view them.
Point is to write from the perspective of end-users so that verbs are in the active forms. If we fix the sentence in the "As a ... , I want to ... so that ... ." form, we can find important information easily. "so that" part can be eliminated if the objective is obvious.
I personally like writing user stories on Evernote or Spreadsheet, because user stories can be moved around to organize with no hassle.
We can identify objects when looking at nouns in the user stories like this:
"As an admitted user, I want to add an item with quantity to my order list so that an admitted user can view them."
And verbs can help identify requirements that the object might have.
"As an admitted user, I want to add an item with quantity to my order list so that an admitted user can view them."
With this sentence, we can say that the order list object could have the responsibility related to add and view.
Assuming the above list includes all the requirements we need to implement. For now, we can simply highlight nouns and verbs, so we can look into details in the next step.
2. Create CRC cards
In this section, we'll organize the components that we just highlighted in the user stories. Here we use CRC cards.
CRC cards are a great way to refine and record the components of the system design. They are like a pre-class diagram. What we need are a pen and physical cards - I personally like to use large size post-it, but we could also use online platforms like Lucidchart.
A CRC card has three sections: 1. Class name 2. Responsibilities 3. Collaborators
Firstly, we'd like to find the class names. Let's look at the first user story on the list.
"As an admitted user, I want to add an item to item list. Each item is created with its name, description, production cost and availability."
In the above sentence, we can see three potential objects: (admitted)user, item, and item list which are all nouns. They can be classes, so create CRC cards with their class names.
The next section is Responsibilities. Here we can focus on verbs in the user stories and consider who is responsible for the action. For instance in the sentence, "add" is the responsibility of the class ItemList.
But when you think about it, it's a bit strange, right? Because in real-life, if you are a user of a box and if you want to put something into it, the activity itself is not the responsibility of the box but rather the users. So why the add is the responsibility of ItemList, not the User ?
Because in object-oriented thinking, objects are all self-aware, even if it's not a living thing. So we think all objects can do something too.
Imagine our ItemList is a living thing that works very hard for you. If a user tells it to put something into it, they'll do it. If they can do it, you should leave the responsibility to them.
So the CRC card for the class ItemList can have a list of items and the ability to add an item into the list.
Lastly, we'll find Collaborators. For ItemList class, a collaborator can be Item because it's the object that will be added in the ItemList using the add activity. Therefore they are collaborators to each other.
While creating CRC cards, it is good practice to look at the collaborators' section and place the cards next to each other if they have a relationship. We can move around as you add new information.
3.Translate CRC cards into a class diagram
When we have covered most of the nouns and verbs on CRC cards, we can move on to translating them into a class diagram.
It's now much easier to draw it using both user stories and CRC cards. I personally like using Lucidchart that helps create clear diagrams easier.
For instance, I have translated the CRC card to the class like this:
Responsibilities in the CRC card such as its name, description, production cost, availability was included as attributes, and methods were evolved from edit each component responsibility. Ideas of relationships came from the collaborator section.
Make sure to cross out each user story as you create related class diagram components -- so that we won't miss out on any requirements.
If you have difficulties to identify Objects or relationships, I'll highly recommend taking a look at Object-Oriented Design course on Coursera -- You could even learn most of the module by just reading its class note pdf.
Conclusion
Creating a class diagram is something that can help us create a solid software design as well as to communicate with other members of the team or future self, but at the same time, we may not have much time to spend on this activity. Using these small techniques would help us achieve a better result at the end of the day.
