ZEIT2301 Design of Information Systems Structural Design: Class Diagrams School of Engineering and Information Technology 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, 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 Domain Solution Domain Structural Modelling

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, 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, 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, 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, Elements of a Class Diagram NB. Class name should be singular

20 Relationships Describe how classes relate to one another Three basic types in UML 1.Association Relationships between classes 2.Generalization Enables inheritance of attributes and operations 3.Aggregation Relates 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 DepartmentBoss EmployeeChild BossEmployee * 11..* 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 EmployeeDepartment worksFor isHeadOf 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, 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 studentID name changeProgram() Course courseCode description availability checkAvailability() 0..* enrolsIn mark grade Association Class

Session 2, 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 studentID name 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 studentID name 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..* 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, Fig 6.2