Проектирование RUP/ICONIX. 4-ый этап - Антикризисный ларец

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

Этап 4 начинает вторую веху проектирования после первой вехи, где подготовили требования. Вторая веха называется «предварительный проект». И начинается он — с анализа пригодности, 4-го этапа проектирования.

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

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

Диаграммы пригодности — это по существу диаграммы классов UML, но с проставленными стереотипами классов. Классы классифицируются по 3 видам:

граничные: с объектами этих классов взаимодействуют актёры для вхаимодействия с проектируемой системой;
сущностные: объекты этих классов обычно фигурируют прямо в предметной области один в один, это либо классы источники информации, либо классы стоки информации, либо и то, и другое; часто это классы т.н. модели данных;
управляющие: нужны для обеспечения корректной передачи управления от граничных к сущностным объектам, их ещё называют контроллерами.

Анализ пригодности служит звеном, позволяющим переходить от вопросов «что» к вопросам «как». В вехе предварительного проектирования ICONIX уже начинают задумываться о возможных альтернативных стратегиях реализации и архитектурах, выбор которых зависит от применяемых технологий. Выбор ещё не осуществлён, но анализ пригодности сужает поиск и подсказывает с выбором. В ходе анализа пригодности мы в прецедентах уже имеем описания сценариев, изложенных с учётом требований заказчика. В ходе анализа пригодности уточняются и тексты прецедентов, и модель предметой области. Классификация объектов на граничные, сущностные и управляющие может заставить добавить недостающие классы. Анализ пригодности связывает объекты, но уже накладывает ограничения на связи. Далее это сильно поможет при проектировании последовательностей в окончательном проекте.

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

Актёры могут взаимодействовать только с граничными объектами.
Граничные объекты могут общаться только с контроллерами и актёрами.
Сущностные объекты могут общаться только с контроллерами.
Контроллеры могут общаться со всеми, кроме актёров.

Граничные и сущностные объекты надо называть существительными, а контроллеры — глаголами. Таким образом правила легче запомнить как «существительные не общаются с сущетвительными напрямую, только через глаголы».

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

В ходе анализа пригодности часто совершают следующие ошибки.

Нарушают правила взаимодействия объектов, описанные выше.
Не меняют тексты прецедентов в ходе анализа. Правила взаимодействия объектов должны коснуться и самих текстов прецедентов, т.к. объекты и их взаимодейсвтия реализуют сценарии прецедента.
Игнорируют альтернативные сценарии прецедентов в анализе пригодности. Альтернативные сценарии надо реализовывать так же, как и основные. Это порядок реакции на ошибки и т.п..
Имена классов модели пригодности и тексты прецедентов не согласуются.
На этапе анализа пригодности нет достаточной информации для выделения методов, которые нужны классам. Не надо указывать методы у классов на этом этапе. Это делается позже.
Если на диаграмме пригодности для прецедента становится слишком много контроллеров (более 10), то прецедент получился слишком большой, и его надо делить на несколько. Если контроллеров мало, один или два, значит прецедент недостаточно обусловлен, как отдельный, и надо его отнести к какому-то существующему. Либо прецедент недостаточно проанализирован.
Зацикливаются на диаграммах пригодности и пытаются всё дальнейшее проектирование провести на них. Повторимся, для анализа операций и выделения методов классов пока недостаточно информации. Кто с кем объается это ещё не методы.
Не выполняют сверку диаграммы пригодности и текстов прецедента.
Ленятся обновлять статическую модель. Не добавляют новых классов на диаграммы классов, модель предметной области идёт вразнобой с анализом пригодности, т.е. становится непригодной.

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

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