Sept 200491.3913 Ron McFadyen1 Extend Relationship.

Sept 2004 91.3913 Ron McFadyen 1

Extend Relationship


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)


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

<<extend>>

Handle Gift Certificate Payment

Cashier Payment, if the Customer presents a gift certificate

Process SaleExtension Points:

Payment


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)

<<extend>>

Handle Gift Certificate Payment

Cashier Payment, if the Customer presents a gift certificate

Process SaleExtension Points:

Payment


System Sequence Diagrams


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


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

...


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

:Cashier :System

• an arbitrary cashier

• a cashier object

• the software system to be developed

•We’ll see it as a black box


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


System Sequence Diagram

:Cashier :System

Message at Time1 from :Cashier to :System

Response at Time2 from :System to :Cashier

Earlier events are above later events in the diagram

time travels downward

Time1 earlier than Time2:

Time1 < Time2

message

response


Figure 9.1


Figure 9.3

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.


Contracts


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


Domain Model

Use Case Model

•text

•diagram

•SSD

•System operation contracts

Design Model

Figure 13.3 Relationship between Contracts and other artifacts


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


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


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.

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

Contracts


Software contract:

•The responsibilities of the client will be called pre-conditions

•The responsibilities of the supplier will be called post-conditions

Pre-condition: both sequences to be merged are each already sorted

Post-condition: the two sorted sequences are merged into one sorted sequence

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)

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

Contracts


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


: Cashier:System

addLineItem(itemID, quantity)

endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

* [more items]

makeNewSale()

these input system eventsinvoke system operations

the system eventmakeNewSale invokes asystem operation calledmakeNewSale and so forth

this is the same as in object-oriented programming whenwe say the message fooinvokes the method (handlingoperation) foo

SSD for a samplePOS Use Case Figure 13.1Input Events invoke a system operation of the same name

same idea as in object-oriented programming when we say a message foo invokes the method foo

Referred to as the enterItem system operation


SalesLineItem

quantity

Product Specification

itemID

Sale

1

1..*

*1Described by

Contained in

The part of the Domain Model relevant to enterItem( )


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


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/jw-0216-cooltools.html

DBC (aside)

Sept 200491.3913 Ron McFadyen1 Extend Relationship.

Documents

Transcript of Sept 200491.3913 Ron McFadyen1 Extend Relationship.