Chapter 9 Domain Models The classic OOAD model

Fig. 9.1

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

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

Fig. 9.2

Fig. 9.3

Fig. 9.4

Fig. 9.5

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

Fig. 9.6

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!

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

Fig. 9.7

Fig. 9.8

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

Fig. 9.9

Fig. 9.10

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

Fig. 9.11

Fig. 9.12

Fig. 9.13

Fig. 9.14

Fig. 9.15

Fig. 9.16

Fig. 9.17

Fig. 9.18

Attributes Information that needs to be remembered

Fig. 9.19

Fig. 9.20

Fig. 9.21

Fig. 9.22

Fig. 9.23

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

Fig. 9.24

Fig. 9.25

Fig. 9.26

Fig. 9.27

Fig. 9.28

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