1. DOMAIN MODEL—PART 2: ATTRIBUTES BTS430 Systems Analysis and Design using UML

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

3. How do we discover attributes initially? Nouns found in the use case specifications which identify simple data types are used to create attributes.

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

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

6. Derived Attributes 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.

7. Examples of Derived Attributes

8. Full attribute text notation visibility name : type multiplicity = default {property-string} (Larman,ch. 16)

9. Attributes in Supplier class using the Rose icon for private & BTS430 conventions As a convention, most modelers will assume attributes have private visibility

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

11. Example of a data type class OR A data type class

12. 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 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. 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.

14. Quantities 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.

15. Quantity

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

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

18. Description Classes 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. 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

20. Product Description figure 9.9

21. When to use Data Type Classes 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. When to use Data Type Classes 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.

23. Figure 9.24: Item ID shown as a data class

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

25. 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  In EliteBike case study, the customer is given a receipt after he has put a deposit on a special order which shows

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

27. Fig. 9.22 (p.165)

28. Fig. 9.23

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

30. Figure 9.25

31. Final thoughts on Domain Models 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. Acknowledgement 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