Problemlösning. Analys och design OOA&D. Programutveckling sker i faser OOA&D. Fastställa och analysera förutsättningarna/ kraven.

Transkript

1 Analys och design med hjälp av CRC 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. 42 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 43 OOA&D 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) 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 44 45

2 Skapa en 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 46 Implementation Översättning av design till källkod Implementationen fokuserar på kod-detaljer Alla viktiga beslut tas vid analys och design 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 ANALYS SYSTEM DESIGN PROGRAM DESIGN V modellen Validera kraven Verifiera designen KODNING 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 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) 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 50 51

3 CRC Metoden 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 Brainstorming Kandidater? 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 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 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 Börja med några väldigt enkla 56 57

4 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 UML Klassdiagram 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 Exempel 1: Cohesion: Exempel 1 public void setnameandage (String name, int age); 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++; public void calculateholidays(); public void incrementage(); 62 Exempel 3: Cohesion: Exempel 2 public void setfirstname (String name){ firstname = name; public void setlastname (String name){ lastname = name; public void setfirstname (String name) { firstname = name; public void setlastname (String name){ lastname = name; 63

5 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 64 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 65 Ju starkare relation desto starkare koppling ( sämre) svag koppling Dependency Association Komposition! Arv UML: Klassrelationer <<beror på>> relation stark koppling 66