CMPT 370: Information Systems Design
Lecture Topic: Requirement Determination
Class Exercise: Domain Models
Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003
Objectives

This lecture covers two main topics:
• UML as a Language
• Introduction to Domain Modeling
–
–
–
–
Concept of models
Concept of domain modeling
Techniques to model the domain
Documenting domain models
Domain modeling is also referred to as Business modeling
2
UML As a Language




Basic Architecture
Mechanisms of UML Problem-Solving
Views
Strengths of a UML Model
3
Basic Architecture of UML

“Things” in a Metamodel
• Class and Association (Common structural
behaviours, properties, and relationships)
• Object and Link (Instances)

Labeling Metamodel
• Descriptive Words
• Multiplicities: 1-to-1, 1-to-many, etc.

Metamodel Composed of:
• Behaviour Elements: Collaborations, Use Cases,
State Machines, Common Behaviour
• Foundation Elements: Core, Auxiliary Elements,
Extension Mechanisms, Data Types
• Management of the Metamodel
4
Mechanism of UML Problem-Solving (1)

Perspectives of Purpose
• Conceptualize a problem (Analysis)
• Specify a Solution (Design)
• Construct and Realize the Solution

Dichotomies (how things viewed in two
different perspectives)
• Type & Instance
• Specification & Realization
• Static & Dynamic / Structural & Behavioural
5
Mechanism of UML Problem-Solving (2)

Layers of Abstraction represented in a
System
• Subsystem Levels (high-level)
• Classes
• Method Level (low-level)

Customizing
• Stereotypes (marking elements in << >>)
• Tagged Values (specify properties of model)
• Constraints (specify conditions for meaning)
6
Views and Perspectives of UML

User View
• Use Cases

Structural View
• Class Diagrams
• Object Diagrams

Behaviour View
•
•
•
•

Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
Implementation View
• Component Diagrams

Environment View
• Deployment Diagrams
7
Strength in UML Models

Syntax
• Legal Structure of the Language
• Allows for Customization / Future Extensions

Semantics
• Meaning of the Model
• Reduce Ambiguity

Executable
• Generate Code for Forward-Engineering

Integration Flow
• Meaning between different UML Artifacts (b/w
different perspectives/views)
8
From UML to Domain Modeling



UML is a specific language for Unified
Modeling in Object Oriented Analysis &
Design
Abstracting/Generalizing again to go back
and talk about Modeling
Will specialize and talk about Domain
Modeling
9
What is a model?

A model is an abstraction of what is real and
required (as-is or to-be)

Models are made up of diagrams
• A model must be comprehensive but focused, the real
world can be complex, messy and unfocussed
• Models are not just diagrams, the diagrams are only the
visual rendering of the model and express views of the
model
Human understanding of diagrams is constrained by the limits
of human cognitive capabilities, such as short term memory
• A model is the interpretation of its diagrams
10
Why as-is and to-be models?

A model is an abstraction of what is real and
required (as-is : to-be)
• First we model the as-is to understand the current context
of roles and processes
• Then we model to-be to understand how we can change or
optimize roles and processes to provide value to our
stakeholders
• If as-is and to-be are the same we are probably not
attaining a good use of resources. We use domain
modeling to provide the opportunity to better analyze the
problem so as to determine a better solution
11
Types of diagrams

Two types of diagrams,
• Static diagrams – represent the pieces of the
system and their relationship
• Dynamic diagram – represent the behaviour of
the elements of the system and their interactions
The term model and diagram are often used interchangeably
12
Textbook Modeling Terminology

Data and Relationships (Domain)
• ERD - Entity Relationship Diagram
• ORD - Object Relationship Diagram
– In UML: Class Diagrams

Processes/Algorithms with inputs and
outputs
• DFD - Data Flow Diagrams
– In UML: Collaboration or Sequence Diagrams

Ordering/Triggering Processes
• FSM – Finite State Machine
– In UML: Statechart Diagram
13
Context of domain modeling
•Build the right product
•Build the product right
Requirements
( Analysis)
Design
‘What’
‘How’
SMOP
-fuzzy-
14
Context of domain modeling

We need to model our
understanding of the context,
requirements, practices and
constraints to ensure that we
have the problem and the
problem setting right.

Only then do we model the
architecture, specification,
design, implementation and
deployment of what the
builders should build.

Models are not right or wrong,
just more or less useful
alignment
fit
Architecture
Domain
Product
rules
roles
requirements
constraints
standards
affordances
Solution
15
Why do we need domain models?

•
•
Stakeholders

??
Gap between stakeholders and developers
Domain models begin to close this gap
•
•
•

Capture needs in a format that is interpretable
and understandable to stakeholders
It validates user needs
Model needs in a format that begins to
formulate an understanding of the solution to
developers
Re-iterate
•
•
•
•
Developers
Stakeholders have the vision
Developers need the specifications
•
Document the nature of things
Store the essence of a thing for retrieval
Communicate the nature of things to others
Discuss the correctness of the model without
observing real objects in action
Can write a program to implement things
16
Domain requirements considerations

Understandability
• Requirements need to be expressed in the language of the
application domain
• These requirements may not be understood by software
engineers developing the system
– Domain models begin the road to understanding through the
identification of vocabulary

Implicitness
• Domain specialists (SMEs) understand the area so well
that they do not think of making the domain requirements
explicit
– Domain models help stakeholders fill in the gaps so that the
model can be properly interpreted
17
What is domain modeling?

A domain is a package of business features and
services at some level of abstraction that is
meaningful to an organization and its stakeholders
• These are the essential activities, services and things

Domain modeling – the study of these fundamental
business abstractions.

Modeling at this level is conceptual and
independent of implementation

Domain models are useful for bounding a domain
so it is useful as well for software and planning
purposes.
18
What is a domain model?
Domain models include the following
 The context for multiple applications within an area
of study (a domain)
 A definition of scope for the domain
 Information (or objects) at the conceptual level
 Features (or use cases), including factors that lead
to variations, again high level and business oriented
 Operational/ behavioral characteristics (consider
that this will be more important when we do Class
Diagrams later)
19
Domain model use

A domain model must be capable of being directly
validated and explained by the end users.

There should be no implementation detail in the
domain model.

Domain information is the critical context for design
decisions.

Design decisions must be traceable to the domain.
20
Domain models

Domain models should be simple

The simple model is not necessarily the first one
that we come up with

Finding a simple model takes time and effort

When a simple model is found it is obvious (we will
know it when we see it)

Simple models make things easier to design, build,
maintain and expand
21
How to model domains
1.
Identify essential information through the use of
a vocabulary understandable by stakeholders Concepts
2.
Identify roles that will perform interactions with
the system – Actors
3.
Identify interactions or domain activities – Use
Cases
4.
Illustrate the domain model using a set of class
diagrams
22
Questions to ask when domain modeling

For each concept
• What is known about this concept
• What parts are this concept made of

For each action
•
•
•
•
Who is involved in this action
What steps are involved
Whom does it affect
What could be different from one occasion to
another
23
Organizing/Representing Concepts in a Data Model (1)

“Things” / Physical Objects / Tangible Things /
External Entities
• People, Equipment, Cars, Robot, Letters, Reports, Signals

Places
• Parking Spot, University, Warehouse

Organizations, Organizational Units
• Team, Flight Crew

Roles
• Customer, Sub-Teacher, Manager

Incidents/Transactions to be recorded / Records of
Events
• Purchases, Customer Order, Airplane Landing, Phone
Call, Sale, Payment
• Transaction Line Items (sub-records on receipt)
From Various Sources, one good one is Larman, Craig - “Applying UML and Patterns”
24
Organizing/Representing Concepts in a Domain Model (2)

Specifications / Procedures / Rules and Policies
• Repair Manual, Recipes, Organic Compound, Refund
Policy

Intangible Concepts / Abstract Noun Concepts
• Bank Account, Time Delay, Sound Recording, Hunger,
Acrophobia

Relationships / Interaction b/w two objects
• Customer’s Sales Associate, Flight’s Captain, Marriage

Structures (Containers and Things in a Container)
• Airplane parts: Body, Wings, Engines, Tail

Displayable Field
• String, Icon, Image
25
Associations in a Domain Model (1)

Has / Ownership
• A Plane is owned by an Airline

Uses / Manages
• An Employee is managed by a Manager

Membership / Organizational Unit Information
• A Pilot is a member of a Union

Communications With
• A Passenger communicates with A Flight Attendant

Part-of (Physical or Logical)
• A Wing is part-of an Airplane

Containment (Physically or Logically)
• Passengers are physically contained in an Airplane
From Larman, Craig - “Applying UML and Patterns”
26
Associations in a Domain Model (2)

Description-for
• A Flight Description is a description for a Flight

Events
• Flight Arrival is an event related to a Flight

Transactional
• Line Item of Transaction for (Flight Leg is a line item of
transaction for a Booking)
• Is Related to a Transaction (Customer is related to a
Payment)
• Is a Transaction related to another Transaction
(Reservation and Cancellation)

Captured Information (Recorded / Reported)
• A Reservation is reported in a Flight Manifest
27
Vocabulary In Models

Vocabulary may apply to more than one
concept
• Need to get agreement among stakeholders
• Each concept must be uniquely labeled
– The ‘hand’ concept
• A concept may be labeled more than once
– Customer, member
28
Relationships in Models

Illustrations of Links between Entities
• Map showing route for Navigation

Navigability Preference
• Arrow if a Relationship goes one-way
• Labeling for Readability (Clockwise)

Cardinality
• Optionality (lower-bound – can or must exist)
• Multiplicity (upper-bound – 1, n, * are used)
–
–
–
–
–
0..1 – zero or one
1 – one and only one (default, usually omitted)
0..* – zero or more (also can be written as just *)
1..* - one or more
n1..n2 – between n1 and n2
29
Relationships in Models

‘can be’ should be modeled as a 0..n
• Use ‘may be’ to interpret this cardinality in a relationship
• The activity cardinality should be validated and agreed to
by stakeholders
– Is rents a 1..* or a 0..* relationship?

All relationships should be modeled
• A ‘has’ relationship can sometimes be modeled using
a more active verb (ie: owns, is ordered by)
• Conversations about the domain should be recognizable in
the model (have we identified all concepts – round, rotate
dealer )
• Some relationships can be derived and thus need not be
modeled (a card game uses cards)
30
Modeling considerations

Level of abstraction
• Abstraction: a description that omits details that are not
relevant (generalize)
– Abstract concepts
– Abstract relationships
• Try and keep away from detail and implementation
• Remove implementation details through abstraction
– “Barcode” can be abstracted to “Code Identifier”
• Helps us to look a problem before determining solution
• When in doubt go more abstract
– One person’s view of reality can be different from another’s
– Try and remove inconsistencies

Modeling is an active exercise
• This is not passive discovery, it is active construction
31
Modeling Example

Card Game domain
• What is some of the common vocabulary ?
• Who are some of the actors?
• What are usual “use cases” in a card game?
32
Modeling Example

Card Game domain
• Common vocabulary
– deck, card, suit, card value, deal, trick, trump, game,
game rules
• Actors
– dealer, player
• Use cases
– deals, trumps, shuffles, plays
33
Card game domain model
Deck
1..*
uses
52
Card Game
has
Card
has
1..*
is played by
1..*
is held in
1..*
Player
plays
Hand
has
4
Card Value
is a kind of
holds
has
Suit
Rule
has
Dealer
deals
Deal
34
Modeling Result
A domain model shows the main types of
interests
• Concepts and links on how they interact
(Relationships)
• High level abstractions should accomplish a
business task or objective or should abstract a
group of such actions
• The resulting business model acts as a central
glossary of terms for all projects associated with
it

A domain model is owned by the people
who own the business
35
Domain Model Validation

Domain models should be validated with
stakeholders
• Technically Models are (by default) read from left to right
and top to bottom –
– consider that in general think of it as “clockwise direction”
– Exceptions can be made in UML, need a little by-itself arrow
head (not on an association) pointing to denote direction
•
•
•
•
Can the model be read and understood
Is the vocabulary used applicable to the domain
Are the concepts correct
Do the relationships between concepts exist and are they
correctly labeled
• Is the cardinality of each relationship correct
36
A word about “Normalization” and Modeling



Highly developed process for relationship
modeling in relational database design
(data)
It is concerned more with the proper
assignment of Primary Keys, Foreign Keys,
Composite Keys, and proper division
between relationships in database design
In object design, we need to consider we
have things like object references, etc. in
order to accomplish links between objects
37
Textbook References

Section 2.1 - Fundamentals of Object Technology
• REQUIRED READING for upcoming classes

Section 2.2 – Guided Tutorial In Analysis Modeling
• Good reading to understand potential flow for project
• Sections 2.2.4, 2.2.5 – are partial examples of our domain
modeling exercise, but heavily influenced by UML
diagrams to produce

Section 2.3 – Problem Statement for Case Studies
• Examples that are referenced throughout the book
(University Enrolment, Video Store, Contact Mgmt,
Telemarketing)
38
In-Class Exercises for Week #3

Domain Modeling
•
•
•
•
Validate Card Domain Model against games
DM from Problem Statement (textbook)
DM from Use Case(s)
DM from Requirements Document
39