Post on 26-Dec-2015
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