Semla Design Method
for use in Skywalker
A Design Method with a Focus on Semantic Descriptions
Karlstad University
Ericsson Infotech AB
NUTEK
Karlstad University
Dept. of Computer Science
2000-05-09
Improved software quality through
semantic descriptions (Skutt)
What is this Course About?
•
•
•
A university research project (Skutt) for software improvement is
going on since 1999
– in cooperation with Ericsson Infotech here in Karlstad
– supported by NUTEK
• the Swedish National Board for Industrial and Technical
Development
A design method for improved software quality (Semla) has been
developed
– focusing on the description of the semantics
– based on contracts
• the terms will be explained shortly
The project leader team for Skywalker Services has decided to apply
the method in the Skywalker Services
– as a complement to RUP
Karlstad University
Dept. of Computer Science
Semla 2
Course Objectives
After this course, you should
•
Have a common understanding of what a design contract is
•
Have a common understanding of how to use contracts during
design and implementation
•
Be able to use contracts in your work for Skywalker
Karlstad University
Dept. of Computer Science
Semla 3
Before We Start
•
•
•
•
•
System development is a team work
Which is better?
– Microscopic view:
• “I should always protect my
module against crashes”
– Macroscopic view
• “I should always protect the
system against defects”
The overall goal is to make the system
work well
That can be done by
– Avoiding errors in the first place
– Detecting and removing errors that sneak in
Surviving an error is not a goal
– Errors should be detected and removed
Karlstad University
Dept. of Computer Science
Semla 4
Traceability of Errors
•
Where do delivered “bugs” come from?
Defect origins
Delivered defects (%)
Requirements
34
Design
26
Documentation
14
Bad fixes
14
Coding
12
Karlstad University
Dept. of Computer Science
Semla 5
Modularity
•
•
•
•
Modularity promotes black box design
The interface of each module should be well defined
– Syntactic definition
• Syntax = what the program looks like
– Semantic definition
• Semantics = what the program does
– We will use contracts for the semantic description
• Will be explained shortly
Each module should be used correctly
– The compiler helps us with the syntactic side
– We must take care of the semantic side ourselves
– Contracts will help us to use modules correctly
Each module should behave well
– The contracts will guide us to implement the correct semantics
Karlstad University
Dept. of Computer Science
Semla 6
Contracts - Clients and Suppliers
•
A contract is an agreement between two parties
•
A contract has a client and a supplier
Karlstad University
Dept. of Computer Science
Semla 7
Contracts - Allocation of Responsibilities
•
•
A contract specifies obligations and benefits
Obligation
Benefit
Client
Pay
Get goods
Supplier
Supply goods
Get money
The supplier only needs to fulfill his obligations if the client fulfills his
Karlstad University
Dept. of Computer Science
Semla 8
Contracts - Preconditions and Postconditions
•
In module design, the obligations and benefits of the contracts are
regulated through preconditions and postconditions
Client
Supplier
Obligation:
•
Assure
precondition
Precondition
Method
Benefit:
•
Benefit:
•
Assume
postcondition
Karlstad University
Dept. of Computer Science
Assume
precondition
Obligation:
Postcondition
Semla 9
•
Assure
postcondition
Some Details about the Class Stack
•
Assume that these functions are defined for a stack:
– top() returns a reference to the topmost element on the stack
• the element itself is unaffected by the operation
• the element remains on the stack
– size() returns the number of elements currently on the stack
•
Assume these implementation details about a stack:
– the stack is implemented using an array called elements
– topIndex is the index of the topmost element on the stack
Karlstad University
Dept. of Computer Science
Semla 10
Example 2.1
•
The following is one possible implementation of the operation top:
Object top() throws IndexOutOfBoundsException
{
if (size() > 0)
return elements[topIndex];
else
throw(new IndexOutOfBoundsException());
}
•
Part 1: Identify the contract implicitly defined by this method
– That is: Specify its precondition and postcondition
•
Part 2: Try to suggest another contract
– How is this new contract different from the first one?
Karlstad University
Dept. of Computer Science
Semla 11
Suggested Answer to Example 2.1, part 1
•
In this example, no particular requirements are placed on the client.
The client is allowed to call top in all situations, including when there
is no top element to return.
•
Precondition:
– true
• that is, there is no requirement, the precondition is always satisfied
•
Postcondition:
– The stack is unchanged
– If the stack is not empty, then the topmost element is returned, else
(that is, if the stack is empty), then an exception is thrown
Karlstad University
Dept. of Computer Science
Semla 12
Suggested Answer to Example 2.1, part 2
•
Another contract for top could be
•
Precondition:
– The stack is not empty
•
Postcondition:
– The stack is unchanged
– The topmost element of the stack is returned
Karlstad University
Dept. of Computer Science
Semla 13
Discussion around the Contracts
•
•
•
It will never be possible to get an element where there is
none
– Asking for the topmost element of an empty stack seems quite
meaningless
Imagine that you need a plate for your food. You know where
the plates use to be piled up
– Will you try to grasp one if the pile is empty?
– Probably, you first look to see if there is any plate left, and
then you pick one.
– If the pile is empty, you will probably look elsewhere for a plate
Does the same logic apply for software development?
– First make sure that an operation is meaningful
– Then do the operation
Karlstad University
Dept. of Computer Science
Semla 14
Comparing the Contracts
•
With the first contract, the responsibility for the dangerous situation
(an empty stack) is not clearly defined
– The stack is responsible for detecting an illegal call
– The client is responsible for handling the illegal call
– Code for handling the illegal situation is needed both in the client code
and in the stack module
– In the end, the client is still responsible for taking care of the situation
•
With the second contract, the stack knows that top will only be
invoked when it is meaningful
– The responsibility to assure that the call is meaningful is clearly
defined to be with the client
– The top method does not need to consider any other situation
Karlstad University
Dept. of Computer Science
Semla 15
Different Styles of Calling a Function With and Without
Contracts
•
Obtaining the top element of a stack
– with contracts
Precondition for top: !isEmpty()
•
User code
...pushes and pops...
if(!myStack.isEmpty())
anElement = myStack.top()
else
printErrorMessage();
Karlstad University
Dept. of Computer Science
Semla 16
Different Styles of Calling a Function With and Without
Contracts
•
Obtaining the top element of a stack
– without contracts
Precondition for top: true
•
User Code
...pushes and pops...
try {
anElement = myStack.top();
}
catch(stackEmptyException sEE)
{
printErrorMessage();
}
Karlstad University
Dept. of Computer Science
Semla 17
Discussion - Consequences for the user
•
As can be seen in the previous two examples, the user has to
perform a check both when using contracts and when not.
– The reason for this is of course that it is not known in advance if the
stack is empty or not and this is a situation that needs to be tested.
– In the contract example, the test comes before the call
– In the non-contract example, the test comes after the call
– The user must always test
Karlstad University
Dept. of Computer Science
Semla 18
Discussion - Weak and Strong Contracts
•
Contract use is more closely related to human thinking
– We tend to test before we do things. (At least most of us…)
– The pile of plates example shown previously is a typical example. We
don’t try to take something that isn’t there. We check first.
•
Even if no contracts are defined explicitly, they are present in the
way the method is being implemented
– Weak contract, e.g. precondition: true
– Strong contract, e.g. precondition: <a condition that the user must
ensure is true>
Karlstad University
Dept. of Computer Science
Semla 19
Discussion - Strong Contracts do not always Apply
•
It is not possible to use strong contracts in all cases
•
System boundary classes need weak contracts
– Communication over a non-reliable channel
• The channel might be working when the test is performed but nonworking when the call is to be executed.
– The user might not be trustable
• End-users do not accept that they have to test before a function
call, which calls for weak contracts.
•
Expensive or time-consuming tests may need weak contracts
– The test might include the completion of the actual call up to a certain
point, e.g. matrix inversion.
Karlstad University
Dept. of Computer Science
Semla 20
Different Programming Styles With and Without Contracts
•
Stack without contract
Object top() throws IndexOutOfBoundsException
{
if (size() >= 0)
return elements[topIndex];
else
throw(new IndexOutOfBoundsException());
}
•
Stack with contract
Object top()
{
return elements[topIndex];
}
Karlstad University
Dept. of Computer Science
Semla 21
Discussion
•
The solution without contract has more than twice as many program
lines as the one with contract
– Should be assumed to contain at least twice as many errors
•
In reality, the number of errors should be even greater, because of
the increased complexity
– The tests to detect illegal situations complicate the control structure of
the implementation
•
This may not be so serious for one single method
– With thousands of lines of code, it becomes a serious complication
•
Simplicity is the road to quality
– Every test complicates the program
Karlstad University
Dept. of Computer Science
Semla 22
Exercise 4.2: Alternative implementation of getElement
•
•
Assume that the list is implemented
using a linked list
– The List class has a reference
first to the first node in the list
– Each node has a reference next to
the next node in the list
– Each node has a reference data to
the data value of that node
List
first
Node
next
Node
next
Give a contract for the operation
int getElement(int position)
– The data element at the selected
position should be returned
Karlstad University
Dept. of Computer Science
Semla 23
Object
Object
Paradox: Guaranteeing More by Checking Less
•
•
•
•
How can quality increase by less testing?
– Simplicity is the allied number one for quality
Placing conditions on the client allows for a simple implementation
– Hence allows for quality
Not trusting the client requires testing the conditions
– Both client and supplier need to test
– Hence complicating the implementation
– Hence jeopardizing the quality
The key issue is who’s “quality” we are looking for
– Microscopic view, just my own module:
• Lots of tests in the supplier code
– Macroscopic view, the system as a whole:
• Place the responsibility where it belongs
Karlstad University
Dept. of Computer Science
Semla 24
What Happens if the Precondition is not Satisfied?
Karlstad University
Dept. of Computer Science
2000-05-09
Improved software quality through
semantic descriptions (Skutt)
Different Strategies for Handling Violated Preconditions
•
Since the client has not kept its part of the contract, the supplier has
no obligations whatsoever
•
The supplier can do whatever it wants
•
Two strategies are recommended
– Do nothing special
• try to perform the task
• hope that the system will die
– Trap the violation and make the system die
• throw a runtime exception or exit
• possibly dump an error code to a log file
Karlstad University
Dept. of Computer Science
Semla 26
An Example of Handling Precondition Violations
• getElement method in a list
– The precondition states that position should be ok
– If the position is not ok, the system will still survive as long as position
is within the array boundaries.
– The solution is to trap the violation and make the system die to notify
the developer to correct the error in the client code
// Pre: positionOK(position)
// Post: the selected element is returned from the list
Object getElement(int position)
{
if(Compilation.ASSERT_IS_ON)
Assert.isTrue(positionOK(position));
return elements[position];
}
Karlstad University
Dept. of Computer Science
Semla 27
Do Not Try to Handle the Error
•
•
Handling errors by allowing the system to go on as if nothing
happens only makes things worse
– The client should not be aware of any exceptions that might be thrown
– It could be tempting to catch it and thereby to allow the error to live on
– Would actually implement a different contract than the one specified
for the method
Very different from error handling with weak contracts
– The client is not aware of the test
• from the client’s point of view, the contract is not “protected”
– The test can be removed without affecting the contract
• it is not part of the contract
– There is no recovery from the error
• the only measure taken if the precondition is violated is to exit the
system
Karlstad University
Dept. of Computer Science
Semla 28
Rules for Precondition Violation Traps
•
The trap should be completely transparent to the user
– There is no return value to test or exception to catch
– A trap causes the program to die when it detects an error
•
The user should develop the client code without resorting to the
traps
– The traps may be disabled or enabled without his knowledge
•
The supplier code should produce the same result without a trap as
with it
– The program may be run with traps disabled
– The trap should not affect the behavior of the system in any way
– In particular, the trap should not change any variables
Karlstad University
Dept. of Computer Science
Semla 29