Előfordulhat, hogy a turnOn esemény hatására start nélkül is végrehajtja az állapotgép az initialize viselkedést.

turnOn esemény hatására mindig a Working állapotba kerülünk.

A turnOff esemény hatására az állapotgép kiküldi a stop eseményt.

Az initialize esemény kiküldése mindig a start esemény hatására következik be, mivel csak így juthatunk a Working állapotba.

A socket által küldött üzenet fogadóját nem modelleztük, ismeretlen vagy lényegtelen. 

Client csak azért törölheti Socket-ot a diagram végén, mivel ő is hozta létre korábban.

A socket által fogadott üzenet küldője hiányzik, a modell így hibás, később be kell fejeznünk.

A függőleges szaggatott vonalakat letakaró téglalapok az életvonalak. 

Igen, hiszen a kliens mindig megvárja előző üzenete megérkezését a szerverhez.

Igen, hiszen a két üzenet egymás után következik.

Nem, mert se az üzenet, se a lifeline nem közös, így nincsen biztos rendezettség.

Nem, mert attól, hogy egy esetet lemodellezünk, még bármi megtörténhet.

Az x üzenet aszinkron, de ezt az y üzenet nélkül nem tudhatnánk.

Az x egy szinkron hívás, és ezt az y üzenet nélkül is meg tudjuk állapítani. 

Az x egy szinkron hívás, de ezt az y üzenet nélkül nem tudhatnánk.

Az x üzenet aszinkron, és ezt az y üzenet nélkül is meg tudjuk állapítani. 

Előfordulhat, hogy a turnOn esemény hatására start nélkül is végrehajtja az állapotgép az initialize viselkedést.

turnOn esemény hatására mindig a Working állapotba kerülünk.

A turnOff esemény hatására az állapotgép kiküldi a stop eseményt.

Az initialize esemény kiküldése mindig a start esemény hatására következik be, mivel csak így juthatunk a Working állapotba.

Az x üzenet aszinkron, de ezt az y üzenet nélkül nem tudhatnánk.

Az x egy szinkron hívás, és ezt az y üzenet nélkül is meg tudjuk állapítani. 

Az x egy szinkron hívás, de ezt az y üzenet nélkül nem tudhatnánk.

Az x üzenet aszinkron, és ezt az y üzenet nélkül is meg tudjuk állapítani. 

Kezdetben (bármilyen esemény érkezése előtt) a {Working, H} állapotkonfigurációba kerül az állapotgép.

A {Working, Waiting for Feedback, Drinking Coffee} állapotkonfigurációból indulva a feedbackEmail, majd emptyTodoList érkezése az állapotgépet visszaviszi ugyanebbe az állapotkonfigurációba.

A paperSubmitted, majd 12AMAlarm esemény sorozat hatására az állapotgép a {Working, Waiting for Feedback, Sleeping} állapotkonfigurációba kerülhet.

A kezdőállapotból indulva a paperSubmitted, 12AMAlarm, morningAlarm esemény szekvencia végén az állapotgép a {Working, Waiting for Feedback, Making Coffee} állapotkonfigurációba kerül.

Igen, hiszen a kliens mindig megvárja előző üzenete megérkezését a szerverhez.

Igen, hiszen a két üzenet egymás után következik.

Nem, mert se az üzenet, se a lifeline nem közös, így nincsen biztos rendezettség.

Nem, mert attól, hogy egy esetet lemodellezünk, még bármi megtörténhet.