Domain Modeling- 2. Generalization

Transcription

1 Generalization Domain Modeling- 2 Conceptual superclasses and subclasses When to create a subclass? A superclass? Abstract classes Modeling state changes Operation contracts Attaching pre- /post-conditions to seq diagram actions -- effects on domain model classes Domain Models2-7, CS431 F06, BG Ryder/A Rountev 1 Generalization Superclass-subclass relationships Used in the domain model and in the design model Cash Credit Domain Models2-7, CS431 F06, BG Ryder/A Rountev 2 1

2 Meaning of Generalization All members of the subclass set are also members of the superclass set Every instance of Credit is also an instance of is-a-kind-of Cash Credit Domain Models2-7, CS431 F06, BG Ryder/A Rountev 3 Meaning of Generalization All associations and attributes of the superclass apply to the subclass Sale Paid-by 1 1 amount:money applies to all subclasses Cash Credit Domain Models2-7, CS431 F06, BG Ryder/A Rountev 4 2

3 Additions Subclasses could add associations and attributes Sale Paid-by 1 1 Cash Credit * Identifies-credit-with 1 Credit Card Paid-with 1 1 Domain Models2-7, CS431 F06, BG Ryder/A Rountev 5 Basic Idea Domain model: a superclass represents a general concept, and a subclass represents some specialization Cash is-a-kind-of Design: the subclass interface conforms to the interface of the superclass Software components with interfaces Substitutability: the subclass can be used in any place where the superclass is allowed Domain Models2-7, CS431 F06, BG Ryder/A Rountev 6 3

4 A Question about subclasses For the POS system, is this a good idea? Customer Male Customer Female Customer Domain Models2-7, CS431 F06, BG Ryder/A Rountev 7 Motivation for Superclasses The model may contain a set of classes for which it makes sense to create a superclass When the classes represent variations of a similar concept e.g. if we have CreditAuthorizationService and AuthorizationService, it may be a good idea to create superclass AuthorizationService Duplicate attributes/associations often indicate that a superclass is needed Domain Models2-7, CS431 F06, BG Ryder/A Rountev 8 4

5 Creating Superclasses When creating a new superclass, always need to make sure that the relationship is is-a-kind-of and all superclass attributes/associations apply to all subclasses If all subclasses have the same attribute, it should be moved to the superclass If all subclasses have the same association, it should also be moved Domain Models2-7, CS431 F06, BG Ryder/A Rountev 9 Example POS system uses external authorization services for credit payments Three different kinds of payment transactions: requests, approvals, denials Each transaction has date and time associated with it Approvals and denials have processing time associated with them e.g., for performance measurements Domain Models2-7, CS431 F06, BG Ryder/A Rountev 10 5

6 Abstract Conceptual Classes Any instance of the class must be an instance of some known subclass Cash UML notation Credit amount:money or {abstract} amount:money Domain Models2-7, CS431 F06, BG Ryder/A Rountev 11 Modeling of State Do not model the states of concept as subclasses of e.g. state of payment = { unauthorized, authorized } Do not create subclasses Authorized and Unauthorized Problem: an instance of the concept may change states a payment is initially in unauthorized state, and then moves to authorized state Domain Models2-7, CS431 F06, BG Ryder/A Rountev 12 6

7 Modeling of State One possible solution: create a state hierarchy, and associate it with Is-in 1 1 State Authorized State Unauthorized State Example of the State design pattern Domain Models2-7, CS431 F06, BG Ryder/A Rountev 13 Artifact Use-Case Model Supplem. Spec Domain Model Design Model Implem. Model UP Artifacts Incep Elab Domain Models2-7, CS431 F06, BG Ryder/A Rountev 14 Const Trans Requirements analysis: Use-Case Model + Supplementary Specification Domain analysis: Domain Model Design: Design Model Coding: Implementation Model 7

8 More on the Use Case Model Use cases: primary way to describe requirements For certain scenarios: systems sequence diagrams Developed in parallel with Domain Model Operation contracts: a way to describe in more detail the use cases Part of the Use Case Model Use pre-/post-condition form to explain effects of system operation on domain objects (i.e,. Object state changes) Only for complex operations to clarify what they do Domain Models2-7, CS431 F06, BG Ryder/A Rountev 15 System Operations in POS : Cashier : System makenewsale() enteritem(itemid,quantity) description, total *[more items] endsale() total with taxes make(amount) change, receipt Domain Models2-7, CS431 F06, BG Ryder/A Rountev 16 8

9 Relevant Part of the Domain Model Sales LineItem quantity 1..* 1 Sale date time * Contained-in Described-by 1 Product Specification description price itemid Domain Models2-7, CS431 F06, BG Ryder/A Rountev 17 Example of a Contract enteritem(itemid:itemid,quantity:int) Cross References: Process Sale use case Preconditions: there is a sale underway Postconditions (state changes on operation completion) A SalesLineItem instance sli is created sli is associated with the current Sale sli.quantity becomes quantity sli is associated with ProductSpecification, based on itemid match Domain Models2-7, CS431 F06, BG Ryder/A Rountev 18 9

10 Other Example Contracts Stand-alone system Item No external inventory system * Stocked-in Adding items to the inventory 1 An instance of Item is created Store The new instance is address associated with the Store name Removing items from the inventory The association is destroyed and the Item instance is also destroyed Domain Models2-7, CS431 F06, BG Ryder/A Rountev 19 10