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