Behavior models
Behavior models test whether you can specify what the system does, separately from how it is structured, using activities, interactions, state machines and use cases. Expect questions on flow semantics, on combined fragments, and on the trigger/guard/effect anatomy of a transition.
Activities
An activity contains actions, control flow and object flow. Object flow requires pins or parameter nodes and carries typed items; control flow carries only sequencing. Use decision and merge for branching, fork and join for concurrency, and partitions (swimlanes) to show responsibility. Streaming and «continuous» parameters model physical flows such as fuel or torque.
Interactions
A sequence diagram orders messages among lifelines. Synchronous messages expect a reply; asynchronous messages do not. Combined fragments express control: alt for alternatives, opt for optional, loop for iteration, par for concurrency, break for exceptions. Interaction uses factor out common sequences.
State machines
A state machine describes the state of one block. A transition is written trigger [guard] / effect. States may have entry, exit and do behaviors; composite states and regions handle hierarchy; shallow and deep history restore prior configurations.
Use cases
Actors interact with a subject through use cases. «include» always includes the included behavior; «extend» adds optional behavior at a named extension point, and the arrow runs from the extending use case to the base.
Worked example
A door controller has states Closed and Open. The transition Closed to Open fires on trigger openCmd, with guard [obstacle == false] and effect motor.start(). The trigger is the event received; the guard is evaluated only when that event occurs; the effect runs after the guard passes.
Traps
Putting a condition in the trigger instead of the guard, using alt where opt is meant, drawing object flow without pins, confusing activity final with flow final, expecting a sequence diagram to define structure, and reversing the include arrow.