DOMAIN MODEL—PART 2: ATTRIBUTES

SYS466

Looking For Potential Classes

“Know the business”.Ask QuestionsIdentify business concepts; filter nouns

(person, place, thing).Use category listsLook for “patterns” (e.g. Order, OrderLine,

etc.)

How do we discover attributes initially?

Nouns found in the use case specifications which identify simple data types are used to create attributes.

Attributes

A logical data value of an object (Text, p. 158)

In a domain model, attributes and their data types should be simple, such as Number or String.

Data Types

Most common data types or attributes Boolean Date (or DateTime) Number Character String (Text) Time

Data Types

Other Data Types which may or may not be used as attributes: Address Colour Geometrics Phone Number Social Insurance Number Universal Product Code SKU Postal Codes Enumeration (Size=Small)

Class or Attribute?

Primitive data type? Probably an attribute

Multiple occurrences? Probably a class (e.g. Part)

More complex? Could be a class

Do we want to reuse it? (e.g. Address) Could be a class

Objects as Attributes

Sometimes more complex “things” are properties of classes Address object (e.g. address:Address) Group of part objects (e.g. partSet:Part) Group of credit card objects (e.g.

creditCardSet:CreditCard)

When to use Data type classes

“Represent what may initially be considered a number or string as a new data type class in the domain model if” it Is composed of separate sections

Phone number, address Has operations associated with it such as parsing or

validation Social insurance number, credit card number

Has other attributes Sales price could have a start (effective) date and an end

date

Example of a data type class

VideoStore

address : Address

OR

Address

street1street2cityNameprovNamepostalCode

VideoStore

11 11

Located-at

A data type class

When to use data type classes (continued)

“Represent what may initially be considered a number or string as a new data type class in the domain model if” it: is a quantity with a unit

Payment amount has a unit of currency Is an abstraction of one or more types with some of

these qualitities Item identifies in the sales domain is a generalization of

types such as Universal Product Code (UPC)

Quantity

Most numeric quantities should not be represented as plain numbers. Consider price or weight. Saying “the price was 13” or “the weight was 37” doesn't say much.

These are quantities with associated units, and it is common to require knowledge of the unit to support conversions.

Quantity

Attributes vs Classes

GUIDELINE: If we DO NOT think of a conceptual class as text or a number in the real world then it is probably a class, not an attribute e.g. a sale is made at a store

Sale is a conceptual class because in the real world the term suggests a legal entity, an organization or something that occupies space

Description Classes

A description class contains information that describes something else E.g., a ProductDescription records price, picture, and

text description of a product

Description Classes

Common in sales, product, and service domainsIn manufacturing which requires a description of

a manufactured item that is distinct from the thing itself.

Description Classes

Use a description class when: 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 (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.

It reduces redundant or duplicated information. Example: ProductDescription

Report Objects

Not generally useful since information can be derived from other sources which is why you do not have create report use cases.

Report Objects

Shown if they have a special role in terms of business rules—e.g. need Receipt in order to get refund—then they should be included

A Few Final Thoughts

In the domain Model Relate conceptual classes with an association, NOT an

attribute Cashier to Register NOT currentRegister attribute of Cashier

Attributes should preferably be “data type”, not complex concepts Flight to Airport NOT destination attribute of Flight

Fig. 9.23

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complex concept

Objects as Attributes

Sometimes “which object is an attribute of which other object” is not clear. We need to go to the business for more information. E.g. Customer to Order (in Charlene’s Cakes)

We make the customer object an attribute of Order because Order is meaningless without Customer (To whom do you deliver the baked goods? Who pays?)

We may retrieve orders in several ways—by unpaid, by date, by customer etc. If we put order into customer, which orders would we give customer? Customer can exist very nicely without Order.

Handling Groupings of Objects

Sometimes we use temporary lists/sets etc. in order to store retrieved objects. The use case “controller” class (the class that holds the business logic) might look after this.

Sometimes classes themselves contain groupings of objects: E.g. contactSet:ContactPerson is a grouping of

contact people(perhaps an array list) in Supplier

Attributes in Supplier class using the Rose icon for private & SYS466

conventions

Supplier

supplierNumbersupplierNamesupplierAddress : AddresssupplierPhonecontactSet : ContactPerson

As a convention, most modelers will assume attributes have private visibility

Classes versus Database

Not the same thingClasses do not have “foreign keys”. Think

object. E.g. You would NOT model custID as an attribute of Order; but you might model customer:Customer as an attribute of Order.

Do not use attributes as foreign keys

Attributes should not be used to relate conceptual classes in the domain model.

Do not add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types.

Figure 9.25

Acknowledgement

Slide material was taken fromApplying UML and Patterns: An Introduction to Object-

Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman, Published by Prentice Hall, Pub. Date: October 20, 2004. Chapter 9