Presentation on Domain Modelling Submitted by WWW.ASSIGNMENTPOINT.COM

1. Presentation on Domain ModellingSubmitted byWWW.ASSIGNMENTPOINT.COM www.assignmentpoint.com

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 www.assignmentpoint.com

3. Domain Model, a Visual Dictionary of Abstractions www.assignmentpoint.com

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

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 www.assignmentpoint.com

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

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. www.assignmentpoint.com

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): Customer arrives at the POS checkout with goods and/or services to purchase Cashier starts a new sale Cashier enters item identifier ………… www.assignmentpoint.com

9. Conceptual Class Category List Table 10.1 Conceptual Class Category List www.assignmentpoint.com

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

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 www.assignmentpoint.com

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 Storebe an attribute of Sale, or a separate object • Should destination be an attribute of Flight, or Airport be a separate object www.assignmentpoint.com

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 www.assignmentpoint.com

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” Worse Better www.assignmentpoint.com

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 www.assignmentpoint.com

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. www.assignmentpoint.com

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 Route Protocol Connection Dialog Port www.assignmentpoint.com

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

19. Lowering the Representational Gap www.assignmentpoint.com

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 www.assignmentpoint.com

21. Domain Model: Adding Associations www.assignmentpoint.com

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

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 www.assignmentpoint.com

24. UML Association Notation www.assignmentpoint.com

25. Finding Associations – Common Association List www.assignmentpoint.com 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) www.assignmentpoint.com

27. Multiple Associations • Two types may have multiple associations www.assignmentpoint.com

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 www.assignmentpoint.com

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. www.assignmentpoint.com

30. NextGen POS Domain Model www.assignmentpoint.com

31. Suggestions • Focus on need-to-know associations • Avoid redundant or derivable associations www.assignmentpoint.com

32. Domain Model: Adding Attributes www.assignmentpoint.com

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 www.assignmentpoint.com

34. Examples www.assignmentpoint.com

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) www.assignmentpoint.com

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. www.assignmentpoint.com

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

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. www.assignmentpoint.com

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

40. Domain Model Conclusion NextGen POS System Model www.assignmentpoint.com