Föreläsning 4 Arkitektur, design, kodning

Transkript

1 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 4 Arkitektur, design, kodning Jonas Wisbrant 2 Agenda Kursinformation Arkitektur Design Kodning Produktlinjer Konfigurationshantering - forts 3

2 Detta har hänt... Pratat krav och plan och test Övning 3: Utformat testfall Fått återkoppling och kanske reviderat krav och plan inför MS1 Haft kursombudsmöte Påbörjat testplan med testspecifikation? Förbereda testrapport? Påbörjat design? Börjat programmera? 4 Ombudsmöte Långsiktiga utmaningar: Möjlighet till samtidig skrivning i en wiki-sida Möjlighet att ladda ned föreläsningsfilmerna Önskemål inför nästa kursomgång: Mer tidigt stöd för wikin, wiki-lathund och kanske gör-det-själv-labb, ordnad peer-support? Bättre struktur på informationsmaterialet: - Kompendiet ostrukturerat - bättre logisk följd - Övningsfrågorna borde finnas i kompendiet - Bättre beskrivning av hur projektet ska gå till - Wikins templates stämmer inte med projektbeskrivningen (kurswebb) Önskemål på kort sikt: Förtydligande av vad som förväntas av manual/lathund i projektet. Förtydligande av om det är frågan om ett studentprojekt, fiktivt verkligt projekt eller både-och. Finns inget självklart svar. Förtydligande av att man inte kan räkna med föreläsningsfilmerna under hemtentan Eventuellt nytt möte måndag 9/5 kl

3 Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt? Utmaning Kan man förstå vad som händer i stora programvaruprojekt utan att ha studerat software engineering? = barcode reader Operator = electronic lock Barcode printer PC Kravspecifikation = pincode terminal Fas 1 Specifikation Projektplan Testplan Extra exit door Bicycle garage Entry door Fas 2 Design Designdokument Exit door Fas 3 Implementation och enhetstest Fas 4 Systemtest Exekverbar källkod Dokumenterat genomförda systemtest Projekthandledare Projektgrupp QA från IP3 6 Hur ska vi gör med manualen / lathund? Svar: Vet ej! På lämpligt sätt... ;-) Detta vill vi uppnå: En metod för att bli klokare på hur systemet skall användas Smidigare acceptanstest (kurs-läge) Utnyttja/förstå kopplingen: Likhet: Förlopp Testfall Skillnader: - Inramning - Språkbruk - Kontext 1. Börja 2. Genomför 3. Slutför Användarfall Manual 7

4 Önskemål om Versionshistorien Kommentera gärna bort länkarna till 0.x-versionerna eller åtminståne till de outnyttjade versionerna 8 Kursinformation V 4: Nu: Arkitektur, design, kodning, versioner Ti kl 24: MS 1 eller To Ö: Mer om test: T V 5: Må kl 13 F: Utvecklingsprocesser, vidareutveckling, om tentamen To övning: Om tenta och återkoppling testplan Notera: och i andra kurser -> ingår INTE i denna kurs 9

5 Arkitektur och Design 10 Design är både en aktivitet och ett resultat arkitektur -> design -> kod är en vettig hierarki. 11

6 Modulär nedbrytning Helt system Helt system Helt system M1 M1 M11 M12 M2 M3 M2 M21 M3 M22 12 men man kan ju även designa bottomup M11 M12 M21 M22 M1 M11 M12 M2 M21 M22 M3 Hela systemet M1 M11 M12 M2 M3 M21 M22 13

7 Alltså Top-down Bottom-up Toppom-dup 14 Koppling I hur stor utsträckning är enheter i programmet kopplade till varandra? Man vill ha låg koppling 15

8 Koppling påverkas av Antal gränssnitt mellan olika delar Typ av gränssnitt Enkla gränssnitt ger lägre koppling än komplicerade gränssnitt Åtkomst av interna detaljer ger högre koppling än endast anrop av funktioner Kommunikation av endast data ger lägre koppling än kommunikation av kontrollinformation Vid objektorientering komponent-nivå-koppling t ex när en klass har en annan klass som instansvariabel Interaktionskoppling (som gränssnitt ovan) Koppling baserat på ärvning 16 Samhörighet (Cohesion) Hela systemet M1 M11 M12 Hur väl innehållet i en del hänger samman M2 M3 Slumpvis inga meningsfulla beroenden, M21 bara paketerat M22 Logiskt t ex en modul som sköter all utmatning av data Temporal t ex en modul som sköter all uppstart eller avslut Procedurbaserad när procedurer som utförs efter varandra slås ihop, t ex innehållet i en loop Kommunikationsbaserad när delar som behandlar samma data slås ihop Sekvensiell när serier av procedurer som utgör indata till varandra slås samman Funktionell när innehållet står för en enstaka funktion, t ex sortera vektor 17

9 Diskutera i grupper om 2-3 personer Varför är det viktigt med låg koppling och hög samhörighet i allmänhet i ert projekt Hur ska man göra för att uppnå detta rent konkret i ett projekt som ert? Hela systemet M1 M11 M12 M2 M21 M22 M3 18 Mål med en arkitekturdesign (dokument) Förståelse och kommunikation Möjliggöra återanvändning på hög nivå Stöd för konstruktion och utveckling Underlag för analys 19

10 Arkitekturdesign, olika vyer Modul-beskrivning t ex programkod med relationer Klass A är beroende av Klass B Komponenter och konnektorer t ex binärer och kopplingar Object A delar data med objekt B Allokeringsbeskrivningar fysisk allokering av systemets komponenter låsreglerna finns i systemet, låstimern finns i dörrposten 20 Arkitekturer: Exempel Delad data gemensam information repository Client-server -modellen Klient 1 Klient 2 Klient n Nätverk Delsystem 1 Delsystem 2 Delsystem n Betj. 1 Betj. 1 Betj. m Abstract-machine modellen / Layered system Pipes and filters 21

11 Delad data gemensam information repository Delsystem 1 Delsystem 2 Delsystem n Fördelar: Effektivt med mycket data De som producerar data måste inte veta så mycket om mottagaren Backup, etc lätt Svårigheter: Alla delsystem använder samma dataform Vidareutveckling kan vara svårt eftersom mycket bygger på en viss datamodell Olika krav på detta 22 Client-server -modellen Klient 1 Klient 2 Klient n Nätverk Betj. 1 Betj. 1 Betj. m Fördelar: Distribuerad arkitektur Lätt att lägga till klienter och betjänare Svårigheter: Nya enheter måste kanske anpassas Ingen gemensam datamodell 23

12 Layered system: Exempel OSI - referensarkitektur 24 Hur ska man välja arkitektur? Kvalitetskrav påverkar beslutet, t ex: Prestanda (svarstid, genomströmning) Inte för mycket kommunikation, Säkerhet mot intrång (Security) Kritiska funktioner i lägre lager, Säkerhet för användaren (Safety) Operationer i begränsat antal moduler, Tillgänglighet Redundanta komponenter, Underhållbarhet Komponenter som är lätta att förstå för sig själva, låg komplexitet, 25

13 Utvärdering - Mått på design? Hur avgör man om en design är bra? Några förslag: Graph impurity Informationsflöde = size * (inflow * outflow) 2 Weighted methods per class:... WMC= n " i=1 c i! Hela systemet M1 M11 M12 M2 M21 M22 M3 Inte uppenbart hur man ska mäta detta! 26 Ett förslag: Graph impurity GI = n e 1 n = antal noder e = antal bågar GI = 0: perfekt Är detta ett bra mått på en design? - Varför? - Varför inte? 6-5-1= = -8 27

14 Kodning 28 Kodning Kombineras med enhetstestning Kodningsstandarder kan finnas Kodgranskningar kan utföras 29

15 Ett exempel på en kodningsstandard (Java) Basic File names File organization Indention (4 characters) Comments Declarations (1/line) Statements (if always with {}) White space (2 lines between ) Naming conventions Additional Naming (semantic consistency, understandable abbreviations, ) Constant names instead of raw numbers) Every class should have a comment Avoid static variables File size < 200 LOC Exempel från Xuefen Fang, Using a coding standard to improve program quality Quality Software, Varför vill man ha denna typ av standarder? Ökad rörlighet Personer kan gå mellan projekt Erfarenheter best practice Trovärdighet Vilka problem finns att införa standarder? Vad kan man göra för att komma tillrätta med problemen? 31

16 Design/arkitektur är även att bestämma ansvar Varje modul/klass/etc ska utvecklas av någon Person, avdelning, företag, Även resurser i organisationen kan påverka design/ arkitektur Organisation speglar design (och vice versa?) 32 Plattformar 33

17 Plattformar inom produktutveckling Inte bara inom programvara: Black & Decker Battery Pack Motor Pack Bilindustri Peugeot, Fiat, Toyota, etc Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4 34 Software product line A software product line is a set of softwareintensive systems that share a common, managed set of feature that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. F k1 F k2 F kn productlines/about_pl.html Plattform v. k F k+1.1 F k+1.2 F k+1.m Plattform v. k+1 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4 35

18 Vad innebär detta? Parallell utveckling -> lägre kostnader, fler produkter, kortare tid till marknad per produkt Ökad komplexitet: t ex nya krav och påverkar flera produkter (och plattformar). Mer komplexa projektplaner, testning, organisation Långsiktiga beslut för plattform, kortsiktiga beslut för produkter Nya produkter innehåller funktioner från tidigare produkter -> I stort sett aldrig specifikation från 0. Mycket arv 36 Er design i projektet Ingen mall finns Alla klasser ska beskrivas Namn, konstruktorer, publika metoder, ärvning Ange även ansvarig för klasser/metoder Rita grafiskt (klassdiagram) Följ gränssnitt enligt projektbeskrivningen. 37

19 Konfigurationshantering Testpro tokoll Design Utb.- plan Test Manualer Projektplan Krav Process Kod Olika versioner Olika produktvarianter Olika kunder 38 Diskussion: Försök förklara för din granne: Vad är det för skillnad mellan konfiguration och version och variant? & Vad betyder:

20 Configuration Management Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. 40 Configuration Management Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. 41

21 Typiska frågor man kan vilja ha svar på Vilka kunder har installerat en viss version av systemet? Vilken hårdvara och OS krävs för en viss version? Vilka versioner har levererats av ett visst system? Vilka versioner påverkas om jag ändrar en viss komponent i systemet? Hur många olika ändringar håller man på att göra av ett visst system? Hur många rapporterade men ännu ej rättade fel finns det i ett system hos en viss kund? 42 Planering av konfigurationhantering Bestäm vad som ska konfigurationshanteras Projektdokument inte säkert Produktdokument ja Organisationsdokument ja, men inte av projektet Bestäm rutiner för konfigurationshantering Bestäm ansvarig för konfigurationshantering Bestäm hur ändringshantering ska gå till Bestäm vilka verktyg för konfigurationshantering som ska användas (och vilken typ av databas man ska använda) 43

22 Versioner, releaser och delta V 1.0 release V 1.1 version V 1.2 version V 1.3 version V 2.0 release V 2.1 version V1.0 V1.1 V1.2 Delta 1 Delta 2 Lagra ändringar i delta Hålla reda på ändringshistoria ID för varianter/grenar V1.1a V1.1.1 V1.0 V1.1 V1.2 V2.0 V1.1b Delta? 44 Ändringshantering ordnad övergång Begär ändring genom att fylla i formulär Analysera ändringsbegäran Om ändring nödvändig och korrekt {! Utvärdera hur ändring kan göras + kostnad! Skicka förfrågan till CCB! Om ändring accepterad {!! Ändra i systemet!! Uppdatera ändringsbegäran!! tillverka ny version av systemet! } } 45

23 Formulär för ändringshantering, del av information Del 1 Namn Projekt Ändring nr Anledning Objekt att ändra Del 3 Förslag på ändring Skattad tid CCB-möte, datum CCB beslut Del 2 Utredare Resultat av utredning Del 4 Ansvarig för ändring Kommentar Ny version: 46 CCB Change Control Board Strategiska beslut om vilka ändringar som ska ske Inte bara tekniska beslut Representerar kund, projekt och andra intressenter För programvara som används i flera produkter blir det mer komplicerat 47

24 Systembygge Bygga en fungerande version av hela systemet från de komponenter som finns, t ex Senaste versionerna av allt En viss version av en viss produkt En viss version av en viss produkt till en viss kund En viss version av en viss produkt till en viss plattform Behövs t ex vid systemtest och andra tester (och såklart vid leverans) 48 Sammanfattning och i andra kurser -> ingår inte i denna kurs Design görs på olika nivåer: arkitektur -> design -> kodning Man vill ha låg koppling och hög sammanhållning Exempel på vanliga arkitekturer: delad data, client server, layered system, pipes and filters Kvalitetskravkrav påverkar arkitekturen Plattformsbaserad utveckling ger parallellism och kortare tid till marknad, men också ökad komplexitet Ändringshantering görs för att rätt beslut ska tas baserat på både tekniska frågor och affärsbeslut I projektet får ni göra mycket som ni vill innan v 0.99, men efter det måste ni följa procedurerna i kompendiet. För kravspecifikationen måste ändringar efter 1.0 godkännas av projekthandledaren. 49

25 Uppgift: Programmera ett cykelgarage Uppdrag Faser och leverabler Målmiljö Kravspecifikation = barcode reader Operator = electronic lock Barcode printer PC = pincode terminal Fas 1 Specifikation Projektplan Testplan Fas 2 Design Extra exit door Bicycle garage Entry door Designdokument Fas 3 Implementation och enhetstest Exit door Fas 4 Systemtest Utvecklingsmiljö Aktörer Dokumentmiljö Projekthandledare Projektgrupp QA från IP3 Alltså V 4: Ti kl 24: MS 1 eller eller annan ÖK! To Ö: Mer om test: T.9-11 Tips: Titta på en gammal tenta... V 5 inleds med tecknad serie 51 Exekverbar källkod Dokumenterat genomförda systemtest