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 1 Agenda Kursinformation Arkitektur Design Kodning Produktlinjer Konfigurationshantering - forts 2

2 Var är vi? Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt? Kan man förstå vad som händer i stora programvaruprojekt utan att ha studerat software engineering? Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4 3 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

3 Fråga från webben: Hur göra med användarmanual för systemstart? Svar: Vet ej! På lämpligt sätt... ;-) Detta vill vi uppnå: Smidigare acceptanstest (kurs-läge) Bör baseras på: krav och användarfall kring systemstart testfall för systemstart 5 Önskemål om Versionshistorien Kommentera gärna bort länkarna till 0.x-versionerna eller åtminståne till de outnyttjade versionerna 6

4 Kursinformation V 16: Nu: Arkitektur, design, kodning, versioner On kl 24: MS 1 eller To Ö: Mer om test: T Tips: Titta på en gammal tenta så förstår du varför det är bra att ägna tid åt kursboken. V 17 Ti kl MS 2: Test, Design + föregående granskningar to kl 9 Ö: Återkoppling test V 19: Må kl 15 F: Utvecklingsprocesser, vidareutveckling, om tentamen V 20: Må kl 15 F: Om tentamen, sammanfattning, utvärdering Notera: och i andra kurser -> ingår INTE i denna kurs 7 Arkitektur och Design 8

5 Design är både en aktivitet och ett resultat arkitektur -> design -> kod är en vettig hierarki. 9 Modulär nedbrytning Helt system Helt system Helt system M1 M1 M11 M12 M2 M3 M2 M21 M3 M22 10

6 men man kan ju även designa bottom-up M11 M12 M21 M22 M1 M11 M12 M2 M21 M22 M3 Hela systemet M1 M11 M12 M2 M3 M21 M22 11 Alltså Top-down Bottom-up Toppom-dup 12

7 Koppling I hur stor utsträckning är enheter i programmet kopplade till varandra? Man vill ha låg koppling 13 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 14

8 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 15 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 16

9 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 17 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 18

10 Arkitekturer: Exempel Delad data Client-server -modellen gemensam information repository 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 19 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 20

11 Client-server -modellen Klient 1 Klient 2 Klient n Betj. m Nätverk Betj. 1 Betj. 1 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 21 Layered system: Exempel OSI - referensarkitektur 22

12 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, 23 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! 24

13 Kort om kodning 25 Kodning Kombineras med enhetstestning Kodningsstandarder kan finnas Kodgranskningar kan utföras 26

14 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? 28

15 Design/arkitektur är även att fördela 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?) 29 Plattformar 30

16 Plattformar inom produktutveckling Inte bara inom programvara: Black & Decker Battery Pack Motor Pack Bilindustri Peugeot, Fiat, Toyota, etc 31 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 32

17 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 33 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. 34

18 Konfigurationshantering Testpro tokoll Design Utb.- plan Test Manualer Projektplan Krav Process Kod Olika versioner Olika produktvarianter Olika kunder 35 Diskussion: Försök förklara för din granne: Vad är det för skillnad mellan konfiguration och version och variant? & Vad betyder: Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4

19 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. 37 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. För system eller produkt etablera & underhålla Konsistens mellan Å ena sidan: prestanda, funktioner, attribut Å andra sidan: krav, design, operationell information Livscykel 38

20 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? 39 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) 40

21 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? 41 Ä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! } } 42

22 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: 43 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 44

23 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) 45 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. 46

24 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 V 19 inleds med tecknad serie (F5) Fråga: Ska jag avdela en del av F6 till LUs webbprojekt? 48 Exekverbar källkod Dokumenterat genomförda systemtest