Structure
After having established the classes in the system, the structure will now be defined with the
use of a class diagram.
Theory
The purpose of the class diagram is to describe structural relations between objects and classes
in a problem domain (Lars Mathiassen, 2000, p. 71). The structural relations are different for
the classes and objects which will be described below.
Class structures
The relations between the classes are abstract, static and general, and can consist of a
generalisation. A generalisation is a general class that describes the properties that are common
for a group of subclasses. Generalisations can be expressed linguistically using the formulation
“is-a”. The subclasses inherits all of the properties and behaviors that the super-class contains
(Lars Mathiassen, 2000, p. 75). A class is abstract if it has no related objects. These classes are
used for descriptive reasons and the class names are written in italic (Lars Mathiassen, 2000,
p. 73).
Object structures
The relations between objects are – opposite to classes – specific and dynamic, and consists of
either an aggregation or an association. An aggregation structure means that one object is a
fundamental and defining part of the other (Lars Mathiassen, 2000, p. 77). Aggregations can be
expressed linguistically using the formulation “has-a” (Lars Mathiassen, 2000, p. 78). Likewise
the classes that are aggregated can be linguistically expressed as “part-of” or “owned-by” (see
figure 4.2).
An association structure is much like the aggregation structure, but the difference is that the
associated objects are not fundamental and defining for one another. Therefore the association
structure is often used when an aggregation structure would imply a too strong relation
(Lars Mathiassen, 2000, p. 79). The association structure can be linguistically expressed as
“knows” or “associated with”.
When creating the class diagram it is important to numerate the possible relations. If for
example object A is an aggregation of zero or more object B’s, this is denoted by “0..*”
(Lars Mathiassen, 2000, p. 78).
Creating class diagrams
When the class diagram is being created it is important to only model the necessary structural
relations (Lars Mathiassen, 2000, p. 86). Likewise the use of generalisations and aggregations should only be applied when they add anything relevant to the description. The names,
concepts, and structural relations should reflect the users’ understanding of the problem domain.
But they do not necessarily have to be completely identical (Lars Mathiassen, 2000, p. 87).
Though the best case scenario would be that the problem domain reflects a future user’s
understanding of the problem domain.
The graphical notation of the relation structures between classes is illustrated in figure 4.2.
Figure 4.2. Graphical notations of structures
Class Diagram Analysis example
In section 4.1.2 we described that our problem domain contains four classes: Employee, Manager,
Team, and Questionnaire. The employee and manager classes could be described as roles for a
new general class user. The validity of this choice is tested using the linguistic formulation for
aggregations “has-a” and the linguistic formulation for generalisations, “is-a”. So “a user has a
role” and “a manager is a role”. This confirms that these classes can be roles of a class called
user. There are no objects related to Role so this is an abstract class, and the class name is
therefore written in italic in the class diagram.
The primary job for the manager is to compose new teams. The relation between the manager
class and the team class could therefore be described as an association. They have a meaningful
relation but one object is not fundamental or defining of the other. This relation is linguistically
expressed as “a manager is associated with a team”. One team can be managed by one or more
managers, while one manager manages zero or more teams. This is respectively denoted as
“1..*” and “0..*” in the class diagram.
The Team class could be described as an aggregation of employee-objects, because the selected
employees make up a specific team. Without these employees there would not be a team. The
validity of this choice could be tested by using the linguistic formulation for aggregations, “hasa” or “is-part-of”. So “a team has an employee” and “an employee is part of a team”. One
employee can be part of zero or more teams, while one team requires two or more employees.
The employees fill out questionnaires in order for the managers to collect data about the
employees competences and personality types. For this reason the employee class is associated
with the questionnaire class. There are multiple types of questionnaires based on the employees
fields of work. For this reason one employee is associated with one or more questionnaires, and
one questionnaire is associated with many employees.
The managers create the questionnaires, which is why the manager class are related to the
questionnaire class. The managers are not a defining property of the questionnaire objects and
vice versa. For this reason the relation is an association structure, and not an aggregation
structure. One manager can be associated with zero or more questionnaires, while one questionnaire is associated with at least one manager.
The managers manage the employees which is why they are related. Like the manager and
questionnaire relation, the managers are not a defining property for the employees, which is
why the relation is an association structure. One manager can manage zero or more employees,
and one employee can have zero or more managers.
This results in the class diagram shown in figure 4.3.
Figure 4.3. Class diagram for the problem domain