1. Lecture 9 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor

2. Domain Model

3. Domain Models Fundamental OO analysis model –Shows important concepts in the domain of interest –Visual dictionary of concepts & their relationships –Inspiration for SW objects in class diagram –Depicts objects, their attributes, associations between objects –Does NOT show object’s operations

4. Partial Domain Model – A Visual Dictionary

5. Domain Model It shows an abstraction of the conceptual classes, because there are many other things one could communicate about registers, sales, and so forth. Guideline: –Avoid a waterfall-mindset big-modeling effort to make a thorough or "correct" domain model. it won't ever be either, and such over- modeling efforts lead to analysis paralysis, with little or no return on the investment.

6. Domain Objects

7. Conceptual classes not Software Objects

8. Conceptual Classes The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class is an idea, thing, or object. Conceptual class may be considered in terms of its –Symbol – words or images representing a conceptual class –Intension – the definition of a conceptual class –Extension – the set of examples to which the conceptual class applies Example –Symbol – Sale –Intension – represents the event of a purchase transaction, and has a date and time –Extension – all the examples/instances of sales

9. A Conceptual Class has a Symbol, Intension, and Extension

10. Domain models Don’t confuse with data model –Object might have attributes that aren’t persisted –Object might have no attributes –Such objects wouldn’t be in a data model

11. Domain Models Domain model simpler than full-blown design class model Easier for users to understand Use it to educate users about basic OO modeling Reduces tendency for modeler to drill too deep too quickly

12. Motivation: Domain Models OO modeling lowers the representational gap between our mental and software models. Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities.

13. Lower Representational Gap with OO Modeling

14. Domain Models How to create a domain model? –Bounded by the current iteration requirements under design: Find the conceptual classes Draw them as classes in a UML class diagram. Add associations and attributes

15. Guideline: How to Find Conceptual Classes? 1.Reuse or modify existing models 2.Use a category list 3.Identify noun phrases

16. Conceptual Class CategoryExamples business transactions Guideline: These are critical (they involve money), so start with transactions. Sale, Payment Reservation transaction line items Guideline: Transactions often come with related line items, so consider these next. SalesLineItem product or service related to a transaction or transaction line item Guideline: Transactions are for something (a product or service). Consider these next. Item Flight, Seat, Meal where is the transaction recorded? Guideline: Important. Register, Ledger FlightManifest roles of people or organizations related to the transaction; actors in the use case Guideline: We usually need to know about the parties involved in a transaction. Cashier, Customer, Store MonopolyPlayer Passenger, Airline

17. Conceptual Class CategoryExamples noteworthy events, often with a time or place we need to remember Sale, Payment MonopolyGame Flight physical objects Guideline: This is especially relevant when creating device-control software, or simulations. Item, Register Board, Piece, Die Airplane descriptions of things Guideline: See p. 147 for discussion.147 ProductDescription FlightDescription catalogs Guideline: Descriptions are often in a catalog. ProductCatalog FlightCatalog containers of things (physical or information)Store, Bin Board Airplane things in a containerItem Square (in a Board) Passenger other collaborating systemsCreditAuthorizationSystem AirTrafficControl records of finance, work, contracts, legal matters Receipt, Ledger MaintenanceLog financial instrumentsCash, Check, LineOfCredit TicketCredit schedules, manuals, documents that are regularly referred to in order to perform work DailyPriceChangeList RepairSchedule

18. Method 3: Finding Conceptual Classes with Noun Phrase Identification linguistic analysis: – Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes –Have to differentiate between attribute and class –A weakness of this approach is the imprecision of natural language –It is recommended in combination with the Conceptual Class Category List technique. The fully dressed use cases are an excellent description to draw from for

19. Example Main Success Scenario (or Basic Flow): 1.Customer arrives at a 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.Cashier repeats steps 2-3 until indicates done. 6.System presents total with taxes calculated. 7.Cashier tells Customer the total, and asks for payment. 8.Customer pays and System handles payment. 9.System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory). 10.System presents receipt. 11.Customer leaves with receipt and goods (if any).

20. Initial POS Domain Model

21. Guidelines Agile Modeling and Maintain the Model in a Tool Report Object in the domain –include it in domain model or not? –e.g., Receipt is only a report of Sale and Payment Think like a Mapmaker –Use the existing names in the territory. For example, if developing a model for a library, name the customer a "Borrower" or "Patron" the terms used by the library staff. –Exclude irrelevant or out-of-scope features.

22. Guidelines How to Model the Unreal World? –e.g., Software for Telecommunication –It requires a high degree of abstraction listening carefully to the core vocabulary and concepts that domain experts use. A Common Mistake with Attributes vs. Classes –If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute.

23. Guidelines Objects vs. attributes –Attributes are ‘simple’ data types e.g., number, text –Concepts that are described by simple attributes are objects A Store has an address, phone number, etc. –As another example, consider the domain of airline reservations. Should destination be an attribute of Flight, or a separate conceptual class Airport?

24. Guidelines: Description classes When to model with Description classes –A description class Contain info that describes something else, very common in OO models A ProductDescription that records the price, picture, and text description of an Item. –If description is not separate from the underlying object, then deletion of the object results in loss of all info about that object –Also error prone due to data duplication

25. Guidelines: Description classes

26. When Are Description Classes Useful? –Add a description class (for example, ProductDescription) when: There needs to be a description about an item or service, independent of the current existence of any examples of those items or services. Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing. It reduces redundant or duplicated information.

27. Guidelines: Associations Associations –A meaningful relationship between objects –When knowledge of relationship needs to be preserved. For example, do we need to remember what SalesLineItem instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total. A Cashier may look up ProductDescriptions, but there is no need to remember the fact of a particular Cashier looking up particular ProductDescriptions. –Consider including the following associations in a domain model: Associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-remember" associations). Associations derived from the Common Associations List.

28. Guidelines: Associations Why Should We Avoid Adding Many Associations? –Many lines on the diagram will obscure it with "visual noise.“ –focus on "need-to-remember" associations. Associations are NOT –A model of data flows –DB foreign keys –Instance variables –SW object connections it is a statement that a relationship is meaningful in a purely conceptual perspective in the real domain. –Many, but not all, associations will be implemented eventually

29. Applying UML: Association Notation

30. An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation.

31. Applying UML: Association Notation Name an association based on a ClassName-VerbPhrase-ClassName format. –Simple association names such as "Has" or "Uses" are usually poor, as they seldom enhance our understanding of the domain. –Sale Paid-by CashPayment bad example (doesn't enhance meaning): Sale Uses CashPayment

32. Applying UML: Association Notation Applying UML: Roles –Each end of an association is called a role. Roles may optionally have: multiplicity expression name navigability Applying UML: Multiplicity Normally, the multiplicity at a particular moment in time

33. Applying UML: Association Notation

34. Multiple Associations Between Two Classes Can have more than 1 association between classes. A class can also have an association with itself! Can you think of an example?

35. Applying UML: Association Notation How to Find Associations with a Common Associations List?

36. Common Associations List. CategoryExamples A is a transaction related to another transaction BCashPaymentSale CancellationReservation A is a line item of a transaction BSalesLineItemSale A is a product or service for a transaction (or line item) BItemSalesLineItem (or Sale) FlightReservation A is a role related to a transaction BCustomerPayment PassengerTicket A is a physical or logical part of BDrawerRegister SquareBoard SeatAirplane A is physically or logically contained in/on BRegisterStore, ItemShelf SquareBoard PassengerAirplane A is a description for BProductDescriptionItem FlightDescriptionFlight A is known/logged/recorded/reported/captured in BSaleRegister PieceSquare ReservationFlightManifest

37. Common Associations List. CategoryExamples A is a member of BCashierStore PlayerMonopolyGame PilotAirline A is an organizational subunit of BDepartmentStore MaintenanceAirline A uses or manages or owns BCashierRegister PlayerPiece PilotAirplane A is next to BSalesLineItemSalesLineItem SquareSquare CityCity

38. Example: Associations in the Domain Models Transactions related to another transaction Sale Paid-by CashPayment. Line items of a transaction Sale Contains SalesLineItem. Product for a transaction (or line item) SalesLineItem Records-sale-of Item.

39. NextGen POS partial domain model.

40. Attributes –A logical data value of an object that needs to be remembered Some attributes are derived from other attributes –The usual ‘primitive’ data types Numbers, characters, Booleans –Common compound data types Date, time (or dateTime), address, SSN, phoneNumber, bar codes, etc. May become full class objects in design

41. Attributes Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information. –Sale needs a dateTime attribute. –Store needs a name and address. –Cashier needs an ID.

42. Applying UML: Attribute Notation

43. Showing visibility on domain model is probably overkill. We’ll talk about visibility later in the course.

44. Applying UML: Derived Attribute The total attribute in the Sale can be calculated or derived from the information in the SalesLineItems.

45. Data Types Relate with associations, not attributes. Don’t use an attribute in lieu of an association

46. Attributes

47. Two Ways to Indicate a Data Type Property of an Object

48. Do Not Use Attributes as Foreign Keys

49. Modeling Quantities

50. NextGen POS Partial Domain Model

51. References Craig Larman, Applying UML and Patterns, 3 rd Edition