Upload
jin-flowers
View
46
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Domain Model:. Larman Chapter 9, Sections 16 and 17 Adding Attributes Prepared by: Sachin Verma. OBJECTIVES. Learn how to identify and specify attributes in a domain model Learn to distinguish attributes correctly. ATTRIBUTES. - PowerPoint PPT Presentation
Citation preview
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
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