Lecture10 use case model operation contracts
- 1. Use Case Model Operation Contracts
- 2. Objective 2 Create contracts for system operations.
- 3. Unified Process Artifacts Business Model Requirements Design Domain Model Use Case Model Operation Contract Use Case Text System Sequence Diagrams Interaction Diagrams Supplementary Specifications Vision Glossary See Figure 11.1 in text book for more detail
- 4. Why 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 for operations can help define system behavior. 4
- 5. Domain Model And Contracts A Domain Model is a visual representation of conceptual classes or real-world objects in a domain of interest. Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model, after a system operation has executed. 5
- 6. Keep it Agile In many, or even most software development projects, operation contracts may be unnecessary. For an agile process, use them only when necessary to add additional detail and understanding. 6
- 7. System Operations and the System Interface Contracts may be defined for system operations – operations that the system as a black box offers in its public interface to handle incoming system events. System operations can be identified by discovering these system events. The entire set of system operations, across all use cases, defines the public system interface, viewing the system as a single component or class. 7
- 8. Example Contract: enterItem Operation: enterItem(itemID : ItemID, quantity : integer) Cross References: Use Cases: Process Sale Preconditions: There is a Sale Underway. Postconditions: -A SalesLineItem instance sli was created (instance creation) -sli was associated with the current Sale (association formed) -sli.quantity became quantity (attribute modification) -sli was associated with a ProductSpecification, based on itemID match (association formed) 8 Contract CO2: enterItem
- 9. Contract Sections Operation: Name Of operation, and parameters. Cross References: (optional) Use cases this can occur within. Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. Postconditions: -The state of objects in the Domain Model after completion of the operation. 9
- 10. Postconditions The postconditions describe changes in the state of objects in the Domain Model. Domain Model state changes include instances created, associations formed or broken, and attributes changed. Postconditions are not actions to be performed, during the operation; rather, they are declarations about the Domain Model objects that are true when the operation has finished. 10
- 11. The Spirit of Postconditions: The Stage and Curtain Express postconditions in the past tense, to emphasize they are declarations about a state change in the past. (better) A SalesLineItem was created. (worse) Create a SalesLineItem. 11
- 12. The Spirit of Postconditions: The Stage and Curtain Think about postconditions using the following image: The system and it’s objects are presented on a theatre stage. Before the operation, take a picture of the stage. Close the curtains on the stage, and apply the system operation Open the curtains and take a second picture. Compare the before and after pictures, and express as postconditions the changes in the state of the stage (A SalesLineItem was created…). 12
- 13. Writing Contracts Leads to Domain Model Updates New conceptual classes, attributes, or associations in the Domain Model are often discovered during contract writing. Enhance the Domain Model as you make new discoveries while thinking through the operation contracts. 13
- 14. 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. If the details and complexity of required state changes are awkward to capture in use cases, then write operation contracts. 14
- 15. Contracts vs. Use Cases contd… If developers can understand what to do based on the use cases and ongoing (verbal) collaboration with a subject matter expert, avoid writing contracts. Operation contracts are uncommon. If a team is making contracts for every system operation: the use cases are poorly done, or there is not enough collaboration or access to a subject matter expert, or the team is doing too much unnecessary documentation. 15
- 16. Guidelines: Contracts To make contracts: Identify system operations from the SSDs. For system operations that are complex and perhaps subtle in their own results, or which are not clear in the use case, construct a contract. To describe the postconditions, use: - instance creation and deletion - attribute modification - associations formed and broken 16
- 17. Operation Contracts Within the UP Phases Inception – Contracts are not needed 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. 17