About Domain Models. Value of OOA/D knowledge over UML notation;

Transcription

1 Domain Models

2 About Domain Models. Domain model is the most important and classic model in OO analysis. 2. Illustrates noteworthy concepts in a problem domain. 3. Acts as a source of inspiration for software objects. Value of OOA/D knowledge over UML notation; Basic notation is trivial, but there are subtle modeling guidelines for a useful model. Will explore basic skills in creating domain models.

3 Domain Model Key idea: Domain Model A visual dictionary of abstractions about the real world. Class diagrams with no operations specified. Attributes and relationships YES. Conceptual classes: idea, thing, or object. Classes don t necessarily correspond to software classes. Store Register Sale

4

5 How to identify classes?. Use a conceptual class category list. 2. Linguistic Analysis: identify noun phrases in use cases.

6 Conceptual Class Category List Physical or tangible objects Register, Airplane Specifications, or descriptions of things ProductSpecification, FlightDescription Places Store, Airport Transactions Sale, Payment, Reservation Transaction items SalesLineItem Roles of people Cashier, Pilot Containers of other things Store, Hangar, Airplane Things in a container Item, Passenger Computer or electro-mechanical systems CreditPaymentAuthorizationSystem, AirTrafficControl Catalogs ProductCatalog, PartsCatalog Organizations SalesDepartment, Airline Same category list applies to many problems.

7 Finding noun phrases in use cases Main Success Scenario (or Basic Flow):. Customer arrives at POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory).

8 Candidate Conceptual Classes Register (cat list) Item (noun) Store (cat list) Sale (noun) Payment (noun) ProductCatalog (cat list) ProdSpecification (cat list) SaleLineItem (noun) Cashier (noun) Customer (noun)

9 Attribute or class? If we don t think of some conceptual class X as a number or string, then X is probably a class, not an attribute.

10 E.g. Need for specification classes An Item instance represents a physical item in a store. An Item has a description, price, and itemid, which aren t recorded anywhere else. Everyone in store has amnesia. Every time a real physical item is sold, an Item is deleted. What can go wrong?. When some product is all sold out there is no info anymore about it. 2. The data about price and description is replicated at each item. This brings update anomalies. Why?

11 Solution: add specification class Even if all inventoried items are sold and their corresponding Item software instances are deleted, the ProductDescription still remains.

12 Another Specification Example (Flights)

13 Associations Associations record relationships for which there is a need to preserve some memory. Usually when: A is subpart/member of B. (SaleLineItem - Sale) A uses or manages B. (Cashier Register, Pilotairplane) A communicates with B. (Student - Teacher) A is transaction related to B. (Payment - Sale) A is next to B. (SaleLineItem - SaleLineItem) A is owned by B. (Plane-Airline) A is an event related to B. (Sale-Store)

14 Roles and Multiplicity Each end of an association is called a role. Multiplicity defines how many instances of a class A can be associated with one instance of class B. E.g., a single instance of a Store can be associated with many (zero or more) Item instances. Store Stocks * Item multiplicity of the role

15 Some examples of multiplicity * T zero or more; "many"..* T one or more..40 T one to 40 5 T exactly 5 3, 5, 8 T exactly 3, 5, or 8

16 POS Domain Model quantity LineItem..* 0.. Records-sale-of Item * Contained-in Stocked-in Sale Store date time address name Houses Paid-by..* amount Payment Captured-on 4 Register

17 Multiple associations It s non uncommon to have more than one associations between two classes. Flight * Flies-to * Flies-from Airport

18 Attributes vs. Associations Worse Cashier name currentregister not a "simple" attribute Better name Cashier Uses number Register Relate conceptual classes with an association, not with an attribute.

19 Conceptual vs. Implementation How the associations are implemented in Java or C++? Very often by references or pointers, which are attributes of the software classes. This is a source of confusion but they are conceptually different. So, we keep the associations distinct from attributes in the Domain Model.

20 In practice keep the implementation in mind Suppose you have two Person objects, o and o 2 whose names are Jill Smith. These people are different, and so are the memory addresses (refs) of o and o 2. Now, suppose you want to compare the phone numbers of two people. You care about the values, not about their memory address! Thus, when comparing we do so with respect to memory addresses and we are Ok. The same for name, address, etc. Bottom line Attributes are data values. Associations are refs.

21 What about values that can get too complex, like address? The choice is yours, with a slight preference for creating separate classes for them. Also, no attributes as foreign keys.

22 Register Item Store address name Sale date time Payment amount Sales LineItem quantity Cashier Customer Manager Product Catalog Product Specification description price itemid Stocks * Houses..* Used-by * Contains..* Describes * Captured-on Contained-in..* Described-by * Records-sale-of 0.. Started-by Paid-by Initiated-by Logscompleted 6 * 3 Records-sales-on..*

23 What about some DM for the airline?