Versions Compared

Key

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

 

Objekttilstandsdiagrammer viser hvordan objekt(struktur)er endres over tid, når en kaller metoder. En kan tenke på objekttilstandsdiagrammer som en blanding av objektdiagrammer og tilstandsdiagrammer, hvor objekt(struktur)er utgjør tilstander med metodekall-transisjoner mellom, slik at en ser hvordan ulike metodkall endrer tilstanden til objektstrukturer og dermed hvordan objektene endres over tid. Merk at denne diagramtypen ikke er standard UML, men en (oppfinnsom) kombinasjon/hybrid av to eksisterende diagramtyper, objektdiagrammer og tilstandsdiagrammer.

Enkelt sagt så knytter en strukturer av objekter, slik de tegnes i objektdiagrammer, sammen med transisjonspiler annotert med metodekall. Transisjonspilene er stiplede, for å gjøre de lettere å skille fra referanser mellom objekter. Objektstrukturen i fra-enden representerer før-tilstanden og objektstrukturen i til-enden er etter-tilstanden en får dersom metodekallet utføres. Metodekallene skrives slik en gjør i programkode, men med objektidentitet istedenfor variabelreferanser.

Denne diagramtypen kan brukes til å spesifisere hva en metode er ment å gjøre, eller til å dokumentere hva metoden faktisk gjør. Diagrammer av denne typen er lett å oversette til en enhetstest, som jo rigger opp en før-tilstand, utfører koden som skal testes og sjekker at etter-tilstanden er som forventet.

 

PlantUML Macro
object "~#1:Person" as p1 {
	name = null
}

object "~#1:Person" as p2 {
	name = "Ola Nordmann"
}
p1 ..> p2: setName("Ola Nordmann")
I dette enkle eksemplet ser vi hvordan et Person-objekt (id=1) får satt navnet sitt. Før-tilstanden viser Person-objektet uten navn. Den stiplede transisjonspilen leder til etter-tilstanden, hvor vi ser at navnet nå er satt til "Ola Nordmann". Teksten på transisjonspilen viser at endringen skyldtes et kall til setName-metoden på Person-objektet med "Ola Nordmann" som argument.

 

Før- og etter-tilstanden er ofte større objektstrukturer, som vist under.

PlantUML Macro
object "~#3:Playlist" as playlist31 {
	name = "Beatles ballades"
}

object "~#yesterday:Song" as yesterday1 {
	name = "Yesterday"
	playLength = 123
}

object "~#2:Song" as song21 {
	name = "Let It Be"
	playLength = 230
}

object "~#4:Song" as song41 {
	name = "Get Back"
	playLength = 194
}

playlist31 -> yesterday1: songs
playlist31 -> song21: songs

object "~#3:Playlist" as playlist32 {
	name = "Beatles ballades"
}

object "~#yesterday:Song" as yesterday2 {
	name = "Yesterday"
	playLength = 123
}

object "~#2:Song" as song22 {
	name = "Let It Be"
	playLength = 230
}

object "~#4:Song" as song42 {
	name = "Get Back"
	playLength = 194
}

playlist32 -> yesterday2: songs
playlist32 -> song22: songs
playlist32 -> song42: songs

playlist31 ..> playlist32: addSong(#4)

Den øverste delen av figuren viser en objektstruktur med fire objekter, ett Playlist-objekt og tre Song-objekter, hvorav to av Song-objektene er knyttet til Playlist-objektet og ett Song-objekt er alene. Denne objektstrukturen utgjør før-tilstanden.

Den stiplede pilen leder fra objektstrukturen som utgjør før-tilstanden til objektstrukturen som utgjør etter-tilstanden. Teksten på den stiplede pilen angir hva som leder fra før-tilstanden til etter-tilstanden.

Her er det metodekallet addSong(#4), altså addSong-metoden kalt på Playlist-objektet med det ensomme Song-objektet som argument, som har som effekt å knytte argumentet til Playlist-objektet, slik (objektstrukturen som utgjør) etter-tilstanden viser.