Domain Modelling
Sunday, 23 September 12
Part 1: Conceptual Classes
Sunday, 23 September 12
What is a Domain Model
Sunday, 23 September 12
a diagram (or set of diagrams) which represents real
world domain objects
conceptual classes
not a set of diagrams describing software classes, or
software objects with responsibilities
Why make a Domain Model?
to understand what concepts need to be modelled by
our system, and how those concepts relate
a springboard for designing software objects
Sunday, 23 September 12
What should it show?
Sunday, 23 September 12
conceptual classes
associations between conceptual classes
attributes of conceptual classes
Example
from Ch 9 Applying UML & Patterns (Larman 2004)
Sunday, 23 September 12
What should it avoid?
Sunday, 23 September 12
software artifacts
such as the User Interface or databases
responsibilities and methods
these should appear in sequence and class diagrams
Example
Include:
Sale
date
time
Avoid:
from Ch 9 Applying UML & Patterns (Larman 2004)
Sunday, 23 September 12
Identifying Conceptual
Classes
Sunday, 23 September 12
try to represent all the objects in the domain, whether
they are:
tangible objects
product, book
intangible concepts
course, route
people
student, lecturer
places
city, classroom
events
sale, enrolment
...or something else
booking policy
Noun-Phrase Identification
Sunday, 23 September 12
one way to identify conceptual classes
from client documents or use case descriptions
note that this wont capture everything
student
Example
1.
The user requests a list of courses currently available for enrolment.
2.
The system retrieves the list of courses available and displays the list to the user.
3.
The system provides the user with the opportunity to select a course or to exit the use case.
4.
The user selects a course for which he or she wants to enrol.
5.
The system retrieves the details for the chosen course, including the course outline, timetable and
eligibility requirements and displays the details to the user.
6.
The user confirms that he or she wants to enrol for the course.
7.
The system checks that the user has taken and passed the pre-requisite courses for the chosen
course.
8.
The system checks that the user is not already enrolled on a course whose timetable clashes with the
chosen course.
9.
The system records that the user is now enrolled to the chosen course, updating the list of students.
10.
The system informs the user that enrolment has been successful, and offers the student the opportunity
to receive proof of enrolment.
...
Sunday, 23 September 12
Maintain the context of the
problem domain
where a concept already has a name, use it
dont add concepts that dont belong
dont include concepts from beyond the domains
boundary
model actual concepts rather than over-specific
versions of them
Sunday, 23 September 12
exhaust pipe, brake calliper, windshield - too specific
auto part (with an attribute of type)
- better
Object or Attribute
If we do not think of come conceptual class X as a
number or text in the real world, X is probably a
conceptual class, not an attribute.
Craig Larman in Applying UML & Patterns (2004)
Sunday, 23 September 12
Examples
Sale
Sale
store
Flight
Airport
Store
location
Flight
Airport
name
from Ch 9 Applying UML & Patterns (Larman 2004)
both Store and Airport represent concepts of interest in their own
right, so we model them as conceptual classes rather than attributes
Sunday, 23 September 12
Adding Specification or
Description Conceptual Classes
sometimes we need to separate out the description of
a concept from the concept itself, so that even if no
instances of the concept exist at a given point in time,
its description will still be present in the system
doing this can reduce unnecessary redundancy in
recording information when we move into design and
build
Sunday, 23 September 12
Examples
from Ch 9 Applying UML & Patterns (Larman 2004)
Sunday, 23 September 12
Examples
Describes-flights-to
from Ch 9 Applying UML & Patterns (Larman 2004)
Sunday, 23 September 12
Domain versus Design Models
from Ch 9 Applying UML & Patterns (Larman 2004)
Sunday, 23 September 12
Part 2: Associations
Sunday, 23 September 12
Associations
Sunday, 23 September 12
we should model the important relationships between
conceptual classes
not every relationship, that would create clutter and
confusion
not too few, we want a useful model
for each association, provide:
a short yet meaningful text label
the multiplicity
Example
Student
name
Course
takes
title
teaches
Lecturer
name
Sunday, 23 September 12
Multiplicity
how many instances of class A can be associated with a
single class B at a particular point in time
Student
name
8..*
takes
Course
0..3
title
0..3
teaches
1
Lecturer
name
Sunday, 23 September 12
Types of Multiplicity
Sunday, 23 September 12
many (zero or more)
1..*
many (one or more)
0..3
zero to three
1..3
one to three
exactly 8
2,4,6
exactly 2, 4 or 6
Many-to-Many?
where possible try to make all associations 1-to-n (or
0-to-n), since this will help to identify deeper concepts
in the domain
Student
Enrolment
1
name
0..3
makes
Course
8..*
name
is upon
title
0..3
teaches
1
Lecturer
name
Sunday, 23 September 12
Identifying Associations
one approach is to list for each conceptual class how it
relates to others:
each Student...
takes zero to three courses
has exactly one timetable
...
each Lecturer...
teaches zero to three courses
belongs to one or two
departments
...
is taught by exactly one lecturer
is taken by 8 to many students
each Course...
Sunday, 23 September 12
Multiple & Reflexive Associations
can two conceptual classes have multiple associations
with each other, and can a class associate with itself?
yes,
Sales Rep
1..*
1..*
makes sales in
name
manages
and yes
Course
title
Area
1 title
*
*
is pre-requisite for
but in each case it might be better to use generalisation and/or to add
further conceptual classes to the model
Sunday, 23 September 12
Generalisation
sometimes conceptual classes are (sub) types of
another class:
Student
student id
8..*
takes
Course
0..3
title
0..3
teaches
1
Person
name
Sunday, 23 September 12
Lecturer
employee #
Composition and Aggregation
Composition:
Chess Board
64
Square
colour
consists of
without the chess board, the square wouldnt exist...
Aggregation:
Class List
0..3
8..*
contains
Student
name
...but without the class list the student would
Sunday, 23 September 12
Part 3: Attributes
Sunday, 23 September 12
Object or Attribute
(reminder)
If we do not think of come conceptual class X as a
number or text in the real world, X is probably a
conceptual class, not an attribute.
Craig Larman in Applying UML & Patterns (2004)
Sunday, 23 September 12
No Foreign Keys
Student
student id
timetable
fails the simple number or text test
better:
Student
Timetable
student id
Why avoid listing foreign keys as attributes?
- because there may be more than one way to implement an
association in design
Sunday, 23 September 12
To conclude
find many associations between the conceptual classes,
but only model the useful ones
take care with multiplicity
Sunday, 23 September 12
domain modelling can be taken further - such as using
association classes and packages - but the techniques and
artifacts demonstrated here are sophisticated enough
for you to analyse and model most problem domains
References & Further Reading
base structure and figures taken from:
a different approach (just skipping to class diagrams):
Sunday, 23 September 12
Applying UML & Patterns (Larman 2004), Chapters 9, 10,
11 & 27
Object-Oriented Systems Analysis and Design (Bennett et
al, 2nd Edition, 2002), Chapter 7