The ICONIX Process in pieces: Domain modelling
Book extract, part I Reg Developer regular and Agile Iconoclast Matt Stephens admits to being something of a code fiend since he was 11.
Recently, Matt and his colleague Doug Rosenberg decided to commit the experiences of their youths spent coding software rather then jetting around the park on their BMX bikes to their latest book explaining the best ways for developers to use domain modeling to roll out a solid foundation for Object Oriented Analysis and Design (OOAD).
Their book, Use Case Driven Object Modeling with UML: Theory and Practice, is packed full of illustrative diagrams and helpful exercises for readers to undertake, and features a useful set of top 10 to do lists in each chapter that take you through the construction of a model – in this case for a sample internet bookstore application.
Each chapter opens with a "you are here" diagram of the ICONIX Process that shows in glorious red the area covered by that chapter to keep you orientated.
In this, the first in a series of four excerpts from Use Case Driven Object Modeling with UML: Theory and Practice Matt and Doug introduce domain modeling and challenge you to think in models.
The following chapter introduces the domain model aspect of the ICONIX Process.
The domain model - you are here...
Imagine if everyone on your team was talking a different language. Let's say you're speaking German, your team mate is speaking French, and someone else is speaking Swahili.
Every time someone speaks, people glean whatever slivers of meaning they can, and then nod as if they've understood perfectly. They then walk away with a completely wrong interpretation of what the speaker was really trying to say.
In virtually all IT projects, the problem of miscommunication is rampant, but it's rarely noticed because everybody thinks they're speaking the same language. They're not. One person says "book review" and some people interpret this as meaning "editorial review" (a review written by an editorial team), whereas others might interpret it as meaning "customer review" (a review written by a customer and posted to the site).
The results can be - and often are - catastrophic, as the system gets developed with everyone interpreting the requirements and the design differently.
Domain modeling aims to solve the problem of miscommunication on projects by establishing a common vocabulary that maps out the problem space. The domain model is a live, collaborative artifact. It is refined and updated throughout the project so it always reflects the current understanding of the problem space.
The diagram below (Figure 1) shows an excerpt from a domain model early on in the example project. As the project progresses, you'll allocate behavior (methods/operations) and data (fields/members) to each domain object, until it becomes an entity class, part of the overall design.
Figure 1: Drill down: example of a domain model diagram
Top 10 domain modeling guidelines
Each chapter's top 10 to-do list contains a concentrated dose of what you need to know, with the chapter delving into more detail and providing examples and exercises that illustrate each point. Here's our domain modeling top 10 list – pay attention, I'll be asking questions later:
10. Focus on real-world (problem domain) objects
9. Use generalization (is-a) and aggregation (has-a) relationships to show how the objects relate to each other
8. Limit your initial domain modeling efforts to a couple of hours
7. Organize your classes around key abstractions in the problem domain
6. Don't mistake your domain model for a data model
5. Don't confuse an object (which represents a single instance) with a database table (which contains a collection of things)
4. Use the domain model as a project glossary
3. Do your initial domain model before you write your use cases, to avoid name ambiguity
2. Don't expect your final class diagrams to precisely match your domain model, but there should be some resemblance between them
1. Don't put screens and other GUI-specific classes on your domain model
Domain modeling in practice
Our next diagram (Figure 2) shows a domain model diagram with attributes on the Order class. Take a close look at this diagram - what problem does it suggest?
Hint: this relates back to item number six in the chapter's opening domain modeling top-10 list.
Figure 2. Class diagram showing attributes
Domain modeling – the answer: Mapping database tables to domain classes
The Order domain class includes attributes that really don't seem like they belong in an Order class (see Figure 3). The most likely cause is that the modeler has mapped these domain classes directly from a relational database schema. Figure 4 gives the corrected diagram. The extra attributes have been separated out into their own domain classes (customer account and dispatch).
Note that we'd generally not show the attributes at all during domain modeling.
Figure 3. Order class domain attributes erroneously influenced from database schema
Figure 4. Domain attributes this time in more appropriate classes
In this excerpt we described the first major stage of the ICONIX Process. Domain modeling forms the basis for the whole object modeling activity. The key point here is that you start out with an initial, rough attempt at the domain model before writing the use cases, then refine the domain model (discover new objects, add attributes and operations) as you work your way towards detailed design, tests, and code.
In their next installment Matt and Doug will look at use cases, which are written in the context of the domain model. The next two pieces will examine robustness analysis (preliminary design), which helps tighten up both the domain model and the use case text, bringing the use cases and object model closer together.
Use Case Driven Object Modeling with UML: Theory and Practice is available for purchase through Register Books, at the special price of £34.99.