Appendix: Class diagrams

4.1. Overview

A class diagram captures the static relationships of your software.

4.2. Classes

A class is represented by a retangular box divided into compartments. A Compartment is an area in the box to write information. The first compartment holds the name , the second holds the attributes and the third is used for the operations .

Any compartment can be hidden to improve readability of the diagram.

UML suggests that a class name:

• Starts with a capital letter

• is centered in the top compartment

• is written in a boldface font

• is written in italics if the class is abstract

4.3. Attributes

Attributes specifies details of a class and can be simple types or objects.

Attributes can be defined inlined (as part second compartment of the diagram of the class) or as relationship.

4.3.1. Inlined Attributes

Inlined attributes are placed in the second compartment of the class. The notation for inline attribute is:

visibility name: type {multiplicity} {=default}

Table 1.

Element	Values	Description
visibility	+ - # ~	public Attribute private Attribute protected Attribute package Attribute
name	myName	Name of the attribute following the camelCase notation
type		Class name, interface or primitive types, e.g. int
multiplicity		Optional, if not specified then it is assumed to be 1, * for any value, 1,..,* for ranges.
default		Optional, default value of the attribute

4.3.2. Attributes by Relationship

To model attributes by relationship you use an association relationship between the class which represents the attribute and the class containing the attribute.

4.3.3. Static Attributes

Static attributes (attributes that are part of the class and not part of the instance of the class) are displayed via underlining the name of the relationship.

4.4. Interfaces

Interfaces are indicated via the stereotype <> .

Relationships can be expressed via the ball-and-socket notation.

4.5. Relationships

UML defines several ways of representing relationships between classes.

4.5.1. Association

Read as "..has a.." association between classes. Drawn as a straight line between the two classes. Does not mean that the classes are owned by one, other classes may use the connected class too.

4.5.2. Aggregation

Read as "..owns a ..". Not as strong as a composite.

4.5.3. Composition

Strong relationship between classes to the point of containment. Read as "..is part of..". If the owning instance is destroyed then normally (not necessarily) the linked object is destroyed too.

4.5.4. Generalisation

Read as ".. is a..". Use to express inheritance. Represented by a solid line and a hollow triangular arrow. For example the following code could be expressed with the following diagram.

					

package animals;



public abstract class Animal {



}



				

					

package animals;



public class Frog extends Animal {



}



				

4.6. Export your class diagram as image

To export your diagram as image / graphic, right click on your diagram and select File -> Save as Image File.