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, esp. for conceptual class diagrams ** 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: 1 2 SynchPartnership ---- Computer, vs. Bad: SynchPartnership's computer1 computer2 attributes ------------------------------------------ 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 (parts) - 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 ------------------------------------------ Q: Can you give examples from StickSync? - 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) *** StickSync Q: What attributes are needed in the StickSync example to support Propogate File Change? ------------------------------------------ STICKSYNC PARTIAL DOMAIN MODEL |-----------| |---------| | Synch |* Stored-on 1| PMSD | |Partnership|-----------------|---------| |-----------| | name | | 1 |/freeSpace | |---------| | Consists-of | | 2 |--------------| | Computer | |--------------| | name | | OS | |--------------| | 1 | | Contains | | * |--------------|1 | Directory |---\ |--------------| | Contains | name |---/ |--------------|* | 1 | | Contains | | * |-------------| |--------------| | File | Contains | FileContents | |-------------|----------|--------------| | name |1 1| bytes | | modTime | |--------------| |-------------| ------------------------------------------ *** POS System Process Sale Q: What attributes are needed in the POS example to support Process Sale? See Figure 12.9 also ------------------------------------------ PARTIAL DOMAIN MODEL (Fig 10.1) |-----------| |---------| | Sales | Records-sale-of | Item | | LineItem |-----------------|---------| |-----------|0..1 1| | | quantity | |---------| |-----------| |* |1..* Stocked-in| | | |Contained-in |1 | |---------| |1 | Store | |-----------| |---------| | Sale | | address | |-----------| | name | | date |----| |---------| | time |1 | |1 |-----------| | | 1| | Houses| | | | Paid- | | | by | | |---------| | | Captured-on| Register| 1| |------------|---------| |-----------| 1| | | Payment | |---------| |-----------| | amount | |-----------| ------------------------------------------ ** derived attributes (12.8) E.g., If a PMSD can be associated with 1..* SynchPartnerships, then may want a derived attribute which is the multiplicity |-----------| |--------------| | Synch |* Stored-on 1| PMSD | |Partnership|-----------------|--------------| |-----------| | name | | capacity | | /numPartners | |--------------| E.g., 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.