next previous Något om hantering av krav. Testning. Undantagshantering OOMPA 2000 Föreläsning 11

previous next 2 Hantering av krav. Testning. Undantagshantering. Hantering av krav Läs också Bruegge kapitel och kursivt 8.3.7, OH-bilderna i detta delavsnitt tagna från Bruegge

previous next 3 Hantering av krav. Testning. Undantagshantering. An aircraft example A320 First fly-by-wire passenger aircraft 150 seats, short to medium haul A319 & A321 Derivatives of A320 Same handling as A320 Rationale: Reduce pilot training & maintenance costs Increase flexibility for airline

previous next 4 Hantering av krav. Testning. Undantagshantering. An aircraft example (2) A330 & A340 Long haul and ultra long haul 2x seats, 3x range Similar handling than A320 family Rationale With minimum cross training, A320 pilots can be certified to fly A330 and A340 airplanes Consequence Any change in these five airplanes must maintain this similarity

previous next 5 Hantering av krav. Testning. Undantagshantering. Overview Rationale: –What is it? –Why should you care? Rationale methods –Representing rationale –Authoring rationale –Accessing rationale State of practice & research Summary

previous next 6 Hantering av krav. Testning. Undantagshantering. What is rationale? Rationale is the reasoning that lead to the system. Rationale includes: Issues that were addressed, Alternatives that were considered, Decisions that were made to resolve the issues, Criteria that were used to guide decisions, and Debate developers went through to reach a decision.

previous next 7 Hantering av krav. Testning. Undantagshantering. Why rationale? Software systems are similar to passenger airplanes: They result from a large number of decisions taken over an extended period of time. Evolving assumptions Legacy decisions Conflicting criteria -> High maintenance cost -> Loss & rediscovery of information

previous next 8 Hantering av krav. Testning. Undantagshantering. Rationale helps deal with change Improve maintenance support –Provide maintainers with design context Improve learning –New staff can learn the design by replaying the decisions that produced it Improve analysis and design –Avoid duplicate evaluation of poor alternatives –Make consistent and explicit trade-off

previous next 9 Hantering av krav. Testning. Undantagshantering. Levels of rationale No rationale captured –Rationale is only present in memos, online communication, developers’ memory Rationale reconstruction –Rationale is documented in a document justifying the final design Rationale capture –Rationale is documented during design as it is developed Rationale integration –Rationale drives the design

previous next 10 Hantering av krav. Testning. Undantagshantering. Centralized traffic control CTC systems enable dispatchers to monitor and control trains remotely CTC allows the planning of routes and re-planning in case of problems

previous next 11 Hantering av krav. Testning. Undantagshantering. Centralized traffic control (2) CTC systems are ideal examples of rationale capture: Long lived systems (some systems include relays installed last century) –Extended maintenance life cycle Downtime is expensive (although not safety critical) –Low tolerance for bugs –Transition to mature technology Initial developers are not available

previous next 12 Hantering av krav. Testning. Undantagshantering. input?:Issuedisplay?:Issue Issues Issues are concrete problem which usually do not have a unique, correct solution. Issues are phrased as questions. How should track sections be displayed? How should the dispatcher input commands?

previous next 13 Hantering av krav. Testning. Undantagshantering. Proposals Proposals are possible alternatives to issues. One proposal can be shared across multiple issues. input?:Issue addressed by display?:Issue text-based:Proposalpoint&click:Proposal The interface for the dispatcher could be realized with a point & click interface. The display used by the dispatcher can be a text only display with graphic characters to represent track segments.

previous next 14 Hantering av krav. Testning. Undantagshantering. input?:Issue addressed by display?:Issue point&click:Proposal Consequent issue Consequent issues are issues raised by the introduction of a proposal. terminal?:Issue raises Which terminal emulation should be used for the display? text-based:Proposal

previous next 15 Hantering av krav. Testning. Undantagshantering. Criteria A criteria represent a goodness measure. Criteria are often design goals or nonfunctional requirements. input?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails display?:Issue point&click:Proposal The time to input commands should be less than two seconds. The CTC system should have at least a 99% availability. text-based:Proposal

previous next 16 Hantering av krav. Testning. Undantagshantering. Arguments Arguments represent the debate developers went through to arrive to resolve the issue. Arguments can support or oppose any other part of the rationale. Arguments constitute the most part of rationale.

previous next 17 Hantering av krav. Testning. Undantagshantering. Arguments (2) input?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by display?:Issue point&click:Proposal Point&click interfaces are more complex to implement than text-based interfaces. Hence, they are also more difficult to test. The point&click interface risks introducing fatal errors in the system that would offset any usability benefit the interface would provide. text-based:Proposal

previous next 18 Hantering av krav. Testning. Undantagshantering. Resolutions Resolutions represent decisions. A resolution summarizes the selected alternative and the supporting argument. A resolved issue is said to be closed. A resolved issue can be re-opened if necessary, in which case the resolution is demoted.

previous next 19 Hantering av krav. Testning. Undantagshantering. Resolutions (2) input?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by text-based&keyboard :Resolution resolves display?:Issue point&click:Proposaltext-based:Proposal

previous next 20 Hantering av krav. Testning. Undantagshantering. Representing rationale: issue models ProposalCriterion$ Issue? meets + fails - is a consequence responds Argument! supports + objects to - supports + objects to - Resolution. resolves

previous next 21 Hantering av krav. Testning. Undantagshantering. Testning Läs också Bruegge kapitel 9, speciellt 9-9.4

previous next 22 Hantering av krav. Testning. Undantagshantering. Terminology Reliability: The measure of success with which the observed behavior of a system confirms to some specification of its behavior. Failure: Any deviation of the observed behavior from the specified behavior. Error: The system is in a state such that further processing by the system will lead to a failure. Fault (Bug): The mechanical or algorithmic cause of an error. There are many different types of errors and different ways how we can deal with them.

previous next 23 Hantering av krav. Testning. Undantagshantering. Examples of Faults and Errors Faults in the Interface specification –Mismatch between what the client needs and what the server offers –Mismatch between requirements and implementation Algorithmic Faults –Missing initialization –Branching errors (too soon, too late) –Missing test for nil Faults in the Interface specification –Mismatch between what the client needs and what the server offers –Mismatch between requirements and implementation Algorithmic Faults –Missing initialization –Branching errors (too soon, too late) –Missing test for nil Mechanical Faults (very hard to find) –Documentation does not match actual conditions or operating procedures Errors –Stress or overload errors –Capacity or boundary errors –Timing errors –Throughput or performance errors Mechanical Faults (very hard to find) –Documentation does not match actual conditions or operating procedures Errors –Stress or overload errors –Capacity or boundary errors –Timing errors –Throughput or performance errors

previous next 24 Hantering av krav. Testning. Undantagshantering. Dealing with Errors Verification: –Assumes hypothetical environment that does not match real environment –Proof might be buggy (omits important constraints; simply wrong) Modular redundancy: –Expensive Declaring a bug to be a “feature” –Bad practice Patching –Slows down performance Testing (this lecture) –Testing is never good enough

previous next 25 Hantering av krav. Testning. Undantagshantering. Another View on How to Deal with Errors Error prevention (before the system is released): –Use good programming methodology to reduce complexity –Use version control to prevent inconsistent system –Apply verification to prevent algorithmic bugs Error detection (while system is running): –Testing: Create failures in a planned way –Debugging: Start with an unplanned failures –Monitoring: Deliver information about state. Find performance bugs Error recovery (recover from failure once the system is released): –Data base systems (atomic transactions) –Modular redundancy –Recovery blocks

previous next 26 Hantering av krav. Testning. Undantagshantering. Some Observations It is impossible to completely test any nontrivial module or any system –Theoretical limitations: Halting problem –Practical limitations: Prohibitive in time and cost Testing can only show the presence of bugs, not their absence (Dijkstra)

previous next 27 Hantering av krav. Testning. Undantagshantering. Testing takes creativity Testing often viewed as dirty work. To develop an effective test, one must have: Detailed understanding of the system Knowledge of the testing techniques Skill to apply these techniques in an effective and efficient manner Testing is done best by independent testers –We often develop a certain mental attitude that the program should in a certain way when in fact it does not. Programmer often stick to the data set that makes the program work –"Don’t mess up my code!" A program often does not work when tried by somebody else. –Don't let this be the end-user.

previous next 28 Hantering av krav. Testning. Undantagshantering. Testa program I varje steg i designen kommer testning på ett eller annat sätt in I huvudsak används traditionella testmetoder även vid objektorienterad design För att kontrollera –riktighet fungerar det hela? Gör programmet vad det ska? –relevans är våra mål relevanta och möjliga? –verifiering gör systemet det kunden vill att det skall göra?

previous next 29 Hantering av krav. Testning. Undantagshantering. Testa program (forts) Vi prövar kontinuerligt och periodiskt –enhetlighet (/modultestning) är de utvecklade delarna enhetliga, dvs icke motsägelsefulla –kravspecifikationen följs den? –kundernas reaktion är kunderna nöjda med inriktning och utveckling? –tillräcklighet för att gå vidare till nästa fas är det vi utvecklat tillräckligt för att gå vidare? –nödvändighet har vi minimerat överlappning men ändå täckt alla möjligheter? har vi konstruerat delarna utan att överspecificera?

previous next 30 Hantering av krav. Testning. Undantagshantering. Testa program (forts) –flexbilitet är delarna tillräckligt flexibla för att möta rimliga variationer? –format har format och stilregler följts? –spårbarhet har vi dokumenterat besluten som lett oss "hit" tillräckligt? Under programutvecklingen gör vi –komponenttestning klasser, objekt –integrationstestning samverkan mellan komponenter –regressionstestning vi gör om testerna efter korrektion av fel

previous next 31 Hantering av krav. Testning. Undantagshantering. Testa program (forts) Vi kan också testa –prestanda på alla nivåer (enhets, integration eller system) Är prestandan godtagbar? –systemets stresstålighet klarar systemet av störra belastningar än normalt?

previous next 32 Hantering av krav. Testning. Undantagshantering. Testa program (forts) Tre olika huvudprinciper: –planering för test börjar redan vid kravspecifikationen och slutar då användaren accepterar programmet –testning skall orsaka och upptäcka fel kan orsaka mentala problem vid test av egen programvara. Alltså testa varandras moduler –testningsförfarandet skall vara rimligt omfattande testa rimligt urval och extremfall (omöjligt att testa allt) Faser –alfa görs internt av utvecklaren –beta några utvalda kunder provar

previous next 33 Hantering av krav. Testning. Undantagshantering. Testa program (forts) Strategier –top-down testning starta med övergripande tester av hela systemet och bryt ner detta i delar ner till detaljnivå –bottom-up testning testa detaljer först sedan större och större delar –middle-out testning –white-box testning där vi också har möjlighet att "se in" i koden vanligen görs detta av programmerarna –black-box testning från "utsidan" där vi inte har tillgång till kod kan göras innan användning av en viss modul

previous next 34 Hantering av krav. Testning. Undantagshantering. Testa program (forts) Testning på olika nivåer –enhets- och modultestning görs oftast av programmeraren under utvecklingen Vi kontrollerar att enskilda bitar gör vad dom ska –integrationstestning flera modulers samverkan. Görs av utvecklare. –funktionstestning tesning av integrationstestade moduler som skall samverka för att utföra en viss användarfunktion som finns dokumenterad i kravspecen –systemtestning kombinerar alla funktioner för att testa delsystem eller hela system –användaracceptanstestning ungefär som systemtestning fast utförd av användarna

previous next 35 Hantering av krav. Testning. Undantagshantering. Testa program (forts) Tester i UML –genomgång av modeller en grupp undersöker en modell för att verifiera dess riktighet och konsekvens. en detaljerad beskrivning kan ofta upprättas kontroll av krav. –kontroll av datakatalog kontrollera att den är enhetlig att alla termer som finns i katalogen är definierade. –genomgång av användningsfall gå igenom användingsfallen genom rollspel en person som "spelar" ett visst objekt undersöker för varje händelse som skickas till honom/henne vilka operationer den berör eller om delegering skall ske

previous next 36 Hantering av krav. Testning. Undantagshantering. Testa program (forts) –enhetlighet ofta erbjuds olika representationer av domänen, tex med olika gränssnitt, vilka kanske inte är helt konsekventa –väg och frågetest för att testa klassdiagram brukar frågor som är typiska för klasserna i det aktuella diagrammet ställas. Diagrammet kontrolleras genom att en väg som besvarar frågan identifieras –spårbarhet av krav varje krav spåras till klasser, associationer, begränsningar och metoder som uppfyller kravet i större projekt behövs speciella verktyg och/eller databas –användar- och kundverifiering representanter för kunder och användare bör delta i alla steg av verifieringen. Bla då risken för att nya krav uppkommer är stor och det är bra att få dem så fort som möjligt.

previous next 37 Hantering av krav. Testning. Undantagshantering. Testing Activities Tested Subsystem Code Functional Integration Unit Tested Subsystem Requirements Analysis Document System Design Document Tested Subsystem Test Test Unit Test Unit Test User Manual Requirements Analysis Document Subsystem Code Subsystem Code All tests by developer Functioning System Integrated Subsystems

previous next 38 Hantering av krav. Testning. Undantagshantering. Global Requirements Testing Activities ctd User’s understanding Tests by developer PerformanceAcceptance Client’s Understanding of Requirements Test Functioning System Test Installation User Environment Test System in Use Usable System Validated System Accepted System Tests (?) by user Tests by client

previous next 39 Hantering av krav. Testning. Undantagshantering. Testa program (forts), varför inte? Varför görs test av program ofta så dåligt? –Tråkigt Speciellt dokumenteringen av processen –Dyrt Tar mycket tid Ibland över 50% av ett helt projekts tid, ca 30% i medel Alternativet att inte testa ofta dyrare i långa loppet Man får ta (den större) kostnaden senare –Test planeras för sent Kommer i kläm då deadlines prioriteras –Kunder vill ha så snabb leverans som möjligt

previous next 40 Hantering av krav. Testning. Undantagshantering. Några speciella problem i OO-testning... Enhetstest –Enheterna är åtminstone klasser Enheterna är också publika metoder –En klass svårare att testa än en funktion –En metod kan ändra en klass tillstånd och påverka en annan metods beteende –Därför Använd tillståndsdiagrammen! Testa varje tillstånd och dom möjliga övergångarna dem emellan

previous next 41 Hantering av krav. Testning. Undantagshantering. … Några speciella problem i OO-testning... Arv –Oftast behöver vi testa ärvda metoder även i subklasser Normalt kan vi inte räkna med att arvet är en specialisering –Vi kontrollerar också tex att inte metod i superklass är duplicerad i subklass –Arv försvårar ofta också möjligheten att se om systemet är heltäckande –Testerna som sådana kan dock oftast återanvändas i test av olika klasser i en hierarki –Därför Testa alla klasser i en hierarki

previous next 42 Hantering av krav. Testning. Undantagshantering. … Några speciella problem i OO-testning Inkapsling –Inget problem i sig men kan ge problem undersöka hur ett visst objekt beter sig eller förändras (tex vilka tillståndsförändringar som sker) –Eventuellt kan man införa vissa ”spårmetoder” som bara används under testningen Polymorfi –Varje polymorfiskt alternativ måste testas –Svårt att se bindningar till konkreta metoder

previous next 43 Hantering av krav. Testning. Undantagshantering. Testa program (forts), fallstudie Ett projekt som konstruerade ett Objective C-bibliotek ["Succeeding with Objects", av Goldberg och Rubin, s ] –80% av koden testades med ad hoc metoder –13% av koden genomgick granskning av projektmedlemmar –7% av koden granskades speciellt, antingen med extra testfall eller gruppgenomgång Resultat –40% av felen hittades i ad hoc-testet –40% genom att spela upp script av människa datorgränssnitt –20% genom kodläsning och "ren tur"(!!!?) Leverans –användare fann bara 5 fel i rader kod första året. Mot normala 10 fel per 1000 rader kod.

previous next 44 Hantering av krav. Testning. Undantagshantering. Undantagshantering

previous next 45 Hantering av krav. Testning. Undantagshantering. Undantagshantering (eng. Exception handling) Java är från början konstruerat med insikten om att fel uppkommer-ofta oväntade fel Programmeraren skall alltid vara beredd att hantera ett fel Därför ingår undantagshantering som en grundläggande mekanism i Java En "exception" är en händelse som "stör" det normala programflödet och hindrar programmet från att fortsätta Undantag kan vara av två olika modeller: –terminerande, dvs vi kan inte fortsätta från den punkt felet uppstod utan att åter anropa metoden som resulterade i felet –återupptagbar, vi kan fortsätta från avbrottspunkten (eventuellt med vissa data förändrade i felhanteringen) Java använder en terminerande modell

previous next 46 Hantering av krav. Testning. Undantagshantering. Exceptions Hanterar situationer då fel har uppstått Kan orsakas av fel koden inte klarar av att exekvera –tex division med noll eller okontrollerbara fel hos externa enheter –tex filsystemet har gått ner eller annat fel i filhantering Om något går fel –systemet signalerar ett avbrottsobjekt –Avbrottsobjektet letar sig upp i anropsstacken tills dess att en hanterare för det aktuella felet hittas. try {//"normal" kod} catch(Feltyp e) {//kod för att hantera felet} try {//"normal" kod} catch(Feltyp e) {//kod för att hantera felet}

previous next 47 Hantering av krav. Testning. Undantagshantering. Konsekvenser Genom att använda exceptions kan vi först fokusera på att skriva koden för normalfallet –Först sedan tar vi hand om olika fel Vi kan också (uniformt) hantera fel av grundläggande karaktär eller som sker i systemobjekt, som den virtuella maskinen Ett fel som uppstår i en del av koden kan hanteras i en annan (där man förmodligen bättre vet hur lämplig hantering skall gå till) Ett alternativ är att returnera null och sedan låta anropande rutin testa för detta fel –men vad händer om vi verkligen vill använda null som ett möjligt värde/resultat?

previous next 48 Hantering av krav. Testning. Undantagshantering. Javas exceptions I Java kan en metod deklarera att den "kastar" ett exception Användare av en sådan metod kan inte "glömma" att ta hand om ett sådant undantag utan är tvingade att skriva kod som hanterar felsituationen Tar man inte hand om undantaget så säger kompilatorn ifrån try { //kod som använder metod som kastar AktuelltUndantag } catch(AktuellUndantag e) {} try { //kod som använder metod som kastar AktuelltUndantag } catch(AktuellUndantag e) {} public void m() throws AktuelltUndantag {…}

previous next 49 Hantering av krav. Testning. Undantagshantering. Exempel: fånga IOException try { File f = new File("exceptiontest1.result"); FileWriter w = new FileWriter(f); PrintWriter out = new PrintWriter(w); out.println("Det blev inga fel!"); out.println(); out.close(); } catch(IOException e) { System.err.println("Fel i filhantering"); }

previous next 50 Hantering av krav. Testning. Undantagshantering. Exempel: aritmetiskt fel int res, a = 10, b = 0; try { res = a / b; } catch(ArithmeticException e) { out.println(e); res = 1; } out.println("Efter felhantering är res: " + res);

previous next 51 Hantering av krav. Testning. Undantagshantering.... kan också fångas via generellare Exception try { res = a / b; } catch(Exception e) { out.println(e); // skriv ut info om felet res = 100; } out.println("Efter felhantering är res: " + res);} ArithmeticException subklass till RuntimeException som är subklass till Exception

previous next 52 Hantering av krav. Testning. Undantagshantering. Felsignalerna bildar en hierarki Throwable Error LinkageError IncompatibleClassChangeError InstantiationError VirtualMachineError InternalError OutOfMemoryError StackOverflowError Exception IllegalAccessException IOException EOFException FileNotFoundException InterruptedIOException MalformedURLException RuntimeException ArithmeticException ClassCastException EmptyStackException IndexOutOfBoundsException ArrayIndexOutOfBoundsException StringIndexOutOfBoundsException NegativeArraySizeException NullPointerException SecurityException

previous next 53 Hantering av krav. Testning. Undantagshantering. Skapa och signalera fel Ny egen exception skapas som subklass till klassen Exception Signalera fel med meddelandet throw throw new MyException() public class MyException extends Exception { public MyException() {super();} public MyException(String s) {super(s);} } public class MyException extends Exception { public MyException() {super();} public MyException(String s) {super(s);} }

previous next 54 Hantering av krav. Testning. Undantagshantering. Exempel: throw package java.util public class Stack extends Vector { public Object push(Object item) {addElement(item); return item;}... public synchronized Object peek() { intlen = size(); if (len == 0) throw new EmptyStackException(); return elementAt(len - 1); }...

previous next 55 Hantering av krav. Testning. Undantagshantering. Fånga flera fel Vi kan fånga flera olika fel genom: Vi kan använda finally om vi alltid vill utföra ett kodblock try{öppna fil} catch(SomeException e) {felhantering} finally{fil.close()} try{...} catch(ExceptionOne e1) {} catch(ExceptionTwo e2) {} catch(ExceptionThree e3) {} try{...} catch(ExceptionOne e1) {} catch(ExceptionTwo e2) {} catch(ExceptionThree e3) {} try{...} catch(SomeException e) {} finally {//Gör alltid detta} try{...} catch(SomeException e) {} finally {//Gör alltid detta}

previous next 56 Hantering av krav. Testning. Undantagshantering. Fler exempel try { int a[] = new int[2]; a[4]; } catch (ArrayIndexOutOfBoundsException e) { System.out.println("exception: " + e.getMessage()); e.printStackTrace(); } Argumentet givet då undantaget kastades Skriv information om felet på System.err

previous next 57 Hantering av krav. Testning. Undantagshantering. Deklarera att ett exception kastas Vi kan i en metod deklarera att ett exception kastas Eller flera samtidigt public void myOpenFile() throws IOException {...} public File search(String s) throws IOException, MyException1, MyException2 {...}

previous next 58 Hantering av krav. Testning. Undantagshantering. Vissa exceptions behöver man inte ta hand om, om man inte vill Av praktiska skäl behöver man inte ta hand om exceptions som är subklasser till –Error –RuntimeException Annars skulle man behöva ha exceptionhandling överallt –Varför?

previous next 59 Hantering av krav. Testning. Undantagshantering. Exempel: Throwtest // Några egna Exceptions. class MyException extends Exception { public MyException() {super(); } public MyException(String s) {super(s);} } class MyOtherException extends Exception { public MyOtherException() { super(); } public MyOtherException(String s) {super(s);} } class MySubException extends MyException { public MySubException() { super(); } public MySubException(String s) {super(s);} }

previous next 60 Hantering av krav. Testning. Undantagshantering.... public class throwtest { public static void main(String argv[]) { int i; try { i = Integer.parseInt(argv[0]); } catch (ArrayIndexOutOfBoundsException e) { // argv är tom System.out.println("Must specify an argument"); return; } catch (NumberFormatException e) { // argv[0] inte ett heltal System.out.println("Must specify an integer argument."); return; } a(i); }

previous next 61 Hantering av krav. Testning. Undantagshantering.... // Anropa b(), som är deklarerad att kasta ett visst exception. // Vi hanterar detta exception. public static void a(int i) { try { b(i); } catch (MyException e) { // Point 1. // Vi hanterar MyException och dess subklass MyOtherException if (e instanceof MySubException) System.out.print("MySubException: "); else System.out.print("MyException: "); System.out.println(e.getMessage()); System.out.println("Handled at point 1"); }

previous next 62 Hantering av krav. Testning. Undantagshantering. …finally public static void b(int i) throws MyException { int result; try { System.out.print("i = " + i); result = c(i); System.out.print(" c(i) = " + result); } catch (MyOtherException e){//Point 2 System.out.println("MyOtherException: " + e.getMessage()); System.out.println("Handled at point 2"); } finally { // Gör alltid en radframmatning. System.out.print("\n"); }

previous next 63 Hantering av krav. Testning. Undantagshantering.... public static int c(int i) throws MyException, MyOtherException { switch (i) { case 0: throw new MyException("input too low"); case 1: throw new MySubException("input still too low"); case 99: throw new MyOtherException("input too high"); default: return i*i; }