Domain Model Refinement
advertisement
Domain Model Refinement Notation Extensions Things not seen before in the Domain Model Similar to the concepts in the Object Models Generalization and specialization Conceptual class hierarchies Association classes that capture information about the association Time intervals Packages as a means of organization Fig. 31.1 superclass - more general concept Payment these are conceptual classes, not software classes Cash Payment Domain Classes Credit Payment Check Payment subclass - more specialized concept Fig. 31.2 Alternate notation Payment Cash Payment Credit Payment Payment Check Payment Cash Payment Credit Payment They each show the same thing Check Payment Conceptual Superclasses and Subclasses Conceptual superclass is more general than subclass All members of subclass must be members of the superclass 100% of superclass definition shall apply to the subclass Subclass “is-a” superclass Woman “is-a” human Man “is-a” human Anything else that is a human? All humans have a heart and a brain. Fig. 31.3 Payment amount : Money Cash Payment Credit Payment Check Payment Cash Payment is-a payment. No other type of payment is possible in this domain, e.g. no gift certifications Fig. 31.4 Set view Payment CashPayment CreditPayment CheckPayment Venn Diagram view: All instances of “cash payment” are also members of the “payment class. Fig. 31.5 Payment amount : Money Cash Payment Credit Payment Pays-for 1 1 Check Payment Pays-for applies to all payments! Sale When to use a subclass Start with the super-class and look at differences to find the sub-classes that make sense. Subclass has additional attributes Subclass has additional associations Subclass usage differs from superclass Subclass represents an animate entity that behaves differently Fig. 31.6 Correct subclasses. Customer But useful? Male Customer Female Customer Only useful to POS if men and women pay different amounts, e.g. have specific gender discounts. Useful for age. When to define a superclass Start with a set of sub-classes and look for commonalities that help the model. Potential subclasses represent variations of concept Subclasses meet “is-a” rule and 100% rule All subclasses have common attributes that can be factored out All subclasses have the same association that can be factored out Fig. 31.7 Pays-for 1 1 Sale 1 superclass justified by common attributes and associations 3 Payment additional associations amount : Money 2 each payment subclass is handled differently Cash Payment Credit Payment Identifies-credit-with Check Payment * Paid-with 1 CreditCard 1 Check NextGen POS Class Hierarchies Fig. 31.8 1 Authorizes-payments-of * Store * superclass justified by common attributes and associations AuthorizationService address name phoneNumber Credit Authorization Service 1 additional associations 2 Check Authorization Service 1 Authorizes * Credit Payment Authorizes * Check Payment More or Less Generalization? (Fig. 31.9) Payment Authorization Transaction Concepts too fine grained? Useful to show this degree of partitioning? Too much middle management? Payment Authorization Reply CreditPayment Authorization Reply CreditPayment Approval Reply date time CreditPayment Denial Reply Payment Authorization Request CheckPayment Authorization Reply CheckPayment Approval Reply CreditPayment Approval Request CheckPayment Denial Reply CheckPayment Approval Request Each transaction is handled differently, so it is useful to partition them into discrete classes. Fig. 31.10 Payment Authorization Transaction date time Payment Authorization Request Payment Authorization Reply CreditPayment Approval Reply CreditPayment Denial Reply CheckPayment Approval Reply CheckPayment Denial Reply CreditPayment Approval Request CheckPayment Approval Request Fig. 31.11 Abstract Conceptual Classes Payment (a) CashPayment CreditPayment CheckPayment If a Payment instance may exist which is not a CashPayment, CreditPayment or CheckPayment, then Payment is not an abstract conceptual class. abstract conceptual class Payment (b) CashPayment CreditPayment CheckPayment Payment is an abstract conceptual class. A Payment instance must conform to one of the subclasses: CashPayment, CreditPayment or CheckPayment. Fig. 31.12 abstract class indicated by italics Payment amount : Money Cash Payment Credit Payment Check Payment Fig. 31.13 Modeling Changing State Payment not useful these subclasses are changing states of the superclass Payment Unauthorized Payment * Is-in 1 PaymentState Unauthorized State Authorized Payment better Authorized State Why is this better? More accurate representation of the details. Association Classes If a class C can simultaneously have multiple values for attribute A, put these in a separate class When to use association class An attribute is related to the association, not a class Instances of association class have a lifetime dependency on the association Many to many associations between two concepts can produce multiple values simultaneously. Fig. 31.14 Store address merchantID name both placements of merchantID are incorrect because there may be more than one merchantID Think: transaction ID AuthorizationService address merchantID name phoneNumber Fig. 31.15 a better model, but not yet as useful as possible AuthorizationService Store Authorizes-payments-via address name address 1..* name phoneNumber * Purchases ServiceContract 1..* merchantID 3 Sells * Think: transaction ID Fig. 31.16 AuthorizationService Store Authorizes-payments-via address name * ServiceContract merchantID address 1..* name phoneNumber an association class its attributes are related to the association its lifetime is dependent on the association Think: transaction ID Fig. 31.17 Company a person may have employment with several companies Jail Employs * * Person * Person Employment salary 1 Incarcerates JailTerm dateOfIncarceration Married-to 0..1 0..1 Person Aggregation and Composition Composition in the Domain. If in doubt don’t use it! Should be obvious Composition when: Whole-part exists Lifetime of composite is bound together Operation to the composite propagates to parts Fig. 31.18 Sale 1 Product Catalog 1 1..* 1..* SalesLineItem Product Description Fig. 31.21 roles in associations Employs-to-manage 1 Employs-to-handle-sales cashier Store * * manager Person * 1 manager worker Manages4 roles as concepts Store 1 Employs * Manager 1 Manages 6 1 Employs * Cashier * Fig. 31.22 Sale dateTime /total ... derived attribute Derived Elements No new information but helps comprehension Fig. 31.23 Sale /quantity 1 derivable from the actual multiplicity 1..* SalesLineItem Fig. 31.24 Qualified Associations (a) (b) Product Catalog Product Catalog Contains 1..* 1 1 itemID qualifier Contains 1 Product Description Product Description multiplicity reduced to 1 Fig. 31.25 Person 2 * parent child Creates 4 Self referential Packages Group elements: By subject area In same class hierarchy In same use cases Strong associations Do not know this until the project grows Fig. 31.26 Domain Core Elements Sales Helps comprehension as the project grows. Can only see so many things in a group. Fig. 31.27 Core Elements Sales Core Elements:: Register Store 1 Has 1 1..* Register Captures 1 Sale Shows where the elements belongs, which package owns it. Fig. 31.28 Domain Core Elements Sales Sales is dependent on Core. Sales refers to Core. Fig. 31.29 Domain Core/Misc Payments Products Sales Authorization Transactions POS Domain Model organization Fig. 31.30 Core/Misc Store address name 1 Houses 1 1..* Register Manager 1..* Employs Contents of Core Fig. 31.31 Payments 3 Authorizes-payments-of 1 Payment 1..* AuthorizationService Core::Store ServiceContract amount merchantID Paid-by 1 1 CashPayment amountTendered Credit Payment Check Payment * * * * address name phoneNumber Check Authorized-by 1 * Check Authorization Service Credit Authorization Service 1 Authorized-by Logs 4 Establishescredit-for 5 1 1 1 Accounts Receivable Establishesidentity-for 5 CreditCard Authorization Transactions:: PaymentAuthorizationReply DriversLicense expiryDate number number 1 Identifies - CheckPayments have CheckPaymentReplies 1 1 Abused-by4 1 Sales::Customer - CreditPayments have CreditPaymentReplies Fig. 31.32 Products Sales:: SalesLineItem Described-by 0..1 * 1 Product Description ProductCatalog 1..* 1 description price itemID 1 Records-sale-of6 Describes * Core:: Store Stocks 1 * Item 1 Fig. 31.33 Sales Customer Captured-on4 1 1 Initiates Records-sales-on5 1 Tax LineItem description percentage amount Sale 1 Core:: Register 1 1 SalesLineItem 1..* 1 date isComplete time * 1 1..* /quantity 3 Logs-completed 1 Core:: Store Cashier Fig. 32.34 Authorization Transactions Payment Authorization Transaction Payment Authorization Request Payment Authorization Reply CreditPayment Approval Reply CreditPayment Denial Reply CheckPayment Approval Reply CheckPayment Denial Reply CreditPayment Approval Request CheckPayment Approval Request Monopoly (Fig. 31.35)
