Проектирование RUP/ICONIX. Второй этап

Содержание других частей.

Вторым этапом ICONIX является моделирование прецедентов. В существующий проект с моделями Sparx EA, в котором работали на первом этапе , надо добавить модель прецедентов.

Работа системы зависит от того, как к ней обращаются и что хотят добиться. В моделировании прецедентов двигаются снаружи внутрь: рассматривают внешних по отношению к системе актёров и те действия, которые эти актёры производят с системой. Подчеркну, что на прошлом этапе при создании модели предметной области движение было изнутри наружу: определяли ключевые объекты внутри системы и их отношения с объектами, с которыми они взаимодействуют. Начали мы с модели предметной области, со статической части, для того, чтобы в контексте этой статической части работать с динамической частью — с моделью прецедентов. При этом обновляться и уточняться при моделировании прецедентов могут обе модели если обнаружится, что забыли какие-то моменты.

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

Продумайте, какие имеются актёры, внешние по отношению к проектируемой системе, взаимодействующие с ней. В модели прецедентов создайте диаграмму прецедентов, добавьте туда своих актёров и связанные с ними прецеденты. Старайтесь называть прецеденты 1-2 словами, точно и емко. Подробные словесные описания в Sparx EA можно составлять при помощи описания словесных сценариев, связанных с этими прецедентами.

Подобно элементам модели предметной области, элементы модели прецедентов также надо делать с одной стороны ёмкими, а с другой повторно используемыми, атомарными. Некоторые варианты использования вашей системы могут повторно пригодиться при работе с несколькими разными актёрами. Переходы в один и тот же прецедент возможен из разных других прецедентов, и т.д.. Таким образом у вас образуется структура прецедентов, объединённая в модель. У каждого прецедента в модели будет словесное описание в виде сценария. Сценарии очень похожи на пользовательские требования. Если от заказчика у вас имеются материалы, содержащие такие требования — их как раз нужно структурировать при моделировании прецедентов.

Главный принцип при выявлении прецедентов — их тесная связь с будущим руководством пользователя. Связь каждого прецедента и соответствующим разделом будущего руководства должна быть очевидной. Модель прецедентов это та часть проекта системы, которая базируется на восприятии её пользователями. Таким образом если в проекте системы на этом этапе есть прототипы пользовательских интерфейсов, например в Figma, то это будет большим подспорьем. На этом этапе аналитик и дизайнер максимально продуктивны в проектировании как внешнего вида, так и поведения будущей системы и её программного обеспечения.

Сценарии в основе словесного описания прецедентов должны состоять из утверждений по форме «существительное-глагол-существительное». Вы уже наверняка догадались, что эти существительные — это классы модели предметной области, а глаголы это связи между ними. Если в ходе описания прецедентов появляются существительные, не описываемые какими-либо классами модели предметной области — уточняйте эту модель, внося туда классы и корректируя существующие. Со связями аналогично.

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

В модели прецедентов таким образом наберётся существенное количество прецедентов и связей между ними. То, каким образом можно корректно их связывать между собой через отношения включения или расширения UML — решать вам. Но выбрав один раз способ построения связей — не путайте этот способ с другими, например со связями типа вызова и предшествования, которые тоже будут в меню выбора типов связей. Далее прецеденты нужно будет объединить в пакеты, чтобы облегчить себе работу с ними. Хорошим кандидатом на помещение очередного прецедента в пакет с другими прецедентами будет прецедент, сильно связанный с остальными прецедентами из этого пакета.

Не стремитесь изобразить все прецеденты на одной диаграмме. Если система достаточно сложная, то различные её грани вариантов использования удобно располагать на различных диаграммах прецедентов. В идеале, каждый пакет прецедентов соответствует главе или разделу будущего руководства пользователя.

Для того, чтобы проверять взаимное соответствие модели предметной области и модели прецедентов, в Sparx EA есть инструмент под названием «матрица отношений», на которой можно просталвять связи между элементами как одной модели, так и элементами разных моделей. Таким образом матрица соответствия модели предметной области и модели прецедентов со связями типа «реализует» должна быть без пробелов по строкам и столбцам.

Переходить к следующему этапу проектирования следует только после того, как будут достигнуты цели модели прецедентов:

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

Вот распространённые ошибки в моделировании прецедентов.

Словесный сценарий прецедентов в стиле «существительное-глагол-существительное» это не функциональные требования. Объекты и взаимодействие между ними — вот что главное.
Сконцентрируйтесь на порядке использования, а не на атрибутах и методах. Не надо ссылаться на поля экранных форм. Детали с атрибутами и формами учитываются потом.
Не экономьте слов при описании прецедентов. Лучше описать слишком много, чем упустить что-то из виду.
Нельзя абстрагироваться от интерфейса пользователя. Если есть прототипы интерфейса — используйте их на 100%. Нет прототипов — нарисуйте схему сами.
Описывайте прецеденты строго с точки зрения пользователя (в действительности, актёра, т.к. пользователями тут могут быть и не люди вовсе).
В описании прецедентов не игнорируйте реакцию системы. Пользователи зачем-то обратились к системе — скорее всего для того, чтобы что-то получить. Это «что-то» и есть реакция системы, в том числе ошибки.
Повторюсь, не игнорируйте альтернативные последовательности сценариев.
И ещё раз повторюсь, один раз решите что использовать в UML — включение или расширение, и дальше придерживайтесь этого подхода. Не переходите между одним и другим. Потеряете время без пользы проекту.

PS: те из вас, кто хотел бы создать или укрепить свою компетенцию аналитиков — пожалуйста обращайтесь. Для вас хорошо подойдут эти услуги: раз, два, три, четыре.