Where Are The Objects?

Related Sites

Neither class diagrams nor collaboration diagrams take precedence. It does not matter which ones you start with. The important thing is that you should avoid doing too much of one kind, without balancing them with the other kind. Class diagrams cannot stand alone. Neither can collaboration diagrams. They reinforce each other, and need to be developed concurrently with each other.

Failure to develop these diagrams concurrently will result in dynamic models that cannot be supported statically, or static models that cannot be implemented dynamically. Moreover, you will be heavily vested in the models that you have created, and will find it difficult to change them.

[About starting by creating a domain model, and elaborating it to a design:]
I have no trouble with building a domain model as a way to provide vocabulary and precision to the requirements document. But I do not believe that it is prudent to consider the domain model to be the precursor of a design.

Designs based strictly upon the domain model will probably wind up being too concrete; and too tied to the details of the domain. When we design we try to find the overreaching abstractions that make such details irrelevant. In so doing, we create a design that is valid for the class of domains, of which our domain model is just a single instance.

[And in another post:]
Of course this begs the question: "What is the starting point of a design?". The answer: The creative insight of the engineers. By taking a step (or two) back, and looking at the problem (and its environs) from many different angles, the engineers hunt for the abstraction that underlies the problem. This abstraction will then imply a solution. The solution may look nothing at all like the domain model.

Patrick Logan provided an example of how basing a design on the domain model may break code:

For example, many years ago I joined a company that produced software for designing electronics. At the time I joined the industry was moving from gate level design (ANDs and ORs) to hardware description languages that allow abstract data types. All of the existing software was designed specifically for representing digital bits, i.e. 1s and 0s. Even though many of the software modules could have been applied to abstract values, they could not because they were too domain dependent.

This may be an extreme example. Many years earlier, it would have been difficult to anticipate the need for abstraction, not to mention justify the cost of building it into the system. But it serves to illustrate what happens over and over again in all domains: details change, even details that appear to be "central" to the domain.

Robert C. Martin wrote a series of articles about this subject in the C++ Report:

• Analysis by Noun Lists and Use Cases : A Case Study
• The Payroll Case Study: Contrivances and "Real World" Objects
• The Payroll Case Study: Finding the Underlying Abstractions