Domain Model:

1

NJIT

Domain Model:

Larman Chapter 9, Sections 16 and 17

Adding AttributesPrepared by: Sachin Verma

2

OBJECTIVES

Learn how to identify and specify attributes in a domain model

Learn to distinguish attributes correctly

3

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

4

UML Attribute Notation

SALE

Date: startTime: Time

Attributes

5

Valid Attribute Types

Keep attributes simple Distinguish between conceptual and

implementation perspectives Identify data types

6

Relate with associations, not attributes

CASHIER

NAME :

current register

NOT A “SIMPLE”ATTRIBUTE

Worse

CASHIER

NumberNAME

REGISTER 1 USES 1Better

7

Avoid Representing Complex Domain Concepts as Attributes

FLIGHT

DESTINATION

DESTINATION IS ACOMPLEX CONCEPT

Worse

Flight Airport

1 Flies 1Better

8

Non Primitive Data Type

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

9

Non Primitive Data Type

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)

10

Non primitive data Types

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

11

(continued)

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

12

If the attribute class is a data type, it

may be shown in the attribute box

ProductSpecification

ItemID Store Address

Product Specification

Id: Item ID

Store

address:Address

1 1 1 1

13

No attributes as Foreign Key

CASHIER

Name:currentRegisterNumber

A “simple” attribute butbeing used as a foreignkey to relate to another

object.

Worse

CASHIERnumber

Better

NAME

Register1 USES 1

14

Modelling Attribute Quantites and UnitsPayment

Amount:Number

Payment Quantity

Amount:Number

Unit

Not useful

Has amount Is in

* 1 * 1

Payment

Amount:Quantity

Quantities are pure data values,so suitable to show in attribute

section

Variation: Money is a specializedQuantity whose unit is a currency

Payment

Amount: Money

better

15

Domain Model Conclusion

A relatively useful model has been created for the domain of the POS application.

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.

16

Sales LineItem

quantity

Sale

Date

time

Payment

amount

Customer Cashier

ManagerRegister

Store

Addressname

Product Catalog

ProductSpecification

Description priceItemID

Item

Record -sale-of

Described by

1 Contains 1

Used by

1

*

Stocks1

*

Describes

*

1..

1

*

0..1 *

1..

1 Contain in

Paid By

1

1

Iniated by

1

1

Record Sales on

1

1

Captured on

1 1

Started by

1 1

Houses

1

1..

Logscompleted

A partial domainmodel