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

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,

Domain Model

Lecture 3

– Introduction and definition

– How to create a domain model

 Inception activities

 Different types of requirements

 Scenario & Use case

 Writing Use Cases

 Use Case Diagram

 Use case relationships

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

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

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”

Incremental Development

 Incremental development for the same use case across iteration

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

Use Case Process Sale Process SaleUse Case

Use Case Process Rentals Feature:

Logging

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

Process: on to 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

– Build the core architecture, resolve the high-risk

elements, define most requirements, and estimate the overall schedule and resources.

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

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

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 

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

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

Domain model is not a picture of

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

time print()

avoid

What are conceptual classes

– Extension – the set of

examples to which the

conceptual class applies

Sale date time

concept's symbol

"A sale represents the event

of a purchase transaction It has a date and time."

Domain model vs Data model

 Data model – persistent data to be stored

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.

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

 Steps

– Find the conceptual classes

– Draw them as classes in a UML class diagram– Add associations and attributes

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

Use a category list

 Use a conceptual class category list:

– Physical or tangible objects

Sale, Payment, Reservation

– etc (see Table 9.1 for a fuller list)

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)

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 advice depends on the age range of the

child and the attributes of the toy

kind of unsuitable for the child

Mapping parts of speech to object

model components

Part of speech Model component Examples

of

Example: find and draw conceptual

– 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

Initial POS domain model

Ledger

Initial Domain model of Monopoly

game simulation

Agile modelling style

 It is normal to miss significant conceptual

classes during early domain modeling and

to discover them later during DESIGN

sketching or PROGRAMMING.

 We can maintain the model by drawing it

with tool

 OFTEN, a long-life OO analysis domain

model does not add value

Include report objects?

 It has duplicate information contained in sale

and payment

– In general, showing a report of other information in a

domain model is not useful

– However, it might has special role in terms of

business rules We might have a reason to show it in

the model.

Class or Attributes

 Class or attribute?

– If we do not think of some conceptual class X

as a number or text in the real world, X is

probably a conceptual class, not an attributes

Description Class

 What’s the rationale for representing the description or

specification separately from the item

 In the following domain model, can you tell the difference between (description, price, itemID) and serial number?

Item description price

serial number itemID

ProductDescription description

price

Item serial number Describes Better

Worse

Description classes

 When are description classes

useful?

– There needs to be a description

about an item or service,

independent of the current

existence of any examples of

those items or services

– Deleting instances of things

they describe results in a loss

of information that needs to be

maintained, but was incorrectly

associated with the deleted

FlightDescription number

Airport name

Describes-flights -to Described-by

Flight date number time

Airport name Flies-to

 Definition

– An association is a relationship between objects that indicates

some meaningful and interesting connection

– UML def.: associations are defined as “the semantic relationship between two or more classifiers that involve connections among

their instances.”

Sale Register 1 Records-current 1

association

When to show association

relationship needs to be preserved for some

duration

– In the POS domain

Sale.

we do not need to remember who looked up what after the sales has been made.

– In the monopoly domain

will land, but we do not need to remember that

Associations and implementation

 There is no direct relationship between

associations and implementation.

 Associations do not indicate a certain

implementation construct.

 Many associations may be implemented in software differently

Association Notation

Sale

0 1 1

-"reading direction arrow"

-it has no meaning except to indicate direction of

reading the association label -often excluded

– Sales paid-by CashPayment

 Bad alternative: Sales uses CashPayment

– Piece is-on Square

 Bad alternative: Piece has Square

Applying UML: multiplicity

 Multiplicity defines how many instances of a class A can

be associated with one instance of class B

 Eg “In countries with

monogamy laws, a person

can be Married-to only one

other person at any

particular moment, even

though over a span of time,

that same person may be

married to many persons.”

The answer depends on our interest in using the model Typically and practically, the muliplicity communicates a

domain constraint that we care about being able to check in software, if this relationship was implemented or

reflected in software objects or a database For example, a particular item may become sold or discarded, and thus

no longer stocked in the store From this viewpoint, "0 1" is logical, but

Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensure

that an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault or

corruption in the software elements or data.

This partial domain model does not represent software objects, but the multiplicities record constraints whose

practical value is usually related to our interest in building software or databases (that reflect our real -world domain)

with validity checks From this viewpoint, "1" may be the desired value

*

Multiple association between two

POS partial domain model

POS partial domain model

Register

Item Store

Sale

CashPayment

Sales LineItem

Cashier Customer

Product Catalog

Product Description

Stocks

*

Houses 1 *

Logs-*

 Works-on

1 1

1

1

1 1

1 1

Records-1

Monopoly partial domain model

 An attribute is a logical data value of an

object

 When to show attribute

– Include attributes that the requirements

suggest or imply a need to remember

information

– Eg

Public visibility readonly attribute with initialization

Person firstName

middleName : [0 1]

lastName

Optional value

Suitable attribute types

 Most attribute types

should be what are

currentRegister

Cashier name

Register number

Worse

destination is a complex concept

Data types as attributes

 We sometimes represent what may initially be considered a number

or string as a new data type class in the domain model

 We can show the data type only in attribute compartment or as a

separate class associated with another class.

OK

OK

Product Description

Product Description itemId : ItemID

Store address : Address

1

ItemID id

manufacturerCode countryCode

Address street1

street2 cityName

Attributes are NOT foreign keys

 During implementation, there are many ways to relate objects,

including foreign key, but the decision should be deferred till

DESIGN stage.

Cashier name

currentRegisterNumber

Cashier name

Register number

amount : Money

variation: Money is a specialized Quantity whose

unit is a currency

Iterative and evolutionary domain

model

 Is the domain model correct?

– There is no such thing as a single correct

domain model!

– Domain model is incrementally evolve over

several iterations

– In each iteration, the domain model is limited

to the prior and current scenarios under

consideration