Введение в ICONIX

Введение в ICONIX

Процесс ICONIX представляет собой нечто среднее между очень громоздким, но универсальным унифицированным процессом (Rational Unified Process - RUP) и весьма компактной методологией программирования еХtreme (ХР). Процесс ICONIX, как и RUP, основан на прецедентах, но не характеризуется множеством его недостатков, В этом процессе тоже применяется язык моделирования UML (Unified Modeling Language), однако основное внимание уделяется анализу требований. Отметим еще раз, что ICONIX, по представлению Айвара Джекобсона (Ivаг Jacobson), «основан на прецедентах», вот почему с помощью этого процесса создаются вполне конкретные и простые для понимания прецеденты, которые легко использовать для разработки системы.

ICONIX вобрал в себя лучшие стороны трех методологий, разработанных в начале 90-х годов Айваром Джекобсоном, Джимом Рамбо (Jim Rumbaugh) и Грейди Бучем (Grady Booch), называющими себя «три амиго». Мы пользуемся подмножеством языка UML, отобранным в результате проведенного анализа этих методологий.

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

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

При моделировании предметной области мы хотим выявить наиболее важные абстракции, описывающие пространство задачи или, что то же самое, предметную область создаваемой системы. Для этого воспользуемся методологией ОМТ (Object Modelaig Technique), разработанной Джимом Рамбо, в которой очень подробно рассматриваются разные полезные приемы, применяемые при создании модели предметной области.

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

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

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

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