Objekttilstandsdiagrammer er objektdiagrammer knyttet sammen med metodekall-transisjoner, 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å rammer en inn objektdiagrammer og knytter disse sammen med piler annotert med metodekall. 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.
| 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.
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. |