Centralt innehåll
- Analys, nedbrytning och modellering av programmeringstekniska problem med lämpligt analysverktyg, till exempel användningsfall.
- Skapande av klasser och objekt i ett objektorienterat programspråk utifrån tidigare analys och design.
- Design av lämplig lösning ur föregående analys med lämpligt verktyg och metoder som klassdiagram.
1. Objektorienterad Analys
Objektorienterad analys (OOA) är ett sätt för att analysera en applikation genom att tillämpa ett objektorienterat synsätt.
Objektorienterad analys (OOA) fokuserar på vad som ska göras?
Där man försöker förstå problemområdet och vilka objekt som finns och relationerna mellan dem.
1.1 Analys
- Ser systemet utifrån, vad ska göras?
- Försöker förstå problemområdet. Vilka objekt finns och relationerna mellan dem.
T.ex. en bank app har objekt som kund, konto. - Framställer dokument som ska användas i designarbetet, t.ex. klassdiagram och terminologi (språket).
- Ett datorprogram kan ses som en modell av ett verkligt system.
- Vilka objekt ska modellen bestå av?
- Vad har objekten för medlemsvariabler och metoder?
- Hur är objekten relaterade till varandra, vilka relationer har de?
- Ofta används klassdiagram för att bygga upp modellen. (En modell beskriver vad som ska göras.)
1.2 Vad är ett objekt?
1.3 Hur hittar man objekten?
- I en modell av ett verkligt system är föremål objekt.
- I en skriven beskrivning är substantiv objekt.
2. Objektorienterad Design
Objektorienterad design (OOD) är ett sätt för att designa en applikation genom att tillämpa objektorienterad programmering.
Objektorienterad design (OOD) ser datasystemet inifrån, hur ska systemet utvecklas rent tekniskt?
2.1 Design
- Ser datasystemet inifrån, hur ska det göras rent tekniskt?
- Hur objekten kommunicerar med varandra.
- Tillräckligt med information för kodning, mer detaljerade klassdiagram.
- Om ny teknik används kan det finnas behov av en POC (Proof of Concept), ett sätt att se om idén kan förverkligas.
3. UML
UML (Unified Modeling Language) är tänkt att
fungera som hjälpmedel vid modellering av objektorienterade program.
Det största värdet av modellering är som dokumentation och som hjälpmedel att bena ut sammanhang.
Eftersom människan har en väldigt väl utvecklad förmåga att bearbeta information visuellt vill man givetvis
dra nytta av detta då det är möjligt.
Väldigt ofta kan det räcka med att klottra ned kända fakta på ett papper för att man skall kunna reda ut
problem. Hjärnan kan på något sätt bearbeta informationen lättare när man kan se på det. När det inte räcker
med att intuitivt klottra ned figurer och text så kan det vara till hjälp med standardiserade figurer. Inte bara
kan man få tillgång till genomtänkta figurer och regler utan man kan dessutom underlätta informationsutbyte
mellan personer då man har ett gemensamt språk.
UML är alltså tänkt att vara ett visuellt språk för att beskriva modeller av olika slag. (i vårt fall
objektorienterade program). UML är inte en metod, dvs det är inte ett verktyg för att beskriva hur man
utvecklar system. För detta ändamål finns det systemutvecklingsmetoder som är framtagna, som ofta är
baserade på UML.
3.1 Klasser
En klass definierar attributen och metoderna för en mängd objekt. Alla objekt av klassen (instanser av klassen) delar samma beteende, och har samma mängd attribut (varje objekt har sin egen uppsättning).
Standardutseende för en klass är en box med sektioner (i nämnd ordning):
- titel som beskriver klassnamn (Stor begynnelsebokstav och singularis)
- lista av attribut/egenskaper (medlemsvariabler)
- lista av metoder
Attribut kan skrivas på formatet attributnamn : typ, där typen beskriver attributets typ (datatyp). Typinformationen kan utlämnas om det inte tillför något.
3.2 Relationer
Relationer mellan objekt kan ta form på många olika sätt, bl.a. via enkla associationer, aggregat och generaliseringar. Innebörden är att två klasser har någon sorts koppling till varandra. Man kan tänka sig många fler typer av relationer, men vid skapandet av UM-standarden har man försökt att identifiera de mest utmärkande och vanliga typerna.
3.2.1 Association
En association är en koppling mellan två olika klasser. En association kan vara enkelriktad eller dubbelriktad (utan pilspets). Oftast använder man dubbelriktade associationer, men om man vill minimera kopplingen mellan klasser så kan enkelriktade associationer passa bra.
Associationer kan även specificera multiplicitet, dvs hur många kopplingar det finns på vardera sidan om en association. I figuren visas att banken har en association som heter accountlist till noll eller flera konton, och att kontot har en icke-namngiven association till banken.
Figuren visar även att associationen är private genom att minus (-) är tillsatt framför associationsnamnet.
Association mellan två klasser, där associationen har multiplicitet specificerat.
Dessutom har associationen ett roll-namn på ena änden.
3.2.2 Aggregat
Aggregat är ungefär samma sak som en association, men den visar lite tydligare att två klasser har ett "har ett" - "är del av" förhållande. Exempel: En skola har studenter eller Studenterna är en del av skolan, mellan klasserna råder då ett aggregatförhållande. Ett aggregat visas med hjälp av en liten romb i den ändan där "har ett"-förhållandet gäller.
I figuren visas att förhållandet en bank består av sina kunder.
Aggregat är en mer er specialiserad variant av association.
3.2.3 Komposition
Komposition är ytterligare en variant av association som är i stort sett identisk med aggregat, men innefattar begränsningen att det bara finns en enda ägare till delarna i "har ett"-förhållandet. (Exempel: En bank består (delvis) av sina konton, och dessa konton finns bara i den aktuella banken och kontona kan inte existera utan banken). Komposition visas genom att associationen har en fylld romb vid "har ett"-förhållandets sida.
I figuren visas samma exempel som för association förutom att associationen har ersatts med en komposition.
Betraktaren av diagrammet får en bättre uppfattning hur förhållandet mellan banken och kontot är tänkt att vara.
Komposition är en mer specialiserad variant av aggregat.
3.2.4 Generalisering (Arv)
Generalisering av klasser innebär vanligtvis att en klass har ärvt implementation från en överklass. Detta representeras i UML genom en generaliseringsassociation. Generaliseringen representeras av en pil som pekar ut överklassen.
I figuren visas "är en sorts" förhållande. Exempel: Human är esorts Mammanl. Horse är en sorts Mammal.
Två varianter av arv.
3.2.5 Relationstyperna
- Association: Känner till.
- Aggregat: Har, Är en del av, Består av.
- Komposition: Som aggregat, men hårdare relation. Den ena kan inte finnas utan den andra.
- Generalisering (arv): Är en sorts. Använd arv för klasser som passar in.
3.3 Klassdiagram
Klassdiagram används för att gruppera information (klasser och deras relationer) och belysa vissa delar av en modell på ett enkelt och överskådligt sätt.
Ett klassdiagram visar klasser och relationerna mellan dem.
Begrepp
Analys: Vad som ska göras, förstå problemet och relationer mellan objekt.
Design: Hur systemet ska utvecklas rent tekniskt.
UML: Unified Modeling Language, ett hjälpmedel för att grafiskt beskriva ett objektorienterat system.
Objekt: Ett verkligt eller abstrakt föremål/sak som hanteras som en enhet.
Klass: Mallen till ett objekt. Definierar attribut och metoder.
Attribut: Egenskaper, medlemsvariabler. Variabler som tillhör ett objekt.
Relation: Samband mellan klasser.
Association: En koppling mellan två olika klasser, "Känner till varandra".
Aggregat: En koppling mellan två olika klasser, "Har", "Är en del av", "Består av".
Komposition: En koppling mellan två olika klasser, som aggregat, men hårdare relation. Den ena kan inte finnas utan den andra.
Generalisering (arv): En koppling mellan två olika klasser, "Är en sorts".
Klassdiagram: Visar klasser och relationerna mellan dem.
Länkar
Fakta
Övningar
Inlämningsuppgift
Klassdiagram
Ett bankkonto ska hålla reda på information om namnet på den person som äger kontot och hur mycket pengar som finns på kontot (saldot). Man ska kunna ta ut pengar från kontot och sätta in pengar. Det ska inte gå att plocka ut mer pengar än vad som finns på kontot.
Använd det användningsfallsdiagram som gjordes tidigare.
Gör en OOAD på Banken.
Identifiera klasser och relationerna mellan dem.
Det ska finnas minst en klasshierarki (arv).
Klassdiagram i UML: Gör ett klassdiagram på Banken i UMLetino.