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 nontrivial 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?
are
The most common problem is forgetting to include the
forming of associations. Particularly when new instances
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