ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and...
-
Upload
darrell-griffin -
Category
Documents
-
view
215 -
download
0
Transcript of ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and...
![Page 1: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/1.jpg)
ZEIT2301Design of Information Systems
Structural Design: Class Diagrams
School of Engineering and Information TechnologyUNSW@ADFA
Dr Kathryn Merrick
![Page 2: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/2.jpg)
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
![Page 3: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/3.jpg)
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).
![Page 4: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/4.jpg)
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
![Page 5: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/5.jpg)
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.
![Page 6: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/6.jpg)
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
![Page 7: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/7.jpg)
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.
![Page 8: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/8.jpg)
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).
![Page 9: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/9.jpg)
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
![Page 10: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/10.jpg)
Session 2, 2010 10
Classes
Note the distinction between the Class (generic) and the Object (a specific instance of that class)
![Page 11: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/11.jpg)
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)
![Page 12: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/12.jpg)
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.
![Page 13: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/13.jpg)
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.
![Page 14: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/14.jpg)
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
![Page 15: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/15.jpg)
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.
![Page 16: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/16.jpg)
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 +
![Page 17: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/17.jpg)
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)
![Page 18: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/18.jpg)
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
![Page 19: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/19.jpg)
Session 2, 2010 19
Elements of a Class Diagram
NB. Class name should be singular
![Page 20: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/20.jpg)
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
![Page 21: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/21.jpg)
21
Types of Relationships
![Page 22: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/22.jpg)
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
![Page 23: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/23.jpg)
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
![Page 24: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/24.jpg)
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.
![Page 25: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/25.jpg)
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
![Page 26: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/26.jpg)
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
![Page 27: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/27.jpg)
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.
![Page 28: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/28.jpg)
28
Association Class
Student
studentIDname
changeProgram()
Course
courseCodedescriptionavailability
checkAvailability()
0..* 0..*
enrolsIn
enrolsIn
markgrade
AssociationClass
![Page 29: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/29.jpg)
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
![Page 30: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/30.jpg)
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
![Page 31: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/31.jpg)
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
![Page 32: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/32.jpg)
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)
![Page 33: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/33.jpg)
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.
![Page 34: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/34.jpg)
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
![Page 35: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/35.jpg)
35
HealthTeam
Aggregation
Doctor
1
Nurse Admin person
1..* 1..1
1
An open diamond indicates general aggregation in UML
![Page 36: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/36.jpg)
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
![Page 37: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/37.jpg)
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
![Page 38: ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick.](https://reader036.fdocuments.us/reader036/viewer/2022062421/56649e175503460f94b033b0/html5/thumbnails/38.jpg)
Session 2, 2010 38Fig 6.2