Föreläsning 4: Test II, Design I Programvaruutveckling - Metodik 2017 Markus Borg 1
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
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
Översikt över projekten
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
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
Kort om projektbetygen
Några riktlinjer
Kursbetyget = Projekt + Hemtenta
Ordlista inför och efter tentamen Ligger nu Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik i ETSA0 2 Alla
Construction! Flickr: canadianveggie Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Construction! Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
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
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 https://drive.google.com/open?id=1w3-bokncobiucbnlo-peduks LEkjMH2UAuxil_TKoj4 Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Verifiering & Validering II Programvaruutveckling - Metodik 2017 Markus Borg 1 5
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
Repetition Black-box testing Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Repetition Ekvivalenspartitionering Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Repetition Gränsvärdestestning Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Repetition Parvis testning Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
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
White-box testing Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
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
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
Täcka rader (statement coverage) Exekvera alla rader minst en gång Alla noder i kontrollflödesgrafen
Täcka grenar (branch coverage) Exekvera alla grenar minst en gång Alla bågar i kontrollflödesgrafen Innefattar även komplett radtäckning
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!
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
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
Exempel (CC = #bågar - #noder +2)
Ett något större exempel CC = #bågar - #noder + 2 = 16-14 + 2 = 4
Slutord - Test Testning ofta den enskilt dyraste aktiviteten i ett utvecklingsprojekt $$$
När är testningen färdig? Finns inga garantier att alla defekter är hittade! Man kan alltid testa mer
Programvarudesign Programvaruutveckling - Metodik 2017 Markus Borg 3 4
Programvarudesign - agenda Arkitekturdesign Objektorienterad design Design av användargränssnitt Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Design Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
Design är både en aktivitet och ett resultat Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
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
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
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
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
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
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
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
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
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
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
LinkedIn: Java-arkitektur Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
CSN: http://ow.ly/idn630b6hxi Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik
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
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
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 -
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
Objektorientering - Fundamentala koncept 1. Inkapsling 2. Abstraktion 3. Arv 4. Polymorfism
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
Klassdiagram
Sekvensdiagram (c-sharpcorner)
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
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
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
Exempelmönster: Observer Separera ett objekts tillstånd från presentation Möjliggör flera olika vyer
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
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
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. - @taggar där lämpligt
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
Övning 4a och 4b Samma upplägg som Ö1a-Ö1b kursvecka 2 - Övning 4a på onsdag kl. 13-15 eller 15-17 - Hemarbete 2 h - Övning 4b på torsdag kl. 8-10 eller 10-12 Sista övningarna - men kod/projekt-jour minst kommande onsdag... Lund University Computer Science Markus Borg ETSA02 Programvaruutveckling - Metodik