Objektorienterad analys och design

Transkript

1 Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet June 22,

2 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även och

3 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

4 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

5 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 5

6 Klassisk modell för systemutveckling (vattenfallsprincipen) Fyra faser: 1. Analys 2. Design 3. Implementation/unit testing 4. Integration/testning OBS: vattenfallsprincipen har stora brister! 6

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 7

8 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 8

9 Systemutveckling: implementation 1. Utgå från en design 2. Producera ett färdigt program 3. Kontrollera att implementationen är fullständig effektiv... 9

10 Use cases Svenska: användningsfall Ivar Jacobson 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. 10

11 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 11

12 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 12

13 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 13

14 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 14

15 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) 15

16 UML: tre huvudanvändningar Analysmodell: analysera problemformuleringen Designmodell: rita upp programmet i stora drag Reverse-engineering: hjälp att förstå beintligt program 16

17 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) 17

18 UML: Ansvar Ett fjärde fält i klassdiagrammet. Datum Datum(år, mån, dag) Lagrar information om visst datum 18

19 Samband mellan klasser Två klasser har nåt att göra med varandra Almanacka Datum Klassen Almanacka använder klassen Datum. 19

20 Generalisering (I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik) Exempel: Fordon Bil 20

21 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 21

22 Mera komplext exempel: Fordon toppfart Bil toppfart motorstyrka Cykel toppfart 0..* äger tillhör 1 Person namn ålder 22

23 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 23

24 Multirelationer Om inget annat anges är en association (relation) många till många. Bra eller dåligt? - Person Lärare undervisar Student 24

25 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? 25

26 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 26

27 Sammansättning En slags association. Anger att ett objekt är en del av ett annat Bil Hjul 27

28 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,... 28

29 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 29

30 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 30

31 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. 31

32 Vad är målet med analysfasen? UML-diagram. Beskrivning av alla ingående klasser och deras ansvar. Övrig dokumentation. 32

33 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 33

34 Objekt-orienterad analys Vilka objekt ingår? Tidigare definierade objekt Substantiv i problembeskrivningen (ger garanterat alltför många objekt) 34

35 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 35

36 Objektorienterad programmering Önskemål (Skansholm) korrekt effektivt ändringsbart återanvändningsbart 36

37 Önskemål om OOP Korrekthet: Att programmet är implementerat enligt designspecifikation (Förutsätter att analys och design är OK.) 37

38 Effektivitet: Vanligtvis: Vi vill att programmet skall vara tillräckligt effektivt. Ibland: Ju effektivare desto bättre. 38

39 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. 39

40 Ä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 40

41 Å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 41

42 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;... }... } 42

43 Implementera relationer Exempel: Alla personer har noll eller en cykel Cykel Person class Person { Cykel cykel; } void nycykel (Cykel c) { if (cykel!= null) felmeddelande else cykel = c } 43

44 Alla har noll eller en cykel (forts) class Cykel { Person ägare; } Class(Person ägare) { this.ägare = ägare; ägare.nycykel(this);... }... 44

45 Multirelationer Cykel 0..* 1 Person Använd collection classes! class Person { Set<Cykel> cyklar = new HashSet<Cykel>(); } void nycykel (Cykel c) { cyklar.add(c); } 45

46 Har-relation (komposition) Jämför: komposition och association Bil Bil Hjul Ägare 46

47 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 47

48 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 48

49 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å? 49

50 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

51 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 51