1. Domain Model—Part 2: Attributes

2.  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.

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

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

5.  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)

6.  A quantity that can be calculated from other values, such as role multiplicities, is a derived attribute, designated in UML by a leading slash symbol.

8.  visibility name : type multiplicity = default {property-string} (Larman, Ch. 16)

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

10.  “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

11. OR A data type class

12.  “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)

13.  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.

14.  Quantity is represented as a distinct class, with an associated Unit [Fowler96]. It is also common to show Quantity specializations.Fowler96  Money is a kind of quantity whose units are currencies.  Weight is a quantity with units such as kilograms or pounds.

16.  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

17.  A description class contains information that describes something else  E.g., a ProductDescription records price, picture, and text description of a product

18.  Common in sales, product, and service domains  In manufacturing which requires a description of a manufactured item that is distinct from the thing itself.

19.  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

21.  An itemID attribute is shown as an attribute of ProductDescription. It could be a number or perhaps a string. For example, itemID : Integer or itemID : String.

22.  In this example it is more than that (item identifier has subparts) so we use a data type class named ItemID (or ItemIdentifier) in the domain model, and designate the type of the attribute as such. For example, itemID : ItemIdentifier.

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

25.  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

26.  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

29.  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.

31.  Domain Model is not a data model (which by definition shows persistent data to be stored)  Don’t exclude a class simply because the requirements don’t indicate any obvious need to remember information about it  Valid to have conceptual classes with no attributes* * Larman, p.136

32.  Slide material was taken from Applying 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