Föreläsning 4: Test II, Design I Programvaruutveckling - Metodik 2017 Markus Borg

Transkript

1 Föreläsning 4: Test II, Design I Programvaruutveckling - Metodik 2017 Markus Borg 1

2 Agenda F4 Kursformalia Översikt Kursbetyg Projektet Nästa fas: Construction Burndown charts Programvarutestning - del 2 White-box testning Programvarudesign - del 1 Arkitekturdesign (Objektorienterad design) (Design av användargränssnitt) Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

3 Kursinformation Nyligen: Implementerat feedback 3 Ö3: Skissat på testplan + testspecifikation på systemnivå På gång: Nu: Föreläsning 4 Snart: Muntlig komplettering FB3 - enligt ÖK med PHL Ons-tors:Dubbelövning för testfall för UC1: Cykel Garage Fredag: L4: Krav 1.0 & Projektplan = Baseline MS1 Formell ändringshantering inleds! Nästa vecka: Tisdag(!): Onsdag: Föreläsning 5 (Design II, plattformar, konfigurationer) Kodövningar med jour

4 Översikt över projekten

5 Vad återstår i projekten? Omarbete Muntlig komplettering FB3 per grupp PHL kopierar L4 till QA-mapp Peer QA Meta QA PHL gör extra koll

6 Förslag: Kommentera och färgkoda uppföljningen gult= kan ej, delvis, svårt att följa upp... På fredag när ni rapporterar att Kravspecifikation v. 1.0 finns

7 Kort om projektbetygen

8 Några riktlinjer

9 Kursbetyget = Projekt + Hemtenta

10 Ordlista inför och efter tentamen Ligger nu Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik i ETSA0 2 Alla

11 Construction! Flickr: canadianveggie Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

12 Construction! Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

13 Burndown charts Y-axeln visar återstående arbete i tid X-axeln är återstående tid Blå kurva visar planerad insats Röd kurva visar faktisk insats Synliggör insats Underlättar planering/riskhantering Kan aggregeras till produkt-/verksamhetsnivå Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

14 Omröstning: fördjupning 1. Säkerhetskritisk utveckling Säkerhetsstandarder, spårbarhet, påverkansanalys, certifiering 2. Demonstration av testtekniker och verktyg Parvis testning, testautomation med JUnit, kodtäckningsmätning 3. Gästföreläsning: Produktledning på Sony Mobile Produktplanering, releaseplanering, ekosystem Rösta idag eller imorgon! Google Form finns i ETSA02 Alla LEkjMH2UAuxil_TKoj4 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

15 Verifiering & Validering II Programvaruutveckling - Metodik 2017 Markus Borg 1 5

16 Repetition Black-box vs. White-box Black-box Programmet ses som en svart låda och man utnyttjar inte någon kunskap om koden i samband med definition av testfall Kravspecifikationen används för att ta fram testfall Testar utfall/resultat White-box Kräver tillgång till koden Testar utfall och inre funktion täcker vi raderna? täcker vi vägarna? Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

17 Repetition Black-box testing Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

18 Repetition Ekvivalenspartitionering Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

19 Repetition Gränsvärdestestning Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

20 Repetition Parvis testning Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

21 Repetition Färdigtestat? När vi gjort vad vi lovat i projekt- och testplan: t ex visat att alla kraven på alla abstraktionsnivåer är uppfyllda:...traverserat alla grenar i koden......med alla upptänkliga kombinationer av variabler......på alla plattformar......med >max belastning Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

22 White-box testing Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

23 Vad innebär det som står i kompendiets Testplan (avsnitt 5) Betyder? 3.2 Unit testing Structural (white-box) testing is mainly used Before the developers check in and baseline any code, it should have been tested, using a complete statement coverage criteria No defects found 3.3 Integration testing The integration testing should exercise all calls to the other units API Complete coverage of the API No defects found 3.4 System testing Functional based on the requirements (Appendix A) all requirements are tested No critical defects are found when all defined test cases are executed 3.5 Acceptance testing up to customer... Testrapporter från systemtest är en leverabel - uppfinn och beskriv (se 3.7.3) Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

24 White-box testning Kräver tillgång till koden Tanken är att testfallen ska täcka all kod - Men vad menas med all kod? Betrakta kodens kontrollflödesgraf

25 Täcka rader (statement coverage) Exekvera alla rader minst en gång Alla noder i kontrollflödesgrafen

26 Täcka grenar (branch coverage) Exekvera alla grenar minst en gång Alla bågar i kontrollflödesgrafen Innefattar även komplett radtäckning

27 Täcka vägar (path coverage) Exekvera samtliga vägar från startnod till slutnod Innefattar även komplett grentäckning Antalet testfall exploderar med loopar!

28 Täcka enkla vägar (simple path coverage) Exekvera samtliga linjärt oberoende vägar från startnod till slutnod Innefattar komplett grentäckning Hanterar problematiken med loopar Ofta en rimlig kompromiss

29 McCabe s Cyclomatic Complexity (CC) Används för att beräkna antalet enkla vägar i en kontrollflödesgraf Antal linjärt oberoende vägar: CC = #bågar - #noder + 2 Krav En enda komponent i grafen En unik startnod samt en unik slutnod

30 Exempel (CC = #bågar - #noder +2)

31 Ett något större exempel CC = #bågar - #noder + 2 = = 4

32 Slutord - Test Testning ofta den enskilt dyraste aktiviteten i ett utvecklingsprojekt $$$

33 När är testningen färdig? Finns inga garantier att alla defekter är hittade! Man kan alltid testa mer

34 Programvarudesign Programvaruutveckling - Metodik 2017 Markus Borg 3 4

35 Programvarudesign - agenda Arkitekturdesign Objektorienterad design Design av användargränssnitt Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

36 Design Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

37 Design är både en aktivitet och ett resultat Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

38 Modell för design av objektorienterad programvara Förstå kraven Designa arkitektur Identifiera objekt (Sommerville, 2015) Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik Utveckla designmodell Specificera gränssnitt

39 Arkitekturdesign Nedbrytning av systemets övergripande struktur System - helheten Subsystem enhet som ej beror på andra subsystem Moduler enhet som verkar ihop med andra moduler (Komponenter en eller flera klasser) System Subsystem A M A-1 Subsystem B Subsystem C M C-1 M B-1 M C-2 M A-2 M B-2 M B-3 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik M C-3

40 system = samling komponenter som samverkar för att uppnå ett mål system-av-system = samling system som samverkar för att uppnå mål utöver summan av de ingående systemen (framträdande egenskaper) Från militära tillämpningar till civilt bruk (t.ex. trafikmiljö eller industri 4.0) Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

41 Syfte med arkitekturdesignen Länk mellan kraven och detaljerad design Grov ritning för implementation Kommunicerar designbeslut i organisationen Grund för systemanalys Säkerhet Prestanda Underlättar återanvändning Använda delar i andra system Utveckla produktlinjer

42 Val av arkitekturdesign Förståelse för kontext och intressenter nödvändig för bra beslut Kvalitetskraven avgör ofta beslutet Arkitekturellt signifikanta krav Vad vill vi uppnå? Motsättningar vanligt! Övriga faktorer som kan avgöra Organisationens tekniska kompetens och erfarenhet Återanvändning av tidigare arkitektur Standarder som behöver uppfyllas Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

43 Prestanda? Kommunikation är en prestandatjuv! Samla tunga beräkningar i moduler som kommunicerar minimalt utåt Acceptera att beräkningsmoduler blir stora System Subsystem A M A-1 M A-2 Subsystem B M B-1 M A-3 M B-2 M A-4 M A-5 M A-6 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik M B-3

44 Säkerhet? (security) Åtkomstbegränsning viktigt Introducera säkerhet i olika lager Hantera den känsligaste informationen innerst System Subsystem A M A-1 M A-4 M A-2 Subsystem B M A-3 M SECURE Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik M B-1 M B-2 M B-3 M B-4 M B-5 M B-6

45 Säkerhet? (safety) Att verifiera säkerhetskrav är svårt och dyrt Samla alla säkerhetskritiska operationer i separat subsystem System Subsystem A M A-1 Subsystem B Subsystem C M C-1 M B-1 M C-2 M A-2 M B-2 M B-3 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik M C-3

46 Tillgänglighet? Minimera risken att systemet är otillgängligt Introducera redundans System Subsystem B1 Subsystem A M B1-1 M A-1 M A-2 M A-3 Subsystem B2 M A-4 M A-5 M B2-1 M A-6 46 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

47 Enkelt underhåll/evolution? Fokusera på små oberoende moduler Minimal kommunikation gör det lättare att ersätta moduler i framtiden Tjänsteorienterad arkitektur (microservices) System Subsystem A M A-1 M A-4 M A-2 M A-5 Subsystem B M A-3 M B-1 M B-2 M B-3 M B-4 M B-5 M B-6 M B-7 M B-8 M B-9 M A-6 47 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

48 LinkedIn: Java-arkitektur Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

49 CSN: Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik

50 Typexempel Repository (delad data) Gemensam information repository subsystem 1 subsystem 2 subsystem n Fördelar: Svagheter: - Effektivt med mycket data - Alla subsystem måste använda samma dataformat - Data-producent måste inte veta så mycket om konsument - Operationer på all data underlättas, t.ex. backup - Vidareutveckling kan vara svårt eftersom mycket bygger på en viss datamodell

51 Typexempel - Client-server Klient 1 Klient 2 Klient n Nätverk Betj. 1 Fördelar: Distribuerad arkitektur Lätt att lägga till nya klienter och betjänare Betj. 1 Betj. m Svagheter: Uppdatering av klient eller betjänare kan kräva uppdatering av samtliga Ingen gemensam datamodell

52 Typexempel Abstraktionslager Varje lager utgör en abstrakt maskin som används av nästa lager Fördelar: Svagheter: Stöd för inkrementell utveckling Underlättar portabilitet Kan uppstå beroenden mellan flera lager Kan bli sämre prestanda -

53 Objektorienterad design Implementationsnära design Beskrivning av hur komponenter implementeras på klassnivå Klasser beskriver meningsfulla entiteter i problemdomänen - Substantiv i beskrivningen blir klasser - Operationer implementeras i metoder

54 Objektorientering - Fundamentala koncept 1. Inkapsling 2. Abstraktion 3. Arv 4. Polymorfism

55 Unified Modeling Language - UML Generellt språk för att modellera programvarusystem Standardiserat av ISO Tre skapare, varav en svensk: Ivar Jacobson Statisk modell av systemet Klassdiagram Dynamisk modell av systemet Sekvensdiagram Mer i kursen Objektorienterad design och modellering eller Objektorienterad design och diskreta strukturer

56 Klassdiagram

57 Sekvensdiagram (c-sharpcorner)

58 Designmål: Låg koppling (coupling) I hur stor utsträckning är klasser i programmet kopplade till varandra? Låg koppling underlättar underhåll och evolution

59 Designmål: Hög samhörighet (cohesion) Hur väl innehållet i en klass hänger samman Exempel: Logisk t.ex. en klass som sköter all utmatning av data Temporal t.ex. en klass som sköter all uppstart eller avslut Procedurbaserad aktiviteter som utförs efter varandra slås ihop Kommunikationsbaserad delar som behandlar samma data slås ihop Sekventiell kedja av aktiviteter som hänger ihop i sekvens Funktionell innehållet står för en enstaka funktion, t ex sortera vektor

60 Designmönster Beprövade lösningar på återkommande problem Ursprungligen från arkitektur Inom programvara används objektorienterade koncept Några exempel: Singleton Iterator Visitor garanterar ett unikt objekt av en klass traverserar en samling objekt gör en operation på samtliga objekt i en samling

61 Exempelmönster: Observer Separera ett objekts tillstånd från presentation Möjliggör flera olika vyer

62 Design av användargränssnitt Textbaserat gränssnitt Kraftfullt för expertanvändare Grafiska användargränssnitt Lättare att lära sig och använda

63 Några grundläggande designprinciper Igenkänning Använd välkänd terminologi från domänen Följ beprövade koncept (fönster, flikar, dialogfönster etc.) Konsistens i GUIt Använd samma grafiska komponenter överallt Erbjud samma kortkommandon överallt Inga överraskningar Användaren ska kunna förutspå vad som händer Återhämtning Användare gör fel: tillåt återgång till föregående tillstånd Guida användaren Hjälp användaren och presentera feedback

64 I projektet: Designdokumentet Ingen mall finns Hitta ett format som funkar enligt policy i processmodellen Rita klassdiagram Behöver inte vara UML Relationer och multiplicitet Alla GUI-klasser behöver ej visas (en GUI -box räcker) Högnivå beskrivning av ansvarsfördelning Referens till javadoc med: - Ansvarig utvecklare och kort förklaring av klassens syfte. - Alla publika metoder. Namn, parametrar och returvärde. där lämpligt

65 Design - sammanfattning Design är både en aktivitet och ett resultat Arkitekturdesign är en övergripande nedbrytning av systemstruktur: System Subsystem Moduler Val av arkitektur beror på kvalitetskraven Exempel: repository, client-server, abstract machine Objektorienterad design beskriver hur komponenter implementeras av klasser Beskrivs vanligtvis med UML Sträva efter låg koppling och hög sammanhållning Utveckla GUI som matchar användarens mentala modell

66

67 Övning 4a och 4b Samma upplägg som Ö1a-Ö1b kursvecka 2 - Övning 4a på onsdag kl eller Hemarbete 2 h - Övning 4b på torsdag kl eller Sista övningarna - men kod/projekt-jour minst kommande onsdag... Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik