Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet June 22, 2006 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
Kontrast: ett tekniskt problem Kan ha en komplex specifikation, men är ändå väldefinierat Tekniskt komplicerat, men tydligt var svårigheterna ligger Prestandakraven är hårda, men väldefinierade 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 5 7 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 6 8
Systemutveckling: implementation 1. Utgå från en design 2. Producera ett färdigt program 3. Kontrollera att implementationen är fullständig effektiv... Use case, exempel: i affären, huvudscenario 1. Kunden kommer till kassan med varor 2. Kassören startar en ny försäljning 3. Kassören för in en ny försäljning 4. Systemet lagrar varan, presenterar pris, beskrivning, totalsumma (kassören repeterar 3-4 så länge det finns varor) 5. Systemet presenterar totalsumman 9 11 Use cases Svenska: användningsfall Ivar Jacobson 1986. Idé: beskriv systemkrav i termer av systemets önskade interaktion Vinster: lätt att förstå för kund, liten risk att designval introduceras för tidigt, lätt att kontrollera att implementationen är korrekt. Use case (forts) 6 Kassören talar om totalsumman för kunden 7 Kunden betalar 8 Systemet lagrar information om försäljning i redovisningssystemet + lagerhanteringssystemet 9 Systemet skriver ett kvitto 10 Kunden går med kvitto och varor 10 12
Ett modelleringsspråk Use case: Variationer, exempel Systemet kraschar vid någon punkt ovan Flera varor av samma slag Kunden har inte råd att betala Kunden ber kassören att ta bort en vara Kunden betalar med kreditkort 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) 13 15 Ansvarsdriven design beskriv klasser i termer av deras ansvar: item information som lagras av objekt i klassen operationer som objektet utför andra klasser som klassen samarbetar med Skriv ner klassen på ett indexkort UML: tre huvudanvändningar Analysmodell: analysera problemformuleringen Designmodell: rita upp programmet i stora drag Reverse-engineering: hjälp att förstå beintligt program 14 16
UML: Exempel Fönster Klassnamn Exempel: En klass position storlek Attribut (instansvariaböe) Samband mellan klasser öppna() stäng() flytta() visa() Operationer (metoder) Två klasser har nåt att göra med varandra Almanacka Datum Klassen Almanacka använder klassen Datum. Ofta utelämnas attribut & metoder pga platsbrist (eller: för att göra modellen tydligare) 17 19 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 18 20
Bok Association 0..* 1 Bibliotek 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 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 21 23 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 22 24
Associationsbegreppet En fördel med associationsbegreppet: Man tvingas tänka över multiplicitet Hur många telefonnummer kan en person ha? Hur många fruar? Sammansättning En slags association. Anger att ett objekt är en del av ett annat Bil Hur många adresser? Hur många föräldrar? Hur många nationaliteter? Hjul 25 27 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,... 26 28
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 Kräver förstås att systemet har tillräcklig funktionalitet för att kunna tillhandahålla tjänsten 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. 29 31 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. 30 32
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 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 Utformning av systemet i detalj, tex val av datastrukturer 33 35 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 34 36
Effektivitet (forts) Önskemål om OOP Korrekthet: Att programmet är implementerat enligt designspecifikation (Förutsätter att analys och design är OK.) Typer av effektivitet: Minnesanvändning CPU-användning Responstid (ofta subjektiv, mycket viktig i alla applikationer som kommunicerar med människor) Notera att responstid ofta domineras av diskaccesser och nätverkskommunikation. 37 39 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 38 40
Å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 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 41 43 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);...... 42 44
Cykel Använd collection classes! Multirelationer 0..* 1 Person class Person { Set<Cykel> cyklar = new HashSet<Cykel>(); void nycykel (Cykel c) { cyklar.add(c); 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 45 47 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 46 48
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å? 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 49 51 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 50