Att fundera på medan vi väntar: Vad är det för skillnad mellan
konfiguration och version och variant?
ETSA01 Ingenjörsprocessen för programvaruutveckling – Metodik
&
Föreläsning 4 Arkitektur, design, kodning
Vad betyder:
Jonas Wisbrant
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Agenda
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?
• Kursinformation • Arkitektur • Design • Kodning • Produktlinjer • Konfigurationshantering - forts
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
2
3
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
4
Ombudsmöte 2011-03-31
Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt?
Utmaning
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 12.30
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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
5
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
6
Hur ska vi gör med manualen / lathund?
Önskemål om Versionshistorien
Svar: Vet ej! På lämpligt sätt...
• Kommentera gärna bort länkarna till 0.x-versionerna – eller åtminståne till de outnyttjade versionerna
;-)
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 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Manual 7
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
8
Kursinformation • V 4:
– Nu: Arkitektur, design, kodning, versioner – Ti kl 24: MS 1 eller 0.991... – To Ö: Mer om test: T9.9-11
Arkitektur och Design
• V 5:
– Må kl 13 F: Utvecklingsprocesser, vidareutveckling, om tentamen – To övning: Om tenta och återkoppling testplan Notera: 6.2–6.5 och 7.1.1–7.1.3 i andra kurser -> ingår INTE i denna kurs
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
9
Design
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
10
Modulär nedbrytning
är både en aktivitet
Helt system
Helt system M1
och ett resultat
M2
Helt system M1 M11 M12
M3
M2
M3
M21 M22
arkitektur -> design -> kod är en vettig hierarki.
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
11
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
12
… men man kan ju även designa “bottomup”…
M1 M11 M12
M11 M12
M2 M21 M22
M21 M22
M3
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Alltså…
Hela systemet
Top-down
Bottom-up
Toppom-dup
M1 M11 M12 M2
M3
M21 M22
13
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
14
Koppling
Koppling påverkas av
• I hur stor utsträckning är enheter i programmet kopplade till varandra? • Man vill ha låg koppling
• 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
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
15
16
Samhörighet (Cohesion)
Hela systemet M1 M11 M12
Diskutera i grupper om 2-3 personer
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”
• Varför är det viktigt med låg koppling och hög samhörighet – i allmänhet – i ert projekt
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
17
• Hur ska man göra för att uppnå detta rent konkret i ett projekt som ert? Hela systemet M1 M11 M2
M12 M3
M21 M22
Mål med en arkitekturdesign (dokument)
Arkitekturdesign, olika vyer
• Förståelse och kommunikation
• Modul-beskrivning
18
– t ex programkod med relationer – Klass A är beroende av Klass B
• Möjliggöra återanvändning på hög nivå • Stöd för konstruktion och utveckling
• Komponenter och konnektorer
• Underlag för analys
– 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 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
19
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
20
Arkitekturer: Exempel
Delad data
gemensam information ”repository”
Klient 1
Klient 2
…
Klient n
Nätverk Delsystem 1
gemensam information ”repository”
”Client-server”-modellen
Delad data
Delsystem 2
…
Delsystem n
Betj. 1
“Abstract-machine” modellen / Layered system
Betj. 1
…
Betj. m
Pipes and filters
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Klient 2
Delsystem 2
…
Delsystem n
Fördelar:
Svårigheter:
• Effektivt med mycket data • De som producerar data måste inte veta så mycket om mottagaren • Backup, etc lätt
• Alla delsystem använder samma dataform • Vidareutveckling kan vara svårt eftersom mycket bygger på en viss datamodell • Olika krav på detta
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
21
22
Layered system: Exempel OSI - referensarkitektur
”Client-server”-modellen Klient 1
Delsystem 1
…
Klient n
…
Betj. m
Nätverk
Betj. 1
Betj. 1
Fördelar: – Distribuerad arkitektur – Lätt att lägga till klienter och betjänare
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Svårigheter: – Nya enheter måste kanske anpassas – Ingen gemensam datamodell 23
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
24
Utvärdering - Mått på design? Hur avgör man om en design är ”bra”?
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,…
• Några förslag: – Graph impurity – Informationsflöde = size * (inflow * outflow)2 n
– Weighted methods per class: – ...
WMC=
"c
!
i
i=1
Hela systemet M1 M11 M2
M12 M3
M21 M22
Inte uppenbart hur man ska mäta detta! Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
25
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
26
Kodning
Kombineras med enhetstestning
Kodning
Kodningsstandarder kan finnas Kodgranskningar kan utföras
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
27
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
28
Ett exempel på en kodningsstandard (Java)
Varför vill man ha denna typ av standarder?
Basic
Additional
• File names • File organization • Indention (4 characters) • Comments • Declarations (1/line) • Statements (if always with {}) • White space (2 lines
• Naming (semantic
• Ökad rörlighet – Personer kan gå mellan projekt • Erfarenheter – “best practice” • Trovärdighet
between…) • Naming conventions
consistency, understandable abbreviations,…) • Constant names instead of raw numbers)
• Every class should have a comment • Avoid static variables • File size < 200 LOC
Vilka problem finns att införa standarder? Vad kan man göra för att komma tillrätta med problemen?
… Exempel från Xuefen Fang, Using a coding standard to improve program quality Quality Software, 2001.
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
29
Design/arkitektur är även att bestämma ansvar
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
30
Plattformar
• 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?)
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
31
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
32
Plattformar inom produktutveckling
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.
Inte bara inom programvara: • Black & Decker
http://www.sei.cmu.edu/ productlines/about_pl.html
– Battery Pack – Motor Pack …
Fk1
• Bilindustri Peugeot, Fiat, Toyota, etc …”
Fk2
…
Fkn
Plattform v. k Fk+1.1
Fk+1.2 …
Fk+1.m
Plattform v. k+1
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4
33
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4
34
Vad innebär detta?
Er design i projektet
• Parallell utveckling -> lägre kostnader, fler produkter, kortare tid till marknad per produkt
• 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.
• Ö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” •… Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
35
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
36
Diskussion: Försök förklara för din granne:
Konfigurationshantering
Vad är det för skillnad mellan
konfiguration och version och variant?
Testpro tokoll Design
Utb.plan
&
Test
Projektplan
Manualer
Krav
Vad betyder:
Process
Kod
Olika versioner Olika produktvarianter Olika kunder … Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
37
Configuration Management
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.
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
39
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.
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
40
Typiska frågor man kan vilja ha svar på
Planering av konfigurationhantering
• Vilka kunder har installerat en viss version av systemet?
• Bestäm vad som ska konfigurationshanteras – Projektdokument – inte säkert – Produktdokument – ja – Organisationsdokument – ja, men inte av projektet
• Vilken hårdvara och OS krävs för en viss version? • Vilka versioner har levererats av ett visst system?
• Bestäm rutiner för konfigurationshantering
• Vilka versioner påverkas om jag ändrar en viss komponent i systemet?
• Bestäm ansvarig för konfigurationshantering
• 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? Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
• 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) Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
41
42
Versioner, releaser och delta V 1.0 V 1.1 V 1.2 V 1.3 V 2.0 V 2.1 …
Ändringshantering ≈ ordnad övergång
release version version version release version …
V1.0
V1.1
V1.2
Delta 1
Delta 2
V1.0
V1.1
Analysera ändringsbegäran Om ändring nödvändig och korrekt {
Lagra ändringar i delta
!
Utvärdera hur ändring kan göras + kostnad
Hålla reda på ändringshistoria
!
Skicka förfrågan till CCB
!
Om ändring accepterad {
!
!
Ändra i systemet
!
!
Uppdatera ändringsbegäran
!
!
tillverka ny version av systemet
!
}
ID för varianter/grenar V1.1a
Begär ändring genom att fylla i formulär
V1.1.1 …
V1.2
V2.0 …
V1.1b Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
}
Delta? 43
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
44
Formulär för ändringshantering, del av information
CCB – Change Control Board
Del 1
• Strategiska beslut om vilka ändringar som ska ske
Del 3
Namn Projekt Ändring nr
Förslag på ändring Skattad tid CCB-möte, datum
Anledning Objekt att ändra
CCB beslut
Del 2 Utredare Resultat av utredning
• Inte bara tekniska beslut • Representerar kund, projekt och andra intressenter • För programvara som används i flera produkter blir det mer komplicerat
Del 4 Ansvarig för ändring Kommentar Ny version:
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
45
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
46
Systembygge
Sammanfattning
• Bygga en fungerande version av hela systemet från de komponenter som finns, t ex
• 6.2–6.5 och 7.1.1–7.1.3 i andra kurser -> ingår inte i denna kurs
– – – – –
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 …
• 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
• Behövs t ex vid systemtest och andra tester (och såklart vid leverans)
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
• Design görs på olika nivåer: arkitektur -> design -> kodning
• 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.
47
Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
48
Uppgift: Programmera ett cykelgarage Uppdrag
Alltså
Faser och leverabler
Målmiljö
Kravspecifikation
= barcode reader
Operator
= electronic lock Barcode printer
PC
= pincode terminal
Fas 1 Specifikation
eller annan ÖK!
Projektplan
Testplan Fas 2 Design
Designdokument
Fas 3 Implementation och enhetstest
Exit door
Fas 4 Systemtest
Utvecklingsmiljö
– To Ö: Mer om test: T.9-11
Extra exit door
Bicycle garage
Entry door
• V 4: – Ti kl 24: MS 1 eller 0.991...
Aktörer
Dokumentmiljö
Projekthandledare Projektgrupp
QA från IP3
Exekverbar källkod
Dokumenterat genomförda systemtest
Tips: Titta på en gammal tenta...
V 5 inleds med tecknad serie Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4
50
