1 / 22

Use Case Model Operation Contracts

Use Case Model Operation Contracts. Chapter 11 Applying UML and Patterns Craig Larman. Objectives. Create contracts for each system operation. UP Artifacts. Domain Model. Vision. Use Case Model. Use Case Text. Glossary. Operation Contract. System Sequence Diagrams.

dara
Download Presentation

Use Case Model Operation Contracts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Use Case Model Operation Contracts Chapter 11 Applying UML and Patterns Craig Larman

  2. Objectives • Create contracts for each system operation

  3. UP Artifacts

  4. Domain Model Vision Use Case Model Use Case Text Glossary Operation Contract System Sequence Diagrams Supplementary Specifications Interaction Diagrams Unified Process Artifacts Business Model Requirements Design See Figure 6.1 in text for more detail

  5. Why Write Operation Contracts • Use cases are the primary mechanism in the UP to describe system behavior • They are usually sufficient. • Sometimes a more detailed description of system behavior has value. • Contracts for operations can help define system behavior.

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

  7. Keep it Agile • In many, or even most software development projects, operation contracts may be unnecessary • Use them only when necessary to add additional detail and understanding

  8. System Operations andthe System Interface • Contracts may be defined for system operations • Operations treat the system as a black box which uses its public interface to handle incoming system events. • System operations can be identified by discovering these system events. • The entire set of system operations, defines the public system interface, • views system as single component/class

  9. 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 onitemID match (association formed) Contract CO2: enterItem

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

  11. Postconditions • Five changes in Domain Model include • 1. instance created • 2. instance destroyed • 3. association formed • 4. association broken, • 5. attribute value modified. • Postconditions are declarations about the Domain Model objects that are true when the operation has finished

  12. Naming Postconditions • Express postconditionsin past tense, as they describe a previous state change -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)

  13. Writing Contracts Leads to Domain Model Updates • New conceptual classes, attributes, or associations in the Domain Model are often discovered by writing contracts • Change the Domain Model as you make new discoveries while thinking through the operation contracts

  14. Contracts vs. Use Cases • The use cases are the main repository of requirements for the project. • Provide most or all of the detail necessary to know what to do in design. • If the details and complexity of required state changes are awkward to capture in use cases, then write operation contracts.

  15. Too Many Contracts If… • 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

  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 ONLY: • instance creation and deletion • attribute modification • associations formed and broken

  17. The Most Common Mistake In Creating Contracts • The most common problem in creating contracts is forgetting to include the forming of associations. • When new instances are created, it is very likely that associations to several objects need be established. • Don’t forget to include all the associations formed and broken.

  18. 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] • An operation is an abstraction, not an implementation. By contrast, a method (in the UML) is an implementation of an operation.

  19. Contracts, Operations, and the UML • UML operation has signature (name and parameters), and a specification • Specification describes the effects produced by executing the operation (the postconditions) • UML operation specification does notshow an algorithm or solution • It only shows state changes or operation effects

  20. Operation ContractsWithin the UP • A pre- and postcondition contract is a well-known style to specify an operation. • In UML, operations exist at many levels, from top level classes down to fine-grained classes. • Operation specification contracts for the top level classes are part of the Use-Case Model.

  21. Summary • Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model after a system operation. • Contracts have sections of Operations, Cross references, Preconditions and Postconditions. • Postconditionsare the most important section. • Postconditions describe changes in the state of objects in the Domain Model.

  22. Summary • Only write contracts for the most difficult to understand or complicated system operations. • Dr. Bob’s Rule of Thumb: If an operation has Postconditions, write a contract • Domain Model state changes include instances created, associations formed or broken, and attributes changed.

More Related