1. Chapter 9 Domain Models The classic OOAD model

2. Fig. 9.1

3. Domain Model Representation of real-situation conceptual classes Not software objects! Model: –Domain objects (conceptual classes) –Associations –Attributes of conceptual classes

4. Things not in a Domain Model Software artifacts Responsibilities or methods Data Model

5. Fig. 9.2

6. Fig. 9.3

7. Fig. 9.4

8. Fig. 9.5

9. Why? Understand key concepts of domain –Key concepts –Vocabulary Lower the gap between representations

10. Fig. 9.6

11. How? Reuse an existing model –Easier –Less error prone –Many problems are not new Category list –Text has a table of common categories (table 9.1) Noun phrases –Use with care!

12. Examples using concept list Fig 9.7 is POS domain Fig 9.8 is Monopoly

13. Fig. 9.7

14. Fig. 9.8

15. Guidelines Report objects Think like a mapmaker Modeling the unreal world Attributes vs. classes Description classes

16. Fig. 9.9

17. Fig. 9.10

18. Associations Things that need to be remembered Use with care May or may not be implemented in software Naming: –className-verbPhrase-className

19. Fig. 9.11

20. Fig. 9.12

21. Fig. 9.13

22. Fig. 9.14

23. Fig. 9.15

24. Fig. 9.16

25. Fig. 9.17

26. Fig. 9.18

27. Attributes Information that needs to be remembered

28. Fig. 9.19

29. Fig. 9.20

30. Fig. 9.21

31. Fig. 9.22

32. Fig. 9.23

33. Datatypes Use simple types Define complex types where needed –Subparts –Needs operations –Has attributes (e.g. start date) –Units –Polymorphic types

34. Fig. 9.24

35. Fig. 9.25

36. Fig. 9.26

37. Fig. 9.27

38. Fig. 9.28

39. Summary – Domain Models A domain model is used to understand the domain It is an artifact that is developed iteratively in Agile