1. BTS430 Systems Analysis and Design using UML Domain Model—Part 2: Associations and Attributes

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

3. Attributes vs Classes  Common Mistake: Represent something as an attribute when it should be a conceptual class

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

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

6. Description Classes  Place holders.  Use when: Deleting instances of things they describe results in a loss of information that needs to be maintained  Common in sales, product, and service domains  In manufacturing which requires a description of a manufactured item that is distinct from the thing itself.

7. Fig. 9.10 (p.149) Service Example

8. Report Objects  Not generally useful since information is derived from other sources  But 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

9. Associations  “a relationship between instances of classes that indicates some meaningful and interesting connection” (text, p. 150)

10. When to show Associations  When “memory” of a relationship is required (in a real world situation, not a software situation) SalesLineItem instances are associated with a Sale instance. Otherwise, it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.

11. Finding Associations  “Need to remember”  “Preserved for some duration”  Common Associations List (p.155) “patterns” – e.g. Sale to SaleLineItem to Item.

12. Association Details  Name  Multiplicity (of Roles)  Multiple Associations Examples p.157

13. Multiplicity  Multiplicity defines how many instances of class A can be associated with one instance of class B

14. Fig. 9.12 (p.152)

15. Attributes  A logical data value of an object (Text, p. 158)  Show attributes when They are suggested by use cases and imply a need to remember information

16. Attributes  Most modelers assume attributes have private visibility unless shown otherwise

17. Guidelines  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

18. Fig. 9.22 (p.165)

19. Fig. 9.23

20. Attributes  Most attribute types should be “primitive” data types such as numbers and booleans

21. Data Types  Most common Boolean Date (or DateTime) Number Character String (Text) Time

22. Data Types  Others Address Colour Geometrics Phone Number Social Insurance Number Universal Product Code SKU Postal Codes Enumeration (Size=Small)

23. Guidelines Cont’d  “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, name of a person 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

24. Guidelines Cont’d  “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)

25. Example OR A data type class

26. Fig. 9.24

27. Guidelines Cont’d  In the domain model No attributes representing foreign keys! WORSE BETTER