ZEIT2301Design of Information Systems

Structural Design: Class Diagrams

School of Engineering and Information TechnologyUNSW@ADFA

Dr Kathryn Merrick

2

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

3

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).

Session 2, 2010 4

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

Problem DomainSolution Domain

StructuralModelling

5

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.

6

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

7

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.

Session 2, 2010 8

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 9

Classes, Attributes, & Operations

ClassesTemplates for instances of people, places, or things

AttributesProperties that describe the state of an instance of a class (an object)

OperationsActions or functions that a class can perform

Session 2, 2010 10

Classes

Note the distinction between the Class (generic) and the Object (a specific instance of that class)

11

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)

12

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.

13

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.

14

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.

Visibility

15

Visibility

Public “+” An attribute or operation preceded by a “+” is public & can be

accessed/changed by any other classes Protected “#”

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.

16

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 +

17

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)

18

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

Session 2, 2010 19

Elements of a Class Diagram

NB. Class name should be singular

20

Relationships

Describe how classes relate to one another

Three basic types in UML1. Association

Relationships between classes

2. Generalization Enables inheritance of attributes and operations

3. AggregationRelates parts to wholes

21

Types of Relationships

22

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

23

Association Multiplicities

Department Boss

Employee Child

Boss Employee

1 1

1 0..*

1 1..*

Exactly one:A department has one and only one boss

Zero or more:An employee has zero to many children

One or more:A boss is responsible for one or more employees

24

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.

25

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

Employee DepartmentworksFor

isHeadOf

1..* 1..1

0..11..1

26

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

Session 2, 2010 27

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.

28

Association Class

Student

studentIDname

changeProgram()

Course

courseCodedescriptionavailability

checkAvailability()

0..* 0..*

enrolsIn

enrolsIn

markgrade

AssociationClass

Session 2, 2010 29

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

30

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

31

Generalization

PostGraduate

An open-headed arrow indicates Generalisation in UML

UnderGraduate

researchTopic degreeMajor

Student

studentIDname

getMarks() PostGraduate and UnderGraduate students inherit the attributes and operations of Student

32

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)

33

Student as an abstract class

PostGraduate UnderGraduate

researchTopic degreeMajor

Student

studentIDname

getMarks()

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.

34

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

35

HealthTeam

Aggregation

Doctor

1

Nurse Admin person

1..* 1..1

1

An open diamond indicates general aggregation in UML

36

Summary

Class diagrams show the underlying structure and relationships in an object-oriented system.

Association Relationships between classes e.g. Student enrols in Course

Generalization/specialization 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

37

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

Session 2, 2010 38Fig 6.2