Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 17 juni 2005 en systematisk metod för att gå från problembeskrivning till färdigt system metod för formell beskrivning av problem som ska lösas metod för övergripande beskrivning av systemet [en ritning] kunna ge beskrivningar av olika delsystem så att varje programmerare (i ett större projekt) vet vad han ska göra 1 3 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även 1. http://www.uml.org/ 2. http://www-306.ibm.com/software/rational/uml/ och 3. http://www.holub.com/goodies/uml/ Objekt-orienterad programutveckling Att gå från problem till färdig lösning Exempel: Affärssystem för företag (något eller några av bokföring, fakturahantering, lagerhantering, orderhantering) Inte tekniskt komplicerat. Men: systemet ska integreras i befintlig verksamhet. Eventuellt anpassas till befintliga system. Viktigt att anpassa till kundens önskemål. Kunden ej tekniskt kompetent stor risk för missförstånd. 2 4
Klassisk modell för systemutveckling (vattenfallsprincipen) Fyra faser: 1. Analys 2. Design 3. Implementation/unit testing 4. Integration/testning OBS: vattenfallsprincipen har stora brister! Systemutveckling: design 1. Utgå från en tolkning av problemet i tekniska termer 2. Producera en övergripande design av systemet 3. Kontrollera att designen är fullständig implementerbar rimlig 5 7 Systemutveckling: analys 1. Utgå från en problemformulering 2. Producera en tolkning av problemet i tekniska termer 3. Kontollera att analysen stämmer med kundens önskemål är fullständig Systemutveckling: implementation 1. Utgå från en design 2. Producera ett färdigt program 3. Kontrollera att implementationen är fullständig effektiv... 6 8
Ide: Objektorienterad analys och design UML: tre huvudanvändningar Beskriv allt i termer av objekt Kräver en formell objekt-orienterad notation. Första steg: Identifiera klasserna, deras egenskaper och relationer (associationer). Analysmodell: analysera problemformuleringen Designmodell: rita upp programmet i stora drag Reverse-engineering: hjälp att förstå beintligt program 9 11 Ett modelleringsspråk UML: Exempel Fönster Klassnamn UML Unified Modelling Language Av Booch, Jacobson, Rumbaugh Exempel: En klass position storlek Attribut (instansvariaböe) Resultatet av en sammanslagning av tidigare system Stort system. Beskrivs i ett antal läroböcker & manualer Vi ser på hur man kan beskriva datastrukturer (objekt och klasser) i UML. (UML har mycket annat, tex diagram för dynamisk modellering och use-case) öppna() stäng() flytta() visa() Ofta utelämnas attribut & metoder pga platsbrist (eller: för att göra modellen tydligare) Operationer (metoder) 10 12
UML: Ansvar Ett fjärde fält i klassdiagrammet. Datum Datum(år, mån, dag) Generalisering (I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik) Exempel: Fordon Lagrar information om visst datum Bil 13 15 Association Samband mellan klasser Bok 0..* 1 Bibliotek Två klasser har nåt att göra med varandra Almanacka Datum Klassen Almanacka använder klassen Datum. 0 eller flera böcker associerade till ett visst bibliotek Associationen kan tillåta både att man tar reda på till vilket bibliotek en viss bok tillhör att man tar fram en lista på alla böcker i ett visst bibliotek 14 16
Mera komplext exempel: Fordon toppfart Multirelationer Om inget annat anges är en association (relation) många till många. Bra eller dåligt? - Person Bil toppfart motorstyrka Cykel toppfart 0..* äger tillhör 1 Person namn ålder Lärare undervisar Student 17 19 Exempel (forts) Ett fordon är antingen en bil eller en cykel Varje cykel har en associerad person (cyklisten) Pilen anger att vi kan gå från cykel till cyklist, men ej tvärtom Den svarta pilen vid äger anger hur associationen ska läsas Associationsbegreppet En fördel med associationsbegreppet: Man tvingas tänka över multiplicitet Hur många telefonnummer kan en person ha? Hur många fruar? Hur många adresser? Hur många föräldrar? Hur många nationaliteter? 18 20
Olika typer av diagram i UML Associationsbegreppet (forts) Det visar sig ofta att man vill öka multiplicitet (att en person kan ha flera telefonnummer eller adresser, tex) Det visar sig ofta att man vill kunna gå åt båda hållen Användarfallsdiagram Klassdiagram (redan beskrivet) Dynamisk modellering: tillståndsdiagram, sekvensdiagram Interaktionsdiagram Komponentdiagram - beskriver implementeringsmoduler Det finns även diagram för att beskriva den fysiska realiseringen, processer,... 21 23 Sammansättning En slags association. Anger att ett objekt är en del av ett annat Bil Användningsfall, (scenarier, use cases) Utgå från viktiga användningar av systemet Exempel (bankomat) Kund vill ta ut pengar Kund vill kontrollera saldot Beskriv i modellen hur tjänsten ska utföras Hjul Kräver förstås att systemet har tillräcklig funktionalitet för att kunna tillhandahålla tjänsten 22 24
Mera om objekt-orienterad analys Syfte: Förstå vad systemet ska göra Förstå applikationsområdet och dess terminologi Planera för framtida versioner Förbered för design Vad är målet med analysfasen? UML-diagram. Beskrivning av alla ingående klasser och deras ansvar. Övrig dokumentation. 25 27 Objekt-orienterad analys: Utgångspunkt Kravspecifikation Diskussioner med beställare och användare Verksamhetsanalys Externa system Inte säkert att kravspecen innehåller all information du behöver, att den är entydig, fri från motsägelser, fri från upprepningar, fri från onödiga designbeslut. Några steg i objekt-orienterad analys (Förutsätter att vi har en fullständig kravspec) Hitta objekten (i problemformuleringen) Beskriv objekten (syfte, tjänster, kunskap, ansvar) Relationer mellan klasser Ta fram scenarion och kontrollera att modellen kan hantera dem gruppera klasser 26 28
Objekt-orienterad analys Vilka objekt ingår? Tidigare definierade objekt Substantiv i problembeskrivningen (ger garanterat alltför många objekt) Objektorienterad programmering Önskemål (Skansholm) korrekt effektivt ändringsbart återanvändningsbart 29 31 Objekt-orienterad design Systemdesign Utformning av systemet i stort Val av OS, val av olika verktyg (tex databashanterare), nätverk, integration med befintlig programvara Förfina beskrivningen av de objektbeskrivningar som tagits fram under analysen Önskemål om OOP Korrekthet: Att programmet är implementerat enligt designspecifikation (Förutsätter att analys och design är OK.) Utformning av systemet i detalj, tex val av datastrukturer 30 32
Effektivitet: Vanligtvis: Vi vill att programmet skall vara tillräckligt effektivt. Ibland: Ju effektivare desto bättre. Ändringsbarhet (underhåll) Ett väldesignat program kan förstås en modul i taget. Ändringar i problemspecifikationen bör kunna genomföras med ändringar i en eller ett fåtal moduler 33 35 Typer av effektivitet: Minnesanvändning CPU-användning Effektivitet (forts) Responstid (ofta subjektiv, mycket viktig i alla applikationer som kommunicerar med människor) Notera att responstid ofta domineras av diskaccesser och nätverkskommunikation. Återanvändbarhet För att en klass (eller ett paket) ska kunna brytas ut och användas i ett annat sammanhang krävs att programmet är organiserat i komponenter med välgenomtänkta gränssnitt inga onödiga beroenden mellan klasser undvik att föra in antaganden som gäller för det nuvarande programmet 34 36
Implementera relationer: exempel Cykel tillhor 0..* 1 Varje cykel tillhör en unik ägare. class Cykel { Person ägare; Class(Person ägare) { this.ägare = ägare;...... Person Alla har noll eller en cykel (forts) class Cykel { Person ägare; Class(Person ägare) { this.ägare = ägare; ägare.nycykel(this);...... 37 39 Implementera relationer Exempel: Alla personer har noll eller en cykel Cykel class Person { Cykel cykel; 0..1 void nycykel (Cykel c) { if (cykel!= null) felmeddelande else cykel = c 1 Person Cykel Använd collection classes! Multirelationer 0..* 1 class Person { Set cyklar = new HashSet; void nycykel (Cykel c) { cyklar.add(c); Person 38 40
Har-relation (komposition) Jämför: komposition och association Design-metodik i praktiken Hur fungerar OOD i praktiken? Bil Hjul Bil Ägare Beror på vem du frågar. Tre anekdoter: Koppling mellan analys & design Situationer där modellen fungerar Stora projektet 41 43 Association Java har inget naturligt sätt att skilja på komposition och andra typer av association. Vill att inga andra klasser kommer åt bilens hjul hjulen tillhör endast en bil kopiering av bil > kopiering av hjul Några problem med vattenfallsmodellen Inget sätt att resonera om effektivitet Svårt att avgöra hur bra en design fungerar Svårt att ens vara säker på att det färdiga programmet följer designen om det inte fungerar, är det fel på designen eller implementationen? Om man upptäcker problem med analysen i implementationsfasen bör man gå tillbaka och göra om tidigare steg blir det så? 42 44
Iterativ utveckling Unified process Av Jacobson et. al samma arbetsmoment som vattenfallsmodellen, men ej ett i taget Iterationer av fix längd Varje iteration arbetar i alla faser Varje iteration producerar ett körbart system Tex: Iteration 1 producerar en första prototyp för kunden Sammanfattning Klassisk systemutveckling ett försök att systematisera programutvecklingsprocessen Analys ta fram en teknisk problemformulering. Design utforma systemet i stora drag. Objektorienterad analys och design arbeta med objekt på alla nivåer. UML ett språk för att beskriva resultat av analys och design 45 47 Några råd och iaktagelser om OOA/OOD De olika stegen kan inte göras oberoende av varandra UML är ett mycket komplext och uttrycksfullt språk (nästan som ett programspråk) Frestande att föra in alltför mycket detaljer tidigt Bättre att arbeta med en enklare och överskådlig design 46