Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
So step 1, what we do is collect our Use Cases, our User Stories, and any other written requirements together. And here's where we have one of the greatest benefits of having these written descriptions of our application. We just go through them and start picking out all the nouns. Just start highlighting or underlining, and make a list of them. Because these are your possible objects, your candidate objects. Now when we're gathering, we don't analyze or judge them here. We don't worry if there's a better word to use or if we perhaps used the different noun to describe the same thing on another card.
We just start making the list. We also don't worry we might miss one, it happens. Just take a first run through picking out all the nouns. So I've done them here just on this single casual Use Case to create a partial model, and you'll end up with a list of nouns, potential objects. You can then first take a pass through this and find if there's any obvious duplicates. From my application I referred to the word Sale and the word Order to mean exactly the same thing, so I'll get rid of one of them.
Quite often you'll find yourself combining some of these or even splitting some of them. Picking out the nouns is merely a starting point. Now sometimes what you'll find is that attributes are going to announce themselves at this point. So we look at Order Number and realize this really only makes sense as part of the order concept. So it would be an attribute of an Order class. It's part of an order. But when I focused on showing that kind of data right now, so we can just remove that one. And the same way the Order Details, as far as my Use Case was concerned, this just meant a description of the order, not a separate thing.
So I'll remove that too. Along with Order Status. And although System was used as a noun, I'm going to remove that, too, and I'll get into the reason why a little later on. So we're left with a handful just from this one casual Use Case. Now optionally we can make a quick diagram of these. As always diagrams aren't necessary, but they can be useful. And this is very simple. We just box all the objects. This is the beginning of it. And the conceptual model, we're not turning these yet into full class diagrams, so there are no formal method names and attributes.
We're just using the names of the objects. The benefit of creating a diagram is that it becomes easier to show the responsibilities and the relationships between the different objects as we start to build this out.
Get unlimited access to all courses for just $25/month.Become a member