Modelling a system after having defined the UML use case

Question

...what's next?

After you defined what actors do what actions, which way do you go? Do you model the database or do you prefer to start with the classes?

I thought the better approach was to start with a class-like modelling diagram, to focus on relationships between objects. This has proven to be wrong because I went too deep in detailing classes and, even if the system "seemed to work", when I went to the database modelling, everything just would not fit naturally in the positions I chose in the previous phase.

I read about people saying that one should put application logic into a database and leverage its speed in retrieving data, opposed to building large objects in memory that are queried and provide abstraction of the underlying database. I always thought that the db is there to store my data and provide a fast way to access it. But maybe I'm wrong, I mean, do I really have to build a database which has inside the same logic I would put on a group of classes? Isn't the database lacking the tools to achieve this?

I think I'm failing in identifying the right point where to start, if I choose to start with the database I find it hard to not just think of it as a "place to store my data, let's do app logic on a higher level" thing, if I start with classes the database ends up looking like an unnatural representation of classes, i feel the sensation of missing something important, something like not assigning the right purpose to the right tool.

How do you deal with this? When it comes to decide whether to start with modelling the db or the classes, in your experience, what kind of approach has proven to lead to a natural and clean implementation ?

Thanks in advance

Answer 1

If using Test Driven Development, write your unit tests first. Your classes will be outlined as you go.

You can choose to develop your business logic without a database (mock or stub objects) or develop your database as you go on with your tests.

Remember your database and domain model shouldn't map one on one with each other.

Answer 2

I've had success using Robustness Analysis.

This article focuses on robustness analysis, which involves analyzing the narrative text of use cases and identifying a first-guess set of objects that will participate in each use case, then classifying these objects into three types:

1. Boundary objects, which actors use in communicating with the system.
2. Entity objects, which are usually objects from the domain model (the subject of "Driving Design: The Problem Domain," Jan. 2001).
3. Control objects (which we usually call controllers because they often aren't real objects), which serve as the "glue" between boundary objects and entity objects.Figure 1 shows the visual icons for these three types of objects.

The entity objects are the ones that (usuallly) end up in the database/

On mapping between classes and the database, I would recommend S.Lott's article on "The ORM Problem" (he's also a participant on StackOverflow