Lecture 4: Elaboration Tasks and

Domain Modeling

Copyright W. Howden

Elaboration Tasks
Explore concepts from requirements use
cases
Discovering the basic pieces of the design?
Functional design:
functions in the top down abstraction

Object oriented design

choice of system architecture
class concepts in domain model

Copyright W. Howden

Stable System Design and

Domain Concepts
Systems change due to:
Incremental development, changing
requirements, post deployment enhancement

Domain modeling and design for change

Use basic classes that are a kind of simulation
of the problem domain
Functionality is added to simulation so it can be
removed and changed
Copyright W. Howden

Sample Basic Domain

Concepts in DS

dating system member

date preferences
dater characteristics
matching dates
administrator
date request
...
Copyright W. Howden

Sample Potential
Functionality in DS
Finding a date or set of possible dates
Survey of characteristics of DS members
Average frequency of date requests per
member
Profiles of most frequently selected datees
Report of number of times a dater has
changed his/her dater properties
Copyright W. Howden

Domain Model
Graphical model of basic domain concepts
and their relationships
Nodes: Concepts
May have attributes - properties of concepts-classes

Edges: Relationships between concepts

called associations
Drawn using the UML Class Diagrams
Copyright W. Howden

Sample Partial Domain Model

for Member Actor w/o Attributes
1

initiates

identifies

initiates
1*

LogOn

11

GetADate

SetMemberData

Preferences

partOf
1

describedBy

Member

captured on
*

1
1
DateDescription

captured On

DatingSystem

displays
*

NoDateMessage

displays
1

HasA
1
1

DataBase

MemberData

contained in
1

Copyright W. Howden

PersonalProps

partOf
1

DM Concept Attributes
Included in the DM node for the concept
If not enough room show them in separate
document.

Sample attributes for DS DM

Logon
-Name: : string
-UserType : char

SetMemberData
-Gender : bool
-Religion : string
-Occupation : string

Copyright W. Howden

Finding Concepts for a

Domain Model
Look for noun and noun phrase
identification from prose descriptions and
use cases
Use generic concept category checklists
includes DM-oriented special kinds
description and event concepts

Copyright W. Howden

Sample Nouns
and Noun Phrases for DS

User
Dating System
LogOn
Member
Member Option
Choice
Error Messag
MatchingDates

GetADate
DataBase
SetMemberData
Preferences
DateDescription
NoDateMessage
MemberData
PersonalProps

Copyright W. Howden

10

Concept Categories
and the DS Concepts

Physical Objects: user, member

Descriptions: personal props, prefs., dates
Roles: member, dater, administrator
Containers: DS Data Base
Organizations: DS Accounting Dept.
Events: logon, getADate, SetMemberData
Abstract nouns: session
Copyright W. Howden

11

Descriptions as
Domain Model Concepts
Descriptions of other concepts that have a
lifetime of their own
E.g. dater properties in Dating System
May be stored in data base
May be changed

Copyright W. Howden

12

Events as DM Concepts
Things to which system will have to respond
E.g. logon, date-request

Event objects created and passed to

class/object having responsibility for
handling them
Or, event objects contain knowledge of how
to perform the responsibility (in one of their
methods)
Copyright W. Howden

13

Associations
Edges between nodes in a DM
Describe semantically meaningful
relationships between concepts
May be annotated with roles and
multiplicity designators

Copyright W. Howden

14

Domain Model Example

1

initiates

identifies

initiates
1*

LogOn

11

GetADate

SetMemberData

Preferences

partOf
1

describedBy

Member

captured on
*

1
1
DateDescription

captured On

DatingSystem

displays
*

NoDateMessage

displays
1

HasA
1
1

DataBase

MemberData

contained in
1

Copyright W. Howden

PersonalProps

partOf
1

15

Association Annotations 1
Kind of relationship, sometimes referred to
as a role. In DS DM example
part of, contained in
described by, identifies (used with description
concept)
captured on, initiates (used with events)

Copyright W. Howden

16

Association Annotations 2
Multiplicity
e.g. A 1- 1 B means for every instance of an A
there is 1 instance of a B
e.g. A 1-* B means for every instance of an A
there is 0 or more B instances

Direction
various interpretations. Some relationships are
inherently directional e.g. part-of, initiates
Copyright W. Howden

17

Finding Associations
Look in use cases for relationships that are:
Needed for operation of system
Have a lifetime of importance
Good link: between DS Member and
MemberProperties
Bad link: between Administrator and GetaDate
request - not needed.

Use generic association category checklists

Copyright W. Howden

18

Association Category Checklists

A is a physical or logical part of B
E.g. Personal Characteristics are part-of Dater
Properties

A is physically or logically contained in B

E.g. MembershipData contained-in MemberDB

A is described by or identified by B
Special event-oriented relationships
Copyright W. Howden

19

Special Event-Oriented
Relationships
Actors perform actions/requests that are
modeled as events concepts in the DM
An event is associated with an actor
(concept) that initiates that event
E.g. Member initiates getDate

Each event is handled by or captured on

some entity concept
Copyright W. Howden

20

Description Associations vs
Attributes Why Associations?
Allows postponing of details
Leads to a design that facilitates change
Recognizes that some kinds of
properties/descriptions may have a life of
their own
E.g. may want to treat member descriptions
independently of members for the purposes of a
catalog of profiles
Copyright W. Howden

21

Attributes vs Associations?
Attributes
Should have primitive data type values

Associations
If property is a (complex) object, should be a separate concept
with a linking association
E.g. Dater has Dater Properties. This is a complex object and
should be its own concept. Linking association:
Dater

Describes
*

Copyright W. Howden

Dater Properties

22

Some Domain Model

Dos and Donts
Do

Dont

Static Model

Dynamic Flow Chart

E.g. Parts explosion

diagram

Real World Concepts

E.g. Gender Preference
in Dating System
Application

Do not be afraid to
overdo concept list

One entity sends a

message to another

Software Entities
E.g.
GenderPrefTextString

Leave out concepts

Copyright W. Howden

23

Domain Model Example

1

initiates

identifies

initiates
1*

LogOn

11

GetADate

SetMemberData

Preferences

partOf
1

describedBy

Member

captured on
*

1
1
DateDescription

captured On

DatingSystem

displays
*

NoDateMessage

displays
1

HasA
1
1

DataBase

MemberData

contained in
1

Copyright W. Howden

PersonalProps

partOf
1

24

Data Flow Diagram

Not a Domain Model
Data Base
1

-UsedBy
MatchingDates

DatingSystem -Produces
1
-Used By 1
DateRequest
*

-Initiates 1
*
Member

UML and Domain Models

UML does not include Domain Models
UML class diagrams
can be used for several purposes
Conceptual classes as in Domain Model
Attributes but no methods

Design classes from design activities

Graphical representation of PL classes

Copyright W. Howden

26

Use Cases, Domain Models and

System Increments
Use cases are constructed for the whole
system
Original domain model is for first
phase/iteration only
At the beginning of each new iteration, the
previous domain model is augmented to
include concepts in the next iteration
Copyright W. Howden

27

Assignment 3
Construct a domain model for the first
increment (phase 1) of your project

Copyright W. Howden

28