Föreläsning 2. Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program.

Transkript

1 Föreläsning 2 Objektorienterad analys och design. Analys: att modellera världen. Design: att strukturera program.

2 Vår process Kravbeskrivning (3 dagar). Enkel form av användningsfall (use cases). Analys och design (1 vecka). Design av GUI enligt MDI-kursen. Implementation (4 veckor). I huvudsak en iteration med tillägg om tid medger. Enhetstest av viktiga klasser.

3 Objektorienterad analys och design Varning! Litteraturen är inte ening om hur (eller om) man kan skilja på analys och design vid objektorienterad programutveckling. En tänkbar distinktion Objektorienterad analys: studera krav på systemet (t.ex. från användarfall) och modellera den relevanta delen av världen i form av objekt och relationer mellan dessa. Objektorienterad design: strukturera program i klasser och beskriv hur dessa är relaterade (arv, association, mönster, ). Kom ihåg: klass vs objekt En klass är en del av programmets text. Den utgör en mall från vilken instanser kan skapas under exekveringen.

4 Diskussion Beprövad erfarenhet Design är svårt. Många metoder har föreslagits, men det fortsätter att vara svårt. En vecka analys och design??? Varför så mycket arbete med detta? Är det inte bättre att börja programmera direkt?

5 Objekt ur olika synvinklar Modellbyggarens synvinkel Ett objekt är en modell av en del av världen, fysisk eller begreppsmässig, har attribut och uppvisar karakteristiska beteenden. Programmerarens synvinkel Ett objekt är en dataabstraktion som kapslar in ett tillstånd och tillhandahåller metoder som avläser och/eller påverkar detta tillstånd.

6 Några mål med vårt arbete Vi vill åstadkomma ett system som: uppfyller sin uppgift så bra som möjligt är så enkelt att förstå som möjligt är så enkelt att modifiera som möjligt är som enkelt att bygga ut som möjligt är så enkelt att implementera som möjligt är felfritt... Designdokumenten måste ge så välspecificerade beskrivningar av de olika delsystemen att varje programmerare vet vad han/hon skall göra.

7 Därför analys och design! God design Är en förutsättning för en lyckad produkt. Är enklare att implementera. Dålig design Ger ett system som är svårt att underhålla/modifiera. Ger ett system som är felbenäget. Ger ett system som är svår att utveckla i team.

8 Objektorienterad analys I analysfasen bestäms VAD som systemet skall klara av att göra. Analysens syfte är att vara en brygga mellan kravspecifikationen och designen. Målet är att förstå problemet och bygga en objektorienterad modell av problemdomänen. Analysen fokuserar på de funktionella kraven, dvs systemet betraktas utifrån. Analysen skall vara oberoende av programmeringsspråk och val av användargränsnitt (för att ge en generell lösning). Analysen skapar en terminologi och notation för det fortsatta arbetet. Resultatet från analysen är en beskrivning av de konceptuella objekt (entiteter, klasser) som ingår i problemdomänen, vilka egenskaper och beteenden de har, samt hur de samverkar med varandra.

9 Objektorienterad analys i två faser Utforskande fas 1) Finn objekt i problemdomänen. 2) För varje objekt: Beskriv kortfattat syftet med objektet. Beskriv de attribut (egenskaper) som objektet har. Beskriv de beteenden (operationer) som objektet har. Analyserande fas (kan även ses som en del av designen) 1) Klassificera objekten. 2) Beskriv relationer mellan klasserna. 3) Skapa och exekvera scenarion för att validera systemet. 4) Gruppera klasserna.

10 Analys: att hitta objekt En ofta rekommenderad metod Läs igenom systembeskrivning och användarfall, notera alla substantiv som kandidater till att vara objekt. Stryk alla vaga, problemoberoende ord ur listan. Identifiera och slå ihop synonymer. Identifiera attribut.

11 Ett exempel Vi tänker oss ett system för att boka och sälja biljetter till en biograf med flera salonger. Följande skall gälla för systemet: systemadministratörer kan lägga in föreställningar i systemet säljare kan boka och sälja biljetter ekonomisystemet kan få information om sålda biljetter. Låt oss betrakta några användningsfall.

12 Användningsfall 1 Lägg till en film Aktör: Systemadministratör. Mål: Lägg till en film och dess föreställningar till systemet. Interaktion: Användaren anmodas att ge filmens namn och premiärdatum. Systemet visar grafisk vy med tillgängliga visningstider för de olika salongerna den kommande månaden. Användaren väljer ett antal av dessa alternativ. Systemet bekräftar och lagrar valen. Prioritet: 1. Tidsåtgång: 3 dagar.

13 Användningsfall 2 Sälja biljetter Aktör: Säljare. Mål: Sälja ett antal biljetter till en viss föreställning. Interaktion: Användaren anger en film. Systemet visar en grafisk vy av salongen för nästa föreställning med lediga och upptagna platser markerade. Användaren kan markera ett antal lediga platser och sälja dem. Prioritet: 1. Tidsåtgång: 2 dagar.

14 Objekt eller attribut Begrepp som kan modelleras med fördefinierade typer som strängar eller datum, eller med en enkel typ som heltal, modelleras inte vidare som egna objekt utan endast som attribut till andra objekt. Exempel En film har (bland annat) attributen namn och premiärdatum.

15 Fortsatt modellering: fler attribut Fler attribut När kandidater till objekt identifierats kan man ofta finna fler naturliga attribut. Exempel En film har attributen speltid, språk, regissör, Exempel En plats har ett attribut som anger om den är ledig, såld eller bokad.

16 Fortsatt modellering: fler beteenden Exempel En film har sannolikt inga intressanta beteenden i detta system; ett filmobjekt lagrar bara sina attribut i inkapslad form. Identifiera beteenden Studera användarfallen för att identifiera operationer som objekten skall kunna utföra. Exempel En föreställning skall kunna sälja ett antal platser boka ett antal platser sälja bokade platser rapportera antal sålda platser.

17 En föreställnings livscykel Föreställningen läggs in i systemet. Platser bokas och säljs upprepade gånger. Försäljningsresultat rapporteras. Föreställningen tas bort ur systemet. Tillståndsdiagram För objekt med icke trivial livscykel kan denna illustreras med tillståndsdiagram.

18 Relationer mellan objekt Användningsfall kan också visa relationer mellan objekt: Vem utnyttjar vems tjänst? Om A utnyttjar en operation som B kan utföra, så måste A känna till B. Vem är ett specialfall av vem? Om A är en speciell sorts B, så kan vi modellera med en hierarki. Vem är en del av vem? Om A är en komponent i B, så har B (en referens till) A som attribut.

19 Scenarion flygplan trafiktorn 5 ankomsthall flygplan Flygplats Landvetter landningsbana 2 landningsbana 1 1. Ett flygplan begär landningstillstånd av trafiktornet. 2. Trafiktornet svarar med en lämplig landningsbana. 3. Flygplanet meddelar landningsbanan att det skall landa. 4. Landningsbanan meddelar trafiktornet att planet landat. 5. Trafiktornet meddelar ankomsthallen att ett flygplan anlänt.

20 Från analys till design Resultat av analysen En lista av objekt med attribut och beteenden. En (ofullständig) kunskap om relationer mellan objekt. Design Nu övergår vi från att analysera systemet till att designa programmet. Under designen betraktas systemet inifrån och syftet är att bestämma HUR systemet tekniskt skall realiseras, samt att skapa en tydlig bild av hur koden skall struktureras.

21 Från analys till design Första steg: Översätt objekten till klasser (typiskt med samma namn). objekt klass attribut instansvariabel operation publik metod Beskriv klasserna m.h.a. UML (se Jia och nätet)

22 Designprinciper för OOP Decoupling minimera beroendet mellan klasser. Delegering skicka vidare uppgifter till klassser som är bäst lämpade för jobbet. Inkapsling abstrahera bort implementationsdetaljer. Gränssnitt kommunicera med objekt via meddelanden, ingen kännedom om objektets inre. Abstraktion skapa begrepp på högre nivå genom att gömma undan detaljer i klasser och metoder. Modularitet bryt ner systemet i sammanhängande men sinsemellan löst kopplade delsystem.

23 Fortsatt design Typiska steg Lägg till implementationsinriktade klasser. Skriv klasskelett! Börja skriva användarmanualen för att förfina användarfallen och därmed bekräfta designen. Utnyttja relationer: Relationer medför ofta attribut som refererar till objekt av en annan klass; hierarkier implementeras med subklasser. Specifika parametrar och resultattyper för publika metoder; specificera beteendet med text. Använd javadoc! Hantera GUI via en MVC arkietektur. Inför interfaces för att få lösare kopplingar i programmet. Försök hitta designmönster. Men koda inte metoderna ännu!

24 MVC med passiv modell Om modellen endast kan uppdateras via GUI:t kan följande principiella arkitektur användas:

25 MVC med aktiv modell Om modellen uppdateras också på annat sätt (t.ex. via inkommande paket från nätet) måste modellen ha ansvar för att informera vyn/vyerna då den förändras. Ofta används mönstret Observer:

26 Koppling En bra design bör ha låg koppling mellan klasserna (d.v.s. få förbindelser I klassdiagrammet) Hög koppling Låg koppling

27 Några allmänna råd Håll nere komplexiteten; designa enkelt. Pröva alternativa ideer till design; var beredda att ändra er! Var restriktiv med att använda subklasser (extends)! Designa klasser med hög kohesion; alla metoder jobbar på samma gemensamma data (instansvariabler). En klass skall göra en sak och göra den bra. Designa för förändringar; försök hitta naturliga generaliseringar. Försök hitta designmönster; återuppfinn inte hjulet.

28 Design av GUI Typiska steg Analysera användningsfallen för att finna önskade komponenter. Organisera enligt principen från MDI kursen. Gör prototyp(er) på papper. Testa på utomstående.

29 Designdokumentets innehåll Ungefärlig innehållsförteckning Övergripande struktur hos ert program (klasser/interface och relationer); i förekommande fall indelning i delsystem. Använd UML:s klassdiagram (se Jia och nätet). För varje klass/interface en beskrivning av Syfte (kort textuell beskrivning) Publika metoder med signatur och specifikation Eventuellt redan identifierade privata metoder och instansvariabler (ej för interface). En mer detaljerad beskrivning av användargränssnittets design (val av komponenter) med motiveringar.

30 Läsanvisningar Kapitel 2 i Object-Oriented Software Development Using Java av Xiaoping Jia. Kapitel 5 i Code Complete av Steve McConnell. Detta kapitel finns som sample chapter på bokens hemsida (se kursens hemsida).