1. Chapter 9 Domain Models $PH\06f522\LarmanApplUMLandPtrns\larman3EdDgmsCh01-14\09_domainModelsR2.ppt – RJL060911

2. Fig. 9.1: Sample UP Artifact Relationships

3. Fig. 9.1

4. Fig. 9.2: Partial Domain Model – A Visual Dictionary

5. Fig. 9.3

6. Fig. 9.4

7. Fig. 9.5 A Conceptual Class has a symbol, an intension (metadata) and extension (data)

8. Fig. 9.6 Lower the Representational Gap with OO Modeling

9. Fig. 9.7: Initial POS Domain Model

10. Fig. 9.8: Initial Monopoly Domain Model

11. Fig. 9.9: Descriptions about other things Multiplicity ‘*’ means 0 to many Item instances are related to one Prod’ctDescr’n. Multiplicity ‘1’ means one Prod’ctDescr’n instance is related to some # of Items. Many invariant attributes are duplicated; This wastes space and causes the ‘double-maintenance’ problem – RJL.

12. Fig. 9.10: Descriptions about Other Things Worse Flight date time FlightDescription number Airport name Describes flights-to Described-by Flight date number time Airport name Flies-to Better 1 * 1 * 1 * Clockwise Rule relation name is unambiguous I rearranged model Items to illustrate 2DTopological Order: (by relational multiplicity – RJL. (I use one above/left of many.) David Hay/Oracle both reverse this orientation!

13. Fig. 9.11

14. Fig. 9.12

15. Fig. 9.13

16. Fig. 9.14

17. Fig. 9.15

18. ItemStore Stocks  1 or 0..1 Multiplicity should be "1" or "0..1"? The answer depends on our interest in using the model. Typically and practically, the multiplicity communicates a domain constraint that we care about being able to check in software, if this relationship was implemented or reflected in software objects or a database. For example, a particular item may become sold or discarded, and thus no longer stocked in the store. From this viewpoint, "0..1" is logical, but... Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensure that anItemsoftware instance would always be related to 1 particular Storeinstance, otherwise it indicates a fault or corruption in the software elements or data. This partial domain model does not represent software objects, but the multiplicities record constraints whose practical value is usually related to our interest in building software or databases (that reflect our real-world domain) with validity checks. From this viewpoint, "1" may be the desired value. *

19. Fig. 9.16 Which relation name conforms to the Clockwise Rule? - RJL

20. Fig. 9.17: NextGen POS: partial domain model 06f522 Assignment 1a, due 9/12: Redraw, topologically sorted; use 2-ucLetter symbols as box labels; include dictionary of pairs.

21. Fig. 9.18: Monopoly partial domain model

22. Fig. 9.19: Class and Attributes

23. Fig. 9.20: Attribute Notation in UML

24. Fig. 9.21: Recording the quantity of Items sold in a line item [Here an item quantity attribute could be added to a single SalesLineItem; but it can’t be derived because there is only one associated item.] [Now the associated item only needs to have multiplicity 1, illustrating one possible justification for evolving a conceptual model into a different design model. – RJL]

25. Fig. 9.22: Relate with associations, not attributes [The ‘uses’ relation implies an implicit oid or foreign key attribute in Cashier, to identify the (currently) assigned Register. –RJL ] 06f522 assignment 1b, due 9/12: Expand/redraw this model to include the temporal history of Cashier to Register assignments over time: Add new attributes and associations and state your assumptions.

26. Fig. 9.23: Don’t show complex concepts as attributes; use associations.

27. Fig. 9.24: Two ways to indicate a data type property of an object.

28. Fig. 9.25: Do not use attributes as foreign keys.* * Fkeys are redundant if implied by association links. Warning: This may also force surrogate keys with standard naming conventions. [Disclaimer: I Iike surrogate keys – RJL]

29. Fig. 9.26: Modeling Quantities

30. Fig. 9.27: NextGen POS partial domain model Can you abbreviate names and sort by fanout?

31. Fig. 9.27B: NextGen POS partial domain model [With abbreviated names, leveled by fanout] Level Symbol EntityType 1 LG Ledger 1 PCProductCatalog 2 PDProductDescription 2 SRStoRe 3 CUCustomer 3 CHCasHier 3 ITITem 3 RGReGister 4 SASale 5CPCashPayment 5 SLSalesLineitem 09_domainModelsR2.ppt slide 31

32. Fig. 9.21C: NextGen - Topological sort by fanout [and optionality] Level Symbol EntityType 1 LG Ledger 1 PCProductCatalog 2 PDProductDescription 2 SRStoRe 3 CUCustomer 3 CHCasHier 3 ITITem 3 RGReGister 4 SASale 5CPCashPayment 5 SLSalesLineitem LG PC PDSR CU CHITRG SA CPSL ? 09_domainModelsR2.ppt - slide 32

33. Fig. 9.28: Monopoly Partial Domain Model