Диаграмма конечного автомата по сравнению с диаграммой конечного автомата протокола

Я попытаюсь объяснить разницу очень просто: вы правы, UML определяет два типа State Machine:

1. Поведенческий

2. Протокол

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

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

Типичным примером конечной машины протокола из жизни может быть процесс запуска компьютера:

Представим рабочие состояния компьютера: Загрузка биоса, Загрузка ОС, Подготовлено. Вы не можете выполнить загрузку ОС до загрузки BIOS. Вы не можете выполнить свое приложение до загрузки ОС. Конечный автомат протокола будет иметь 3 состояния и два перехода. Переходы будут определять операции компьютера loadBios() перед загрузкой состояния BIOS, loadOS() между состояниями загрузки Bios и загрузки ОС.

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

Конечный автомат протокола — это конечный автомат, частный случай конечного автомата, применяемый к спецификации протокола.

• Конечный автомат UML определяет концепции, синтаксические правила и базовую семантику диаграмм состояний.
• В случае Конечного автомата протокола эта базовая семантика уточняется и помещается в этот конкретный технический контекст.

Таким образом, конечный автомат протокола представляет собой конкретное приложение простого конечного автомата UML для спецификации/моделирования протокола.

Возможно, вы захотите прочитать эту статью, чтобы узнать больше о машине состояний протокола и о том, как она использует машину состояний UML:

http://www.uml-diagrams.org/protocol-state-machine-diagrams.html

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

С этой точки зрения конечный автомат протокола подобен интерфейсу (он чисто абстрактен), а поведенческий конечный автомат подобен классу. Поведенческий конечный автомат может реализовать протокольный конечный автомат.

Дополнительные сведения, включая нетривиальный пример, ориентированный на доступ к базе данных, можно найти в статье Построение конечных автоматов протокола в UML 2, Майкл Джесси Чонолес и Джеймс А. Шардт.