The document discusses class diagrams and their components for representing a problem domain in a system. It covers identifying the key things or classes to model, the associations and relationships between classes, attributes to describe classes, and different types of associations like generalization/specialization and part-whole relationships.

1. Analyzing system data: Class diagram Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Updated: October 2009

2. Outline Problem domain classes Identifying things to be represented in system Associations among things Multiplicity Attributes Generalization/Specialization association Part-Whole association Associations between class objects 3510 Systems Analysis & Design * Bob Travica of 16

3. Problem domain classes Problem domain Area of business a system supports Classes & objects are the way to represent things that make business (products, orders, invoices, customers, employees…) Identifying and analyzing things in problem domain = essential to defining systems requirements 3510 Systems Analysis & Design * Bob Travica of 16

4. Identifying things to be represented in system 3510 Systems Analysis & Design * Bob Travica of 16 Physical reality - Person who is a customer customerNumber customerName customerAddress … Customer addNew() change() … System - a class Customer

5. Identifying things to be represented in system (cont.) 3510 Systems Analysis & Design * Bob Travica of 16 PEOPLE, OPERATIONS, CONCEPTS,

6. Identifying things to be represented in system (cont.) List nouns users mention when discussing system Event table/use cases as source of potential things: - Use cases (Create new sale) - Actors ( salesperson , customer ) - Triggers, data input (customer’s order ) Responses ( invoice returned) 3510 Systems Analysis & Design * Bob Travica of 16

7. Identifying things to be represented in system – Master and Transaction Data Useful way of thinking: “ Static, permanent things” that make business foundations (employee, department, task, job, inventory, supplier, customer…)  master data versus “ Dynamic, changing things” that make business operations (sales transactions, purchasing transactions, employees’ pay & education, execution of tasks, inventory)  transaction data 3510 Systems Analysis & Design * Bob Travica of 16

8. Associations among things Association = relationship between things Example: Customer places Order Associations apply in both directions Order is placed by Customer 3510 Systems Analysis & Design * Bob Travica of 16

9. Associations among things (cont.) 3510 Systems Analysis & Design * Bob Travica of 16 Arrowheads are used only if reading violates usual direction of reading, which is left-to-right and top-down. Arrange symbols to support usual direction of reading. “ PLACES ” “ WORKS IN ” CUSTOMER EMPLOYEE

10. Associations between Master and Transaction Data A rule of thumb in modeling class diagrams: Master data usually do not connect directly to each other but through transaction data 3510 Systems Analysis & Design * Bob Travica of 16 3510 Systems Analysis & Design * Bob Travica of 16 Customer Order Order Product X Master Data Transaction Data orders places contains

11. Multiplicity (basic idea) 3510 Systems Analysis & Design * Bob Travica of 16 Multiplicity: the number of classes or objects allowed on each side of a relationship (one to many, many to many, one to one) Places 1 order, and can place more. But each order is placed by just one person. Works in 1 dept., while this dept. has other workers as well. CUSTOMER EMPLOYEE “ WORKS IN ” Contains 2 items or more

12. Understanding things -attributes Think of a database record Specific details of things (pieces of data) are called attributes Understanding attributes is part of system analysis Key attribute: uniquely identifies a thing: Social insurance number , product ID , vehicle identification number 3510 Systems Analysis & Design * Bob Travica of 16

13. Attributes 3510 Systems Analysis & Design * Bob Travica of 16 Attributes By providing values to attributes, class is instantiated in objects (objects “carved” out of classes) Classes have attribute names (“skeleton”), objects have attributes specified – values Values

14. Class elements Class name Class attributes Class behaviors (methods, processes/functions working with data) 3510 Systems Analysis & Design * Bob Travica of 16 Class courseNumber courseTitle creditHours Course addCourse()

15. Associations between classes: Generalization/Specialization 3510 Systems Analysis & Design * Bob Travica of 16 Class (Superclass) Subclasses of MotorVehicle Subclasses of Car

16. Associations between classes: Part-Whole 3510 Systems Analysis & Design * Bob Travica of 16 Part classes Whole class

17. Associations between class objects 3510 Systems Analysis & Design * Bob Travica of 16 1 * has Typical relationship involving objects from two classes. Read: A course has sections, and a section belongs to a course. courseNumber courseTitle creditHours Course addCourse() sectionNumber startTime roomNumber Section openSection() closeSection()