Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

PlantUML Macro
class Person {
	String name
}

Person -- Person: ekteskap

Person-klassen og ekteskap-assosiasjonen

Code Block
languagejava
public class Person {
	
	private String name;
	private Person ekteskap;
	
	public Person(String name) {
		this.name = name;
	}
	
	public Person getEkteskap() {
		return ekteskap;
	}
	public void setEkteskap(Person ekteskap) {
		this.ekteskap = ekteskap;
	}
}

 


PlantUML Macro
object "#hallvard~#hallvard: Person" as hallvard {
	name = "Hallvard"
}
object "#marit~#marit: Person" as marit {
	name = "Marit"
}
hallvard --> marit : ekteskap

hallvard er koblet til marit med en ekteskap-kobling

 

Code Block
languagejava
// lage eksempel-objekter
Person hallvard = new Person("Hallvard");
Person marit = new Person("Marit");

// opprette ekteskap-koblingen fra hallvard til marit
hallvard.setEkteskap(marit);

...

En rolle er en assosiasjon sett fra perspektivet til en ene enden, altså fra den ene til den andre. Siden en assosiasjon har to ender, så har den også to roller. Roller er nødvendig fordi logikken knyttet til assosiasjonen som helhet nødvendigvis må fordeles på metoder i hver klasse, og disse metodene må ha perspektivet til klassen de er i. Ta institutt-emne-assosiasjonen som sier hvilke emner et institutt gir, som eksempel. Sett fra institutt-enden (sett mot emne-enden) er det naturlig å kalle den emner, mens det fra emne-enden (sett mot institutt-enden) er naturlig å kalle den ansvarlig-institutt ansvarligInstitutt. Disse navnene kan gi opphav til metoder som addEmne i Institutt-klassen og setAnsvarligInstitutt i Emne-klassen. En tommelfinger-regel er nettopp at rolle-navnet er greit, hvis navnet på innkapslingsmetodene virker greit.

Rolle-navnet brukes altså for å navngi metoder som implementerer logikken for assosiasjonen, altså hvordan koblinger opprettes og fjernes. Men akkurat hvilke metoder en har og hva disse gjør og dermed heter, avgjøres av det som kalles rollens multiplisitet (ofte kalt kardinalitet). Multiplisiteten til en rolle angir hvor mange koblinger som kan (eller må) gå fra et objekt i rolle-retningen. Multiplisiteten til emne-rollen sier altså hvor mange emner et institutt kan ha ansvaret for (mer enn ett), og multiplisiteten til ansvarlig-insitutt ansvarligInsitutt-rollen sier hvor mange institutter som kan ha ansvaret for et emne (ett og bare ett). Multiplisitet angis ofte av en minimum- og en maksimum-verdi, altså et intervallet. Ofte er minimum-verdien 0 og da kan den utelates. Rolle-navnet og multiplisiteten angis sammen i enden av assosiasjonen, men ofte på hver sin side av streken:

PlantUML Macro
class Institutt {
}
class Emne {
}
Institutt "ansvarlig-instituttansvarligInstitutt 1:1" -- "emne 0:*" Emne

PlantUML Macro
object "#tdt4100~#tdt4100: Emne" as tdt4100 {
}
object "#idi~#idi: Institutt" as idi {
}
object "#tdt4180~#tdt4180: Emne" as tdt4180 {
}
idi -up-> "emne" tdt4100
idi -down-> "emne" tdt4180
tdt4100 -down-> "ansvarlig-instituttansvarligInstitutt" idi
tdt4180 -up-> "ansvarlig-instituttansvarligInstitutt" idi

 

 

 

Klassediagrammet over til venstre viser to klasser Insitutt og Emne og en assosiasjon med rollene ansvarlig-institutt ansvarligInstitutt og emne mellom disse. Multiplisitetene 1:1 og 0:* betyr at et Institutt-objekt kan være koblet til 0 eller flere (uten øvre grense) Emne-objekter (og være ansvarlig-institutt ansvarligInstitutt for disse Emne-objektene), mens et Emne-objekt må være koblet til (minimum) ett og kun (maksimum) ett ansvarlig Institutt-objekt (og kan være et av mange emner for dette Institutt-objektet).

Eksempel-objektstrukturen viser to Emne-objekter kalt tdt4100 og tdt4180 som begge rollen som emne ift. Institutt-objektet idi. Motsatt så har Institutt-objektet idi rollen som ansvarlig-institutt ansvarligInstitutt for de to Emne-objektene.

Med disse detaljene på plass er klassediagrammet fullstendig nok til at vi kan skrive Java-kode for Institutt- og Emne-klassene. Her vil vi bare skissere løsningen, mens en slags oppskrift er gitt på siden om koding av 1-n-assosiasjonerMetoder for å opprette og fjerne koblinger er skissert under, med kode for å opprette eksempel-objektstrukturen, men merk at koden ikke sikrer konsistens, dvs. at koblingene er gjensidige, så vi må gjøre det manuelt.

Code Block
languagejava
public class Institutt {

	// felt som kan inneholde flere emner
	private ArrayList<Emne> emner = new ArrayList<Emne>();

	// metode for å opprette emne-kobling
	public void addEmne(Emne emne) {
		this.emner.add(emne);
	}

	// metode for å fjerne emne-kobling
	public void removeEmne(Emne emne) {
		this.emner.remove(emne);
	}
}
Code Block
languagejava
public class Emne {

	// felt som kan inneholde ett Institutt
	private Institutt ansvarligInstitutt;

	// metode for å opprette eller fjerne ansvarligInstitutt-kobling
	public void setAnsvarligInstitutt(Institutt institutt) {
		this.ansvarligInstitutt = institutt;
	}
}
Code Block
languagejava
// opprette instansene
Institutt idi = new Institutt(...);
Emne tdt4100 = new Emne(...);
Emne tdt4180 = new Emne(...);

// opprette koblingene
// den ene veien ...
idi.addEmne(tdt4100);
idi.addEmne(tdt4180);
// ... og den andre veien
tdt4100.setAnsvarligInstitutt(idi);
tdt4180.setAnsvarligInstitutt(idi);

Ulike kombinasjoner av multiplisiteter gir opphav til ulike sett med innkapslingsmetoder og stiller ulike krav til deres logikk. Koding av de ulike variantene skisseres på egne sider (se sidelista under).