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
class Person {
String firstName;
String familyName;
String getFullName();
Collection<Car> cars;
}
class Car {
String brand;
Person owner;
}
| 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).
abstract class AbstractObservable {
Collection<Observer> observers = new ArrayList<Observer>();
public void addObserver(Observer observer) {
observers.add(observer);
}
public void removeObserver(Observer observer) {
observers.remove(observer);
}
protected void fireUpdate() {
for (Observer observer: observers) {
observer.update(this);
}
}
}
class ConcreteObservable extends AbstractObservable {
}
interface Observer {
void update();
}
class ConcreteObserver implements Observer {
public void update(AbstractObservable) {
// method body
}
}
| 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. Den tilsvarende koden er vist til høyre. Vi ser at en heltrukken arvingspil tilsvarer extends og en stiplet arvingspil tilsvarer implements. |