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

Outline Problem domain classes Identifying reality aspects to be represented in information system Master and Transactional Data Associations between reality aspects and between Classes Attributes, Values, and Objects Multiplicity Generalization/Specialization association Part-Whole association

3510 Systems Analysis & Design * Bob Travica Identifying aspects of reality to be represented in system Physical reality - a person in the customer role customerNumber customerName customerAddress … Customer addNew() change() … Information System - a class Customer (older term “Entity”)

3510 Systems Analysis & Design * Bob Travica Identifying aspects to be represented in a system (cont.) PEOPLE IN REALITY ASPECTS “THINGS” CONCEPTS CUSTOMER SATISFACTION EMPLOYEE PERFORMANCE HAPPINESS *

3510 Systems Analysis & Design * Bob Travica Identifying aspects to be represented in system (cont.) List nouns users mention when discussing system Event table/use cases as source of aspects of interest: - Use cases (Create new Order) - Actors (Salesperson, Customer) Responses (Create Invoice)

3510 Systems Analysis & Design * Bob Travica Problem domain classes Problem domain= Area of business a system supports Identifying and analyzing aspects within a problem domain = essential to defining systems requirements Problem domain = customer ordering Problem domain classes = Customer, Order, Item

3510 Systems Analysis & Design * Bob Travica Translating reality aspects in two kinds of classes (data) Considering the stable/static vs. dynamic reality aspects, it is useful to differentiate between: Master classes: “Static, permanent aspects” that make business foundations (people in roles, physical things, organizational units – Employee, Department, Task, Job, Product, Supplier, Customer…) Transaction classes: “Dynamic, changing aspects” that make business operations (events -- Customer Order, Purchasing Order, Sale, Payment)

3510 Systems Analysis & Design * Bob Travica Associations between aspects of reality Association = relationship between aspects of reality Example: Customer places Order Associations apply in both directions Order is placed by Customer

3510 Systems Analysis & Design * Bob Travica Associations between classes The normal direction of reading is left-to-right and top-down. If violated, an arrowhead shows the direction. Whenever possible, arrange symbols to support the normal direction of reading Associations between reality aspects translate into relationships between classes. CUSTOMER ORDER PRODUCT APRODUCT B places contains is contained in

3510 Systems Analysis & Design * Bob Travica Associations between Master and Transaction Data A rule of thumb in modeling class diagrams: Master classes usually are not associated directly to each other but through the transaction class Systems Analysis & Design * Bob Travica Customer Order Product X Master Data Transaction Data orders placescontains

3510 Systems Analysis & Design * Bob Travica Details of a reality aspect and class attributes Specific details of an aspect become class attributes (pieces of data) Think of a database record (row) Understanding attributes is part of system analysis Key attribute: uniquely identifies each instance of a class – each Object (courseNumber; underlined) Class name Class attributes Class behaviors (methods, processes/functions working with data) courseNumber courseTitle creditHours Course addCourse() Class elements

3510 Systems Analysis & Design * Bob Travica Attribute values Attributes By specifying values of attributes, class is instantiated in objects. Classes define attributes (names & data types) - “skeleton”; objects are “carved” out of classes. Values

3510 Systems Analysis & Design * Bob Travica Multiplicity Multiplicity: the number of objects allowed on each side of a relationship. Looking from the Order side, the number of associated objects is as follows: 1 * (many, as soon as >1) Each order is placed by just one Customer. One order can contain several Products Note: Multiplicity still unknown on the Order side (two numbers missing). “CONTAINS”

3510 Systems Analysis & Design * Bob Travica Multiplicity Multiplicity, looking from the Customer and Product side, the number of associated objects is as follows: 1 1 * PLACES CONTAINED ON Places one or more orders. Unique Products contained on just one Order.

Multiplicity – key attribute design 3510 Systems Analysis & Design * Bob Travica Consumer electronics is usually keyed on serial number, so that each instance of a product (item) is unique; thus it can appear just on one order. For convenience, this key can be called “unique key”. But a product category can also be keyed (e.g., cables, or grocery products). This key could be called “generic key”. In this case, the relationship Order-Item is many-to-many 1 (below). Note: In determining multiplicity, it suffices to write maximum number of objects that can participate in a relationship (1..*; *..*; 1:1) 2. Graphical aid:

3510 Systems Analysis & Design * Bob Travica Associations between class objects with multiplicity CourseNumber CourseTitle CreditHours Course addCourse() SectionNumber Term StartTime RoomNumber Section openSection() closeSection() 1 * has Typical relationship involving objects from two classes. and each (one) section belongs to one course. A (one) course has many sections, Reading:

3510 Systems Analysis & Design * Bob Travica Associations between classes: Generalization/Specialization Class (Superclass) Subclasses of MotorVehicle Subclasses of Car Multiplicity is usually not specified, but is assumed to be is

3510 Systems Analysis & Design * Bob Travica Associations between classes: Part-Whole Part classes Whole class 1 part of 1 1 part of 1 (*) 1 part of 1 This part-whole association is called composition, or bill-of-materials. It shows parts that make a computer.