System Contract from SSD

V2.0
October 2013
Ferreiras

5-1
 E08
• Para cada uno de los escenarios, de cada uno de los casos de
uso de su proyecto, preparar su SSD y los contratos del sistema,
como indicado en las PPT-Book.

• 1NOMBRES COMPONENTES DEL E08:

• Diagramas de Secuencia del Sistema

• Contratos del sistema.

• ENTREGA: 25-04-2018
• LUGAR: felix.ferreiras@gmail.com
• HORA: Antes de 2400

2
Analysis, UC from Events Table 2
 E09: Contratos de Operación del
Sistema
• A partir de los SSD preparar los contratos de operación del
sistema de su proyecto
• 1NOMBRES COMPONENTES DEL E09:
• Contratos de operación del sistema
NO APLICA PARA EL 2018-10
• ENTREGA: 11-11-2017
• LUGAR: felix.ferreiras@gmail.com
• HORA: Antes de 2400

5-3
Analysis, UC from Events Table 3
 System Operation Contract
• A system operation contract describes
what the system must to do internally to
respond to the message from the actor.

• Only input messages to the system

• In design we will define the interactions

of software objects within the system.
5-4
System Operation Contract

• Writing contracts for system

operations is the final step in
Object-Oriented System analysis
and make possible the transition to
system design.

5-5
 System Operation Contract

• The SSD show the messages from

the initiating actor to the system.

• Associated with each of the

messages is a system operation

5-6
System Operation Contracts
• A system operation is an operation
which the system carries out in
response to a system input.

• The system input and the system

operation have the same name.

• This relationship will be an important

link between the system analysis
models and the system design
models.

5-7
 Components of a system contract
Contract CO-XXX, Where each X must be from 0,1,2,3,4,5,6,7,8,9,
which may be different. For example: CO-234
Name Name Of operation, and parameters.
Use Case UC-XXX, ... Use cases this can occur within.
Responsibilities A brief description of the responsibilities this operation must
fulfill.
Exceptions Deviations from the typical flow of events and what to do
when they occur.
Output Messages sent to external systems ( not to the user
interface)
Preconditions Assumed state of the system before the operation is
executed. Notable assumptions about the state of the system
or objects in the Domain Model before execution of the
operation.
Postconditions State of the system after the operation has been executed.
The state of objects in the Domain Model after completion of
the operation.
5-8
 Creating
System Operation Contracts
• Identify each system operation
in a system sequence diagram.
• Write the responsibilities of that
operation in the contract.
• Write the preconditions in terms of
the required changes in the domain
model.
• Add the postconditions and exceptions.

5-9
 Postconditions for
System Operation Contracts
• What instances of concepts must be
created or deleted?
• What attributes have their values
modified? To what new values?
• Which instances of associations must
be added or deleted?
• Use the past tense and the passive
voice.

5-10
System Operation Contract, Example
• Considering the SSD show below: 
<<actor>>
:RegistrationSystem
Student

enterStudentIdentifier(studentIdentifier)

requestSection( departmentCode, courseNumber, sectionNumber)

endSectionRequests()

studentClassList

5-11
 System Operation Contract, Example
Contract CO-666
Name enterStudentIdentifier(studentIdentifier)
Use Case UC-334, UC-456
Responsibilities - Accept and validate the Student´s identifier;
- Verify that the Student is eligible to register;
Exceptions - If the student identifier is not valid, indicate that is was a
error;
- If the Student is not eligible to register, inform the
Student;
Output There are not.
Preconditions Student is known to the system
Postconditions None

5-12
 System Operation Contract, Example
Contract CO-667
Name requestSection(departmentCode, courseNumber, sectionNumer)
Use Case UC-334, UC-456
Responsibilities - Enroll the Student in the Section
Exceptions -- If the combination of departmentCode, courseNumber
and sectionNumber is not valid, indicate that it was an
error.
- If no seats are availabe, inform the Student.
Output There are not.
Preconditions Department and Section are known to the system
Postconditions A new instance of the Enrolled In association was created,
linking the Student and the Section.

5-13
 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.
5-14
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-15
 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.

5-16
 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.

5-17
 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.

5-18
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.

5-19
 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…).

5-20
 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.

5-21
 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.
5-22
 Contracts vs. Use Cases
• 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.

5-23
 Guidelines to make 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

5-24
 The Most Common Mistake In
Creating Contracts
• The most common problem in creating
contracts 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 to include all the associations
formed and broken.

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

5-26
Contracts, Operations, and the UML
• A UML operation has a signature (name
and parameters), and also an operation
specification, which describes the
effects produced by executing the
operation; the postconditions.
• A UML operation specification may not
show an algorithm or solution, but only
the state changes or effects of the
operation.

5-27
 Programming Language
Support for Contracts

• Some languages, such as Eiffel,

have first-class support for
invariants and pre- and
postconditions.
• There are pre-processors that
provide similar support in Java.

5-28
 New Systems Operations

• Let us create new system

operations for a Point of Sale
system to handle different forms of
payment:
 makeCreditPayment
 makeCheckPayment

5-29
 New System Operations

• The system event and operation for cash

payment in an earlier iteration was
simply makePayment.
• As the payments are of different types
the operation is renamed as
makeCashPayment.

5-30
New System Operation Contracts

• System operation contracts are an

optional requirements artifact that adds
fine detail regarding the results of a
system operation.
• The use case text itself is sufficient, at
times.
• The contracts are not necessary.

5-31
New System Operation Contracts
• The contracts bring value, on
occasion, by their precise and
detailed approach to identifying
what happens when a complex
operation is invoked on the
system, in terms of state changes
to objects defined in the Domain
Model.

5-32
 Contract: makeCreditPayment
• Operation: makeCreditPayment
(creditAccountNumber, expiryDate)
• Cross References:
• Use Cases: Process Sale
• Preconditions: An underway sale exists and all
items have been entered.

5-33
 Contract: makeCreditPayment

• Postconditions:
 A credit payment pmt was created
 pmt was associated with the current Sale
sale a CreditCard cc was created.
cc.number = creditAccountNumber,
cc.expiryDate = expiryDate
 cc was associated with pmt

5-34
 Contract: makeCreditPayment

 a CreditPaymentRequest cpr was created

 pmt was associated with cpr
 a ReceivableEntry re was created
 re was associated with the external
AccountsReceivable
 Sale was associated with the Store as a
complete sale

5-35
 makeCreditPayment
• There exists a postcondition
indicating the association of a new
receivable entry in accounts
receivable.
• Although, this responsibility is
outside the bounds of the NextGen
system, the accounts receivable
system is within the control of the
business.
5-36
 makeCreditPayment
• The statement has thus been
added as a correctness check.
• During testing, it is clear from this
post-condition that the accounts
receivable system should be tested
for the presence of a new
receivable entry.

5-37
 Contract: makeCheckPayment

• Operation: makeCheckPayment
(driversLicenseNumber)
• Cross References:
• Use Cases: Process Sale
• Preconditions: An underway sale
exists and all items have been
entered

5-38
 Contract: makeCheckPayment

• Postconditions:
 a CheckPayment pmt was created
 pmt was associated with the current Sale
sale
 a DriversLicense dl was created, dl.number
= driversLicenseNumber
 dl was associated with pmt

5-39
 Contract: makeCheckPayment

 a CheckPaymentRequest cpr was created

 pmt was associated with cpr
 sale was associated with the Store as a
completed sale

5-40
 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.
Postconditions are the most important section.
• 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.

5-41
 Summary
• Writing Contracts leads to Domain Model
updates.
• In UML, an operation is a specification of a
transformation or query that an object may be
called to execute.
• Most contracts will be written during
elaboration, when most use cases are written.
Only write contracts for the most difficult to
understand or complicated system operations.

5-42
 References
• Chapter Five: Domain Models And System Operation Contracts; Object-
Oriented Systems Analysis and Design With UML; Robert V. Stumpf, Lavete
C. Teague; Pearson Prentice Hall, 2004.

• Chapter 11: Operation Contacts; , Applying UML and Patterns: An

Introduction to Object-Oriented Analysis and Design and Iterative
Development; Craig Larman; Prentice Hall PTR, 3rd Edition, 2005.
• …

5-43
 Reference
• Object-Oriented Systems Analysis and Design
With UML; Robert Stumpf, Lavette Teague;
Pearson Education, 2010

5-44