1. DOMAIN MODEL— PART 2: ATTRIBUTES SYS466

2. Looking For Potential Classes “Know the business”. Ask Questions Identify business concepts; filter nouns (person, place, thing). Use category lists Look for “patterns” (e.g. Order, OrderLine, etc.)

3. How do we discover attributes initially? Nouns found in the use case specifications which identify simple data types are used to create attributes.

4. Attributes A logical data value of an object  (Text, p. 158) In a domain model, attributes and their data types should be simple, such as Number or String.

5. Data Types Most common data types or attributes  Boolean  Date (or DateTime)  Number  Character  String (Text)  Time

6. Data Types Other Data Types which may or may not be used as attributes:  Address  Colour  Geometrics  Phone Number  Social Insurance Number  Universal Product Code  SKU  Postal Codes  Enumeration (Size=Small)

7. Class or Attribute? Primitive data type?  Probably an attribute Multiple occurrences?  Probably a class (e.g. Part) More complex?  Could be a class Do we want to reuse it? (e.g. Address)  Could be a class

8. Objects as Attributes Sometimes more complex “things” are properties of classes  Address object (e.g. address:Address)  Group of part objects (e.g. partSet:Part)  Group of credit card objects (e.g. creditCardSet:CreditCard)

9. When to use Data type classes “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, address  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

10. Example of a data type class OR A data type class

11. When to use data type classes (continued) “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)

12. Quantity Most numeric quantities should not be represented as plain numbers. Consider price or weight. Saying “the price was 13” or “the weight was 37” doesn't say much. These are quantities with associated units, and it is common to require knowledge of the unit to support conversions.

13. Quantity

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

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

16. Description Classes Common in sales, product, and service domains In manufacturing which requires a description of a manufactured item that is distinct from the thing itself.

17. Description Classes Use a description class when:  There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.  Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.  It reduces redundant or duplicated information.  Example: ProductDescription

18. Report Objects Not generally useful since information can be derived from other sources which is why you do not have create report use cases.

19. Report Objects Shown 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

20. A Few Final Thoughts 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.23

22. Objects as Attributes Sometimes “which object is an attribute of which other object” is not clear. We need to go to the business for more information.  E.g. Customer to Order (in Charlene’s Cakes)  We make the customer object an attribute of Order because Order is meaningless without Customer (To whom do you deliver the baked goods? Who pays?)  We may retrieve orders in several ways—by unpaid, by date, by customer etc. If we put order into customer, which orders would we give customer? Customer can exist very nicely without Order.

23. Handling Groupings of Objects Sometimes we use temporary lists/sets etc. in order to store retrieved objects. The use case “controller” class (the class that holds the business logic) might look after this. Sometimes classes themselves contain groupings of objects:  E.g. contactSet:ContactPerson is a grouping of contact people(perhaps an array list) in Supplier

24. Attributes in Supplier class using the Rose icon for private & SYS466 conventions As a convention, most modelers will assume attributes have private visibility

25. Classes versus Database Not the same thing Classes do not have “foreign keys”. Think object. E.g. You would NOT model custID as an attribute of Order; but you might model customer:Customer as an attribute of Order.

26. Do not use attributes as foreign keys Attributes should not be used to relate conceptual classes in the domain model. Do not add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types.

27. Figure 9.25

28. Acknowledgement Slide material was taken from Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, By Craig Larman, Published by Prentice Hall, Pub. Date: October 20, 2004. Chapter 9