1. DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.

2. DOMAIN MODEL: ADDING ATTRIBUTES An attribute is a logical data value of an object. Include the following attributes in a domain model: Those for which the requirements (for example, use cases) suggest or imply a need to remember information.

3. UML Attribute Notation

4. Valid Attribute Types Keep Attributes Simple

5. Valid Attribute Types Keep Attributes Simple

6. Valid Attribute Types Keep Attributes Simple

7. Conceptual vs. Implementation Perspectives What About Attributes in Code ?

8. Data Types Attributes should generally be data types. This is a UML term that implies a set of values for which unique identity is not meaningful (in the context of our model or system) [RJB99]. If in doubt, define something as a separate conceptual class rather than as an attribute.

9. Non-primitive Data Type Classes Represent what may initially be considered a primitive data type (such as a number or string) as a non-primitive class if: It is composed of separate sections. o phone number, name of person There are operations usually associated with it, such as parsing or validation. o social security number

10. Non-primitive Data Type Classes It has other attributes. o promotional price could have a start (effective) date and end date It is a quantity with a unit. o payment amount has a unit of currency It is an abstraction of one or more types with some of these qualities. o item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) or European Article Number (EAN)

11. Where to Illustrate Data Type Classes?

13. Design Creep: No Attributes as Foreign Keys Attributes should not be used to relate conceptual classes in the domain model. The most common violation of this principle is to add a kind of foreign key attribute.

14. Design Creep: No Attributes as Foreign Keys

15. Modeling Attribute Quantities and Units

16. Attributes in the NextGen Domain Model

18. Multiplicity From SalesLineItem to Item

19. Domain Model Conclusion

20. USE-CASE MODEL:ADDING DETAIL WITH OPERATION CONTRACTS Objectives Create contracts for system operations.

21. USE-CASE MODEL:ADDING DETAIL WITH OPERATION CONTRACTS Contracts Use cases are the primary mechanism in the UP to describe system behavior, and are usually sufficient. However, sometimes a more detailed description of system behavior has value. Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model, after a system operation has executed.

22. System Operations and the System Interface

23. Example Contract: enterltem

24. Postconditions

25. If Contracts Are Used, How Complete Should Postconditions Be?

26. Writing Contracts Leads to Domain Model Updates It is common during the creation of the contracts to discover the need to record new conceptual classes, attributes, or associations in the Domain Model. Do not be limited to the prior definition of the Domain Model; enhance it as you make new discoveries while thinking through the operation contracts.

27. When Are Contracts Useful? Contracts vs. Use Cases? The use cases are the main repository of requirements for the project. They may provide most or all of the detail necessary to know what to do in the design, in which case, contracts are not helpful. There are situations where the details and complexity of required state changes are awkward to capture in use cases.

28. Guidelines: Contracts To make contracts: 1. Identify system operations from the SSDs. 2. For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract. 3. To describe the postconditions, use the following categories: o instance creation and deletion o attribute modification o associations formed and broken

29. Guidelines: Contracts To make contracts: 1. Identify system operations from the SSDs. 2. For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract. 3. To describe the postconditions, use the following categories: o instance creation and deletion o attribute modification o associations formed and broken

30. Advice on Writing Contracts State the postconditions in a declarative, passive past tense form (was...) to emphasize the declaration of a state change rather than a design of how it is going to be achieved. For example: # (better) A SalesLineltem was created..) # (worse) Create a SalesLineltem. Remember to establish a memory between existing objects or those newly created by defining the forming of an association. For example, it is not enough that a new SalesLineltem instance is created when the enterltem operation occurs. After the operation is complete, it should also be true that the newly created instance was associated with Sale; thus: # The SalesLineltem was associated with the Sale (association formed).

31. The Most Common Mistake in Creating Contracts The most common problem is forgetting to include the forming of associations. Particularly when new instances are created, it is very likely that associations to several objects need be established. Don't forget!

32. NextGen POS Example: Contracts

35. Changes to the Domain Model

36. Contracts, Operations, and the UML The UML formally defines operations. To quote: An operation is a specification of a transformation or query that an object may be called to execute [RJB99]

37. Contracts, Operations, and the UML To summarize: The UML defines operation specifications, which are specifiable in the pre- and post-condition contract style. Note that, as emphasized in this chapter, a UML operation specification may not show an algorithm or solution, but only the state changes or effects of the operation.

38. Operation Contracts Within the UP Inception.Contracts are not motivated during inception.they are too detailed. Elaboration.If used at all, most contracts will be written during elaboration, when most use cases are written. Only write contracts for the most complex and subtle system operations.

39. FROM REQUIREMENTS TO DESIGN IN THIS ITERATION

40. Iteratively Do the Right Thing, Do the Thing Right The requirements and object-oriented analysis has focused on learning to do the right thing; that is, understanding some of the outstanding goals for the Next-Gen POS, and related rules and constraints. By contrast, the following design work will stress do the thing right; that is, skillfully designing a solution to satisfy the requirements for this iteration.

41. Didn't That Take Weeks To Do? No, Not Exactly. After many chapters of detailed discussion, it must surely seem like the prior modeling would take weeks of effort. Not so. When one is comfortable with the skills of use case writing, domain modeling, and so forth, the duration to do all the actual modeling that has been explored so far is realistically just a few days.

42. On to Object Design No, Not Exactly. During object design, a logical solution based on the object-oriented paradigm is developed. The heart of this solution is the creation of interaction diagrams, which illustrate how objects collaborate to fulfill the requirements. After or in parallel with drawing interaction diagrams, (design) class diagrams can be drawn. These summarize the definition of the software classes (and interfaces) that are to be implemented in software. In terms of the UP, these artifacts are part of the Design Model.

43. The Importance of Object Design Skill vs. UML Notation Skill