Диаграммы состояний: ограничение времени выполнения состояния

Как я могу графически представить в диаграммах диаграмм состояний, что состояние никогда не выполняется более определенного количества раз? Так что это не заканчивается бесконечным циклом. Что-то вроде

assert enterPIN(int p) <= 3

а затем перейти в другое состояние, если условие нарушено. Должен ли я включить это как-то в охрану? Или в государственной деятельности?

РЕДАКТИРОВАТЬ:

(CheckPIN)--[invalid]-->(counter| + inc.)--[counter>3]-->(retainCard)
    ^                      |
    |-----[counter<=3]-----|

Что-то в этом направлении?

Легенда: (StateName | (+-) активность), Переход: ->, [Guard]

Источник

2 ответа

Решение

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

Х.С. Лахман в своей книге " Разработка на основе моделей: приложения" прекрасно описывает использование конечных автоматов Мура. Конечные автоматы Мура - это то, где действия происходят при входе в состояния, а не действия, которые происходят при переходах между состояниями. Его наиболее веская причина для использования конечных автоматов Мура состоит в том, что переходы не вырождаются в последовательность вызовов функций, а вместо этого объявляют о том, что завершено.

Вот пример того, как избежать всех деталей и создать более прочную модель:

введите описание изображения здесь

Вы заметите, что то, как все происходит, полностью заключено в капсулу. Например, вызов пользователю может включать в себя PIN-код, сканирование сетчатки глаза или подкожный чип. Максимально допустимые сбои для каждого из этих режимов аутентификации могут быть совершенно разными. Эта политика может быть представлена ​​в другом месте.

Источник

Чтобы дать графический ответ:

Вот как я бы это смоделировал.

counter объект обычно не нужен, так как это простой счетчик, и довольно очевидно, что остальные / приращения будут ссылаться на общий счетчик. Тоже нет реального <<flow>> к этому счетчику. Нестереотипная зависимость также будет достаточной.

Источник
Другие вопросы по тегам