2016W - 341-15 Domain Model

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 23

SOEN 341

Domain Model

Definition
from Wikipedia

domain model in software engineering is a


conceptual model of all the topics related to
A

a specific problem.
It describes the various entities, their attributes,
roles, and relationships, plus the constraints that
govern the problem domain.
(A conceptual model represents 'concepts' (entities)
and relationships between them.)

What is a domain model?


A domain model captures the most
important types of objects in the context of
the business. The domain model
represents the things that exist or events
that transpire in the business
environment. I. Jacobsen

cern.ch/it-div-fio-lcg/stateman/slides/Domain
%20modelling.ppt

Domain Model
A domain model should document the key
concepts in the terminology of the system.
It should show the relationships between the
major entities of the system, and identify
important methods and attributes.
It can be used to establish an understanding
between the developer and the client, and can
help constrain the scope of the project.

Domain Model
A domain model will relate objects in
the system domain to each other. It
will define concepts and terms.
Objects in the domain model can be:
Physical objects
Abstract concepts
http://www.comptechdoc.org/independent/uml/begin/umldomainmode
l.html

Domain model
Illustrates meaningful conceptual
classes in problem domain
Represents real-world concepts, not
software components
Software-oriented class diagrams will
be developed later, during design

Domain model
After the list of concepts is complete a domain model
should be made. Consider which simple items should be
attributes of objects.

The domain model is a static model.

Time
flow, with sequence of events or information flow are not
shown in the domain model.

Avoid showing procedural relationships.


This model does not include software. The objects in the
domain model are candidates for programming objects.
(Note: the UML model incliudes attributes, but no
methods)

Why do a domain model?

Gives a conceptual framework of the


things in the problem space
Helps you think focus on semantics
Provides a glossary of terms noun
based
It is a static view - meaning it allows us
convey time invariant business rules
Foundation for use case/workflow
modelling
Based on the defined structure, we can
describe the state of the problem
domain at any time.

Simple domain model


Attribute
Association

Person
first name : String
last name : String
salary

Company

+employer name

+employee
1..*

0..1

Role

+owner
*

Car
type
name

<<Rule>>
If a person is not employed by a
company then they do not have a car.
Domain class

Features of a domain
model
The following features enable us to express time
invariant static business rules for a domain:-

Domain classes each domain class denotes a type


of object.

Attributes an attribute is the description of a


named slot of a specified type in a domain class; each
instance of the class separately holds a value.

Associations an association is a relationship


between two (or more) domain classes that describes
links between their object instances. Associations can
have roles, describing the multiplicity and
participation of a class in the relationship.

Additional rules complex rules that cannot be


shown with symbology can be shown with attached

How do I make a domain model?


Perform the following in very short
iterations:
o
o
o
o
o

Make a list of candidate domain classes.


Draw these classes in a UML domain model.
If possible, add brief descriptions for the classes.
Identify any associations that are necessary.
Decide if some domain classes are really just
attributes.
o Where helpful, identify role names and multiplicity
for associations.
o Add any additional static rules as UML notes that
cannot be conveyed with UML symbols.

Concentrate more on just identifying


domain classes in early iterations !

Domain classes
Each domain class denotes a type of
object. It is a descriptor for a set of
things that share common features.
Classes can be:o Business objects - represent things that are
manipulated in the business e.g. Order.
o Real world objects things that the business
keeps track of e.g. Contact, Site.
o Events that transpire - e.g. sale and
payment.

A domain class has attributes and


associations with other classes
(discussed below). It is important that a
domain class is given a good description

Domain classes
An obvious way to identify domain
classes is to identify nouns and phrases
in textual descriptions of a domain.
Consider a use case description as
follows: 1. Customer arrives at a checkout with goods
and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records the sale line item and
presents the item description, price and running
total.

Attributes
An attribute is a logical data value of an
object.
Include the following attributes in a domain
model: Those for which the requirements
suggest a need to remember information.
An attribute can be a more complex type
whose structure is unimportant to the
problem, so we treat it like a simple type

Attributes
A domain class sounds like an attribute
if: o It relies on an associated class for its
identity e.g. order number class
associated to an order class. The order
number sounds suspiciously like an
attribute of order.
o It is a simple data type e.g. order number
is a simple integer. Now it really sounds like
an attribute!

Associations
Associations describe semantic relationships between
concepts and may be bidirectional. Use an association
to relate classes, not attributes. Some associations may
be:
A is a part of B
line item of
Contained inside
Is a member of
Is a policy of
Is next to
Uses
Communicates with
A relates to B due to a transaction
http://www.comptechdoc.org/independent/uml/begin/umldomainmodel

Associations
When creating associations, ask yourself,
"Does one need to know about the other?".
If the answer is yes, there should probably be
an association. There may be more than one
association between two objects.

http://www.comptechdoc.org/independent/uml/begin/umldomainmodel

Multiplicity
Describes how many instances of one
concept can be associated with one instance
of the related concept.

Definition Detail
The domain model also identifies the
relationships among all the entities within the
scope of the problem domain, and commonly
identifies their attributes.
An accurate domain model can also serve as
an essential input to solution implementation
within a software development cycle since the
model elements comprising the problem
domain can serve as key inputs to code
construction.

Summary
In the UML domain model the following are
shown:
1. Concepts (Objects)
2. Attributes of Objects - Attributes must be
simple attributes such as numbers. They
cannot be objects, dimensioned numbers, or
keys to part of a database.
3. Association between objects
4. Multiplicity
5. Optional direction of relationship arrow
6. Optional role of object
http://www.comptechdoc.org/independent/uml/begin/umldomainmodel.h
tml

Domain Detail: Some Guidelines


Put items up in this order:
1. Concepts
2. Label associations
3. Types on attributes

If concepts have both data (attributes) and


behavior (methods) they more likely fit in
the domain model.
Analyze items that may have additional
types.
http://www.comptechdoc.org/independent/uml/begin/umldomainmo
del.html

References
Scott Ambler (Agile)
http://agiledata.org/essays/agileDataModeling.html
Domain Driven Design and Development In
Practice
http://www.infoq.com/articles/ddd-in-practice
Computech.org
http://www.comptechdoc.org/independent/uml/begi
n/
umldomainmodel.htm

You might also like