meeting -*- Outline -*-

* adding attributes (Larman Ch. 12)

  Goal: "Identify those attributes needed to satisfy the information
  requirements of the current scenarios."

** Attributes
   Q: What is an attribute?
   Q: How is that different from an association?

   Guideline: include attributes that suggest or imply a need to
   remember information.

   e.g., a receipt needs to include a date and time,
	   for return policies, and for management reports

** UML Notation for Attributes (12.2)
   See also Fowler's book, Ch 4.
------------------------------------------
       UML ATTRIBUTE NOTATION

  |-----------------|
  |       Sale      |
  |-----------------|
  | date            |
  | startTime: Time |
  |-----------------|

------------------------------------------

        types are optional

** Valid Attribute Types (12.3)

*** attributes have simple (atomic) types
------------------------------------------
        VALID ATTRIBUTE TYPES (12.3)

Types of attribute should be

  - simple or atomic:

  - object identity shouldn't matter
      (values, "data types")


Common examples:
  1. Boolean, Date, Number, String (Text),
     Time.
  2. Address, Color, geometrics,
     phone number, Social Security number,
     universal productivity, ZIP Code.

------------------------------------------
        ... e.g., numbers.
        ... immutable types

------------------------------------------
       DON'T RELATE CONCEPTUAL CLASSES

Use assocations if object identity
matters:

Good:
        Cashier -- Register,
vs. Bad:
        Cashier's
        currentRegister attribute
------------------------------------------

        Q: How would you implement an attribute?

           Use a field or wrapper/access methods...

        Guideline: when in doubt, define it as a conceptual class and
        use an association.

** on primitive data type classes (12.4)

------------------------------------------
     WHEN TO USE A NON-PRIMITIVE CLASS
    (I.E., WHEN NOT TO USE AN ATTRIBUTE)

Use a non-primitive class if the "value":

  - has separate sections

  - has operations associated with it,
    such as parsing

  - only a subset of its values are legal

  - has other attributes

  - is a quantity with a unit

  - is an abstraction of such a type

------------------------------------------

  - has separate sections
      e.g., phone number, name of a person

  - has operations associated with it,
    such as parsing
       e.g., Social Security number

  - only a subset of its natural rep is legal
       e.g., prime number

  - has other attributes
       e.g., promotional price, with start date and end date

  - is a quantity with a unit
       e.g., payment amount in currency units

  - is an abstraction of such a type
       e.g., UPC code

       Q: What about price in the POS system? amount? address? item
       ID?

  You can show non-primitive types that are value types as attributes
  (like an ItemID type that abstracts from UPC code)

** design creep: no attributes as foreign keys (12.5)
   def: a foreign key is a unique id that can be used to find objects
        of another type.  (These are often used in relational databases.)

   Guideline: don't use foreign keys, use associations.
              don't get design decisions involved in domain modeling.

** modeling attribute quantities and units (12.6)
   You need units if the quantity
       - needs to support conversions
       - the quantity has a dimension/physical meaning

   Q: Does an amount of money need units?  Temperature?

   amount: Number   vs. amount: Money
       (bad)               (better)


** example (12.7)

   Q: What attributes are needed in the POS example to support Process Sale?

   See Figure 12.9 also

** derived attributes (12.8)

   If a SalesLineItem can be associated with 1..* items,
   then may want a derived attribute which is the multiplicity

   |------------------|                                 |------------
   |   SalesLineItem  |0..1    Records-sale-of     1..* |   Item    |
   |------------------|---------------------------------|-----------|
   | /quantity        |
   |------------------|

** conclusion (12.9)

   There's no such thing as a single correct domain model.
   All are approximations.

   Q: What makes a domain model good?
      "captures the essential abstractions and information required to
      understand the domain in the context of the current
      requirements."

      Should be an aid to understanding.