1. TK2023 Object-Oriented Software Engineering CHAPTER 5 DOMAIN MODELLING

2. INTRODUCTION One of the steps in object-oriented analysis is the decomposition of a domain of interest into individual conceptual classes or objects (real- world objects). An important artifact created in this step is a domain model (also known as conceptual model, domain object model and analysis object model).

3. DOMAIN MODELS A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest. In UML, a domain model is illustrated with a set of class diagrams in which no operations are defined. It shows: conceptual classes (concepts / domain objects) associations between conceptual classes attributes of conceptual classes

4. Register Item Store address name Sale date time Payment amount Sales LineItem quantity Stocked-in * Houses 1.. * Contained-in 1.. * Records-sale-of 0..1 Paid-by 1 1 1 1 1 1 0..1 1 Captured-on  concept or domain object association attributes

5. DOMAIN MODEL - A VISUAL DICTIONARY OF ABSTRACTIONS Note that the diagram in the previous slide depicts an abstraction of the conceptual classes; details which are uninteresting to the modellers are ignored in the diagram. The visual makes it easy to comprehend the discrete elements and their relationships. Thus, the domain model may be considered a visual dictionary of abstractions of the domain.

6. DOMAIN MODELS DO NOT SHOW SOFTWARE COMPONENTS A domain model is a visualization of things in the real-world domain of interest, not of software classes. The following elements are not suitable in a domain model:  software artifacts  responsibilities or methods Sale date print() POSApplet

7. IDENTIFYING CONCEPTUAL CLASSES In iterative development, a domain model is incrementally built over several iterations in the elaboration phase. In each iteration, the domain model is limited to the prior and current scenarios under consideration. It is okay to miss conceptual classes during the initial identification step. The domain model can be updated when they are discovered later (e.g. during design work).

8. STRATEGIES FOR IDENTIFYING CONCEPTUAL CLASSES The following techniques can be used:  use a conceptual class category listconceptual class category  identify noun phrases Identify nouns and noun phrases in textual descriptions of a domain, and consider them as candidate classes or attributes.textual descriptions of a domain Weakness: natural language is imprecise  E.g. different noun phrases may represent the same conceptual class or attribute.

9.  use analysis patterns Analysis patterns are existing partial domain models created by experts

10. CASE STUDY: PROCESS SALE Based on a simplified scenario of Process Sale, the following candidate conceptual classes are identified using the first two techniques above: RegisterProductSpecification ItemSalesLineItem StoreCashier SaleCustomer PaymentManager ProductCatalog

11. REPORT OBJECTS Should "receipt" be included in the domain model?  One reason to exclude it: A receipt is a report of a sale. In general, it is not useful to include conceptual classes that reports information that can be derived from other sources.  One reason to include it: A receipt has a special role in the domain. A customer needs a receipt in order to return bought items.

12. BUILDING A DOMAIN MODEL Apply the following steps: 1.Identify candidate conceptual classes related to the current requirements (use case) under consideration. 2.Represent those classes in a domain model. 3.Add associations necessary to record relationships for which there is a need to preserve some memory. 4.Add attributes necessary to fulfill the information requirements.

13. SOME GUIDELINES Use the vocabulary of the domain when naming conceptual classes and attributes.  For example, in the library domain, the term "Borrower" or "Patron" is used rather than "Customer" You should not include conceptual classes in the problem domain not pertinent to the requirements.  For the case study, "Pen" and "PlasticBag" should not be included.

14. You should not include things not in the problem domain.  For example, "Flight" does not exist in the library domain.

15. ATTRIBUTE OR CONCEPTUAL CLASS? A common mistake when building a domain model is to represent something as an atribute when it should have been a conceptual class. OR Represent "store" as an attribute Represent "store" as a conceptual class

16. Use the following rule of thumb: If we do not think of some conceptual class X as a number or text in the real world, then X is probably a conceptual class and not an attribute.

17. Another example, OR

18. Consider our case study. Let's assume that:  An "Item" represents a physical item in a store.  An "Item" has a description, price and itemID, which are not recorded elsewhere.  Everyone working in the store has amnesia.  Every time a real physical item is sold, a corresponding software object "Item" is deleted from the computer memory. “Rice Brand X” RM0.60 11234 “Rice Brand X” RM0.60 11234 “Rice Brand X” RM0.60 11234 “Rice Brand X” RM11.00 U110-134 “Rice Brand X” RM11.00 U110-134 “Rice Brand X” RM11.00 U110-134 SPECIFICATION OR DESCRIPTION CONCEPTUAL CLASSES

19. Problems:  Information about the price of a "Rice Brand X" product is lost if the shop is sold out of "Rice Brand X" products.  Space inefficiency as the price and itemID of "Rice Brand X" are duplicated for every "Item" instance of the same product. This illustrates the need for conceptual classes that are specifications or descriptions of other things.

20. Example:

21. Add a specification or description conceptual class 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 results in a loss of information that needs to be maintained.  It reduces redundant or duplicated information.

22. Another example: Airport name Flight date time FlightDescription number 1 * 1 * Describes-flights-to 1 * Described-by * 1 Airport name Flight date number time * 1 Flies-to 1 *

23. CASE STUDY: INITIAL DOMAIN MODEL Based on the candidate conceptual classes identified previously, an initial domain model can be produced as follows:

24. ASSOCIATIONS An association is a relationship between classes that indicates some meaningful and interesting connection.

25. THE UML ASSOCIATION NOTATION associations in domain models are inherently bidirectional reading direction arrow - no special meaning, it's just to aid reading multiplicity expressions "Cashier initiates Sale"

26. CRITERIA FOR USEFUL ASSOCIATIONS We need to be selective when adding associations to a domain model.  There can be n*(n-1) possible associations in a domain model with n different conceptual classes.  Too many associations in a domain model can make it difficult to understand which defeats its purpose as a communication tool.

27. Associations worth adding to a domain model are usually those for which knowledge of the relationship needs to be preserved for some duration (even for a millisecond). For example, The SalesLineItem objects associated with a Sale object need to be remembered; otherwise, it would not be possible to print a receipt, for instance.

28. Also, include associations as suggested by the requirements (use cases).

29. FINDING ASSOCIATIONS 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-know" associations).  Associations derived from the Common Associations List.Common Associations List Give priority to these categories  A is a physical or logical part of B  A is physically or logically contained in/on B  A is recorded in B

30. USEFUL GUIDELINES Focus on "need-to-know" associations. It is more important to identify conceptual classes than to identify associations. Too many associations tend to confuse a domain model. Avoid showing redundant or derivable associations.

31. Example: DERIVABLE

32. MULTIPLICITY Multiplicity defines how many instances of a class A can be associated with one instance of a class B. association multiplicity

33. zero or more; "many" one or more one to 40 exactly 5 T T T T * 1.. * 1..40 5 T 3, 5, 8 exactly 3, 5, or 8

34. Note that the multiplicity value is dependent on our interest as a modeler and software developer. Consider the following possibilities: husband Person 1 1..4 Married-to wife 1 Person 1 Married-to wife 1 1 husband Person 1 1..* Married-to wife 1 husband

35. NAMING ASSOCIATIONS The name of an association should be a verb or a verb phrase. Ensure that it creates a sequence that is readable and meaningful in the model context. By convention, the default direction is left to right or top to bottom. "Airline Employs Person" "Plane Assigned-to Flight"

36. MULTIPLE ASSOCIATIONS BETWEEN TWO CLASSES It is not uncommon to have multiple associations between two conceptual classes. Consider the following: Both associations need to be shown separately as they indicate distinctly different relationships.

37. ASSOCIATIONS AND IMPLEMENTATIONS Associations in a domain model represent relationships that are meaningful in the real world. Not all associations in a domain model need to be implemented in software.

38. DOMAIN MODEL FOR POS SYSTEM (WITH ASSOCIATIONS) Register Item Store Sale Payment Sales LineItem CashierCustomer Product Catalog Product Specification Stocks * Houses 1.. * Used-by * Contains 1.. * Describes * Captured-on Contained-in 1.. * Records-sale-of 0..1 Paid-by Is-for Logs- completed *  Works-on 1 1 1 1..* 1 1 1 1 1 1 1 0..11 1 - - 1 1

39. ADDING ATTRIBUTES Besides associations, we also need to identify attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.

40. ATTRIBUTE An attribute is a logical data value of an object. A domain model should include attributes for which the requirements (such as use cases) suggest or imply a need to remember information. For example, a receipt normally includes the date and time of sale.

41. NOTATION FOR ATTRIBUTES The type of an attribute is optional. attributes

42. GUIDELINES FOR IDENTIFYING ATTRIBUTES The attributes in a domain model should preferably be simple attributes or data types. Examples of attribute types:  Boolean, Date, Number, String (Text), Time  Address, Colour, PhoneNumber, SocialSecurityNumber, UniversalProductCode, Postcode

43. Consider the following: Cashier name currentRegister Cashier name Register number Works-on 1 1 This is not a "simple" attribute

44. Relate conceptual classes with an association, not with an attribute. destination is a complex concept

45. ATTRIBUTES AS FOREIGN KEYS Do not use attributes as foreign keys to relate conceptual classes (as typically done in relational database designs). Use associations to relate those classes.

46. DOMAIN MODEL FOR POS SYSTEM Register Item Store Sale Payment Sales LineItem CashierCustomer Product Catalog Product Specification Stocks * Houses 1.. * Used-by * Contains 1.. * Describes * Captured-on Contained-in 1.. * Records-sale-of 0..1 Paid-by Is-for Logs- completed *  Works-on 1 1 1 1..* 1 1 1 1 1 1 1 0..11 1 - - 1 1 quantity dateTime total amountTendered name address number itemID description price number