Tham khảo tài liệu 'bài giảng phân tích thiết kế hướng đối tượng (phần 3)', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
AMBIENT/
Chủ đề:
Nội dung Text: Bài Giảng Phân tích thiết kế hướng đối tượng (phần 3)
- Domain Model
Lecture 3
Hoa Sen University 1
- Agenda
Recap
Case Requirements
Elaboration process
Domain model
– Introduction and definition
– How to create a domain model
Hoa Sen University 2
- 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
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
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
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 for the same
use case across iteration
A use case or feature is
1 2 3 ... often too complex to
complete in one short
iteration.
Therefore, different parts
Use Case Use Case Use Case or scenarios must be
Process Sale Process Sale Process Sale allocated to different
iterations.
Use Case
Process Rentals
Feature:
Logging
Hoa Sen University 7
- 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
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
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
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
concept Sales
Item
or domain LineItem Records-sale-of
object 1
quantity 0..1
1..* *
Stocked-in
association Contained-in
1 1
Sale Store
attributes date address
time 0..1 name
1
1
Houses
Paid-by 1..*
1 Register
Captured-on o
Payment
1
amount
Identifying a rich set of conceptual classes is at the heart of OO analysis
Hoa Sen University 12
- 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 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
software objects
Domain model is
visualization of a real-world concept in
a visualization of Sale
dateTime
the domain of interest
it is a not a picture of a software class
things in a real-
world domain of
interest av
o id
SalesDatabase
software artifact; not part
of domain model
Not suitable in a
domain model av
o id
date
Sale
software class; not part
of domain model
– Software artefacts
time
print()
– Responsibilities or
methods
Hoa Sen University 15
- What are conceptual classes
A conceptual class may be
considered in terms of date
Sale concept's symbol
– Symbol – words or images time
representing a conceptual
class "A sale represents the event
of a purchase transaction. It
has a date and time."
concept's intension
– Intension – the definition of
a conceptual class
sale-1
– Extension – the set of sale-3
sale-2 concept's extension
examples to which the sale-4
conceptual class applies
Hoa Sen University 16
- 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
Help to understand the key concepts in a business or problem
domain
Lower representational gap with OO Modelling
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.
Sale
A Payment in the Domain Model Payment 1
1 Pays-for
is a concept, but a Payment in date
the Design Model is a software amount
time
class. They are not the same
thing, but the former inspired the
inspires
naming and definition of the
objects
latter.
and
names in
This reduces the representational
gap.
Sale
This is one of the big ideas in Payment
object technology. 1 1 date: Date
Pays-for
amount: Money startTime: Time
getBalance(): Money getTotal(): Money
...
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.
Hoa Sen University 18
- 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
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
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
