meeting -*- Outline -*- * adding associations (Larman Ch 11) See also Fowler's book, Ch 4. ------------------------------------------ ASSOCIATIONS vs. ATTRIBUTES Def: an association is Example: |--------| 1 Paid-by 1 |---------| | Sale |---------------| Payment | |--------| |---------| Def: an attribute is Example: |-----------| | Sale | |-----------| | date | | startTime | |-----------| ------------------------------------------ ... a relationship between types (i.e., instances of types) that indicates some meaningful and interesting connection. ... a logical data value of an object Q: But can't we represent an The main distinction is that attributes are atomic/simple values, whose identity is not important, while associations to not involve simple values whose identity is unimportant. Guideline (p. 169): "Relate conceptual classes with an association, not with an attribute." ** Criteria for Useful Associations ------------------------------------------ DOMAIN MODEL: ADDING ASSOCIATIONS (Ch. 11) Goal: identify associations needed by information requirements of scenarios in this iteration Consider the following associations: - "need to know" relationship that must be preserved for some length of time - those in common associations list ------------------------------------------ Q: does the Process Sale use case need to remember what SalesLineItem instances are associated with a Sale instance? yes, otherwise how could we pritn receipt, calculate total... Q: does the Process Sale use case need to remember who the manager was when a Sale was created? no, could be derived later from other relationships also. It's important to avoid cluttering up the model with lots of extra associations. ** The UML association notation ------------------------------------------ UML NOTATION |----------| 1 Records 1 |---------| | Register |---------------| Sale | |----------| |---------| ------------------------------------------ For the demand model, no arrows indicating navigation. You can add a "reading direction arrow", which indicates the direction in which to read the name. It has no meaning. The multiplicity expression indicates how many instances that an instance of the class on the other side is associated with. (See Fowler.) ** Common associations list can start fining associations using the following list (table 11.1) ------------------------------------------ COMMON ASSOCIATIONS LIST (Table 11.1) Associate conceptual classes A and B if: - A is a physical part of B - A is a logical part of B - A is physically contained in B - A is logically contained in B - A is a description for B - A is a line item of a transaction or report B - A is known, logged, recorded, reported, or captured in B - A is a member of B - A is an organizational subunit of B - A uses or manages B - A communicates with B - A is related to a transaction B - A is a transaction related to another transaction B - A is next to B - A is owned by B - A is an event related to B ------------------------------------------ ask them to give the airline examples ... - A is a physical part of B e.g., Drawer --- Register - A is a logical part of B e.g., SalesLineItem -- Sale - A is physically contained in B e.g., Register -- Store, Item -- Shelf - A is logically contained in B e.g., ItemDescription -- Catalog - A is a description for B e.g., ItemDescription -- Item - A is a line item of a transaction or report B e.g., SalesLineItem -- Sale - A is known, logged, recorded, reported, or captured in B e.g., Sale -- Register - A is a member of B e.g., Cashier -- Store - A is an organizational subunit of B e.g., Department -- Store - A uses or manages B e.g., Manager -- Store - A communicates with B Customer -- Cashier - A is related to a transaction B Customer -- Payment - A is a transaction related to another transaction B Payment -- Sale - A is next to B SalesLineItem -- SalesLineItem - A is owned by B Register -- Store - A is an event related to B Sale -- Customer, Sale -- Store *** high-priority associations Q: Which of these would be the most useful? Larman suggests: - A is a physical part of B - A is a logical part of B - A is physically contained in B - A is logically contained in B - A is recorded in B ** Association Guidelines (11.4) Q: Which is more important, conceptual classes or their associations? Larman suggests the latter Q: What if we have an association between Sale -- Register and Register -- Store, do we also need an association between Sale and Store. No, could always derive it if necessary ** Roles (11.5) the ends of associations are called "roles". Each role can optionally have: - a name - a multiplicity expression (a number) - navigability information *** multiplicity ------------------------------------------ MULTIPLICITY NOTATION |----------| 1 Stock s * |---------| | Store |---------------| Item | |----------| |---------| Each Store is associated with zero or more instances of Item. Each Item is associated with one Store. notation meaning ==================================== [A]-- A is associated with... *|-----| ----| T | zero or more T's |-----| 1..*|-----| ----| T | one or more T's |-----| 1..4|-----| ----| T | 1, 2, 3, or 4 T's |-----| 5|-----| ----| T | 5 T's |-----| 1,4,6|-----| ----| T | 1, 4, or 6 T's |-----| ------------------------------------------ The multiplicity restrictions are applied at all time instants. Q: Can a used car be stocked-by more than one dealer? ** Naming associations (11.7) Guideline: name an association based on a type-name-verb-name-type- name format e.g. Paid-by (or PaidBy). Names are read left-to-right by convention. ** Multiple associations between two types (11.8) Q: can two types have multiple associations between them? Yes: flights have two assocations to airports. ** Associations and Implementation (11.9) Q: during data modeling, are associations the same thing as instance variables (fields, data members)? no, although they can be implemented that way (among others) ** example (11.10) Q: what relationships are unforgettable in the POS system for the Process Sale use case? register records sale sale paid-by, payment ProductCatalog Records ProductSpecification Q: Use the category checklist to find associations related to the Process Sale use case? (see pp. 162-163, but draw on board) Take out assocations that are not "need-to-know", or that are redundant/derivable, and that don't aid comprehension. Have them do this in their teams. Summary: domain model intended to communicate understanding in the domain.