Bài Giảng Phân tích thiết kế hướng đối tượng (phần 3) ppt

Domain Model
Domain Model
Lecture 3
Lecture 3
Hoa Sen University 1
Agenda
Agenda

Recap

Case Requirements

Elaboration process

Domain model
–
Introduction and definition
–
How to create a domain model
Hoa Sen University 2
Recap
Recap

Inception activities

Different types of requirements

Scenario & Use case

Writing Use Cases


Use Case Diagram

Use case relationships
Hoa Sen University 3
Case requirements
Case requirements

The requirements for the first iteration of
the NextGen POS:
–
Implement a basic, key scenario of the
Process Sale use case
–
Implement a Start Up use case as necessary
to support the initialization needs of the
iteration
–
Nothing fancy or complex is handled
–
No collaboration with external services
–
No complex pricing rules are applied
Hoa Sen University 4
Case requirements
Case requirements

Monopoly
–
Implement a basic, key scenario of the Play
Monopoly Game use case: players moving

around the squares of the board
–
Implement a start Up use case as necessary
to support the initialization needs of the
iteration
–
Two to eight players can play
–
A game is played as a series of rounds
Hoa Sen University 5
Case requirements
Case requirements

Monopoly (cont)
–
Play the game for only 20 rounds
–
After the dice are rolled, the name of the player and
the roll are displayed. When the player moves and
lands on a square, the name of the player and the
name of the square that the player landed on are
displayed.
–
In iteration-1 there is no money, no winner or loser, no
properties to buy or rent to pay, and no special
squares of any kind
–
Square name will be “Go”, “Square 1”, “Square 2”,
…“Square 39”
Hoa Sen University 6

Incremental Development
Incremental Development

Incremental development for the same
use case across iteration
Hoa Sen University 7
1
A use case or feature is
often too complex to
complete in one short
iteration.
Therefore, different parts
or scenarios must be
allocated to different
iterations.
Use Case
Process Sale
2 3 . . .
Use Case
Process Sale
Use Case
Process Sale
Use Case
Process Rentals
Feature:
Logging
Process: inception
Process: inception

What happened in inception

–
Last only one week
–
Most actors, goals and use cases named
–
Most use cases written in brief format; 10-20% of the use cases are
written in fully dressed detail
–
Recommendations on what components to buy/build/reuse, to be
refined in elaboration

Technical proof-of-concept prototypes and other
investigations to explore the technical feasibility of
special requirements/

High-level candidate architecture and components
proposed – NOT necessary to be final or correct

Plan for the first iteration
Hoa Sen University 8
Process: on to Elaboration
Process: on to Elaboration

What happens in Elaboration
–
The core, risky software architecture is programmed
and tested
–
The majority of requirements are discovered and
stabilized

–
The major risks are mitigated or retired
–
Commonly, 2 or more timeboxed iterations

Elaboration in one sentence
–
Build the core architecture, resolve the high-risk
elements, define most requirements, and estimate
the overall schedule and resources.
Hoa Sen University 9
Process: on to Elaboration
Process: on to Elaboration

Best practices in elaboration
–
Do short timeboxed risk-driven iterations
–
Start programming early
–
Adaptively design, implement, and test the
core and risky parts of the architecture
–
Test early, often, realistically
–
Write most of the use cases and other
requirements in detail, through a series of
workshops, once per elaboration iteration
Hoa Sen University 10
Domain models

Domain models

Illustrates noteworthy concepts in a
domain

Drawn with UML class diagram

As with all things in an agile modelling and
UP spirit, a domain model is optional

Input
–
Problem Description, Use Cases, …

Output
–
A set of class diagrams
Hoa Sen University 11
Example
Example
Hoa Sen University 12
Register
Item
Store
address
name
Sale
date
time
Payment

amount
Sales
LineItem
quantity
Stocked-in
*
Houses
1 *
Contained-in
1 *
Records-sale-of
0 1
Paid-by
1
1
1
1
1
1
0 1
1
Captured-on 
concept
or domain
object
association
attributes
Identifying a rich set of conceptual classes is at the heart of OO analysis
What is a domain model
What is a domain model


A domain model is a visual representation of
conceptual classes or real-situation objects in a
domain.
–
Various names

conceptual models, domain object models, analysis object
models

A domain model is illustrated with a set of
CLASS DIAGRAMS in which no operations
(method signatures) are defined
Hoa Sen University 13
Domain models is a visual dictionary
Domain models is a visual dictionary

Domain model provides a conceptual
perspective
–
Domain objects or conceptual classes
–
Associations between conceptual classes
–
Attributes of conceptual classes

The information it illustrates could
alternatively have been expressed in plain
text
Hoa Sen University 14

Domain model is not a picture of
Domain model is not a picture of
software objects
software objects

Domain model is a
visualization of
things in a real-
world domain of
interest

Not suitable in a
domain model
–
Software artefacts
–
Responsibilities or
methods
Hoa Sen University 15
Sale
dateTime
visualization of a real-world concept in
the domain of interest
it is a not a picture of a software class
SalesDatabase
software artifact; not part
of domain model
software class; not part
of domain model
Sale

date
time
print()
What are conceptual classes
What are conceptual classes

A conceptual class may be
considered in terms of
–
Symbol – words or images
representing a conceptual
class
–
Intension – the definition of
a conceptual class
–
Extension – the set of
examples to which the
conceptual class applies
Hoa Sen University 16
Sale
date
time
concept's symbol
"A sale represents the event
of a purchase transaction. It
has a date and time."
concept's intension
sale-1
sale-3

sale-2
sale-4
concept's extension
Domain model vs. Data model
Domain model vs. Data model

Data model – persistent data to be stored
somewhere

Domain model also include
–
Temporary object
–
Object with no attribute
Hoa Sen University 17
Motivation
Motivation

Help to understand the key concepts in a business or problem
domain

Lower representational gap with OO Modelling
Hoa Sen University 18
Payment
amount
Sale
date
time
Pays-for
Payment

amount: Money
getBalance(): Money
Sale
date: Date
startTime: Time
getTotal(): Money
. . .
Pays-for
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.
UP Design Model
The object-oriented developer has taken inspiration from the real world domain
in creating software classes.
Therefore, the representational gap between how stakeholders conceive the
domain, and its representation in software, has been lowered.
1
1
1
1
A Payment in the Domain Model
is a concept, but a Payment in
the Design Model is a software
class. They are not the same
thing, but the former inspired the
naming and definition of the
latter.
This reduces the representational
gap.
This is one of the big ideas in
object technology.

inspires
objects
and
names in
How to create a Domain Model
How to create a Domain Model

Steps
–
Find the conceptual classes
–
Draw them as classes in a UML class diagram
–
Add associations and attributes
Hoa Sen University 19
Find conceptual classes
Find conceptual classes

Three strategies to find conceptual classes
–
Reuse or modify existing models

There are published, well-crafted domain models
and data models for common domains: inventory,
finance, health

Books: Analysis patterns by Martin Fowler, Data
Model Patterns by David Hay, Data Model
Resource Book by Len Silverston
–

Use a category list
–
Identify noun phrases
Hoa Sen University 20
Use a category list
Use a category list

Use a conceptual class category list:
–
Physical or tangible objects
Register, Airplane
–
Specifications, descriptions of things
ProductSpecification, FlightDescription
–
Places
Store, Airport
–
Transactions
Sale, Payment, Reservation
–
etc. (see Table 9.1 for a fuller list)
Hoa Sen University 21
Noun Phrase Identification
Noun Phrase Identification

Noun Phrase Identification [Abbot 83]
–
Analyse textual description of the domain


Identify nouns and noun phrases (indicate
candidate classes or attributes)

Caveats:
–
Automatic mapping isn’t possible
–
Textual descriptions are ambiguous! (different
words may refer to the same class)
Hoa Sen University 22
Example: flow of event
Example: flow of event

The customer enters a store with the intention of
buying a toy for his 3 years old child Alice.

Help must be available within less than one
minute.

The store owner gives advice to the customer.
The advice depends on the age range of the
child and the attributes of the toy.

The customer selects a dangerous toy which is
kind of unsuitable for the child.

The store owner recommends a soft doll.
Hoa Sen University 23
Mapping parts of speech to object
Mapping parts of speech to object

model components
model components
Part of speech Model component Examples
Proper noun Instance Alice
Common noun Class Customer, toy
Doing verb Operation Buy, recommend
Being verb Inheritance Is a kind of, is one
of
Having verb Aggregation
(Composition)
Has, consists of,
includes
Modal verb Constraints Must be
Adjective attributes Attributes 3 years old
Hoa Sen University 24
Example: find and draw conceptual
Example: find and draw conceptual
classes
classes

Case study: POS Domain
–
Input

fully dressed use case model (excellent textual
description of the domain)

Iteration-1: success (cash-only) scenario of Process
Sale use case.
–

Strategy: category list
–
There is no such thing as a “correct” list. It is a
somewhat ARBITRARY collection of domain
vocabulary that the modellers consider
noteworthy
Hoa Sen University 25