Download - Domain Modeling

DOMAINMODELING

Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM

BITS PilaniOff-Campus Work-Integrated Learning Programmes

AGENDA

� Visualization

� Adding Association

� Adding Attributes

SETTING DIRECTION

� Now that we are starting to look at diagrams, I

want to emphasize that this is a class on analysis

and design, not diagramming. While it may look

good on your resume that you can use UML, your

career depends on being able to translate ideas career depends on being able to translate ideas

into good systems.

That is much more difficult.

All the best!

DOMAIN MODEL RELATIONSHIPS

Domain ModelBusiness Model

Classes, attributes,

associationsElaboration on some terms

Use Case Model

Interaction Diagrams

Glossary

Design

Requirements

Domain

objects

WHAT IS A DOMAIN MODEL ?

A domain model:

� Illustrates meaningful conceptual classes in a problem

domain.

� Is a representation of real-world concepts, not software � Is a representation of real-world concepts, not software

components.

� Is NOT a set of diagrams describing software classes, or

software objects and their responsibilities.

A DOMAIN MODEL IS THE MOST IMPORTANT OO

ARTIFACT

� Its development entails identifying a rich set of

conceptual classes, and is at the heart of object

oriented analysis.

� It is a visual representation of the decomposition of a

domain into individual conceptual classes or objects.

It is a visual dictionary of noteworthy abstractions.� It is a visual dictionary of noteworthy abstractions.

DOMAIN MODEL UML NOTATION

� Illustrated using a set of class diagrams for which no

operations are defined.

It may contain:

� Domain Objects or Conceptual Classes

� Associations between conceptual classes

� Attributes of conceptual classes � Attributes of conceptual classes

A D M S

ARTIFACT

A Conceptual class:

Sale

Date

Time

SalesDatabase

Sale

Software Artifacts:

vs.Time Sale

Date

Time

Print()

THINK OF CONCEPTUAL CLASSES IN TERMS OF:

� Symbols – words or images

� Intensions – its definition

� Extensions – the set of examples to which it applies

� Symbols and Intensions are the practical

considerations when creating a domain model.

DECOMPOSITION:

� A central distinction between Object-oriented analysis

and structured analysis is the division by objects

rather than by functions during decomposition.

� During each iteration, only objects in current scenarios

are considered for addition to the domain model.are considered for addition to the domain model.

CONCEPTUAL CLASS IDENTIFICATION:

� It is better to over-specify a domain with lots of fine-

grained conceptual classes than it is to under-specify

it.

� Discover classes up front rather than later.

� Unlike data modeling, it is valid to include concepts for

which there are no attributes, or which have a purely which there are no attributes, or which have a purely

behavioral role rather than an informational role.

IDENTIFY CONCEPTUAL CLASSES BY CATEGORY

LIST:

Common Candidates for classes include:

Tangible objects, Descriptions, Roles,

Places, Transactions, Containers,

Systems, Abstract nouns, Rules,

Organizations, Events, Processes,

Written Materials, Catalogs, Records,

Financial Instruments and Services

IDENTIFY CONCEPTUAL CLASSES BY NOUN

PHRASE:

� Identify Nouns and Noun Phrases in textual

descriptions of the domain.

� Fully dressed Use Cases are good for this type of

linguistic analysis.

It’s not strictly a mechanical process:It’s not strictly a mechanical process:

� Words may be ambiguous

� Different phrases may represent the same concepts.

SALES DOMAIN EXAMPLE –

‘PURCHASE ITEMS’ USE CASE

�We find concepts such as Register, Sale, Item,

Customer, Receipt etc. in this use case.

Should we include Receipt in the Model?

�Con: As a report of a sale, it’s duplicate info.

�Pro: Business Rules for a Return require that

the customer has a receipt.

�Suggestion: Include it in the iteration where

the Return Use Case is covered.

STEPS TO CREATE A DOMAIN MODEL

� Identify Candidate Conceptual classes

� Draw them in a Domain Model

� Add associations necessary to record the relationships

that must be retained

� Add attributes necessary for information to be

preservedpreserved

� Apply existing Analysis Patterns

APPLY THE MAPMAKER STRATEGY

� Use existing names for things, the vocabulary of the

domain

� Exclude irrelevant features

� Do not add things that are not there

A COMMON MISTAKE - CLASSES AS ATTRIBUTES

� Rule: If we do not think of a thing as a number or text

in the real world, then it is probably a conceptual

class.

� If it takes up space, then it is likely a conceptual

class.

Examples:Examples:

� A Store is not an attribute of a Sale

� A Destination is not an attribute of a flight

SPECIFICATION OR DESCRIPTION

CONCEPTUAL CLASSES

� A Class that records information about an item.

� Even if all Instances of the item are sold out, the

description remains.

� Avoids duplication of recording the descriptive

information with each instance of the item.information with each instance of the item.

DESCRIPTION OF A SERVICE EXAMPLE (FLIGHT)

Airport

Name

vs.

Flight

Date

Time

Number

Flies-to

Number

Flight

Date

Time

FlightDesc

Date

Time

Airport

NameDescribed

-by

Describes

-flights-to

MONOPOLY CONCEPTS (CANDIDATES)

Monopoly Game Player Piece

Die Board Square

AGENDA

� Visualization



OBJECTIVES

� Identify associations for a domain model.

� Distinguish between need-to-know and

comprehension-only associations.

INTRODUCTION

� Identify associations of conceptual classes needed to

satisfy the information requirements of current

scenarios.

� Also identify the aid in comprehending the domain

model.model.

ASSOCIATIONS

An association is a relationship between instances of

types that indicates some meaningful and interesting

connection

ASSOCIATIONS

association

Register

Sale Records-current

1 1

USEFUL ASSOCIATIONS

� Associations for which knowledge of the relationship

needs to be preserved for some duration.

� Associations derived from the Common Associations

List.

UML ASSOCIATION NOTATION

� An association is represented as a line between classes

with an association name.

� Associations are inherently bidirectional.

� Optional reading direction arrow is only an aid to the

reader of the diagram.reader of the diagram.

UML ASSOCIATION NOTATION

- “read ing d irec tio n a rrow ”

- it h a s no m ean ing excep t to

ind ic a te d irec tio n o f read ing the

asso c ia tio n lab e l

- o ften exc lud ed

R eg is te r

S a le R eco rd s-cu rren t

1 11 1

m ultip lic ity

a sso c ia tio n nam e

FINDING ASSOCIATIONS

-COMMON ASSOCIATIONS LIST

The common categories that are worth considering are:

� A is a physical part of B . Eg: Wing-Airplane

� A is a logical part of B. Eg: SalesLineItem-Sale.

Eg: Register- Store.� A is physically contained in B . Eg: Register- Store.

COMMON ASSOCIATIONS LIST 2

� A is logically contained in B. Eg:ItemDescription-

Catalog.

� A is a description of B.Eg:ItemDescription-Item.

A is a line item of a transaction or report � A is a line item of a transaction or report

B.Eg:SalesLineItem-Sale.

� A is a member of B .Eg: Cashier-Store.

� A uses or manages B.Eg:Cashier-Register.


� A is known/logged/recorded/reported/captured in B.Eg:

Sale-Register.

� A is an organizational subunit of B .

Eg:Department-Store.

� A communicates with B. Eg:Customer-Cashier.

Eg:City-City� A is next to B. Eg:City-City.


� A is related to a transaction B. Eg: Customer-

Payment.

� A is a transaction related to another transaction B.

Eg:Payment-Sale.Eg:Payment-Sale.

� A is next to B. Eg:City-City.

� A is owned by B. Eg:Register-Store.

� A is an event related to B. Eg:Sale-Customer.

HIGH-PRIORITY ASSOCIATIONS

� A is a physical or logical part of B.

� A is physically or logically contained in/on B.

� A is recorded in B.

ASSOCIATIONS GUIDELINES

� The knowledge of the relationship needs to be

preserved for some duration.

� Identifying conceptual classes is more important than

identifying associations.

� Avoid showing redundant or derivable associations.

ROLES

� Each end of an association is called a role.

� Roles may have

� name

� multiplicity expression� multiplicity expression

� navigability

MULTIPLICITY

� Multiplicity defines the number of instances of a class

A ,that can be associated with one instance of class

B,at a particular moment.

� Eg: In countries with monogamy laws,a person can be � Eg: In countries with monogamy laws,a person can be

married to 1 person at any particular time.But over a

span of time one person can be married to many

persons.

MULTIPLICITY

Store

Item Stocks

1 *

multiplicity of the

role

MULTIPLICITY

T

*

zero or more;

“many”

T

1..*

one or more;

T

1..40

one to 40

T

5

exactly 5

T

3,5,8

exactly 3,5 or 8

NAMING ASSOCIATIONS

� Name an association based on TypeName-VerbPhrase-

TypeName format.

� Names should start with a capital letter.

� Legal formats are:� Legal formats are:

� Paid-by

� PaidBy

ASSOCIATIONS NAMES

Paid-by Captures

1..* 11

Contains

1..*

1

Store

Register Sale Payment

1

Supervises

*

Assigned-to Assigned-to

* *1

Employs

1..*

1

Airline

Person Flight Plane

11

MULTIPLE ASSOCIATIONS

� Two types may have multiple associations between

them.

MULTIPLE ASSOCIATIONS

1

1

*

*

Flies-from

Flight Airport

Flies-to

Flies-from

IMPLEMENTATION

� The domain model can be updated to reflect the newly

discovered associations.

� But,avoid updating any documentation or model

unless there is a concrete justification for future use.

� Defer design considerations so that extraneous

information is not included and maximizing design

options later on.options later on.

CLEANING ASSOCIATIONS 1

� Do not overwhelm the domain model with associations

that are not strongly required.

� Use need-to-know criterion for maintaining

associations.

� Deleting associations that are not strictly demanded

on a need-to-know basis can create a model that

misses the point.misses the point.

CLEANING ASSOCIATIONS 2

� Add comprehension-only associations to enrich critical

understanding of the domain.

A PARTIAL DOMAIN MODEL

Logs-

1

Describes

1..*

1

Records-sale-of

Described-by

*

1..* 1

1

Stocks

* 1

Contains

1..* 1

Product

Catalog

Product

Specfication

Store Item Sales

LineItem

Used-by

* 0..1 *

Initiated-by

Paid-by

Captured-on

Records-sales-on

Logs-

completed

1

1

1

1 1

1 1

1

1

*

1

1..* 1

1 1

Register Manager Sale

Cashier

Customer Payment

Started-by

Houses

1..*

Contained-in

Initiated-by

CONCLUSION

� When in doubt if the concept is required,keep the

concept.

� When in doubt if the the association is required,drop

it.

Do not keep derivable association.� Do not keep derivable association.

AGENDA

� Visualization



OBJECTIVES

� Learn how to identify and specify attributes in a

domain model

� Learn to distinguish attributes correctly

ATTRIBUTES

�After establishing classes based on the concepts of

use case scenarios, the scenarios are examined to

discover attributes

�Attributes are logical data values of an object

UML ATTRIBUTE NOTATION

VALID ATTRIBUTE TYPES

� Keep attributes simple

� Distinguish between conceptual and

implementation perspectives

Identify data types � Identify data types

RELATE WITH ASSOCIATIONS, NOT

ATTRIBUTES

AVOID REPRESENTING COMPLEX

DOMAIN CONCEPTS AS ATTRIBUTES

NON PRIMITIVE DATA TYPE (1)

Represent what may be considered a primitive data type (such as a number or string) as a non primitive class if:

• It is composed of separate sections.

phone number, name of person

• There are operations usually associated with it, such as parsing or validation.

social security number

• It has other attributes

promotional price could have a start date and end date


• It has a quantity with a unit.

payment amount has a unit of currency

• It has abstraction of one or more types with some of these qualities.

item identifier in the sales domain is a generalization of types such as Universal product code(UPC) or European Article Number(EAN)

Applying these guidelines to the POS domain model

yields the following analysis:

• The item identifier is an abstraction of various

common coding codes schemes, including UPC-A,

UPC-E, and the family of EAN schemes. These

numeric coding schemes have subparts identifying

the manufacturer, product and EAN


the manufacturer, product and EAN

• The price and the amount attribute should be non

primitive Quantity or Money classes because they

are quantities in a unit of currency

• The address attribute should be a non primitive

Address class because it has separate sections


IF THE ATTRIBUTE CLASS IS A DATA TYPE,

IT MAY BE SHOWN IN THE ATTRIBUTE BOX

NO ATTRIBUTES AS FOREIGN KEY

MODELING ATTRIBUTE QUANTITIES AND UNITS

DOMAIN MODEL CONCLUSION

�A relatively useful model has been

created for the domain of the POS

application.

�A good domain model captures the �A good domain model captures the

essential abstractions and information

required to understand the domain in

context of current requirements, and

aids people in understanding the

domain – its concepts , terminology, and the

relationships.

THE END

Download - Domain Modeling

Top Related