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
