2017-02-21 8 views
1

Я моделирую процесс, используя диаграмму состояний UML. Вот некоторые псевдо-код, который определяет текущее состояние:Как смоделировать этот процесс, используя диаграмму состояния?

function getAccountState(customer) { 

    if (authorizationRequired(customer)) { 
     return State.AUTHORIZATION_REQUIRED 
    } 

    if (updateRequired(customer)) { 
     return State.UPDATE_REQUIRED 
    } 

    return State.DRAFT 
} 

Ближайший я получил эту диаграмму: State diagram

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

Как можно моделировать этот процесс?

EDIT:

фона позади этого процесса является службой REST. Учетная запись моделируется как ресурс и может проходить через различные состояния. Каждый раз, когда запрашивается ресурс, служба выполняет проверки в порядке, описанном псевдо-кодом выше, для генерации соответствующего представления. В зависимости от ответа, он включает в себя также:

  • ссылку для авторизации учетной записи, если учетная запись требует авторизации
  • ссылку, чтобы обновить профиль, если обновление необходимо (это, однако, может произойти только после того, как счет разрешено или не должно быть санкционировано)
  • ссылка для окончательной доработки учетной записи, если профиль обновлен (либо потому, что он должен быть обновлен и обновлен клиентом, либо он никогда не должен обновляться в первое место)

Код, приведенный выше, является просто экзаменом но все же. Служба также может использовать поле базы данных, хранящее «состояние», хотя это анти-шаблон не является? Более целесообразно «выводить» текущее состояние, применяя бизнес-правила к сохраненным данным вместо (избыточно), сохраняя состояние в отдельном поле. Это то, что должен указывать псевдокод.

+0

Ваш код на самом деле не представляет собой конечный автомат. Непонятно, как необходимо использовать auth/upd.-req. работа влияет на всю систему. Также вы не можете передавать два раза с самого начала. Это займет неопределенный/случайный путь, –

+0

Код должен представлять правила «активного» состояния. Например. При создании учетной записи метод вызывается и может вернуться к тому, что учетная запись должна быть авторизована до продолжения. После этого действия (например, авторизации) метод вызывается снова и может вернуться к необходимости обновления профиля. Если нет, учетная запись находится в проекте состояния. Код должен представлять только эту логику, этот код действительно не существует в какой-либо системе. Я просто хотел проиллюстрировать правила. –

+0

Да, я знаю. Но он просто возвращает условия, возвращаемые из операций. Это вовсе не конечный автомат.Это просто операция, возвращающая условное значение, случайно называющее «состояние». –

ответ

0

Согласно правки, я придумал следующий подход:

enter image description here

Вы достигнете Draft состояния через (по желанию) авторизации и обновления. Если они не работают, конечный автомат сбрасывается.

0

Я бы предложил одно замечание о точке «несколько странно, что каждый переход содержится дважды», я понял, что из одного состояния вы можете иметь несколько переходов, инициированных одним и тем же событием, но в этом случае переходы имеют разные охранники , Как я помню, обозначение evt [guard]. Надеюсь, эта помощь.

+0

Это интересный подход. Вопрос в том, лучше ли выражать условие в первую очередь (используя нотацию UML) или как охранник при переходе. Любые советы о том, когда использовать что? –

+0

В соответствии с этим вопросом (http://stackoverflow.com/questions/5724259/state-transition-with-different-guard-condition) использование охранников на самом деле будет способом. Также связанный пример в принятом ответе говорит о выборе, который используется для двух или более состояний. Разумеется, выбор будет иметь логический выбор, но защита, явно предназначенная для обработки логических вариантов, представляется здесь более уместной. –

+0

Я просто попытался смоделировать это с помощью гвардейцев: http://imgur.com/hFlOazC. Думаю, я пойду на подход выбора. Кажется, легче понять, и что, если не простота - это идея визуализации чего-то со схемой :) –

Смежные вопросы