Analys och design Problemlösning Programutveckling sker i faser

Problemlösning
• Alla större projekt ”misslyckas”, eftersom det är
omöjligt för utvecklarna att till fullo förstå uppgiften
som ska lösas och vilka alla problem som är inneboende
i uppgiften.
– Antaganden måste klargöras
– Möjliga feltolkningar måste undanröjas
• När problem/uppgifterna blir större, måste lösningen
delas in i hanterliga delar
• Denna teknik är fundamental för programvaruutveckling
• I objektorienterad utveckling delas lösningen in i objekt
och klasser
Analys och design
med hjälp av CRC
40
41
OOA&D
Programutveckling sker i faser
• Design
– Kräver förståelse för uppgiften/problemet
• Här: starkt förenklat version
• Passar bara mindre projekt
• Fem delmoment:
–
–
–
–
–
• Analys
Fastställa och analysera förutsättningarna/kraven
Skapa en design
Implementera koden
Testning
Dokumentation
• OBS! Testning och dokumentation ska ske
parallellt med de övriga momenten.
42
43
Fastställa och analysera förutsättningarna/
kraven
OOA&D
•
•
•
•
• Modeller underlättar kommunikation
–
–
–
–
–
– Kräver språk för att uttrycka designen i
– Kräver ett strukturerat arbetssätt
– Bygger på erfarenhet
– Syftar till att få fram en OO modell som går att
implementera
• Design och analys hör ihop
Oberoende av programspråk
Abstraherar från oväsentliga detaljer
Underlättar ”testning” i tidigt skede
CRC-kort
UML (ett modelleringsspråk för OO utveckling)
Vad ska göras?
Vilka begränsningar finns?
Är alla oklarheter utredda?
Gör modeller/utkast
• Undvik att tänka på implementationen
44
45
Skapa en design
Implementation
• Bestäm klasser, objekt och metoder som behövs
– Vad finns redan?
• Bestäm algoritmer för problemlösningen
• I princip oberoende av programmeringsspråk
• Översättning av design till källkod
• Implementationen fokuserar på kod-detaljer
• Alla viktiga beslut tas vid analys och design
– Diagram
– Pseudokod
• Designa för återanvändning?
– Det är svårare att göra generella lösningar
– Kan löna sig i framtiden
– Återanvändning har varit en stor anledning till OOboomen
46
47
Testning och dokumentation
• Tester måste konstrueras för extremer,
svagheter och gränsfall
• Med tester ska fel finnas och inte
undvikas
• Testa tidigt och ofta
• Det är inte bara kod som kan testas
• Dokumentera fortlöpande
V modellen
DRIFT &
UNDERHÅLL
Validera kraven
ANALYS
ACCEPTANSTEST
SYSTEM
DESIGN
Verifiera
designen
PROGRAM
DESIGN
SYSTEMTEST
ENHETS- & INTEGRATIONSTEST
KODNING
48
Vad kännetecknar en god klass
• En odelad, väldefinierad abstraktion
• Uppgiften kan beskrivas kort och tydlig
• Namnet är en substantiv eller adjektiv som
beskriver abstraktionen på ett adekvat sätt
• Har ett koncist och sammanhängande gränssnitt
• Har tillstånd och beteende
• Representerar en mängd möjliga run-time objekt
• Problemet ska delas upp i “lämpliga” klasser
 Cohesion och Coupling (sammanhörighet och
koppling)
 Metoderna i varje klass ska ha stark sammanhörighet
 Klasserna ska vara löst kopplade (oberoende av varann)
50
49
OOA&D med CRC-kort
• Analys
– Förstå problemet/uppgiften
– Utveckla en OO modell av problemet
• Design
– Utveckla en OO modell av lösningen
• Modeller underlättar kommunikation
– Oberoende av programspråk
– Abstraherar från oväsentliga detaljer
– Underlättar ”testning” i tidigt skede
• CRC-kort
• UML(ett modelleringsspråk för OO utveckling)
• Rollspelsdiagram
51
CRC ”Metoden”
Kandidater?
• Grupparbete(4-6 personer)
• Hitta kandidatobjekt
• Filtrera kandidatobjekten
• Skapa CRC-kort för kvarvarande kandidatobjekt
• Definiera scener för testning av modellen (testfall)
• ”Spela in” scener m.h.a rollspelsdiagram (testa)
• Uppdatera CRC-korten och scenerna
52
Filtrering
• Oavsett metod så måste man göra en
bearbetning av kandidaterna
• Brainstorming
– Fokuserat utforskande
– Okritiskt förhållningssätt i genereringsfasen
– Kräver bra förståelse och analys
• Substantiv & adjektiv i uppdragsbeskrivning
– Lätt metod
– Kräver en vettig och inte allt för ordig och lång
beskrivning
• Mix
53
CRC-kort
• Class-Responsibilities-Collaborators
• Klass-ansvar-sammarbetspartner
• Ett CRC-kort motsvarar en klassbeskrivning
– Så att god klass-design uppnås
– Liknande kandidater slås ihop
– Skippa kandidater som:
• Inte går att benämna med ett substantiv eller
adjektiv
• Beskriver imp. detaljer, egenskaper, utan direkt
ansvar, modellerar GUI, ”systemklasser”, utanför
ramarna, …
54
Scenarier
• Informellt verktyg för att ta fram och utvärdera olika
alternativ
55
RPD
• Exempel på hur systemet används
• Hur gör man för att ta fram scenarier?
– Brainstorming, Vilka använder systemet, hur
använder man systemet, vilka kommer i kontakt
med systemet, …
• Så ”heltäckande” det går
• Kräver en gedigen förståelse och analys av
uppgiften
56
• Börja med några väldigt enkla
57
Uppdatera CRC-korten
Efter några scenarion…
• När CRC-korten är någorlunda stabila kan
de ”göras om” till mera formella
klassdiagram
– Design
58
59
Cohesion
Klassdiagram
• Varje metod ska vara “ansvarig” för bara en
uppgift
• Cohesion mäter huruvida en metod uppfyller detta
krav
• Ju mer en metod fokuserar på en enda uppgift,
desto
• UML
– enklare är det att finna ett bra namn
– enklare och förståeligare blir koden
• Metoder med stark samhörighet kan lättare ändras
utan att andra metoder påverkas
 Det ska vara möjligt att beskriva en metod med en
enkel mening med ett verb och ett objekt
60
Cohesion: Exempel 1
Cohesion: Exempel 2
• Exempel 3:
• Exempel 1:
public void setNameAndAge (String name, int age);
Bättre:
public void setName (String name);
public void setAge (int age);
public void setFirstName (String name){
firstName = name;
}
public void setLastName (String name){
lastName = name;
fullName = firstName + ”” + lastName;
}
Exempel 2:
/* Anropas en gång om året */
public void calculateHolidays();
{
holidays += new Holidays();
age++;
}
Bättre:
public void setFirstName (String name) {
firstName = name;
fullName = firstName + ”” + lastName;
}
Bättre:
public void calculateHolidays();
public void incrementAge();
61
public void setLastName (String name){
lastName = name;
fullName = firstName + ”” + lastName;
}
62
63
Coupling
Kategorier av metoder
• Konstruktorer
– Skapa instanser
• Selektor (get-metod)
– Returnerar information om objektets tillstånd
• Mutator (set-metod)
– enklare är det att förstå en enstaka klass
– enklare och förståeligare blir systemet som helhet
– Ändra objektets tillstånd
• Annat
– Gör någonting
 En metod ska tillhöra bara en kategori
64
UML: Klassrelationer
• Ju starkare relation desto starkare koppling (
svag koppling
sämre)
• Dependency
Klass1
<<beror på>>
Klass 2
• Association
Klass1
relation
Klass 2
• Komposition!
Klass1
Klass 2
• Arv
Klass1
Klass 2
• Klasserna ska vara så oberoende som möjligt av
varandra
• Coupling mäter hur starkt klasserna är kopplade
• Ju lösare klasserna är kopplade, desto
stark koppling
66
• Klasserna med lös koppling kan lättare ändras
utan att andra klasser påverkas
 Systemet blir lättare att ändra
 Mera flexibilitet
PROBLEM: Arv skapar starka kopplingar
65