1. Improved software quality through semantic descriptions (Skutt) Karlstad University Dept. of Computer Science 2000-05-09 Semla Design Method for use in Skywalker A Design Method with a Focus on Semantic Descriptions Karlstad University Ericsson Infotech AB NUTEK

2. Karlstad University Dept. of Computer Science Semla 2 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

3. Karlstad University Dept. of Computer Science Semla 3 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

4. Karlstad University Dept. of Computer Science Semla 4 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

5. Karlstad University Dept. of Computer Science Semla 5 Traceability of Errors Where do delivered “bugs” come from? 12Coding 14Bad fixes 14Documentation 26Design 34Requirements Delivered defects (%)Defect origins

6. Karlstad University Dept. of Computer Science Semla 6 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

7. Karlstad University Dept. of Computer Science Semla 7 Contracts - Clients and Suppliers A contract is an agreement between two parties A contract has a client and a supplier

8. Karlstad University Dept. of Computer Science Semla 8 Contracts - Allocation of Responsibilities A contract specifies obligations and benefits Client Supplier BenefitObligation PayGet goods Supply goodsGet money The supplier only needs to fulfill his obligations if the client fulfills his

9. Karlstad University Dept. of Computer Science Semla 9 Contracts - Preconditions and Postconditions In module design, the obligations and benefits of the contracts are regulated through preconditions and postconditions Method Precondition Postcondition SupplierClient Obligation: Assure precondition Benefit: Assume postcondition Benefit: Assume precondition Obligation: Assure postcondition

10. Karlstad University Dept. of Computer Science Semla 10 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

11. Karlstad University Dept. of Computer Science Semla 11 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?

12. Karlstad University Dept. of Computer Science Semla 12 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

13. Karlstad University Dept. of Computer Science Semla 13 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

14. Karlstad University Dept. of Computer Science Semla 14 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

15. Karlstad University Dept. of Computer Science Semla 15 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

16. 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 –with contracts Precondition for top: !isEmpty() User code...pushes and pops... if(!myStack.isEmpty()) anElement = myStack.top() else printErrorMessage();

17. Karlstad University Dept. of Computer Science Semla 17 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(); }

18. Karlstad University Dept. of Computer Science Semla 18 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

19. Karlstad University Dept. of Computer Science Semla 19 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:

20. Karlstad University Dept. of Computer Science Semla 20 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 non- working 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.

21. Karlstad University Dept. of Computer Science Semla 21 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]; }

22. Karlstad University Dept. of Computer Science Semla 22 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

23. Karlstad University Dept. of Computer Science Semla 23 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 Give a contract for the operation int getElement(int position) –The data element at the selected position should be returned ListNode first next ObjectNode next Object data

24. Karlstad University Dept. of Computer Science Semla 24 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

25. Improved software quality through semantic descriptions (Skutt) Karlstad University Dept. of Computer Science 2000-05-09 What Happens if the Precondition is not Satisfied?

26. Karlstad University Dept. of Computer Science Semla 26 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

27. Karlstad University Dept. of Computer Science Semla 27 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]; }

28. Karlstad University Dept. of Computer Science Semla 28 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

29. Karlstad University Dept. of Computer Science Semla 29 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