Objektorienterad analys och design
Sven-Olof Nyström Uppsala Universitet
April 4, 2006
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 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
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.
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
Klassisk modell för systemutveckling (vattenfallsprincipen)
Fyra faser:
1. Analys 2. Design
3. Implementation/unit testing 4. Integration/testning
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: 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
Systemutveckling: implementation
1. Utgå från en design
2. Producera ett färdigt program
3. Kontrollera att implementationen är
• fullständig
• effektiv
• ...
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, 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
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
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
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
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: tre huvudanvändningar
• Analysmodell: analysera problemformuleringen
• Designmodell: rita upp programmet i stora drag
• Reverse-engineering: hjälp att förstå beintligt program
UML: Exempel
Exempel: En klass
storlek
öppna() Fönster
position
Operationer (metoder) Attribut (instansvariaböe) Klassnamn
stäng() flytta() visa()
Ofta utelämnas attribut & metoder pga platsbrist (eller:
för att göra modellen tydligare)
UML: Ansvar
Ett fjärde fält i klassdiagrammet.
Datum
Lagrar information om visst datum
Datum(år, mån, dag)
Samband mellan klasser
“Två klasser har nåt att göra med varandra”
Almanacka Datum
Klassen Almanacka använder klassen Datum.
Generalisering
(I Java: Att en klass ärver en annan, att den ärvande klassen på nåt sätt är mera specifik)
Exempel:
Fordon
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
Mera komplext exempel:
tillhör äger
namn Person toppfart
Cykel toppfart
toppfart
Bil
Fordon
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
Multirelationer
Om inget annat anges är en association (relation) många till många. Bra eller dåligt?
-
Person
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?
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
Sammansättning
En slags association.
Anger att ett objekt är en del av ett annat
Bil
Hjul
Olika typer av diagram i UML
• Användarfallsdiagram
• Klassdiagram (redan beskrivet)
• Dynamisk modellering: tillståndsdiagram, sekvensdiagram
• Interaktionsdiagram
• Komponentdiagram - beskriver implementeringsmoduler
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
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
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.
Vad är målet med analysfasen?
• UML-diagram.
• Beskrivning av alla ingående klasser och deras ansvar.
• Övrig dokumentation.
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 analys
Vilka objekt ingår?
• Tidigare definierade objekt
• Substantiv i problembeskrivningen (ger garanterat alltför många objekt)
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
Objektorienterad programmering
Önskemål (Skansholm)
• korrekt
• effektivt
• ändringsbart
• återanvändningsbart
Önskemål om OOP Korrekthet:
• Att programmet är implementerat enligt designspecifikation
(Förutsätter att analys och design är OK.)
Effektivitet:
Vanligtvis:
• Vi vill att programmet skall vara tillräckligt effektivt.
Ibland:
• Ju effektivare desto bättre.
Effektivitet (forts)
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.
Ä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
Å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
Cykel Person
0..* 1
tillhor
Varje cykel tillhör en unik ägare.
class Cykel {
Person ägare;
Class(Person ägare) { this.ägare = ägare;
...
}
Implementera relationer
Exempel: “Alla personer har noll eller en cykel”
Cykel Person
1 0..1
class Person { Cykel cykel;
void nyCykel (Cykel c) {
if (cykel != null) ‘‘felmeddelande’’
else cykel = c }
}
Alla har noll eller en cykel (forts)
class Cykel {
Person ägare;
Class(Person ägare) { this.ägare = ägare;
ägare.nyCykel(this);
...
} ...
Multirelationer
Cykel Person
0..* 1
Använd collection classes!
class Person {
Set<Cykel> cyklar = new HashSet<Cykel>();
void nyCykel (Cykel c) { cyklar.add(c);
} }
Har-relation (komposition)
Jämför: komposition och association
Bil
Hjul
Bil
Ägare
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
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 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å?
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
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
