ZEIT2301
Design of Information Systems
Structural Design:
Class Diagrams
School of Engineering and Information Technology
UNSW@ADFA
Dr Kathryn Merrick
Week 05: Structural Modelling

Objectives



To appreciate the role of the class diagram as a structural
model of an information system
To consider how classes are “discovered” in the problem
domain
To examine the notation and syntax of class diagrams
Reference: Dennis et al, Chapter 6
2
Structural Modelling

A structural model describes the structure of the
data that supports the business processes

In the Analysis phase - the structural model presents the
logical (ie business centric) organization of data.

In the Design phase - the structural model is updated to
reflect the actual physical storage of data (e.g. in databases,
files).
3
Structural Models
Main goal: to discover the key data contained in the
problem domain and to build a structural model of the
objects to be represented
Structural
Modelling
Solution Domain
Problem Domain
Session 2, 2010
4
Purpose of Structural Models

Structural models represent the:

elements (entities, objects, things, etc) about which
information needs to be captured,
and ….

the relationship between those objects.
5
Class Diagrams

Class diagrams are the principal structural model used
in O-O analysis & design.

The basic elements of a Class Diagram are:

Classes

Attributes

Relationships
6
Classes

Classes may be classified according to the type of real-world “thing”
they represent

Initially, the analyst is primarily concerned with application (problem)
domain classes
eg. Patient, Appointment, Doctor
eg. Student, Course, Enrolment


Later, concerns are for more physical types of classes (e.g. user
interface classes)
In this course we are primarily concerned with the former.
7
Classes

Classes are templates for creating instances
(Objects).

Example:

When a new patient makes an appointment, the Patient
class is used to create a new patient object which stores the
details (i.e. attributes - name, address, …) of that particular
patient (ie instance of the Patient class).
Session 2, 2010
8
Classes, Attributes, & Operations
Classes
Templates for instances of people, places,
or things
Attributes
Properties that describe the state of an
instance of a class (an object)
Operations
Actions or functions that a class can perform
Session 2, 2010
9
Classes
Note the distinction between the Class (generic) and the
Session 2, 2010
Object
(a specific instance of that class)
10
Attributes

Attributes – units of information relevant to the description of
the class in the problem domain

Attributes should be primitive or atomic data types

e.g. integers, real numbers, strings (of characters), dates,
boolean (T/F), etc

Compound attributes typically indicate a relationship to another
class (& should be modelled as a relationship, not an attribute)
11
Compound Attributes

Consider the Student class - attributes might be:






studentID
name
DOB
phoneNo
course (courseCode, courseName, level, ….)
The fact that we wish to store several items of information about
course indicates it should be a class in its own right with a
relationship to the student class.
12
Derived Attributes

Derived attributes start with a leading slash (“/”)

for example: /age



age can be calculated from DOB & current date; it does
not need to be stored with the object (nor updated
annually)
It is still shown on the class diagram, to remind us that it is
a relevant data item
Data items may be described in a data dictionary. For
derived data, this will include the method of calculation.
13
Visibility

Attributes and operations of a class can have a visibility.

Visibility - indicates the access allowed to an attribute or
operation.

This helps enforce the Object-Oriented concepts of
encapsulation and information hiding.
14
Visibility

Public “+”


Protected “#”


An attribute or operation preceded by a “+” is public & can be
accessed/changed by any other classes
An attribute or operation preceded by a “#” is hidden from all other
classes, except its immediate sub-classes.
Private “-”

An attribute or operation preceded by a “–” is hidden from all other
classes.
15
Attribute and Operation Visibility

Visibility is more relevant to later stages of development.

In the analysis phase:


attributes can be given the default visibility of hidden operations the default visibility of public +
16
Operations

Operations - actions that classes can take

Operations define the behaviour of the class

In later phases of system development, operations are
further refined (to cater for implementation issues) and
converted to methods (program code)
17
Operations

In the analysis phase:

focus on relevant problem-specific operations, e.g.
makeAppointment(), payBill(),

rather than more implementation related operations such
as:




create new object
delete object
set attribute value
update attribute value, etc
18
Elements of a Class Diagram
NB. Class name should be singular
Session 2, 2010
19
Relationships

Describe how classes relate to one another

Three basic types in UML
1.
2.
3.
Association
Relationships between classes
Generalization
Enables inheritance of attributes and operations
Aggregation
Relates parts to wholes
20
Types of Relationships
21
Association Multiplicity

Multiplicity constraint specifies how many instances of one
class can associate with instances of another class

Has implications for actual implementation of classes later
on in the development process
22
Association Multiplicities
Department
1
Exactly one:
A department has one
and only one boss
Child
Zero or more:
An employee has zero
to many children
1
Employee
1
Boss
0..*
Boss
Employee
1
1..*
One or more:
A boss is responsible for
one or more employees
23
Associations

Sometimes, you may have more than one association
between classes

Consider employees who work for a department where
one of those employees is the head of the department.
24
1..*
worksFor
1..1
Employee
Department
1..1




isHeadOf
0..1
An Employee works for 1 Department.
A Department employs 1 or more Employees
An Employee is optionally head of 1 Department
A Department is headed by exactly 1 Employee
25
An Association Class

Occasionally, a relationship itself may have associated properties,
especially when classes share a many-to-many relationship.

This association class may have its own attributes and operations.

Shown as another class attached to the association by a dashed line
26
An Association Class


Consider students enrolling in courses.
This is a many-to-many relationship.


A student may enrol in several courses and a particular course may
have many enrolled students.
But the “mark” and “grade” awarded apply to a particular student in a
particular course


They are attributes of the “enrols in” relationship.
Not attributes of Student or Course.
Session 2, 2010
27
Association Class
Course
Student
studentID
name
enrolsIn
0..*
0..*
changeProgram()
courseCode
description
availability
checkAvailability()
Association
Class
enrolsIn
mark
grade
28
Generalization/Specialization

Generalization


Abstracting common elements shared by a set of classes into a
superclass
Specialization

Creating a subclass from an existing superclass by defining
elements (attributes, operations) that are too specific for the parent
class
Session 2, 2010
29
Generalization

A generalization may be used to model “is a kind of” relationships
between classes



A postgraduate student “is a kind of” student
An undergraduate student “is a kind of” student
With generalization a subclass inherits attributes/operations from
a superclass

Plus may have its own unique attributes/operations
30
Generalization
Student
studentID
name
getMarks()
PostGraduate
researchTopic
An open-headed arrow
indicates Generalisation in
UML
PostGraduate and
UnderGraduate students
inherit the attributes and
operations of Student
UnderGraduate
degreeMajor
31
Classes

Classes may be classified as either:


Concrete – used to create objects (e.g. the Student class
in the previous example)
Abstract – a useful abstraction (e.g. if Student is the
superclass of Postgraduate and Undergraduate; we may
not ever create Student objects, but rather only create and
use postgraduate and undergraduate objects)
32
Student as an
abstract class
Student
studentID
name
getMarks()
PostGraduate
researchTopic
UnderGraduate
degreeMajor
If all students are
either
postgraduate
students or
undergraduate
students, then
Student is an
abstract class.
When we create
an instance of
PG or UG
student, they are
automatically
instances of
Student.
33
Aggregation/Composition

Aggregation represents the relationship of a whole to a part.



where the parts can also exist independently
Composition – parts (physical) cannot exist independently eg parts of
a TV
Aggregation classes comprise other classes




A doctor is part of the Health team
A nurse is part of the Health team
Admin personnel are part of the Health team
But doctor, nurse, Admin personnel can also exist independently
as classes
34
Aggregation
HealthTeam
1
1
Doctor
An open diamond
indicates general
aggregation in UML
1..*
1..1
Nurse
Admin
person
35
Summary

Class diagrams show the underlying structure and relationships in an
object-oriented system.

Association



Generalization/specialization



Relationships between classes
e.g. Student enrols in Course
Superclass/subclass: Enables inheritance of attributes and operations
e.g. Undergraduate Student is a kind of Student
Aggregation/Composition


Relates parts to wholes
e.g. Engine is part of a Car
36
Exercise
Spend a few minutes studying the model
on the next slide.
Look for:
• Attributes
• Operations
• Relations:
• Generalization
• Aggregation
• Association classes
• Note the recursive relationship
• Visibility
• Multiplicities
c
37
Session 2, 2010
Fig 6.2
38