Klassediagrammer er en illustrasjon av innholdet i og sammenhengen mellom klasser, som et supplement til tekslig kode. Et klassediagram viser klasser som bokser, attributter og operasjoner som tekstlinjer inni boksene (i hver sine deler) og assosiasjoner og arv som streker med. I tillegg annoteres assosiasjonsstreker med informasjon om navn og såkalt multiplisitet (også kalt kardinalitet). Figuren under viser et enkelt klassediagram med tilsvarende Java-kode til høyre.
Attributter og assosiasjoner
|
| Figuren lengst til venstre viser et klassediagram med to klasser. Person-klassen har to attributter og én operasjon/metode, mens Car-klassen har ett attributt. Person- og Car-klassene er knyttet sammen med en ownership-assosiasjon. ownership-assosiasjon er annotert med "owner: 1" i Person-enden og "cars: *" i Car-enden, for å indikere hvordan assosiasjonen forstås fra hver ende:
Diagrammet tilsvarer omtrent Java-koden som er vist til høyre. Vi ser at attributter og operasjoner i klassediagrammet tilsvarer felt og metoder i Java-koden. Assosiasjonene har ikke noe direkte Java-motstykke, men en finner igjen assosiasjonsrollene som felt som brukes som implementasjonsteknikk. Når en instans kan være koblet til flere andre instanser, så må en bruke Collection (evt. array, List eller Set) og ikke en enkel type. Hvis en assosiasjon har et pilhode, så betyr det at en er enveis, dvs. en kan ikke navigere fra objekter i pilhode-enden til objekter i den andre enden. I praksis betyr det at en utelater felt for å lagre referanser i klassen i pilhode-enden. Hvis f.eks. assosiasjonen i diagrammet hadde pekt fra Person til Car, så hadde ikke Car-klassen trengt et owner-felt. |
Arv (extends og implements)
Arv gjør at nye klasser kan bygge på eller utvide andre klasser. I klassediagrammer angis det med en spesiell pil fra subklassen til superklassen, med et litt stort pilhode som ikke er fylt. En bruker stiplet linje hvis det er snakk om implementasjon av grensesnitt, og ikke vanlig arv mellom klasser (eller mellom grensesnitt).
| Figuren lengst til venstre viser et klassediagram for Observatør-observert-teknikken. Den abstrakte klassen AbstractObservable implementerer støtte for lagring og registrering av lyttere av typen Observer vha. assosiasjonen observers og metoden addObserver og removeObserver. Den konkrete (ikke-abstrakte) observerbare klassen ConcreteObservable arver dette feltet og disse metodene fra AbstractObservable. Observer-grensesnittet fanger opp hva det vil si å observere (være en lytter), nemlig å implementere update-metode som reagerer på endringen i det observerte objektet. Den konkrete klassen ConcreteObserver implementerer dette grensesnittet og dermed også update-metoden. Vi har her angitt synlighet(smodifikatorer) for metodene: Grønn sirkel tilsvarer public og gul ruter tilsvarer protected (og rød firkant tilsvarer private, men det er ikke vist). Den tilsvarende koden er vist under diagrammet. Vi ser at en heltrukken arvingspil tilsvarer extends og en stiplet arvingspil tilsvarer implements. Feltinitialiseringen og innholdet i metodene er ikke med i diagrammet og er med for kompletthet. Merk at iht. navnkonvensjonen i Java så brukes Listener som endelse på observatør-grensesnitt og dermed også på felt, metoder og variabler som har med den å gjøre, altså XXXListener, Collection<XXXListener> xxxListeners, addXXXListener og removeXXXListener.
|