Class diagrams describe the types of objects in the system and the various kinds of static relationships that exist among them. There are two principal kinds of static relationships:
An example of a Class Diagram.
A short asside on perspectives. The way class diagrams are interpreted depends on your perspective. There are three:
The diagrams represent concepts in the domain under study. Class diagrams are made with little or no regard for the software that may implement them. It is a "language-independent" view at the highest abstraction level.
The class diagram looks at the software but just the interfaces. The implementation is not considered. A type can have many classes and a class can implement many types. The concept of a class in an Object Oriented language combines both interface and implementation.
The inside details of classes are examined: Methods and Attributes.
Perspective is not part of UML but it is important to keep in mind when considering class diagrams.
Associations represent relationships between instances of classes (a person works for a company; a company has a number of offices). Each association has two association ends; each end is attached to one of the classes in the association. An end can be explicitly named with a label. This label is called a role name. (Association ends are often called roles. An association end also has multiplicity which is an indication of how many objects may participate in the given relationship. The figure above shows these. The * represents the range 0..infinity.
From the conceptual perspective, associations represent conceptual relationships between classes. Within the specification perspective, associations represent responsibilities. If this were an implementation perspective model, we would now imply that there are pointers in both directions between related classes.
Attributes are very similar to associations. At the conceptual level, a Customer's name attribute indicates that Customers have names. At the specification level, this attribute indicates that a Customer object can tell you its name and has a way of setting a name. At the implementation level, a Customer has a field (also called an instance variable or a data member) for its name.
The UML syntax is
visibility name: type = defaultValue
operations are the processes that a class knows to carry out. Operations
most obviously correspond to the methods on a class. At the specification
level, operations correspond to public methods on a type. Normally, you
don't show those operations that simply manipulate attributes, because
they can usually be inferred. The full UML syntax for operations is
visibility name (paramter-list): return-type-expression {property-string}
where
visibility is +(public), #(protected), or -(private)name is stringparameter-list contains comma-separated parameters whose syntax
is similar to that for attributes: direction name: type =
default value. The only extra element is direction,
which is used to show whether the parameter is used for input (in),
output (out), or both (inout). If there is no
direction value, it's assumed to be in.
return-type-expression is a comma-separated list of
return types. Mose people use only one return type, but multiple return
types are allowed.property-string indicates property values that
apply to the given operation.+ balanceOn (date: Date):Money
.
A typical example of generalization involves the personal and coporate customers of a business. They have differences but also many similarities. The similarities can be placed in a general Customer class (the supertype), with Personal Customer and Corporate Customer as sub-types.
Classification refers to the relationship between an object and its type. See the Multiple Classification figure. Most methods make certain assumptions about this type of relationship -- assumptions that are also present in mainstream OO programming languages. The assumption is of single, static classification of objects. A newer suggestion is to use multiple, dynamic classification of objects for conceptual models. In single classification, and object belongs to a single type, which may inherit from supertypes. In multiple classification, and object may be described by several types that are not necessarily connected by inheritance.
To describe Aggregation and Composition refer to the following figure. Aggregation is the "part-of" relationship. A stronger variety of aggregation is called composition. With composition, the part object may belong to only one whole and the parts are usually expected to live and die with the whole. Consider the diagram above. The compositions to Point indicate that any instance of Point may be in either a Polygon or a Circle, but not both. An instance of Style, however, may be shared by many Polygons and Circles. Furthermore, this implies that deleting a Polygon would cause its associated Points to be deleted, but NOT the associate Style.
