ISOM221+Lecture+15+-+Class+Diagram - Agenda ISOM221...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Agenda ISOM221 Information Systems Analysis and Design Lecture 15: Class Diagram • Basic concepts of object modeling • Key components of class diagram • Building class diagram based on use cases 1 2 Introduction to Object Modeling • Object-oriented analysis (OOA) – an approach used to – study existing objects to see if they can be reused or adapted for new uses – define new or modified objects that will be combined with existing objects into a useful business computing application Class and Objects • A class is a general template we use to define and create specific instances or objects – A class is an entity (person, place or thing) – It has attributes and methods • An object is an instance of a class – Each object has attributes, which describe the object – Each object has behaviors — things that they can do — which are described by methods 3 4 • Object modeling – a technique for identifying objects within the systems environment and the relationships between those objects Classes, Attributes, & Methods • Classes - Templates for instances of people, places, or things Classes and Objects Example • Attributes - Properties that describe the state of an instance of a class (an object) • Methods - Actions or functions that a class can perform 5 6 Attributes and Methods • Units of information relevant to the description of classes – Attributes are information about or characteristics of classes – Only attributes important to the task should be included – For example: Name, Address, Phone Number, etc. for Customer class Attribute Visibility • Attribute visibility can be specified in the class diagram – Public attributes (+) are visible to all classes – Private attributes (-) are visible only to an instance of the class in which they are defined – Protected attributes (#) are like private attributes, but are also visible to descendant classes • Methods represent behavior, functions or operations of a class – Responsible for managing the value of attributes such as querying, updating, reading and writing – Focus on relevant problem-specific operations – Examples: +Insert(), +Delete() 7 • Visibility helps restrict access to the attributes and thus ensure consistency and integrity 8 Encapsulation and Information Hiding • Encapsulation is simply the combination of process and data into a single entity • The principle of information hiding suggests that only the information required to use a software module be published to the user of the module – Attributes can only be accessed and updated via methods – Other classes can call upon a class’s methods 9 Messages and Methods • Messages are information sent to objects to trigger methods – Procedure call from one object to another 10 Polymorphism • The same message can be interpreted differently by different classes of objects Inheritance • Inheritance – the concept wherein methods and/or attributes defined in a class (i.e., superclass) can be inherited or reused by another class (i.e., subclass) 11 12 Example of Inheritance Agenda • Basic concepts of object modeling • Key components of class diagram • Building class diagram based on use cases 13 14 Class Diagram • A key UML structure diagram • Shows the structure of data used in the system • Shows the classes and relationships among classes classes that remain constant in the system over time • Similar to the ERD, but depicts classes which include both attributes and methods, while entities in the ERD include only attributes • Scope of a class diagram, like the ERD, is systemwide 15 Relationships • Describe how classes relate to one another • Three basic types in UML 1. Association (which will be mainly used in this course) course) Miscellaneous relationships between classes 2. Generalization Enables inheritance of attributes and operations 3. Aggregation and Composition Relates parts to wholes 16 Association • A relationship between the two classes • There is an association between two classes if an instance of one class must know about the other other in order to perform its work • Multiplicity denotes the range of allowable associated classes Examples of Association 17 18 Multiplicity • Multiplicity specifies the range of allowable associated classes (i.e., lower and upper bound) – Shows how an instance of an object can be associated with other instances Multiplicity (cont.) • Multiplicity values – 0..1: no instance or one instance (zero or one, optional one) – 1: exactly one instance (one only, mandatory one) – 0..* or *: zero or more instances (zero or more, optional many) – 1..*: one or more instances (one or more, mandatory many) – 5: exactly five 19 20 Exercises on Multiplicity Student takes Course Generalization • An inheritance link indicating one class is a superclass of the other • A generalization has a triangle pointing to the superclass superclass Department offers Course Professor teaches Course 21 22 Examples of Generalization Aggregation and Composition • Aggregation and composition are also called “Apart-of relationship” • Represents the situation where a class consists of several component classes logically (for aggregation) aggregation) or physically (for composition) • Aggregation and composition have a diamond end pointing to the part containing the whole • Some UML experts suggest the inclusion of aggregation and composition to the class diagram is not necessary, as the same information can be simply described by an association 23 24 Example of Aggregation (Logical) This is an “A-part-of relationship” Example of Composition (Physical) This is an “A-part-of relationship” It can be simply described by an association It can be simply described by an association 25 26 Elements of a Class Diagram Elements of Class Diagrams (cont.) 27 28 Sample Class Diagram Agenda • Basic concepts of object modeling • Key components of class diagram • Building class diagram based on use cases 29 30 Steps to Build a Class Diagram Based on Use Cases 1. Determine the goal of each of use cases – E.g., The goal of the use case “Make appointment” is to let a patient book an appointment with a doctor E.g., DOCTOR, APPOINTMENT, PATIENT APPOINTMENT *APP_appointmentID APP_date APP_time APP_duration APP_reason PATIENT *PAT_patientID PAT_firstname PAT_lastname PAT_phone PAT_address PAT_birthdate 31 2. Identify entities using the goal of use cases – 3. Specify entities as classes and their features as attributes of the classes in a class diagram 4. Specify relationships between entities as associations between classes 5. Identify collaboration between use cases and entities – What the use case needs to do with each entity? – For example: • • • The use case “Register new patient” needs to insert a new record to the PATIENT entity The use case “Cancel appointment” needs to delete a record in the APPOINTMENT entity <continue on next page> 32 DOCTOR *DOC_doctorID DOC_firstname DOC_lastname DOC_phone DOC_address DOC_specialty has/ includes schedule/ is scheduled by An entity-relationship diagram (ERD) Sample Class Diagram • • The use case “Update doctor information” needs to update a record in the DOCTOR entity The use case “Remind patient of appointment” needs to read patient’s contact information from the PATIENT entity and the appointment record from the APPOINTMENT entity in order to send a reminder to a patient The use case “Manage appointment” needs to print an appointment list for a particular date DOCTOR - DOC_doctorID - DOC_firstname - DOC_lastname - DOC_phone - DOC_address - DOC_specialty + Insert() + Update() + Read() APPOINTMENT - APP_appointmentID - APP_date - APP_time - APP_duration - APP_reason + Insert() + Update() + Read() + Delete() + Print_AppointmentList() + Send_Reminder() PATIENT - PAT_patientID - PAT_firstname - PAT_lastname - PAT_phone - PAT_address - PAT_birthdate + Insert() + Update() + Read() has 1 1..* schedules 1..* 1 • 6. Specify collaboration as methods of classes If the record of doctor will never be deleted, there will be no “delete()” method 33 A higher-level method can be created to handle a specific task, given that the task is relevant to the class 34 Exercise • Consider the following use cases and do the following: – Identify classes, attributes, and methods – Draw a class diagram Student Use Case Diagram Campus Housing System UC-100 Search Apartments UC-200 Add Apartments UC-300 Delete Apartments Service Staff Owner 35 36 Use Case ID Use Case Actors Description UC-100 Search for Apartments (P) Student The student logs into the campus housing system with preregistered username and password. The student makes a selection from the available choices to search for apartment. Once in the search screen, the student is prompted to enter the desired location, number of bedrooms, and price range. The system will check for availability of apartments that match the student’s criteria. Provided that matched apartments are found, the system provides a listing of matched apartments and the contact information of the apartment owner. The student reviews the results and may add the apartment(s) to his/her shortlisting record with the date specified (the student can shortlist up to 10 apartments). / / / / 37 Use Case ID Use Case Actors Description UC-200 Add Apartments (P) Owner (S) Service Staff The apartment owner requests a form to list an apartment for rent. The service staff provides the form to the owner. The owner fills in the form, providing his/her contact information and information about the location, number of bedrooms, and monthly rent of the apartment. The service staff adds the apartment (with the posting date) to the database. Priority Non-Functional Requirements Assumptions Source / / / / 38 Priority Non-Functional Requirements Assumptions Source Use Case ID Use Case Actors Description UC-300 Delete Apartments (P) Owner (S) Service Staff The apartment owner calls the service staff to delete his/her listing when the apartment has been rented. The service staff deletes the apartment from the database accordingly. If the apartment has been shortlisted by any student, the corresponding entry in the shortlisting record will be marked as “expired”. What are the Classes Identified from Each Use Case? • UC-100 Search for Apartments • UC-200 Add Apartments Priority Non-Functional Requirements Assumptions Source / / / / • UC-300 Delete Apartments 39 40 What are the Attributes for Each Class? What are the Methods for Each Class? 41 42 Class Diagram Summary • After today’s class, you should – Be familiar with the concepts of object modeling – Be able to create class diagrams based on use cases cases 43 44 Next Class • Interaction Diagrams • Reading: – Textbook Ch. 7 45 ...
View Full Document

This note was uploaded on 12/22/2010 for the course ISOM ISOM221 taught by Professor Sheunhhee during the Spring '09 term at HKUST.

Ask a homework question - tutors are online