1. Domain Modelling Presented By Dr. Shazzad Hosain

2. Domain Models A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest. Identifying a rich set of objects or conceptual classes is at the heart of object-oriented analysis In domain model no operations are defined. It may show Domain objects or conceptual classes Associations between conceptual classes Attributes of conceptual classes

3. Domain Model, a Visual Dictionary of Abstractions

4. Domain Models are not Models of Software Components Domain model shows conceptual class, not software class

5. Domain Models and Decomposition In structured analysis the dimension of decomposition is by processes or functions. In OO analysis the division is by conceptual classes or objects. Example conceptual classes in the Sale Domain

6. Conceptual Classes 1.A conceptual class is an idea, thing or object. 2.It may be considered in terms of its symbol, intension and extension

7. Conceptual Class Identification In incremental model iteratively identify classes rather than identify all classes at the beginning. For example, if the iteration is limited to cash-only ProcessSale scenario, then create domain model only for this one It is better to overspecify a domain model with lots of fine-grained conceptual classes than to underspecify it.

8. Strategies to Identify Conceptual Classes Use a conceptual class category list Identify noun phrases, though need some art Main Success Scenario (or Basic Flow): 1.Customer arrives at the POS checkout with goods and/or services to purchase 2.Cashier starts a new sale 3.Cashier enters item identifier 4.…………

9. Conceptual Class Category List Conceptual Class CategoryExamples Physical or tangible objectsRegister, Airplane PlacesStore, Airport TransactionsSale, Payment, Reservation OrganizationsSalesDepartment, ObjectAirline Rules and policiesRefundPolicy, CancellationPolicy Things in a containerItem, Passenger …………. Table 10.1 Conceptual Class Category List

10. Candidate Conceptual Classes for the Sales Domain, an Example Register Item Store Sale Payment ProductCatalog ProductSpecification Cashier Customer Manager There is no such thing as a “correct” list. It is somewhat arbitrary collection of abstractions.

11. On Naming and Modeling Things: The Mapmaker Make a domain model in the spirit of a cartographer or mapmaker User the existing names in the territory Example, use “Borrower” or “Patron” for customer in library domain Exclude irrelevant features Pen and PaperBag may be excluded from sales domain Do not add things that are not there

12. A Common Mistake in Identifying Conceptual 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. Example: Should Store be an attribute of Sale, or a separate object Should destination be an attribute of Flight, or Airport be a separate object

13. Resolving Similar Conceptual Classes Register vs. POST (point-of-sale terminal) A domain model is not absolutely correct or wrong, but more or less useful; it is a tool of communication

14. Specification or Description Conceptual Classes Assume that, Item instance represents a physical item in a store; An item has a description, price, itemID which are not recorded any- where else. Every time a real physical item is sold, the corresponding Item instance is deleted from “software land” WorseBetter

15. Another Specification Example Let an airline company suffers a fatal crash of one of its planes Consequently cancels all flights for investigation, delete Flight instances, no longer a record of what flight routes the airline has

16. Descriptions of Services Flight example is about a service rather than a good (such as a veggieburger item) Descriptions of services or service plans are commonly needed Another example: A mobile company sells difference packages such as “bronze”, “gold”, “dijuce”, “nababi call rate” etc. So you need a description class separate from an actual sold package.

17. Modeling the Unreal World Some software system has little analogy in real world e.g. software for telecommunications. Still you can create a domain model. Message Connection Route Port Protocol Dialog

18. UML Notations, Models and Methods: Multiple Perspectives Software / design class Domain concepts / conceptual class class Implementation class e.g. Java Class

19. Lowering the Representational Gap

20. Domain Modeling Guidelines List the objects using category list and noun phrase identification technique Draw them in a domain model Add associations necessary to record relationships Add attributes in necessary

21. Domain Model: Adding Associations

22. Associations An association is a relationship between types (or more specifically instances of those types) that indicated some meaningful and interesting connection.

23. Criteria for Useful Associations Knowledge of a relationship that needs to be preserved for some duration – may milliseconds or years, depending on context. These are known as “need-to-know” associations. Example: Do we need to remember SalesLineItem instances for Sale instance. Example: Relationship between Sale and Manager? If n different objects then n*(n-1) associations. Be parsimonious. Associations derived from the Common Association List

24. UML Association Notation

25. Finding Associations – Common Association List CategoryExamples A is a physical part of B Drawer – Register Wing – Airplane A is a logical part of BSalesLineItem – Sale A is a description for BFlightDescription – Flight A is a member of B Cashier – Store Pilot – Airline A communicates with BCustomer – Cashier A is owned by BPlane – Airline ……..…………. Table 11.1 Common Association List

26. Roles Each end of an association is called a role. Roles may optionally have: Name (will discuss latter) Multiplicity Expression Navigability (will discuss latter)

27. Multiple Associations Two types may have multiple associations

28. Naming Associations TypeName – VerbPhrase – TypeName format where the verb phrase creates a sequence that is readable and meaningful in the model context Should start with a capital letter Two common and equally legal formats for a compound association name are: Paid-by PaidBy

29. How Detail Should Association Be? Finding conceptual classes is more important than finding association. The majority of time spent in domain model creation should be devoted to identifying conceptual classes, not associations.

30. NextGen POS Domain Model

31. Suggestions Focus on need-to-know associations Avoid redundant or derivable associations

32. Domain Model: Adding Attributes

33. Attributes An attribute is a logical data value of an object Keep attributes simple E.g. Boolean, Date, Number, String, Time Other examples are Address, Color, Universal Product Code (UPC) etc. Relate conceptual classes with an association, not with an attribute

34. Examples

35. Non-primitive Data Type Classes Represent as non-primitive class if If composed of separate sections Phone number, name of person There are operations usually associated with it, such as parsing / validation Social security number It has other attributes Promotional price could have start date and end date It is a quantity with a unit Payment amount has a unit of currency It is an abstraction of one or more types with some of these qualities Item identifier may be UPC or EAN (European Article Number)

36. Where to Illustrate Data Type Classes? A domain model is a tool of communication; choices about what is shown should be made with that consideration in mind.

37. Design Creep: No Attributes as Foreign Keys Relate objects with an association, not with an attribute

38. Modeling Attribute Quantities and Units Most numeric quantities should not be represented as plain numbers. Consider price or velocity that are associated with units.

39. Multiplicity From SalesLineItem to Item Derived attribute indicated with a “/” symbol

40. Domain Model Conclusion NextGen POS System Model

41. References Chapter 10, 11, 12 of “Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and the Unified Process” – by Craig Larman