#uml #requirements #state-diagram
Вопрос:
Имейте диаграмму состояния UML, описывающую поведение системы, показывая взаимодействие пользователя и системы для выполнения варианта использования. Эта схема используется в качестве соглашения (требования) с разработчиками системы.
Когда пользователь запрашивает вариант использования, система запрашивает информацию у пользователя и показывает сообщения об ошибках, если информация неверна. Система также аутентифицирует пользователя и показывает ему ошибку, если он не аутентифицирован.
Но не имеет значения, какое действие выполняется в первую очередь. Это то, какая ошибка, информация или ошибка аутентификации отображается первой. Мы хотим четко дать понять разработчикам, что порядок действий не имеет значения, хотя все действия должны быть выполнены. Как мы этого достигаем? Я думаю, что элемент «вилка» на диаграмме состояний предназначен для этого?
Комментарии:
1. В случаях использования нет порядка. Действия-это сценарии в вариантах использования и подробные сведения о том, в каком порядке выполняются действия. Диаграмма состояний описывает поведение определенного элемента (класса, компонента, узла, чего угодно).
2. Прецедент-это последовательность действий, включая ее вариации, между конкретным субъектом и системой, которая дает наблюдаемый результат, представляющий ценность для этого субъекта. Схема вариантов использования свяжите субъекта с вариантом использования (с именем варианта использования). Спецификация варианта использования может быть передана с помощью диаграммы состояний, содержащей состояния и действия, которые выполняют изменение состояния. Конечно, на диаграмме состояний существует упорядоченная последовательность действий от начального состояния до конечного состояния, ищите диаграмму состояний в любой поисковой системе.
3. UC описывается n действиями для различных сценариев. Каждое действие содержит m действий, в которых вы определяете порядок, в котором они выполняются по некоторой логике. Вы делаете это с помощью диаграмм активности. Использование государственной машины было бы, ну, странно. Но, может быть, у вас есть для этого UC?
Ответ №1:
Похоже, вы путаете диаграмму состояния с диаграммой активности (и, возможно, также диаграммой последовательности). У последнего есть вилка (и на диаграмме последовательности есть способ показать, что события происходят параллельно).
Диаграмма конечного автомата действительно показывает изменения состояния и его триггеров, но не является основной диаграммой для отображения связанных действий или их потока. Более того, на весь конечный автомат сущности обычно влияет более чем одна история пользователя. Другими словами, триггеры изменения состояния могут быть вызваны различными вариантами использования. Таким образом, государственная машина находится в нескольких пользовательских историях, а не описывает только одну.
Если вы попытаетесь документировать поток вариантов использования с помощью диаграммы конечного автомата, вы, скорее всего, делаете это неправильно.
Комментарии:
1. Диаграммы состояния и активности эквивалентны. У обоих есть состояния и виды деятельности. Разница в том, что стрелки на диаграмме состояний-это действия, а квадраты-состояния, прямо противоположные диаграмме действий. И диаграмма состояния имеет вилку ( uml-diagrams.org/state-machine-diagrams.html# ).
2. Я не понимаю, что означает «вся государственная машина сущности, на которую влияет нечто большее, чем история пользователя». Вариант использования-это взаимодействие между действующим лицом и системой в виде черного ящика и его общая схема состояний для указания варианта использования. Для данного случая использования действия переходят из начального состояния в конечное состояние, имея промежуточные состояния между этими действиями. Действия, такие как пользователь запрашивает систему для выполнения варианта использования, затем система запрашивает информацию у пользователя, затем пользователь заполняет информацию, затем система отображает сообщение пользователю, подтверждающее операцию.
3. Описание взаимодействия между субъектом и системой заключается в определении варианта использования. И для этого вы можете использовать диаграмму состояний. Это взаимодействие имеет действия (система запрашивает некоторую информацию у пользователя или отображает некоторую информацию пользователю…), и поэтому у вас есть состояния между этими действиями (отображаемая информация, запрашиваемая информация…).
4. Тот факт, что вы можете представлять состояния и действия как на диаграммах состояний, так и на диаграммах действий, не делает их эквивалентными. У вас совершенно другой фокус и уровень детализации. Государственная машина не отображает подробные сведения о действиях, вы не можете разложить имеющуюся там деятельность на более подробные действия (и если вы попытаетесь, вы не сможете отобразить всю соответствующую логику). Кроме того, стрелки на диаграммах государственных машин не являются действиями, это переходы . Действие может быть выполнено во время перехода, но не обязательно.
5. Машина состояний предназначена для отображения всего жизненного цикла объекта и того, как его статусы меняются с течением времени. Теперь, хотя есть некоторые объекты, которые создаются и уничтожаются во время одного случая использования, они являются скорее исключением, чем правилом. Даже типичные примеры использования типа CRUD указывают на то, что в UC есть один для создания, другой для обновления, еще один для удаления объекта и так далее. Конечный автомат этого объекта должен отображать создание, обновление (не всегда) и удаление на одной диаграмме. Возьмем, к примеру, заказ в интернет-магазине.