Как диаграмма конечного автомата может быть представлена ​​как поведение для операции в UML?

Question

Поведения (тело метода) могут быть конечными автоматами или действиями - действия легко понять, поскольку они являются эквивалентом процедурного кода.

Я не понимаю, как конечный автомат может использоваться как поведение для операции?

Не могли бы вы привести простой пример для этого?

---Заметка---

Операция является элементом только для спецификации - представьте его как сигнатуру метода в языках программирования ОО. У него есть имя и список параметров.

Поведение - это (среди прочего) то, что делает операция (или другая поведенческая особенность, такая как прием), когда вызывается - представьте это как тело метода.

Answer 1

"То, что ты можешь, не значит, что ты должен".

Другими словами: может быть законно использовать модель состояния для определения поведения операции, но это не значит, что вы должны это делать. Я никогда не сталкивался со сценарием, где это было бы полезно; но, конечно, это не значит, что они не существуют. Это также является симптомом отсутствия единства в некоторых спецификациях UML.

Было бы целесообразно, чтобы операция (не включающий класс) имела поведение с состоянием. Чтобы использовать действительно надуманный пример: рассмотрим метод TcpConnection.close(), Если соединение уже было закрыто, то звоню close() не будет иметь никакого эффекта. Если соединение было открыто, то звонил close() закрыл бы это.

[Однако: как пример, который также иллюстрирует, почему я никогда не находил необходимость в модели состояния конкретного метода. Модель состояния действительно принадлежит классу, а не операции.

НТН.

Answer 2

Самый простой способ понять, что такое Поведение: это может изменить значение вашей переменной-члена. Например

class MyClass
{
    public Integer i = 0;
    public void Operation1(){
        i++; //This could be an interpretation of of opaque action from an Activity
    };
    public void RunStateMachine(){
        //You can use state's entry/doActivity/exit behavior. E.g. put "i++" in any of them
        //You can use transition's effect behavior. E.g. put "i++" in it
        //state's entry/doActivity/exit, transition's effect can specify to another behavior, e.g. run another Activity or statemachine, 
        //UML provides a good recursive way to let user to model what ever they wanted.

        //NOTE: When using statemachine as behavior, you should know that the context (e.g. MyClass my = new MyClass(); here my is the context) of the statemachine 
        //is expecting an EventOccurence if the transitions has triggers. 
        //If no triggers are defined in any of the transitions in a statemachine, it can be think of being downgraded as an activity
        // (well, it is not conforming to UML, but you can think in that way.)
    }

}