Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 1
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/ 2
Objekt-orienterad utveckling Saker man vill uppnå: 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 3
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. 4
Klassisk modell för systemutveckling (vattenfallsprincipen) Tre faser: 1. Analys 2. Design 3. Implementation 5
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 6
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 7
Systemutveckling: implementation 1. Utgå från en design 2. Producera ett färdigt program 3. Kontrollera att implementationen är fullständig effektiv... 8
Objektorienterad analys och design Ide: Beskriv allt i termer av objekt 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). 9
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) 10
UML: Exempel Exempel: En klass Fönster position storlek Klassnamn Attribut (instansvariaböe) öppna() stäng() flytta() visa() Operationer (metoder) Ofta utelämnas attribut & metoder pga platsbrist (eller: för att göra modellen tydligare) 11
UML: Ansvar Ett fjärde fält i klassdiagrammet. Datum Datum(år, mån, dag) Lagrar information om visst datum 12
Samband mellan klasser Två klasser har nåt att göra med varandra Almanacka Datum Klassen Almanacka använder klassen Datum. 13
Generalisering (I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik) Exempel: Fordon Bil 14
Association Bok 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 15
Mera komplext exempel: Fordon toppfart Bil toppfart motorstyrka Cykel toppfart 0..* äger tillhör 1 Person namn ålder 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 17
Multirelationer Om inget annat anges är en association (relation) många till många. Bra eller dåligt? - Person Lärare undervisar Student 18
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? 19
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 20
Sammansättning En slags association. Anger att ett objekt är en del av ett annat Bil Hjul 21
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,... 22
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 23
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 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. 25
Vad är målet med analysfasen? UML-diagram. Beskrivning av alla ingående klasser och deras ansvar. Övrig dokumentation. 26
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 27
Objekt-orienterad analys Vilka objekt ingår? Tidigare definierade objekt Substantiv i problembeskrivningen (ger garanterat alltför många objekt) 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 Utformning av systemet i detalj, tex val av datastrukturer 29
Objektorienterad programmering Önskemål (Skansholm) korrekt effektivt ändringsbart återanvändningsbart 30
Önskemål om OOP Korrekthet: Att programmet är implementerat enligt designspecifikation (Förutsätter att analys och design är OK.) 31
Effektivitet: Vanligtvis: Vi vill att programmet skall vara tillräckligt effektivt. Ibland: Ju effektivare desto bättre. 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. 33
Ä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 34
Å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 35
Implementera relationer: exempel Cykel tillhor 0..* 1 Person Varje cykel tillhör en unik ägare. class Cykel { Person ägare; Class(Person ägare) { this.ägare = ägare;... }... } 36
Implementera relationer Exempel: Alla personer har noll eller en cykel Cykel 0..1 1 Person class Person { Cykel cykel; } void nycykel (Cykel c) { if (cykel!= null) felmeddelande else cykel = c } 37
Alla har noll eller en cykel (forts) class Cykel { Person ägare; } Class(Person ägare) { this.ägare = ägare; ägare.nycykel(this);... }... 38
Multirelationer Cykel 0..* 1 Person Använd collection classes! class Person { Set cyklar = new HashSet; } void nycykel (Cykel c) { cyklar.add(c); } 39
Har-relation (komposition) Jämför: komposition och association Bil Bil Hjul Ägare 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 41
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 42
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å? 43
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 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