html5-img
1 / 18

Analyzing system data: Class diagram

Asper School of Business University of Manitoba. Systems Analysis & Design. Instructor: Bob Travica. Analyzing system data: Class diagram. Updated: October 2013. Outline. Problem domain classes Identifying reality aspects to be represented in information system

nijole
Télécharger la présentation

Analyzing system data: Class diagram

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

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

  4. Identifying aspects to be represented in a system (cont.) CONCEPTS Customer Satisfaction Employee performance Happiness REALITY ASPECTS “THINGS” * PEOPLE IN 3510 Systems Analysis & Design * Bob Travica

  5. Identifying aspects to be represented in system (cont.) • List nounsusers 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

  6. 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

  7. 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

  8. 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

  9. Associations between classes • Associations between reality aspects translate into relationships between classes. CUSTOMER places ORDER is contained in contains PRODUCT A PRODUCT B • 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 3510 Systems Analysis & Design * Bob Travica

  10. Associations betweenMaster 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. Master Data Customer Product X orders Order places contains Transaction Data 3510 Systems Analysis & Design * Bob Travica 3510 Systems Analysis & Design * Bob Travica

  11. Course courseNumber courseTitle creditHours addCourse() 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 elements • Class name • Class attributes • Class behaviors (methods, processes/functions working with data) 3510 Systems Analysis & Design * Bob Travica

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

  13. 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: Each order is placed by just one Customer. One order can contain several Products 1 * (many, as soon as >1) 3510 Systems Analysis & Design * Bob Travica

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

  15. Multiplicity – key attribute design 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, pens, or products in a grocery store). This key could be called “generic key”. In this case, the relationship Order-Item is many-to-many1 (below). Note: In determining multiplicity, it suffices to write maximum number of objects that can participate in a relationship (1..*; *..*; 1:1) 2. 3510 Systems Analysis & Design * Bob Travica

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

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

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

More Related