1. Sept 200491. 3913 Ron McFadyen1 Section 10.1 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. Sept 200491. 3913 Ron McFadyen2 Domain model

3. Sept 200491. 3913 Ron McFadyen3 Figure 10.1 Partial domain model

4. Sept 200491. 3913 Ron McFadyen4 Figure 10.4 Conceptual class has a symbol, intension, extension

5. Sept 200491. 3913 Ron McFadyen5 Strategy in OO analysis is Divide-and-conquer via conceptual classes Analysis task: identify concepts of interest and document these in the Domain Model.

6. Sept 200491. 3913 Ron McFadyen6 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...

7. Sept 200491. 3913 Ron McFadyen7 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)...

8. Sept 200491. 3913 Ron McFadyen8 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

9. Sept 200491. 3913 Ron McFadyen9 Register Item Store Sale Payment Product Catalog Product Specification Sales Line Item Cashier Customer Manager Section 10.3 Candidate Conceptual Classes No “correct” list

10. Sept 200491. 3913 Ron McFadyen10 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

11. Sept 200491. 3913 Ron McFadyen11 Section 10.7 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 …

12. Sept 200491. 3913 Ron McFadyen12 Section 10.7 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

13. Sept 200491. 3913 Ron McFadyen13 Section 10.9 Lowering the Representational Gap Domain Model provides a visual dictionary of the domain vocabulary and concepts

14. Sept 200491. 3913 Ron McFadyen14 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

15. Sept 200491. 3913 Ron McFadyen15 Classes are usually derived from: Where NextGen POS thingsregister, item rolescashier eventssale

16. Sept 200491. 3913 Ron McFadyen16 Ch 11 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 Multiplicities we indicate via multiplicities the range of allowable cardinalities for participation in an association examples: 1, 1..*, 0..*, 1..3 PersonCompany 1..* 1

17. Sept 200491. 3913 Ron McFadyen17 zero or more; "many" one or more one to forty exactly five T T T T * 1.. * 1..40 5 T 3, 5, 8 exactly three, five or eight Customer Video Rents  * One instance of a Customer may be renting zero or more Videos. One instance of a Video may be being rented by zero or one Customers. 0..1 Multiplicity

18. Sept 200491. 3913 Ron McFadyen18 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

19. Sept 200491. 3913 Ron McFadyen19 Figure 11.8 A partial domain model

20. Sept 200491. 3913 Ron McFadyen20 Ch 12. 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

21. Sept 200491. 3913 Ron McFadyen21 attributes are preferably primitive (or just data types) boolean, date, number, string,... Invoice invDate: date Attributes

22. Sept 200491. 3913 Ron McFadyen22 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

23. Sept 200491. 3913 Ron McFadyen23 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

24. Sept 200491. 3913 Ron McFadyen24 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

25. Sept 200491. 3913 Ron McFadyen25 Page 172: 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

26. Sept 200491. 3913 Ron McFadyen26 Page 175: 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

27. Sept 200491. 3913 Ron McFadyen27 Figure 12.9 A partial domain model