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

2. In these notes: Report Objects Attributes vs Classes Description Classes Associations

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

4. Attributes vs Classes GUIDELINE: If we DO NOT think of a concept as a text or number in the real world domain then it is probably a class, not an attribute e.g. a sale is made at a store Sale is a conceptual class Is store and attribute of Sale or is it a conceptual class Store?

5. Description Classes Place holders. Use when: there needs to be a description of an item/service even when the item/service does not exist e.g. Movie still exists even when MovieShowing does not it reduces redundancy/duplication

6. In the Pay Per View example: In a system for a store that rents computer games:

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

8. When to show Associations When “memory” of a relationship is required (in a real world situation, not a software situation)

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

10. Association Details Name Multiplicity (of Roles) Multiple Associations (e.g. FlightDescription to Airport) Examples p.157

11. Fig. 9.12 (p.152)

12. Fig. 9.16 (p.155) In our Project Example