Java Reference
In-Depth Information
3.2.1
Identifying classes, attributes, and relationships
Designing a domain model, like many other software design activities, requires
both a solid understanding of the problem domain as well as a certain amount of
creativity, experience, and common sense. A good way to start is by talking to the
businesspeople who understand the problem domain
and by analyzing the use
cases. Quite often the nouns that are used when describing the problem domain
suggest class names.
Applying UML and Patterns
[Larman 2004] offers an in-depth
discussion of how to identify classes, their attributes, and associations.
Not surprisingly, in the case of the example application, the Food to Go busi-
nesspeople and the Place Order use case both use terms such as Order, Restau-
rant, Menu Item, Coupon, Address, and Payment Information, which are all
plausible classes. Furthermore, we know from past experience that this applica-
tion requires a shopping cart concept, which means that we need some classes to
accumulate information about the order. Analyzing the domain and applying a
small amount of creativity yields the domain model shown in figure 3.3.
This domain model is a simplified version of the one you saw earlier in figure 3.2.
In this version of the domain model, the classes only have attributes and relation-
ships; the methods have not yet been identified. Furthermore, this domain model
only defines entities such as
PendingOrder
and
Restaurant
and value objects such
as
Address
and
TimeRange
. It does not define
PendingOrderRepository
,
Restaurant-
Repository
,
OrderRepository
, or
PlaceOrderService
. Although it would be reason-
able to assume the existence of those classes, we will instead identify them as we
determine the behavior for the domain model classes in the next section.
3.2.2
Adding behavior to the domain model
So far, the classes in the domain model have only attributes and associations. This
is certainly a necessary first step, but we need to bring the domain model to life by
adding behavior. To determine their behavior, we must identify their responsibili-
ties and collaborations. The
responsibility
of a class is what the class does, knows, or
decides and is fulfilled by one or more methods. The domain model in figure 3.1
describes what each class knows because it defines attributes and associations.
What it doesn't describe are responsibilities that concern what each class does or
decides. The
collaborations
of a class are the other classes that it invokes in order to
fulfill its responsibilities. The domain model in figure 3.1 outlines some of the
possible collaborations because it describes associations between classes. However,
as we will see, many more are waiting to be discovered.
Search WWH ::
Custom Search