Consider as a single class or attribute/operation of existing class?

Question

There are different methods for recognizing classes in UP methodology:

1. noun/verb analysis
2. using CRC analysis
3. using RUP stereotypes
4. other sources

I have read above methods fully detailed in UML 2 and the Unified Process_ Practical Object-Oriented Analysis and Design (2nd Edition)-Addison-Wesley Professional (2005) book.

Definition: There are some ambiguity considering something as a single class or attribute of the existing class.

Suppose we have goods transportation system with the following obvious classes:

1. driver
2. system admin
3. goods
4. order
5. customer
6. etc.

In this system the customer should see the live location of the driver, who transports his/her order.

The problem is that we don't know consider the location like longitude and latitude as driver's attributes (and its functionality as operations) or consider it as single class which has relationship with driver class.

Question: Is there any method for finding the solution and clarifying this kind of ambiguity?

Answer 1

This RUP process as you described it follows a BDUF approach which is IMHO not well-suited for making detailed design decisions like "should longitude/latitude just be two attributes, or should it become a class on its own".

A process which can make such design decisions is the following one:

• start with two attributes in the driver class

• then implement some of the behaviour in code (for example, using tests, maybe by test driven development)

• if during the implementation, one finds out that there are sensible operations working with the pairs longitude/latitude alone (like copying them around, transforming them into a different coordinate systems, or whatever the system requires), then refactor them into a separate class.

If your system does not require such operations, leave the attributes where they are.

The classes found during an initial "analysis phase" maybe a good start to work with, but the classes your system really requires are often found in an iterative process "analyse a little - design a little - implement a little - test a little - refactor".

So if you want to achieve a sensible design, do yourself a favor and replace any waterfall approach by a more iterative development process. Without the necessary feedback loops you cannot really make good design decisions.

Answer 2

The semantics is the same.

It's a diagramming choice: you can communicate how you see things or how you would like to see things:

• You may define a "property" (UML terminology for attribute), e.g. x: MyType
• You may instead use an association with the class MyType, showing x at the association end. Preferably you should use the dot notation to show ownership.
• Multiplicities can be used in both cases, as long as it's 1 on the A side. As soon as this is no longer true, you have to consider the association instead of the property.

As indicated on the weblink above:

Attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line arrow notation to make it perfectly clear that the attribute is also an association end.

How to chose the representation ?

The following practice can guide you (but it's a personal practice, not an official recommendation):

• when objects of a class have their own identity, e.g. when the same object an be referred to from several places, always use an association with the class.
• when a class is complex objects with complex behavior, use the association as well.
• when objects are simple "value objects", i.e. when you don't care about unique objects and they are fully defined by the combination of values of their properties, prefer to show them as poperties.

Another (compatible) practice is to use the stereotype «datatype» for classes that you intent to use for attributes in other diagrams, just to better communicate your intent.