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

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

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

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

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

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

7. Fig. 9.12 (p.152)

8. Aggregation Relationship  Aggregation is a special type of association relationships  It denotes a ‘whole/part’ relationship  In other words ClassA (the whole or aggregate) is made up of ClassB (the part)  As a general rule – do not use aggregation relationships

9. Composition Relationship  Composition is a special type of aggregation relationship  If the ‘whole’ or aggregate is deleted, ALL the ‘parts’ are deleted too  This type of relationship only appears in special cases i.e. Invoice/Invoice Detail i.e. Order/Order Detail

10. Composition Relationship

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

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

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

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

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

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

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

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

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

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

21. Fig. 9.22 (p.165)

22. Fig. 9.23

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

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

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

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

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

28. Example OR A data type class

29. Fig. 9.24

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