Semla Design Method for use in Skywalker A

  • Slides: 29
Download presentation
Semla Design Method for use in Skywalker A Design Method with a Focus on

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 10/7/2020 Improved software quality through semantic descriptions (Skutt)

What is this Course About? • • • A university research project (Skutt) for

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

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

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

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

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

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

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

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: • 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

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 – top. Index 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:

Example 2. 1 • The following is one possible implementation of the operation top: Object top() throws Index. Out. Of. Bounds. Exception { if (size() > 0) return elements[top. Index]; else throw(new Index. Out. Of. Bounds. Exception()); } • 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

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

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

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

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

Different Styles of Calling a Function With and Without Contracts • Obtaining the top element of a stack – with contracts Precondition for top: !is. Empty() • User code. . . pushes and pops. . . if(!my. Stack. is. Empty()) an. Element = my. Stack. top() else print. Error. Message(); Karlstad University Dept. of Computer Science Semla 16

Different Styles of Calling a Function With and Without Contracts • Obtaining the top

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 { an. Element = my. Stack. top(); } catch(stack. Empty. Exception s. EE) { print. Error. Message(); } Karlstad University Dept. of Computer Science Semla 17

Discussion - Consequences for the user • As can be seen in the previous

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

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

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

Different Programming Styles With and Without Contracts • Stack without contract Object top() throws Index. Out. Of. Bounds. Exception { if (size() >= 0) return elements[top. Index]; else throw(new Index. Out. Of. Bounds. Exception()); } • Stack with contract Object top() { return elements[top. Index]; } Karlstad University Dept. of Computer Science Semla 21

Discussion • The solution without contract has more than twice as many program lines

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 get. Element • Give a contract for the

Exercise 4. 2: Alternative implementation of get. Element • Give a contract for the operation int get. Element(int position) – The data element at the selected position should be returned Karlstad University Dept. of Computer Science Semla 23 List first Node ta 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 da • Object next Node next Object

Paradox: Guaranteeing More by Checking Less • • How can quality increase by less

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 simplementation – 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

What Happens if the Precondition is not Satisfied? Karlstad University Dept. of Computer Science 10/7/2020 Improved software quality through semantic descriptions (Skutt)

Different Strategies for Handling Violated Preconditions • Since the client has not kept its

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 • get. Element method in a list –

An Example of Handling Precondition Violations • get. Element 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: position. OK(position) // Post: the selected element is returned from the list Object get. Element(int position) { if(Compilation. ASSERT_IS_ON) Assert. is. True(position. OK(position)); return elements[position]; } Karlstad University Dept. of Computer Science Semla 27

Do Not Try to Handle the Error • • Handling errors by allowing the

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

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