Процесс ICONIX

Одним из вариантов гибкого анализа требований (и частично моделирования) является использование и адаптация процесса ICONIX.

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

Сам процесс разработки продукта в ICONIX носит практически водопадный характер, поэтому его необходимо адаптировать для итеративной методологии, к которой относится Scrum.

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

На первом этапе происходит анализ вариантов использования, который является своеобразным аналогом построения карт историй.

ICONIX – подмножество UML

Структура процесса ICONIX

Диаграмма вариантов использования

Здесь отображаются роли пользователей (персоны из карт историй) и варианты применения, которые фактически являются более тяжеловесным вариантом историй пользователей. Обратите внимание на стереотипы «Эпик» и «Тема», которыми обозначены два варианта использования.

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

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

Диаграмма предметной области

Диаграмма классов

Для примера разберем один из вариантов использования и опишем его более подробно в виде диаграммы робастности, на которой будут отражены:

• граничные объекты – интерфейс взаимодействия с пользователями;

• котроллеры – бизнес-логика и различные алгоритмы;

• сущности – данные приложения.

Можно заметить, что данная диаграмма очень похожа на шаблон проектирования Model-View-Controller.

Диаграмма робастности

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

Диаграмма робастности нужна, чтобы:

• осуществить проверку полноты вариантов использования;

• выявить дополнительные объекты;

• проработать архитектуру на высоком уровне.

Последний пункт очень важен, ведь между анализом и архитектурой существует практически пропасть, которую эта диаграмма призвана заполнить.

Пропасть между анализом и архитектурой

После такого анализа можно описать подробности алгоритма или логики в диаграмме последовательности.

Диаграмма последовательности