Objekt
Ett objekt är en individuellt identifierbar entitet som kan vara konkret
eller abstrakt. Ett objekt har tillstånd, beteende och identitet.
Kodkvalitet
– Reellt, gripbart, synligt ting (t ex en specifik person)
– Abstrakt ting (t ex en tid eller en anställd)
Varje objekt har ett tillstånd, ett beteende och en identitet.
150
Klass
– Tillståndet beskriver objektets egenskaper (t ex adress
och ålder hos en person)
– Beteendet beskriver vad objektet kan göra (t ex flytta).
OBS! Detta kan innebära att tillståndet ändras
– Identiteten skiljer ett objekt från alla andra objekt
151
Klassdiagram
En klass är en “byggplan” för objekt av samma sort.
– Alla objekt av en klass (instanser) har samma
sorts egenskaper och beteenden
– En klass beskriver en mängd liknande objekt
– Datatyp
Person
Namn på klassen
namn
ålder
adress
egenskaper
(attribut)
flytta
...
beteende
(metoder)
152
Johan Eliasson
Programutveckling sker i faser
• Här: starkt förenklat version
• Passar bara mindre projekt
• Fem delmoment:
– Fastställa och analysera förutsättningarna/kraven
– Skapa en design
– Implementera koden
– Testning
– Dokumentation
OBS! Testning och dokumentation ska ske
154
parallellt med de övriga momenten.
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
155
Legacy code - ärv kod
Legacy code - ärv kod
Skriva kod som lever i flera generationer och
varianter, som andra än du själv jobbar med.
Vad är viktigt då för att minimera kostnader och
risker?
Ändra/jobba med kod som andra (eller du själv)
har utvecklat, tex.
»
Bygga vidare
»
Ny version
»
Kundanpassa
156
»
Rätta fel
Sträva efter kod som är…
• kod som är bra, dvs, hög kodkvalitet
• kod som är man kan stå för, för man kan
garantera att den gör det den ska göra och
inget annat, bra testad
• kod som är beskriven på ett bra och tydligt
sätt, dvs bra dokumenterad
Samt
Färdigheten att läsa och förstå andras system och kod,
158
dokumentation, etc.
Livscykel, vidareutveckling och
återanvändning
Scenario 1: Nyproduktion av ett hus, som ska
fungera som skola
Scenario 2: Ombyggnation av ett modernt hus,
byggt 2010 används som en förskola och ska
fortsätta att användas som F-9 skola
Scenario 3: Ombyggnation av ett gammal Kmärkt skola byggt 1870, till kontor
Scenario 4: Åtgärda en skola som är klassat
som ett sjukt hus. Skolan är bygg 1990. 160
Systemen/koden är lätt att förstå
Lätt att testa det nya utan att ha sönder det gamla
157
Kodkvalitet
Vad är god kodkvalitet?
Vad är dålig kodkvalitet?
Hur ”mäter vi kodkvalitet”?
Vem bär ansvaret för kvalitet på koden?
159
Livscykel, vidareutveckling och
återanvändning
Scenario 1: Nytt system som ska byggas från
grunden
Scenario 2: Utökning av funktionalitet i RSV
system för folkbokföring som påbörjades 1985
Scenario 3: Anpassning ett system mot en helt
ny kund, systemet utvecklat sedan 2010
Scenario 4: Jobba bort felrapporter som
kommer in på mobiltelefonsystem, för att
komma ut med en helt ny release.
161
Kodkvalitet
Hur kan man jobba med kodkvalité?
Hur kan man jobba för att nå hög kvalité?
Vems ansvar är det om en klass eller metod beter
sig konstigt och orsakar fel?
1. Jobba strukturerat genom hela
processen
162
Hur kan man jobba med kodkvalité?
•Fokusera på kvalité och inte kvantitet
– Bygg det ”viktigaste” först”
•Jobba tillsammans
– Gemensamt ansvar en för alla alla för en
– Kontinuerlig uppföljning av processen
•Kod-granskning
•Lätt att läsa, lätt att testa, förklara
•Koden följer grundläggande kodprinciper
•Koden, systemet är inte onödig svårt att förstå
•Involvera testning i ett tidigt skede av processen
163
Hur kan man jobba med kodkvalité?
• Tydlighet i förväntningar
• Tydliga krav vad som ska systemet ska kunna göra
• Tydliga definitioner när en funktion/del fungerar som den ska
både i det lilla och i det stora
• Tydliga definitioner på när det inte fungerar (undantag, fel, etc)
• Bra design
• System/klassdesign/metoddesign
•Systemarkitektur, klasser, metoder, etc
• Dokumenterad testning på många nivåer
• Enhets, integrering, system,…acceptans-test
• Hur ska man följa upp/garantera att koden fungerar även efter
flera generationer
• Mer om det senare
164
165
OOA&D
Systemdesign/arkitektur
• Modeller underlättar kommunikation
• Vilka klasser består systemet av
• Arvshierarkier, beroenden, synlighet, mm
• Minimera beroenden men samtidigt jobba med arv
för att minska kodningen och få bättre, tydligare
struktur
• Jobba strukturerat med att förstå uppgiften
• Jobba strukturetat med att fånga en
systemarkitektur
• Jobba med kända designlösningar -s.k Designmönster och Anti-mönster
CRC
166
– Oberoende av programspråk
– Abstraherar från oväsentliga detaljer
– Underlättar ”testning” i tidigt skede
• Några bra verktyg
– CRC-kort
– UML (ett modelleringsspråk)
– Designmönster (Fabrik, ...)
– Interaktionen/flödet
• Scenarios
• Swim-lanes
• Skisser
• Mock-up:er
167
Fastställa och analysera förutsättningarna/
kraven
•
•
•
•
Vad ska göras?
Vilka begränsningar finns?
Är alla oklarheter utredda?
Skapa en OO-design
• 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
Gör modeller/utkast
– Diagram
– Pseudokod
• Undvik att tänka på implementationen
168
Implementation
• När man kommer till detta steg så har man ”ritning
klar”, det mesta av ”materialvalen är gjorda”
• Översättning av design till källkod
• Implementationen fokuserar på kod-detaljer
• Alla viktiga beslut tas vid analys och design
170
• 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
169
