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

Fig. 9.1: Sample UP Artifact Relationships

Fig. 9.1

Fig. 9.2: Partial Domain Model – A Visual Dictionary

Fig. 9.3

Fig. 9.4

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

Fig. 9.6 Lower the Representational Gap with OO Modeling

Fig. 9.7: Initial POS Domain Model

Fig. 9.8: Initial Monopoly Domain Model

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.

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!

Fig. 9.11

Fig. 9.12

Fig. 9.13

Fig. 9.14

Fig. 9.15

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

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

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.

Fig. 9.18: Monopoly partial domain model

Fig. 9.19: Class and Attributes

Fig. 9.20: Attribute Notation in UML

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]

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.

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

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

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]

Fig. 9.26: Modeling Quantities

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

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

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

Fig. 9.28: Monopoly Partial Domain Model