Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 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) Tre faser: 1. Analys 2. Design 3. Implementation 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
Objektorienterad analys och design UML: Exempel Fönster Klassnamn Ide: Beskriv allt i termer av objekt Exempel: En klass position storlek Attribut (instansvariaböe) Låt varje nivå (analys, design, implementation) vara en förfining av närmast föregående. Kräver en formell objekt-orienterad notation. Första steg: Identifiera klasserna, deras egenskaper och relationer (associationer). öppna() stäng() flytta() visa() Ofta utelämnas attribut & metoder pga platsbrist (eller: för att göra modellen tydligare) Operationer (metoder) 9 11 Ett modelleringsspråk UML Unified Modelling Language Av Booch, Jacobson, Rumbaugh 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) UML: Ansvar Ett fjärde fält i klassdiagrammet. Datum Datum(år, mån, dag) Lagrar information om visst datum 10 12
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 13 15 Generalisering (I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik) Exempel: Mera komplext exempel: Fordon toppfart Fordon Bil Bil toppfart motorstyrka Cykel toppfart 0..* äger tillhör 1 Person namn ålder 14 16
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? 17 19 Multirelationer Om inget annat anges är en association (relation) många till många. Bra eller dåligt? - Person 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 Lärare undervisar Student 18 20
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 21 23 Olika typer av diagram i UML 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,... 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 22 24
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 25 27 Vad är målet med analysfasen? UML-diagram. Beskrivning av alla ingående klasser och deras ansvar. Övrig dokumentation. Objekt-orienterad analys Vilka objekt ingår? Tidigare definierade objekt Substantiv i problembeskrivningen (ger garanterat alltför många objekt) 26 28
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 29 31 Objektorienterad programmering Önskemål (Skansholm) korrekt effektivt ändringsbart återanvändningsbart Effektivitet: Vanligtvis: Vi vill att programmet skall vara tillräckligt effektivt. Ibland: Ju effektivare desto bättre. 30 32
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 33 35 Implementera relationer: exempel Cykel tillhor 0..* 1 Person Ä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 Varje cykel tillhör en unik ägare. class Cykel { Person ägare; Class(Person ägare) { this.ägare = ägare;...... 34 36
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 37 39 Alla har noll eller en cykel (forts) class Cykel { Person ägare; Har-relation (komposition) Jämför: komposition och association Class(Person ägare) { this.ägare = ägare; ägare.nycykel(this);...... Bil Hjul Bil Ägare 38 40
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 OOA/OOD 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å? 41 43 Design-metodik i praktiken Hur fungerar OOD i praktiken? Beror på vem du frågar. Tre anekdoter: Koppling mellan analys & design Situationer där modellen fungerar Stora projektet 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 42 44
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