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, paycheck, spaceship, asteroid, level, 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 on 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.

 

4. 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.

 

 

5. 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 verifies items, provides payment and address, process sale, validatepayment, confirm order, provide order number, check order status, and sendorder details email.

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.