1

>

Modeling

Dr. Anıl Koyuncu

> Domain Analysis & Modeling
➢Domain analysis and modeling identifies the system elements needed to
solve the problem (i.e., meet the requirements)
➢Why? —The goal of domain modeling is to understand how system-to-be will
work
• Requirements analysis determined how users will interact with system-to-be (external
behavior)
• Domain modeling determines how elements of system-to-be interact (internal behavior) to
produce the external behavior
➢How? —We do domain modeling based on sources:
• Knowledge of how system-to-be is supposed to behave (from requirements analysis, e.g.,
use cases)
• Studying the work domain (or, problem domain)
• Knowledge base of software designs
• Developer’s past experience with software design
> Domain Model Relationships

3
 How to create the domain model?
> (If we are not readily familiar with the domain.)
1. Find the conceptual classes
Strategies:
1. Use a conceptual class category list (derived from thinking about the
target domain)
2. Identify noun phrases
2. Draw them as classes in a UML class diagram
3. Add associations and attributes

4
> Use a conceptual class category list
➢For the target domain, first think about class categories, then think
of the classed

5
> Identify noun phrases

6
> Identify noun phrases

7
> Identify noun phrases

8
> Identify noun phrases
Use Case: ProcessSale
Main Success Scenario (or Basic Flow):
1. The customer arrives at a POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price calculated
from a set of price rules. Cashier repeats steps 2-3 until indicates done.
5. System presents total amount with taxes calculated.
6. Cashier tells customer the total amount and asks for payment.
7. Customer pays and System handles payment.
8. System logs the completed sale and sends sale and payment information to the external accounting
(for accounting and commissions) and Inventory systems (to update inventory).
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).

9
> Identify noun phrases
Use Case: ProcessSale
Main Success Scenario (or Basic Flow):
1. The customer arrives at a POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price calculated
from a set of price rules. Cashier repeats steps 2-3 until indicates done.
5. System presents total amount with taxes calculated.
6. Cashier tells customer the total amount and asks for payment.
7. Customer pays and System handles payment.
8. System logs the completed sale and sends sale and payment information to the external accounting
(for accounting and commissions) and Inventory systems (to update inventory).
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).

10
 Identifying Concepts (Domain Classes) from Noun
> Phrases (NPs)
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. Class or Attribute?

3. Cashier enters item identifier.

4. System records the sales line item and presents the item
description, price and running total.

11
>

12
> How to identify Attributes ?
A domain class sounds like an attribute if ...
• It relies on an associated class for it’s identity – e.g. ‘order number’
class associated to an ‘order’ class.
• The ‘order number’ sounds suspiciously like an attribute of ‘order’.
• It is a simple data type – e.g. ‘order number’ is a simple integer.
• Now it really sounds like an attribute!

13
> Use Cases vs. Domain Model

In use case analysis, we consider In domain analysis, we consider

the system as a “black box” the system as a “transparent box”

(a) (b)
S y s te m D o m a in M o d e l

U s e C a s e 1

U s e C a s e 2

A c to r
A c to r
U s e C a s e N A c to rs
A c to rs
 What is Domain Modeling
> Example: ATM Machine
S y s te m

(b)
1
4 2
7
0
8
5
9
6
3
Domain Model
A c to r
(B a n k
A c to r Concept 3
(A (R e m o te
c u s to m e r) T Concept 1
M d a ta c e n te r)
m
a
c
h
in
e
)
Concept n
(a)
Actor Concept 2

Actor
> Building Domain Model from Use Cases

Step 1: Identifying the boundary concepts

Boundary concepts
Concept 3
Concept 1
Actor C
Actor A

Step 2: Identifying the internal concepts

Concept 2
Concept 4
Actor B Actor D
Concept 3
Concept 1
Actor C
Concept 6
Actor A
Concept 5

Internal
Concept 2 concepts
Concept 4
Actor B Actor D
Step 2: Identifying the internal concepts
Internal concepts “route” data between boundaries
• Data format conversion
• Data protection policies
> Use Case 1: Unlock

Use Case UC-1: Unlock

Related Requirements: REQ1, REQ3, REQ4, and REQ5 stated in Table 2-1

Initiating Actor: Any of: Tenant, Landlord

Actor’s Goal: To disarm the lock and enter, and get space lighted up automatically.

Participating Actors: LockDevice, LightSwitch, Timer

• The set of valid keys stored in the system database is non-empty.

Preconditions: • The system displays the menu of available functions; at the door keypad the menu
choices are “Lock” and “Unlock.”
Postconditions: The auto-lock timer has started countdown from autoLockInterval.

Flow of Events for Main Success Scenario:

→ 1. Tenant/Landlord arrives at the door and selects the menu item “Unlock”
2. include::AuthenticateUser (UC-7)
System (a) signals to the Tenant/Landlord the lock status, e.g., “disarmed,” (b) signals to
 3.
LockDevice to disarm the lock, and (c) signals to LightSwitch to turn the light on
 4. System signals to the Timer to start the auto-lock timer countdown
→ 5. Tenant/Landlord opens the door, enters the home [and shuts the door and locks]
> Extracting the Responsibilities

Responsibility Description Concept Name

Container for user’s authentication data, such as pass-code, timestamp, door identification, etc. Key

Verify whether or not the key-code entered by the user is valid. KeyChecker

Container for the collection of valid keys associated with doors and users. KeyStorage

Operate the lock device to armed/disarmed positions. LockOperator

Operate the light switch to turn the light on/off. LightOperator

Operate the alarm bell to signal possible break-ins. AlarmOperator

Block the input to deny more attempts if too many unsuccessful attempts. Controller

Log all interactions with the system in persistent storage. Logger

> Domain Model (1)

S y m b o liz e s S y m b o liz e s
“ w o r k e r ” -ty p e “ th in g ” -ty p e
c o n c e p t. c o n c e p t.
« e n tit y » « e n tit y »
K e yC h e cke r K e y S to ra g e

« b o u n d a ry » « e n tit y »
K e y c o d e E n tr y K e y

« b o u n d a ry » « c o n tr o l»
S ta tu s D is p la y C o n tr o lle r L o c k D e v ic e
« b o u n d a ry »
H o u s e h o ld D e v ic e O p e r a to r

R e s id e n t L ig h tS w itc h

Domain concepts for subsystem #1 of safe home access

> Extracting Associations

20
> Extracting Attributes

21
 «entity»
Key

> Domain Model (2) user code

access location
timestamp

Domain model for Associations: who needs to work together, not how they work together

UC-1: Unlock Concept pair | Association description | Association name

« e n t it y » r e t r ie v e s v a lid k e y s « e n t it y »
K eyC hecker K e y S to ra g e

v e r if ie s

Model (2)

conveys requests
« e n t it y »
o b t a in s A ttrib u te s
Key
« b o u n d a ry»
K e y c o d e E n tr y u s e r I d e n t it y C o d e
t im e s t a m p
d o o r L o c a t io n

A s s o c ia tio n
« b o u n d a ry» nam e
S t a t u s D is p la y
« c o n tr o l» L o c k D e v ic e
C o n t r o lle r c o n v e y s re q u e s ts « b o u n d a ry»
H o u s e h o ld D e v ic e O p e r a t o r
n u m O fA tte m p ts
m a x N u m O fA tte m p ts d e v ic e S t a t u s e s

“ R e a d in g d ire c tio n a rro w .”

R e s id e n t H a s n o m e a n in g ; it o n ly h e lp s re a d in g
L ig h tS w itc h
th e a s s o c ia tio n la b e l, a n d is o fte n le ft o u t.
>

23