Domain Model RefinementWhen to make generalization hierarchies? Why is the following a good example?100% and Is-a rulesWhat about this hierarchy?Is this hierarchy OK? What does it add to our understanding of the domain?When to design Association classes?What about this hierarchy? (Why not?)More Association classesWhen to add Composition notation?UML package diagramsHigher order package for POS domainCore/Misc packageA rich packageNote: Composition and tie to Core packageIteration-3 of Monopoly domain modelDon’t forget to plan testing!Domain Model RefinementLarman, chapter 31CSE 432: Object-Oriented Software EngineeringGlenn D. Blank, Lehigh UniversityWhen to make generalization hierarchies?Why is the following a good example?CashPaymentCreditPaymentCheckPaymentPaymentsuperclass - more general conceptsubclass - more specialized conceptthese are conceptual classes, not software classesFigure 31.1Guidelines: • Identify superclasses and subclasses when they help us understand concepts in more general, abstract terms and reduce repeated information.• Expand class hierarchy relevant to the current iteration and show them in the Domain Model.100% and Is-a rulesCashPaymentCreditPaymentCheckPaymentPaymentamount : MoneySalePays-for11100% rule: Subclasses must conform to 100% of superclass’s attributes and associations. Do they above?Is-a rule (informal test): “Subclass is a Superclass”What about this hierarchy?MaleCustomerFemaleCustomerCustomerCorrect subclasses.But useful?Fig. 31.6Guidelines for creating conceptual subclasses:• Subclass has additional attributes or associations of interest• Subclass behaves or is operated on, or handled or manipulated differently than superclass or other subclassesIs this hierarchy OK? What does it add to our understanding of the domain?CreditAuthorizationServiceCheckAuthorizationServiceCheckPaymentAuthorizationServiceaddressnamephoneNumberadditional associationssuperclass justified by common attributes and associationsStoreAuthorizes-payments-of*AuthorizesCreditPaymentAuthorizes***1 1Fig. 31.8Models transactions with external services which are important in POS domainWhen to design Association classes?addressnamephoneNumberAuthorizationServiceaddressnameStoremerchantIDServiceContractan association class its attributes are related to the associationits lifetime is dependent on the association Authorizes-payments-via1..**Fig. 31.16addressnamephoneNumberAuthorizationServiceaddressnameStoremerchantIDServiceContractPurchases1..**a better model, but notyet as useful as possible SellsAuthorizes-payments-via1..**Fig. 31.15ServiceContract records merchantID—good.But ServiceContract is dependent on relationship between two classesWhat about this hierarchy? (Why not?)Paymentnot usefulthese subclasses are changing states of the superclassUnauthorizedPaymentAuthorizedPaymentPaymentStatebetterUnauthorizedStateAuthorizedStatePaymentIs-in1*Fig. 31.13• Classes should be invariant• Classes can maintain state information as attributes• Rather than subclasses, model changing states with state chartsMore Association classessalaryEmploymentEmploysCompany Person**dateOfIncarcerationJailTermIncarceratesJail Person*Married-toPerson0..10..11a person may have employment with several companiesFig. 31.17When to add Composition notation?SalesLineItemSale1..*ProductDescriptionProductCatalog1..*11Fig. 31.18Guidelines for drawing Composition (whole-part) relationships:• Obvious whole-part physical or logical assembly • Lifetime of part is bound within lifetime of whole (create-delete dependency)• Some properties of whole propagate to parts, e.g., location• Operations of whole propagate to parts, e.g., movement• But: If in doubt, leave it out.UML package diagramsUML packages for higher level structure than classesDenoted by box with smaller box on topNote dependency arrowsA dependency indicates that changes to one element may cause changes to the otherGuidelines for partitioning the domain model into packages:Place elements together if they are in same class hierarchy, participate in the same use cases, or closely related by concept or purpose, or strongly associated Packages can be grouped in higher-order packagesPackages may include packagesCommon package as <<global>> means all packages in system have dependency to this oneGeneral package marked {abstract} means this package is an interface, with subtypesGuidelines: divide classes into packages; analyze dependencies; refactor to reduce dependenciesHigher order package for POS domainDomainCore/Misc Payments Products SalesAuthorization TransactionsFig. 31.29What does this higher order package contain?Core/Misc packageCore/MiscRegister ManagerStoreaddressnameHouses1..*Employs1..*11Fig. 31.30Why call this package Core for the POS domain?A rich packagePaymentsCheckAccountsReceivableCreditPaymentCheckPaymentCheckAuthorizationServiceCreditAuthorizationServiceAuthorized-byAuthorized-by***AuthorizationServiceaddressnamephoneNumberCore::StorePaymentamountEstablishes-credit-for Logs *CreditCardexpiryDatenumberDriversLicensenumber1..*Establishes-identity-for Paid-by CashPaymentamountTendered*Sales::CustomerAbused-byIdentifiesAuthorization Transactions::PaymentAuthorizationReply- CheckPayments have CheckPaymentReplies- CreditPayments have CreditPaymentReplies11111111 111 Authorizes-payments-ofmerchantIDServiceContract1Fig. 31.31Note: Composition and tie to Core packageProducts1..*Core::StoreStocks*Describes*Sales::SalesLineItemDescribed-by*Records-sale-of0..1ProductDescriptiondescriptionpriceitemIDProductCatalogItem11111Fig. 31.32Iteration-3 of Monopoly domain modelWhat’s new?Don’t forget to plan testing!Plan testing for classes and systemWrite system and unit test plan descriptions as part of class designUnit test all public member functionsTest for valid, invalid and boundary casesSystem testing follows thorough class testingSee Junit tool for automated test generation