Основные концепции и укрупненная схема процесса ICONIX. Классы анализа и базовые правила их взаимодействия. (201, 205)

Процесс ICONIX представляет собой нечто среднее между очень громоздким рациональным унифицированным процессом RUP (Rational Unified Process) и весьма компактной методологией программирования XP (eXtreme Programming). Процесс ICONIX, как и RUP, основан на вариантах использования, но не характеризуется множеством его недостатков. В этом процессе тоже применяется язык моделирования UML, однако основное внимание уделяется анализу и контролю требований. В главе 32 руководства по языку UML [4] говорится: “ 80% всех задач можно моделировать с помощью 20% UML ”. Однако в книге не говорится о том, что это за 20%. Процесс ICONIX включает базовую нотацию (минимальное подмножество UML), которую должно хватить для большинства моделей.

Исходной информацией в процессе ICONIX являются представления о том, что должна делать система в виде прототипа графического интерфейса пользователя и некоторых выявленных сценариев или моделей вариантов использования. После этого можно приступать к анализу и проектированию. Говоря об уровне проектирования, следует иметь в виду такой уровень детализации, при котором полученная диаграмма классов может служить шаблоном для создания кода; она должна точно отражать организацию будущей программы. Таким образом, надо решить основную проблему – каким-то образом перейти от вариантов использования к диаграммам классов уровня проектирования.

 

Рис. 6.17. Укрупненная схема процесса ICONIX

 

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

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

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

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

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

На следующем шаге уточняем структуру программы. Этот подход, на 80% заимствованный из работы Айвара Якобсона [22,19], позволяет разбить систему на части, определяемые границами вариантов использования, после чего результаты анализа вариантов использования используются для перехода на достаточно детальный для кодирования уровень объектной модели, то есть на уровень статической модели.

 

29. Анализ пригодности: цель, элементы анализа пригодности, связь между анализом и проектированием, пример использования анализа пригодности для варианта использования "Оформить заказ" книжного интернет-магазина. (208, 213)

Цель анализа пригодности (предварительного проектирования) – выявить объекты и распределить поведение по этим объектам. Для выявления объектов, а следовательно, и классов системы применяется техника анализа пригодности, разработанная А.Якобсоном.

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

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

· сущностные объекты () – обычно доменные объекты предметной области;

· управляющие объекты () - обычно называемыми контроллерами, так как им ничего не соответствует в реальном мире, выполняющие функции «клея» между граничными и сущностными объектами.

·

· Рис. 6.18. Связь между анализом и проектированием