LARMAN CD MODULES

Module 13

Class Diagrams in the Design Model

Introduction

Up to this point in the CD Modules we have focused on using UML interaction diagrams to look at the dynamic design of how the objects are going to collaborate in terms of messaging. This module focuses more on the static design of the objects, or in other words, the class diagrams in the design model.

This Module shows us how to read and write UML diagram notation and draw class diagrams in the design model.

Design Class Diagrams

The Design Class Diagrams depict software classes, not domain model concepts. You will recall that domain model concepts contain no methods.

The following static class diagrams show two class objects, Register and Sale. The design class diagram is divided into three compartments: the class name in the top compartment, the main attributes in the middle compartment and method names in the bottom compartment. Note that we can hint that the compartment contains information that we are not specifically showing in the diagram by the use of "..." in the compartment. What we are saying here is that this information is not necessarily noteworthy in terms of the class diagram. Also note that we can show more detailed information in the class diagram than the domain concept diagram, such as data types.

Basically, it depends on who your audience is and the purpose of your diagram when choosing how much detail to show. If you are going to use a Case Tool for code generation, then you will need to show all the attribute and method signature details. However, if you are just knocking up a few diagrams on the whiteboard, leave the detailed stuff out.

Design Class Diagrams v Domain Concept Diagrams: Recap

Design Class Diagrams and Domain Concept Diagrams look similar in appearance and therefore it is worthwhile to provide a brief recap of their similarities and their differences before continuing on.

In the Domain Model, the notation of using boxes and lines is used to visualise conceptual classes. You will recall that we referred to this as the visual dictionary to the domain. The important point here is that the perspective is on visualising concepts in the real world domain.

In contrast, the Design Class Model, is used to visualise actual software classes, irrespective of whether they appear as a domain concept or not. Because we are talking about software classes, it is appropriate to add software methods to the model. And here, we can also show reference, or complex, attributes as well as simple attributes, unlike in the Domain Model.

The use of Navigation Arrows to show/imply attribute visibility

You may recall that the previous module discussed the issue of achieving visibility; attribute, parameter, local or global. In the diagram above, the Design Class Model of "Register" doesn't explicitly show an attribute of type "Sale", however the use of an association arrow from Register to Sale implies that register has visibility to one sale object. This is quite common in the UML Design Class Model. Alternatively, you could show it explicitly by an attribute in the Register class such as "currentSale : Sale". This is not as common, but not illegal!

The use of Dependency Arrows to show Temporary visibility

The following diagram shows that Register has temporary visibility to some Product Specification. This only exists while within the scope of a method and then disappears. Note, the author recalls that Dmitry doesn't really like this notation.

Adding Methods to the Design Class Diagram

We can identify the methods we want to show in the Class Diagrams, from the Interaction Diagrams we have already created. The following diagram illustrates a message in an interaction diagram appearing as a method in the Class Diagram. Register sends a MakeLineItem message to a Sale object, therefore, the Sale object must contain a MakeLineItem method. Basically, Register is sending a message to Sale "make me a line item!". Sale, upon receiving the message, must be able to "make it", so Sale must implement a MakeLineItem method. Simple.

Other Design Notation

Showing Templates (relevant only to C++ at the moment)

Attribute Notation - Static attributes, public attributes, private attributes, unspecified attributes, attribute types

We might recall this stuff from doing JBank in CP2004. Larman provides the following UML Diagrams:

• Underline the static attributes
• plus sign for the public attributes
• minus sign for the private attributes
• no sign for when you are not specifying public/private
• colon sign separating attribute and its type
• curly brackets to indicate that this is a final, or constant attribute
• slash sign to indicate that the value is derived not necessarily stored.
• keyword "signal" for capturing exceptions etc.

The Design Class Diagram in the Design Model

So, to summarise this CD Module, the following diagram shows the Design Class Model. It shows the major classes in the domain layer.

Home

Module 1 | Module 5 | Module 6 | Module 7 | Module 8 | Module 9

Module 10 | Module 12 | Module 13 | Module 14