1. January 200592.3913 Ron McFadyen1 Domain Models Domain Model: a visual representation of conceptual classes or real-world objects in a domain of interest Domain models are also called conceptual models, domain object models, analysis object models Domain models are illustrated with a class diagram containing Conceptual classes Associations Attributes

2. January 200592.3913 Ron McFadyen2 Domain model

3. January 200592.3913 Ron McFadyen3 Figure 10.4 Conceptual class has a symbol, intension, extension

4. January 200592.3913 Ron McFadyen4 Section 10.2 Identifying conceptual classes Simple cash-only Process Sale scenario 1. Customer arrives at a POS checkout with goods and/or services to purchase 2. Cashier starts a new sale 3. Cashier enters item identifier 4. System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done 5. System presents total with taxes calculated 6. Cashier tells customer the total and asks for payment 7. Customer pays and System handles payment...

5. January 200592.3913 Ron McFadyen5 Main Success Scenario 1. Customer arrives at a POS checkout with goods and/or services to purchase 2. Cashier starts a new sale 3. Cashier enters item identifier 4. System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done 5. System presents total with taxes calculated 6. Cashier tells customer the total and asks for payment 7. Customer pays and System handles payment 8.System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and inventory systems (to update inventory) 9.System presents receipt 10.Customer leaves with receipt and goods (if any)...

6. January 200592.3913 Ron McFadyen6 Main Success Scenario Price running total total taxes payment Accounting commissions inventory receipt Customer checkout goods services Cashier sale item identifier System sale line item item description

7. January 200592.3913 Ron McFadyen7 Register Item Store Sale Payment Product Catalog Product Specification Sales Line Item Cashier Customer Manager Section 10.3 Candidate Conceptual Classes No “correct” list

8. January 200592.3913 Ron McFadyen8 Draw the conceptual classes in the domain model Add associations necessary to record relationships for which there is some need to preserve some memory Add attributes Section 10.4 Domain Modeling

9. January 200592.3913 Ron McFadyen9 Specification (Description) conceptual classes Include a specification class when we need a description of something irrespective of its existence deletions result in loss of information it reduces duplicated information Sale SaleLineItemProductSpecification We need Product Specifications … and we’ll need them in a catalog …

10. January 200592.3913 Ron McFadyen10 Specification (Description) conceptual classes A university will have a catalog that contains descriptions of courses. Student EnrollmentCourseSpecification We need Course Specifications … and we’ll need them in a catalog

11. January 200592.3913 Ron McFadyen11 Lowering the Representational Gap Domain Model provides a visual dictionary of the domain vocabulary and concepts

12. January 200592.3913 Ron McFadyen12 Classes are usually derived from: Where Examples thingsbook, copy, course, student, building roleslibrary member, student, director of students, admissions clerk eventsarrival, leaving, request interactionsmeeting Good object oriented design results in a class model which does not distort the conceptual reality of the domain

13. January 200592.3913 Ron McFadyen13 Classes are usually derived from: Where NextGen POS thingsregister, item rolescashier eventssale

14. January 200592.3913 Ron McFadyen14 Associations correspond to verbs expressing a relationship between classes objects do not exist in isolation - they fit together in some way examples: a Library Member borrows a Copy of a Book a Person works for a Company An employee is supervised by an employee Multiplicities we indicate via multiplicities the range of allowable cardinalities for participation in an association examples: 1, 1..*, 0..*, 1..3

15. January 200592.3913 Ron McFadyen15 Associations PersonCompany 1..* 1 MemberBook * * * 0,1 Employee

16. January 200592.3913 Ron McFadyen16 Associations Names and roles you can name the relationship and indicate how to read it you can give role names for participating objects PersonCompany Works for 1..* 1 employer employee The role of a Person in this relationship The role of a Company in this relationship The name of the relationship and the direction for reading the name

17. January 200592.3913 Ron McFadyen17 Associations PersonCompany 1..* 1 MemberBook * * * 0,1 Employee reports to supervised supervisor borrower borrows Works for employee employer

18. January 200592.3913 Ron McFadyen18 Attributes an object contains data which are defined as part of the Class definition examples: Students have names, addresses, etc; Courses have titles, descriptions, prerequisite information. Rectangle corner: Point Student name: string address: string

19. January 200592.3913 Ron McFadyen19 attributes are preferably primitive (or just data types) boolean, date, number, string,... Invoice invDate: date Attributes

20. January 200592.3913 Ron McFadyen20 Attributes show only “simple” relatively primitive types as attributes connections to other concepts are to be represented as associations, not attributes we do not show attributes that would be implementations of associations example: an Invoice would not have an attribute for Customer; that is handled by the association between Customer and Invoice Invoice invDate: date Customer name: string address: string

21. January 200592.3913 Ron McFadyen21 Non-primitive types where the associated things don’t need to be distinguished, such as phone number, quantities, points … the abstraction makes sense in the problem domain a phone number has many parts an item number that has subparts in its encoding price is a Currency amount is a Currency qty_ordered is a Quantity these make sense in the problem domain the calculation: price * qty_ordered makes sense Attributes

22. January 200592.3913 Ron McFadyen22 An Invoice will have a grand total Each Invoice Line will have a quantity ordered and a subtotal InvLine amount: Currency qty_ordered: Quantity Quantity amount: Number Invoice invDate: date amount: Currency Attributes Currency amount: Number

23. January 200592.3913 Ron McFadyen23 No Foreign Keys as attributes in the Domain Model foreign keys are considered later in design example: an Invoice is not shown with an attribute for Customer; that is handled by the association between Customer and Invoice Invoice invDate: date Customer name: string address: string Attributes

24. January 200592.3913 Ron McFadyen24 Derived attributes the UML notation is to prefix the attribute with a / SalesLineItem /quantity /subtotal Item 1..*0, 1 In this case, according to the model, there could be several items related to one line in the sale. These items are all the same type, and the quantity is therefore derivable by counting the number of related items. We are just adding more information to the model. Attributes

25. January 200592.3913 Ron McFadyen25 A partial domain model

26. January 200592.3913 Ron McFadyen26 Generalization a generalization is a relationship between a general thing (the superclass or parent class) and a more specific kind of thing (the subclass or child class) example: a StaffMember is a specialized kind of LibraryMember a StudentMember is a specialized kind of LibraryMember LibraryMember StaffMemberStudentMember

27. January 200592.3913 Ron McFadyen27 Generalization Multiple subclasses can be grouped to indicate they are related subclasses LibraryMember StaffMemberStudentMember It then becomes meaningful to consider certain constraints: complete, incomplete, disjoint, overlapping

28. January 200592.3913 Ron McFadyen28 Generalization Inheritance of attributes and behaviour: everything a LibraryMember can do, a StaffMember can do everything a LibraryMember can do, a StudentMember can do If a LibraryMember can borrow a book, so can a StaffMember and a StudentMember a StaffMember and a StaffMember have all the attributes the LibraryMember has, and possibly more Specialization: there are some things that a specialized class can do that a LibraryMember cannot LibraryMember StaffMemberStudentMember

29. January 200592.3913 Ron McFadyen29 example: a SavingsAccount is a specialized kind of BankAccount a ChequingAccount is a specialized kind of BankAccount a BankAccount is a specialized kind of Asset RealEstate is … Asset RealEstateBankAccountSecurity SavingsAccountChequingAccount

30. January 200592.3913 Ron McFadyen30 Payment Amount: money Cash Payment Credit PaymentCheque Payment Sale Pays-for 1 1 Every payment, regardless of whether it is cash, credit, or cheque, has an Amount and it is associated with a Sale CreditCardCheque 1 1 1 *

31. January 200592.3913 Ron McFadyen31 Motivation for partitioning a conceptual class into subclasses: subclass has additional attributes of interest subclass has additional associations of interest subclass is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses the subclass concept represents an animate thing that behaves differently than the superclass or other subclasses

32. January 200592.3913 Ron McFadyen32 The name Payment is italicized - meaning it is an abstract class An abstract class is a class that will never be instantiated; only its subclasses can exist If “Payment” was not in italics then a Payment could exist that is not a Cash, Credit, or Check payment Payment Amount: money Cash Payment Credit PaymentCheque Payment

33. January 200592.3913 Ron McFadyen33 What is the difference: Payment Unauthorized Payment Authorized Payment PaymentState Unauthorized StateAuthorized State Payment Is-in * 1

34. January 200592.3913 Ron McFadyen34 A composite is a group of objects in which some objects contain others; one object may represent groups, and another may represent an individual item, a leaf. Composite Pattern We will examine the composite pattern later in the course. At this time, we are many concerned with its structural aspect. Consider the class diagram that follows. What objects does it allow us to instantiate and how will they relate to one another?

35. January 200592.3913 Ron McFadyen35 Generic UML class diagram Component Operation() Leaf Operation() Composite Operation() Other() * Client Composite Pattern

36. January 200592.3913 Ron McFadyen36 MachComponent getMachineCount() Machine getMachineCount() MachComposite components: List getMachineCount() * PlantFloor 1 * 1 Composite Pattern Consider a UML class diagram for machines. Machines may be complex and contain other machines.

37. January 200592.3913 Ron McFadyen37 An object diagram illustrating the machine on floor 5 of the plant L1: Machine M1: MachComposite L2: Machine L7: MachineL4: Machine M9: MachComposite floor5 :Plantfloor Composite Pattern