Klasser och objekt? Objekt och klasser. Analys och design. Objekt. Klass. Programmering?

Transkript

1 Objekt och klasser Analys och design med hjälp av CRC Objekt Modeller av saker i problemdomänen ( den röda bilen i parkeringshuset Nanna ) Klasser Representerar alla objekt av ett visst slag ( bil ) Klasser och objekt? Vad är en klass? Vad är ett objekt? Vad är skillnaden mellan klass och objekt? Objekt Ett objekt är en individuellt identifierbar entitet som kan vara konkret eller abstrakt. Ett objekt har tillstånd, beteende och identitet. 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. 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 Klass 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 namn ålder adress flytta... Person Namn på klassen egenskaper (attribut) beteende (metoder) 49 Programmering? Ni har läst grundläggande programmeringsmetodik C, Python, etc Ni har läst Datastrukturer och algoritmer Använd C eller Python för att bygga listor, träd, tabeller, etc. Hur väl stödjer C de saker som DoA:n lyfter fram Inkapsling, återanvändning, mm 50

2 Programmering? Är ni taggade på att ta nästa steg, för att klara av att bygga större mer komplexa system? Vi behöver utöka verktygslådan Designtänk och metodik Bättre stöd för DoA i språket Börja tänka test och använda verktyg för att testa Verktyg för att stödja samarbete Angripa vaga problemställningar 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 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 parallellt med de övriga momenten. 53 OOA&D Design Kräver förståelse för uppgiften/problemet Analys 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 54 OOA&D Modeller underlättar kommunikation 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 56

3 Fastställa och analysera förutsättningarna/ kraven Vad ska göras? Vilka begränsningar finns? Är alla oklarheter utredda? Gör modeller/utkast Undvik att tänka på implementationen 57 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 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 58 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 Testning och dokumentation Tester måste konstrueras för extremer, svagheter och gränsfall Med tester ska fel hittas och inte undvikas Testa tidigt och ofta Det är inte bara kod som kan testas Dokumentera fortlöpande ANALYS SYSTEM DESIGN PROGRAM DESIGN V modellen Validera kraven Verifiera designen SYSTEMTEST ENHETS- & INTE- GRATIONSTEST DRIFT & UNDERHÅLL ACCEPTANS- TEST 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 KODNING 61 62

4 Vad kännetecknar en god klass 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 varandra) 63 Cohesion 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 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 64 Kategorier av metoder Konstruktorer Skapa instanser Selektor (get-metod) Returnerar information om objektets tillstånd Mutator (set-metod) Ändra objektets tillstånd Annat Gör någonting En metod ska tillhöra bara en kategori 65 Exempel 1: Cohesion: Exempel 1 public void setnameandage (String name, int age); Bättre: public void setname (String name); public void setage (int age); Exempel 2: /* Anropas en gång om året */ public void calculateholidays(); { holidays += new Holidays(); age++; Bättre: public void calculateholidays(); public void incrementage(); 66 Exempel 3: Bättre: Cohesion: Exempel 2 public void setfirstname (String name){ firstname = name; public void setlastname (String name){ lastname = name; fullname = firstname + + lastname; public void setfirstname (String name) { firstname = name; fullname = firstname + + lastname; public void setlastname (String name){ lastname = name; fullname = firstname + + lastname; 67 Coupling 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 enklare är det att förstå en enstaka klass enklare och förståeligare blir systemet som helhet 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 68

5 Klassdiagram Klassdiagram UML: Klassrelationer Klassdiagram svag koppling stark koppling 71 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 73 CRC Metoden Grupparbete(4-6 personer) Hitta kandidatobjekt Brainstorming Substantiv & adjektiv 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 74

6 Brainstorming Fokuserat utforskande i grupp Okritiskt förhållningssätt i genereringsfasen Substantiv & adjektiv i uppdragsbeskrivning Lätt metod Kräver en vettig och inte allt för ordig och lång beskrivning Kräver bra förståelse och analys Filtrering Oavsett metod så måste man göra en bearbetning av kandidaterna Så att god klass-design uppnås Liknande kandidater slås ihop Skippa kandidater som: CRC-kort Class-Responsibilities-Collaborators Klass-ansvar-sammarbetspartner Ett CRC-kort motsvarar en klassbeskrivning Inte går att benämna med ett substantiv eller adjektiv Beskriver imp. detaljer, egenskaper, utan direkt ansvar, modellerar GUI, systemklasser, utanför Informellt verktyg för att ta fram och utvärdera olika ramarna, alternativ Scenarier 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 Börja med några väldigt enkla 79 RPD - skapa scenarior för att testa designen

7 RPD spela rollspelet RPD -spela in rollspelet 82 Uppdatera CRC-korten Efter några scenarion & iterationer När CRC-korten är någorlunda stabila kan de göras om till mera formella klassdiagram Design Byggritningen (utan GUI)