Extend Relationship
Sept 2004
91.3913 Ron McFadyen
1
Extend Relationship
• The extend relationship is typically used for optional
behaviour
• Extend is used to separate optional from mandatory
behaviour; extend is used to distinguish variants in behaviour
• Under a specified condition the base use case is extended with
the behaviour specified in the addition use case.
• We say the addition use case is dependent on the base use case
(note the directed line in the drawing)
Sept 2004
91.3913 Ron McFadyen
2
Extend Relationship
• Process Sale collects the payment from the customer.
Suppose payment via a gift certificate is considered an
exceptional case. See Figure 25.3
Process Sale
Extension Points:
Payment
Cashier
<<extend>>
Payment, if the Customer
presents a gift certificate
Handle Gift Certificate Payment
Sept 2004
91.3913 Ron McFadyen
3
Extend Relationship
• Process Sale declares/states “Payment” is an extension point,
but Process Sale does not know anything else: the condition,
the name of the other addition use case. (see page 389)
Process Sale
Extension Points:
Payment
Cashier
<<extend>>
Payment, if the Customer
presents a gift certificate
Handle Gift Certificate Payment
Sept 2004
91.3913 Ron McFadyen
4
System Sequence Diagrams
Sept 2004
91.3913 Ron McFadyen
5
Use-case model: System Sequence Diagrams
Elaboration Iteration 1:
• a simple cash-only success scenario of Process Sale
• beginning a wide-and-shallow design and implementation
• touches on many major architectural elements
• begins with a expansion of the Use Case Model with a System
Sequence Diagram
•to clarify the input and output system events
Sept 2004
91.3913 Ron McFadyen
6
Simple cash-only Process Sale scenario
1. Customer arrives at a POS checkout with goods and/or
services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. System records sale line item and presents item description,
price, and running total
Cashier repeats steps 3-4 until indicates done
5. System presents total with taxes calculated
6. Cashier tells customer the total and asks for payment
7. Customer pays and System handles payment
...
Sept 2004
91.3913 Ron McFadyen
7
System Sequence Diagram
• a picture showing actors and systems, lifelines, messages, time
• for a particular scenario
• for SSDs we will be ignoring an “activation box” that is
normally placed on a lifeline
:System
:Cashier
• an arbitrary cashier
• a cashier object
• the software system to be
developed
•We’ll see it as a black box
Sept 2004
91.3913 Ron McFadyen
8
Sequence Diagram
• object-oriented systems perform tasks by interacting with each
other through the passing of messages
• a sequence diagram is an interaction diagram that emphasizes the
messaging sequence
•A sequence diagram illustrates the dynamic behaviour of a
system of objects
•The arrow we utilize (
) is for procedural or synchronous
messages – where the sender sends a message, transfers control
to the receiving object, and waits for a response
•To indicate a return message and the explicit return of control,
we use
•Ch 15 discusses interaction diagrams more fully
Sept 2004
91.3913 Ron McFadyen
9
System Sequence Diagram
:System
:Cashier
Earlier events are
above later events in
the diagram
time travels
downward
message
Time1 earlier than Time2:
response
Time1 < Time2
Message at Time1 from
:Cashier to :System
Sept 2004
Response at Time2 from
:System to :Cashier
91.3913 Ron McFadyen
10
Figure 9.1
Sept 2004
91.3913 Ron McFadyen
11
There are 4 system
events shown here.
The cashier will
interact with the
system in 4 ways.
The events are given
operation names:
makeNewSale,
enterItem, endSale,
makePayment.
Figure 9.3
Sept 2004
91.3913 Ron McFadyen
12
Contracts
Sept 2004
91.3913 Ron McFadyen
13
Contracts
• Used to help understand requirements more completely
• based on assertions; assertions are applicable to any
element of the UML
• text discusses contracts for system operations; contracts
are applicable to execution of any software component
Sept 2004
91.3913 Ron McFadyen
14
Domain Model
Use Case Model
•text
•diagram
•SSD
•System operation contracts
Design Model
Figure 13.3 Relationship between Contracts and other artifacts
Sept 2004
91.3913 Ron McFadyen
15
Contracts
A contract is a technique for describing system operations in
terms of state changes to objects in a Domain Model
Contracts in Chapter 13, are based on work by Bertrand Meyer
… Eiffel programming language
Based on concept of assertion
•a statement, a constraint or declaration, that must be true
•a false value indicates a bug
•may be expressed informally, or in the UML we can
(optionally) use the Object Constraint Language (OCL;
1999) to specify constraints rigorously
Sept 2004
91.3913 Ron McFadyen
16
Constraints
• Three types
• pre-condition: must be true before a part of the
system executes
• post-condition: must be true after a part of the
system executes
• invariant: must be true before and after any part of
the system is executed.
• Constraints can be
• enclosed in braces and placed in a note on a diagram
• appear as guards on a diagram
• kept in a separate file
• managed by a CASE tool
Sept 2004
91.3913 Ron McFadyen
17
Contracts
Consider the execution of a routine:
•The called routine provides a service - it is the supplier
•The caller is the client requesting the service.
•A contract will spells out precisely the obligations of the
caller (client) and the callee (supplier).
•The contract serves as an interface specification for the
routine.
Example: consider a routine that merges two sorted
sequences. The merge routine is the supplier of the service;
the calling routine is the caller. A contract will spell out the
responsibilities of each party.
Sept 2004
91.3913 Ron McFadyen
18
Contracts
Responsibilities:
Client: Ensure that the both sequences to be merged are
each already sorted
Supplier: Efficiently merge the two sorted sequences into
one sorted sequence
Sept 2004
91.3913 Ron McFadyen
19
Contracts
Software contract:
•The responsibilities of the client will be called preconditions
•The responsibilities of the supplier will be called postconditions
Pre-condition: both sequences to be merged are each already
sorted
Post-condition: the two sorted sequences are merged into one
sorted sequence
Sept 2004
91.3913 Ron McFadyen
20
Contracts
•During analysis developers must first understand the
problem domain and identify domain objects, their
relationships with other domain objects, and their
constraints.
•If a contract is defined in terms of domain objects the
constraints can be clear and explicit, easily understood
•Everyone understands the business contracting metaphor.
•Business rules (constraints) can become an integral part of
the software from the very beginning.
Example: consider a withdraw method for an ACCOUNT
class: withdraw (amount_to_withdraw: MONEY)
Sept 2004
91.3913 Ron McFadyen
21
Contracts
Example: consider a withdraw method for an ACCOUNT class:
withdraw (amount_to_withdraw: MONEY)
Pre-conditions:
•positive_amount: amount_to_withdraw > 0
•sufficient_balance: balance >= amount_to_withdraw
Post-conditions:
•correct_balance: balance =
initial balance - amount_to_withdraw
Sept 2004
91.3913 Ron McFadyen
22
Contracts
Contract Components (Larman)
Operation - name and parameters
Cross References - where operation used
Preconditions - assumptions about the state of the system
or Domain Model objects
Postconditions - state of objects after the operation
completes
•objects:any new ones? any attributes modified?
•associations: any new or modified associations?
Larman’s version is very informal
Sept 2004
91.3913 Ron McFadyen
23
SSD for a samplePOS Use Case
: Cashier
Figure 13.1
Input Events invoke a
system operation of
:System
the same name
makeNewSale()
addLineItem(itemID, quantity)
description, total
* [more items]
endSale()
total with taxes
makePayment(amount)
change due, receipt
Sept 2004
91.3913 Ron McFadyen
same idea as in
object-oriented
these input system events
invokesystem operations
programming
when
we
say aevent
message foo
thesystem
makeNewSale
invokes a
invokes
thecalled
method
system operation
makeNewSale
and so forth
foo
this is the same as in objectoriented programming when
we say the
message
foo
invokes the
method(handling
operation)
foo
Referred to as the enterItem
system operation
24
The part of the Domain Model relevant to enterItem( )
*
Described by
SalesLineItem
1
Product
Specification
itemID
quantity
1..*
Contained in
1
Sale
Sept 2004
91.3913 Ron McFadyen
25
Contracts
Example
Operation: enterItem (itemID : ItemID, quantity : integer)
Preconditions
•there is a Sale underway
Postconditions
•a SalesLineItem instance was created
•an association between the sale and the sales line item
was created
•an attribute, quantity, was modified
•an association between the product specification and the
sales line item was created
Sept 2004
91.3913 Ron McFadyen
26
DBC (aside)
Design By Contract (DBC) provides the basis for
documenting software interfaces
Reusers of a software component need to understand what
the software provides them and what they must do to
obtain these benefits. This is the contract.
DBC is perhaps a best non-practice.
Example of a new DBC tool:
iContract: Design by Contract in Java
allows one to include runtime assertions for
development purposes and suppress them for
production
http://www.javaworld.com/javaworld/jw-02-2001/jw0216-cooltools.html
Sept 2004
91.3913 Ron McFadyen
27