חוזים – Contracts 1

Larman – Chapter 10 – SSDs 10.2 What are System Sequence Diagrams? (introduction) Use cases describe how external actors interact with the software system we are interested in creating. During this interaction an actor generates system events to a system, usually requesting some system operation to handle the event. For example, when a cashier enters an item's ID, the cashier is requesting the POS system to record that item's sale (the enterItem event). That event initiates an operation upon the system. The use case text implies the enterItem event, and the SSD makes it concrete and explicit. 2

10.2 What are System Sequence Diagrams? (cont.) The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them. A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events. All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems. Guideline Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios. 3

Larman – Chapter 11 – Operation Contracts (p. 181) Operation contracts may be considered part of the UP Use-Case Model because they provide more analysis detail on the effect of the system operations implied in the use case. The prime inputs to the contracts are the system operations identified in SSDs, the domain model, and domain insight from experts. The contracts can in turn serve as input to the object design, as they describe changes that are likely required in the software objects or database. 4

11.2 What are the sections of a contract? Operation: Name of operation, and parameters. Cross References: Use cases this operation can occur within. Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. These are non- trivial assumptions the reader should be told. Postconditions: This is the most important section. The state of objects in the Domain Model after completion of the operation. Discussed in detail in a following section. 5

11.3 Definition: What is a System Operation? Operation contracts may be defined for system operations – operations that the system as a black box component offers in its public interfaces. System operations can be identified while sketching SSDs. To be more precise, the SSDs show system events – events or I/O messages relative to the system. Input system events imply the system has system operations to handle the events, just as on OO message (a kind of event or signal) is handled by an OO method (a kind of operation). The entire set of system operations, across all use cases, defines the public system interface, viewing the system as a single component or class. In the UML, the system as a whole can be represented as one object of a class named (for example) System. 6

11.4 Definition: 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 observations about the domain model objects that are true when the operation has finished – after the smoke has cleared. To summarize, the postconditions fall into these categories: Instance creation and deletion. Attribute change of value. Associations (to be precise, UML links) formed and broken. 7

Analogy: The Spirit of Postconditions: The Stage and Curtain Why write postconditions in the past tense? Think about them using the following image: The system and its objects are presented on a stage theatre. Before the operation, take a picture of the stage. Close the curtains on the stage, and apply the system operation (background noise of clanging, screams, and screeches…). Open the curtains and take a second look. Compare the before and after pictures, and express as postconditions the changes in the state of the stage. (An item was created…). 8

11.8 Guideline: How to Create and Write Contracts Apply the following advice to create contracts: Identify system operations from the SSDs. For system operations that are complex and perhaps subtle in their results, or which are not clear in the use case, construct a contract. To describe the postconditions, use the following categories: Instance creation and deletion Attribute modification Associations formed and broken What's the Most Common Mistake? 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! 9

Conclusion Identify Use-Cases in the system. How is it going to be used? From the Use-Cases, understand what are the Events in the system (triggers received from the user/external system). These are the inputs triggering the system to react. Events can be displayed in a special type of Sequence Diagram called System Sequence Diagram (Actor vs. System, only!). Identify classes in the Use-Cases and create a Conceptual Class Model. The system reacts by operating: thus, we are met with System Operations. These are the operations required in order to properly handle the triggers from outside the system. To define the System Operations more properly, write Contracts specifying an operation’s pre- and-post- conditions. Consider the Domain Model Class Diagram in the Post-Conditions. Finish by creating Sequence Diagrams for the operations. 10

Conclusion (Illustrated( Identify Use-Cases Events ~= triggers System Sequence Diagram (Actor vs. System, only!). System Operations Conceptual Classes (“nouns” in the Use-Cases) Contracts specifying post- conditions. Create Sequence Diagrams for operations. 11