Versions Compared

Old Version 17

changes.mady.by.user Unknown User (hal)

Saved on

compared with

New Version 18

changes.mady.by.user Unknown User (hal)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

PlantUML Macro
class Person {
	String firstName
	String familyName
	String getFullName()
}

class Car {
	String brand
}

Person "owner: 1" -- "cars: *" Car: ownership
Code Block
languagejava
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:

  • Fra Person-enden kan en komme til Car-enden via cars-rollen, og *-tegnet indikerer at én Person-instans kan være knyttet til flere Car-instanser.
  • Fra Car-enden kan en komme til Person-enden via owner-rollen, og 1-tegnet indikerer at én Car-instans bare kan være knyttet til én Person-instans.

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

PlantUML Macro
abstract class AbstractObservable {
	+void addObserver(Observer)
	+void removeObserver(Observer)
	#void fireUpdate();
 }

class ConcreteObservable {
}

AbstractObservable <|-- ConcreteObservable

interface Observer {
	+void update(AbstractObservable)
}

AbstractObservable -right- "*" Observer: observers

class ConcreteObserver {
}

Observer <|.. ConcreteObserver
Code Block
languagejava
interface Observer {
	public void update();
}

abstract class AbstractObservable {

	private 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 {
}

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.

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.