Object-Oriented Analysis And Design — Conceptual Model (Part 2)
Identifying the most important objects, their relationship and interactions between them.
This is a series of articles on Object-Oriented Analysis And Design. The full series of articles can be found here.
Conceptual Model
Once we’ve some use cases or user stories, the next thing we can do is create a conceptual model of our system. It simply means you’re identifying the most important objects.
You shouldn’t be worried about software object right now, but more generically what are the things in the application that we need to be aware of.
Things like product, item, shopping cart, order, invoice, customer, that’s what we’re identifying here. Some of them will become actual classes and software object, but not all of them.
The Process
So, we’re going to identify those objects, start to refine them, and then draw them in a simple diagram. And we can also show the relationship and interactions between them.
An Advice
Creating a simple conceptual model for most applications is not and should not be a long process. A few hours spent on this is usually more than enough.
Don’t worry about perfection. First time through it will be incomplete, and that’s absolutely normal to miss out even important objects, things that you will discover later on during programming.
1. Identifying Objects
What we do is to start collecting our use cases, user stories, and any other written requirements together.
Now, we are going to identify the most important parts of our software; the most important things, or objects.
Objects will be in form of nouns. Those are the candidate objects, some of them will be actual objects in the system, and the rest won’t, as you’ll see later.
You are just identifying the objects, you don’t analyze or judge them. We also don’t worry about missing one, at the first spin, you may miss some objects, which is normal.
2. Refining Objects
After underlying your candidate objects, you start refining them, you start choosing your actual objects that will be in the system. So, to do that, …
- Remove any duplicates. We may find same objects with different names, but they actually mean the same thing.
- You may need to combine some objects, or, even splitting them into some other objects.
- You may identify an attribute as an object instead.
- You may identify a behavior as an object instead.
An attribute is a property or characteristic of the object. For example, when we say “A car is red”, red here is a property for the car, which is the actual object.
A behavior is something an object can do (responsibility). For example, when we say, “A bird can fly”, fly here is a behavior, while the bird is the actual object.
You don’t have to consume a lot of time refining your objects, don’t look for perfection, it’s normal to encounter some mistakes, or miss up some objects that will be figured out through the process.
3. Drawing Objects
What you need to do now is using your pencil and paper, just draw the conceptual model by box all objects.
There are some tools you may use, but for now, a pencil, and piece of paper are more than enough.
3. Identifying Object Relationships
You start indicate the relationships between your objects.
It’s very obvious that these objects will interact with each other. For example, a customer can place an order, a student can enroll in a course, an admin can update a post, and so on.
Drawing a line between objects, and writing the relationship verbs is enough to denote there is a relationship.
4. Identifying Object Behaviors
Behaviors are the things (verbs) the object can do, or, in other words, the responsibilities of an object, that will become the methods in our object class.
So, we can go back to the use case or a user story, and look for verbs and verb phrases to pick responsibilities.
Things like adds items, enter payment and address details, fulfill the order, process payment, send order details email, and view order details.
Now, not all of these will become behaviors, some will be combined, some will need to be split apart, and some will just not be needed or be replaced by something else, but they are a good starting point.
Whose Responsibility Is This?
What isn’t always obvious is where these responsibilities belong, particularly if they affect different objects. It’s because the use case describes what initiates a behavior, not necessarily who’s responsible to perform that behavior.
So, even though it’s the customer who wants to know the status of the order, it’s the responsibility of the order to check it’s status. The customer should ask the order object to report it’s own status.
When you ask whose responsibility is this? Always remember that an object should be responsible for itself.
The Generic Verbs
We can change the generic verb provide to set and get instead to make it clear for what we are trying to do.
The “System” Object
Now, here’s another issue that often comes up. It’s common to see phrases like “system” validates payment or “system” will send the customer an email at use cases, and that can lead to people creating a system object and putting a huge amount of responsibilities in it.
These phrases really mean that some part of this system validates payment, some part of this system will send an email, and it’s our job to figure out what part of the system should be responsible for that behavior.
The God Object
If you have an object that has a lot of responsibilities, chances are, you are doing it wrong.
You may need to re-think about the responsibility of each object, and distribute the responsibilities among the objects. Remember that an object should be responsible for itself as much as possible.
Class Responsibility Collaborator (CRC) Cards
Class Responsibility Collaborator (CRC) is another technique for organizing the objects.
You write every object on a piece of paper, with it’s associating behaviors on a side, and the other side has the other objects (collaborators) that has a relationship with that object.
They are small, easy to use, you can move them around to show the relationship, you can modify them easily if there is a mistake.
