com6030-9; Department of Computer Science; 2001
Operation specification
 Operation specification using non-algorithmic and
algorithmic approaches
 Non-algorithmic specifications: decision tables, preand post-conditions
 Algorithmic notation: structured English (pseudocode)
 Library system reconsidered
References
 Object Oriented Systems Analysis and Design, by S
Bennett, S McRobb and R Farmer, Mc Graw
Hill,1999,p 186-204
1
com6030-9; Department of Computer Science; 2001
The role of operation specifications
Analysis stage: an operation defines some aspects of an
application domain (adding books to a library, borrowing
books in some conditions)
Design stage: an operation defines for a programmer a
method (algorithm) of implementing the specification
When the operation is simple the two mentioned
approaches are quite close
Sometimes the algorithm implementing an operation may
be fairly complex (how to do) compared with the
specification (what to do) - an operation involving
putting some information in a specified order requires a
sorting strategy that is defined during design stage How much to specify? …
2
com6030-9; Department of Computer Science; 2001
Two perspectives:
Only operations that are computationally complex, nontrivial need to be specified
or
All operations should be specified.
Specification techniques
The specification may be made in natural language
(English) or in a specialised form (non-algorithmic or
algorithmic notation) - UML does not specify any –
Non-algorithmic notations define operations as black
boxes; this is coherent with OO methodology as it
preserves encapsulation (only public aspects are visible)
and with object distribution (the work is distributed
over some objects as small chunks of behaviour)
Two non-algorithmic notations: decision tables and preand post-conditions
Algorithmic notation (more related to design decisions)
is a specification in steps of the logic of an operation
3
com6030-9; Department of Computer Science; 2001
Non-algorithmic notations
1. Decision tables
A decision table is a matrix showing the conditions under
which a decision is made and the actions that may result.
Example. Let us consider an operation that checks
whether the moves performed by a queen on a chess
board are correct or not.
How does the queen move and capture?
“The queen can move horizontally, vertically, or on the
diagonal; it can move far in one direction so long as there
are no pieces in its path. “
http://www.princeton.edu/~jedwards/cif/chess.html
In this position, the queen can capture the rook and the
bishop, can move to any of the squares marked with an
"X", and may not jump over any of the pieces on the
board.
4
com6030-9; Department of Computer Science; 2001
inLine
finLine
*
*
inColumn
finColumn
Let us consider the operation, checkMove(), that will
deal with the above attributes. The move from initial
position (inLine, inColumn) to (finLine,
finColumn) can be made if the following conditions
are satisfied
1. Both positions are inside the chess board: 1p8,
where p is any of the above attributes
2. the final position is correctly chosen: (inLine,
inColumn) and (finLine, finColumn) are
on the same line, or column, or diagonal
3. there are no pieces between the two positions
4. final position is free or contains an enemy piece
5
com6030-9; Department of Computer Science; 2001
The decision table for checkMove() is:
Conditions
Positions inside?
Final position
correct?
No pieces in
between?
Final position ok?
Actions
Wrong positions
Wrong move
Correct move
R1
N
-
R2
Y
N
R3
Y
Y
R4
Y
Y
R5
Y
Y
-
-
N
Y
Y
-
-
-
N
Y
X
X
X
X
X
“Y” – means corresponding condition True (“N” –
means False, and “–“ means any of them)
“X” – associates an action to one or many rules; the
values defining a rule are used with ‘and’ (R5 is read as
all conditions should be True)
An action is specified according to selected rules
(Wrong positions is associated with R1 or R2, i.e.
when positions are not inside or the final position is
incorrect, irrespective of any other values)
If all conditions are explicitly specified then a very
complex table is obtained - in this case the number of
rules would be 24(!) -
6
com6030-9; Department of Computer Science; 2001
2. Pre- and post-conditions
This non-algorithmic specification focuses on defining
the conditions satisfied before an operation is executed
and after that. These are expressed as Boolean conditions
involving attributes and various parameters or returning
values occurring in operation signature.
Conditions involved may be specified in (1) an abstract
formal way, (2) in OCL, (3) or in natural language.
Example 1. A merge operation may be specified as
follows:
merge(item1:array,item2:array,
noOfItems1:Integer,
noOfItems2:Integer)
and there are attributes item:array and
noOfItems:Integer receiving the results.
If item1={1,3,7,11}, item2={1,2,2,5} then
item={1,1,2,2,3,5,7,11}
Pre-condition:
noOfItems10, noOfItems20,
item1[k]item1[k+1], 1k<noOfItems1
item2[k]item2[k+1], 1k<noOfItems2
Post-condition:
noOfItems=noOfItems1+noOfItems2
item[k] item[k+1], 1k<noOfItems
7
com6030-9; Department of Computer Science; 2001
Example 2. A search problem may be specified as
follows:
Search(X:Intarray, Key:Integer):
Integer;
-- it returns an array index
Using the following pre- and post-conditions we get
Pre-condition:
If X has n elements then n>0 and exists k:
X[k]=Key, 1kn
Post-condition:
X[Search(X,Key)]=Key
Compare this with the following Z schema
SearchSchema
Search: (seqZ)ZZ
X: seqZ
Key?: Z
X<>
(k  X[k]=Key?, 1k#X 
Search(X,Key?)=k)
8
com6030-9; Department of Computer Science; 2001
Example 3. Consider now lendBook()
Pre-condition:
exist book, bookCopy available (in book,
copiesAvailable>0), borrower
Post-condition:
In book, copiesAvailable is incremented by 1;
selected bookCopy keeps dateBorrowed set to
current date; bookCopy points to borrower
9
com6030-9; Department of Computer Science; 2001
Pre- and post-conditions standard stereotypes
Pre-condition – constraint – specifies a constraint that
must hold before the invocation of an operation
Post-condition – constraint – specifies a constraint that
must hold after the invocation of an operation
Algorithmic approach
Describes the internal logic of a process by breaking it
down into small units and steps to follow up.
A logical structure is made up by using indentation, some
key words and a vocabulary close to everyday usage in
the business context and simple sentences consisting in
imperative statements or equations; they are combined
such as to give sequences, selections and iterations.
This approach is in general used during design. In the
analysis stage is used to accurately illustrate some
requirements.
10
com6030-9; Department of Computer Science; 2001
Algorithmic approach: structured English (pseudocode)
Sequential constructs
compute next position
check whether it is correct
Selective (alternative) constructs
if – then - else construct: checkCorrectMove()
if final position is incorrect or
position outside the table
error “wrong position”
else
if pieces in between or
final position not Ok
error “wrong move”
else
correct move
case construct (switch in Java):
checkCorrectMove()
begin case
case incorrect position
 error
“incorrect position”
case wrong move
 error
”wrong move”
otherwise
 correct move
end case
11
com6030-9; Department of Computer Science; 2001
Repetitive (iterative) constructs
do - while construct:
set correct_move to false
do while correct_move is false
get position
if position is not correct
error “incorrect position”
else
if it’s wrong move
error “wrong move”
else
correct move
set correct_move to true
end do
repeat construct:
set correct_move to false
repeat
get position
if position is not correct
error “incorrect position”
else
if it’s wrong move
error “wrong move”
else
correct move
set correct_move to true
until correct_move becomes true
Similar constructs may be found in usual programming
languages.
12
com6030-9; Department of Computer Science; 2001
Example 3. Consider now lendBook()
find a Book object, b
if b.copiesAvailable>0
find a BookCopy object, c
else
stop
find a Borrower object, bo
decrease b.copiesAvailable by 1
set c.dateBorrowed to current date
keep bo reference in c
13
com6030-9; Department of Computer Science; 2001
Library system modified
Returning book use cases with pay fine included
Return to
Main Menu
Find Book
uses
uses
Find Book
Copy
uses
Return Book
{overdue}
Library
Assistant
pay Fine
uses
uses
uses
Complete
Return
14
Find Borrower
com6030-9; Department of Computer Science; 2001
Return Book Dialog including fines
CopyId
RetDate
PayFine
ConfirmPaym
15
com6030-9; Department of Computer Science; 2001
Class Borrower with fine attribute
«business»
::Borrower
name: String
address: String
phoneNumber: Int
fine:int
totalFines: Int
New attributes
Class ReturnsBookDialog
1
«user»
::ReturnsBookDialog
findBookandBookCopyAction
completeReturnAction
1
returnAction
ConfirmPaymentAction
1
1
Displays to get book copy
1
«user»
::FindBookDialog
1
Makes available
1
foundBookCopy
«business»
::BookCopy
1
Displays
1..*
findBookCopyDialog
findBookDialog
Is loaned to
1
currentBorrower
«user»
::FindBookCopyDialog
«business»
::Borrower
*
1 Contains
Modifies foundBook data
«business»
::BookCopyList
1 bookCopies
1 Has a
Saves edited foundBook and currentBorrower
foundBook
pom
1
«business»
::POM
1
«business»
::Book
Pays fine for late return
1
foundBookCopy
«business»
::BookCopy
1
Adds fine
1
currentBorrower
«business»
::Borrower
new elements:
 confirmPaymentAction
 relationships for payment implementation
 add modification (in POM) to currentBorrower –
new fine
16
com6030-9; Department of Computer Science; 2001
Conclusions
 Operation specification using non-algorithmic and
algorithmic approaches
 Non-algorithmic specifications: decision tables, preand post-conditions
 Algorithmic notation: structured English (pseudocode)
 Library system with fines
17