Responding to Cressey...

The short answer is: anyway you want -- so long as the specification
semantics are compliant with the UML execution meta model.

As a series of unit tests, each using assertions which are generally imperative.
The methods in the objects are more declarative.

I think it would be a mixture of both. At some level you have to write the
code that actually implements the algorithms/behavior. Once the
implementation is done, the "How" of the matter, you can move up a level in
abstraction and use a more declarative approach, the "What" of the matter.
So if I do something like this:

class DarkStar
{
public:
   // Stuff...

   void CancelBombDetonation()
   {
       // Code that actually implements the cancel bomb detonation
       // algorithm... have philosophical conversation with bomb
       // to convince it not to blow up...
   }
};

The code for the CancelBombDetonation method is imperative; it determines
how the algorithm is carried out. I can now take a more declarive approach:

darkStar.CancelBombDetonation();

At the level where the behavior is invoked, I don't care about how the
algorithm is implemented, only that it does *what* I expect.

Does this make sense?

State machine? Declarative style would push the model towards
algebraic description: Kleene algebra, idempotent semiring, etc. The
connection between Kleene and Tarski relation algebra is well known.
The difference between Kleene and Relational Algebra is quite
significant, and IMO is the essence of the divide between procedural
(i.e. sequential) and relational worlds.

As usual, the object perspective have really no insight to contribute.

Do you have an example in mind?  eg., local store sells sardines at 89
cents a can or two for $1.59.  That behaviour seems declarative to me.