Введение в 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). Важно добиться стабильного и правильного описания еще на этапе предварительного проектирования до того, как мы приступим к созданию детального проекта, изображаемого на диаграммах последовательности.

 

Требования к книжному Internet-магазину

Сформулируем их: книжный магазин должен принимать заказы через Internet; книжный магазин должен поддерживать до миллиона счетов клиентов; …  

Основные элементы моделирования прецедентов

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

Готовая диаграмма прецедентов

На рис. 3.2 показана полная диаграмма прецедентов для книжного Internet-магазина. В частности, на ней присутствуют и прецеденты, которые упоминались в упражнениях, и задействованные в них актеры.

Анализ пригодности

Диаграмма пригодности (Robustness Diagram) напоминает диаграмму кооперации из UML: на ней изображены объекты (точнее – классы), участвующие в… Создавая язык UML, «три амиго» знали о существовании этой техники, но не… По существу, диаграмма пригодности в UML - это диаграмма классов, хотя в оригинальной концепции Джекобсона она была…

Основные элементы анализа пригодности

Теперь подробно рассмотрим три стереотипа, применяемые к объектам на этапе анализа пригодности: · граничные объекты - это такие объекты, с которыми непосредственно…

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

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

Основные элементы диаграмм последовательности

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

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

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

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

2. Добавьте сущностные объекты, представленные на диаграмме пригодности. Каждый «з них - это экземпляр некоторого класса, изображенного на диаграмме классов в статической модели. (Если вы забыли обновить статические диаграммы классов сразу после обнаружения новых объектов на этапе анализа пригодности, сделайте это сейчас. У этих объектов уже должна быть проставлена большая часть атрибутов. Многие из них будут выступать в качестве данных, передаваемых другим объектам.) Можно надеяться, что пропущенные атрибуты вы обнаружите по ходу работы над диаграммой последовательности. Не забудьте добавить их в статическую модель, так как, во всей вероятности, это последний шаг перед написанием кода.

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

Если вы придерживаетесь методологии ICQNIX, то первые три шага должны выполняться механически,(На самом деле нам удалось свести их к программе, которая создает основу диаграммы носледователь-ности. Если вы пользуетесь программой Rational Rose, то.можете загрузить написанный для нее сценарий со страницы http://www. iconjxsw.com/RoseSeripts.html. Похожие средства разрабатываются и для других иструментальных систем, например GDPro компании Embarcadero и Together/J компании TogetberSoft.) Такого рода средства автоматизации очень воодушевляют, если вы серьезно относитесь к проектированию.

4. Определите, какие методыи в какие классы поместить - это суть моделирования взаимодействий;

Распределение методов по классам предполагает, в частности, преобразование контроллеров; изображенных на диаграммах пригодности, в методы и сообщения, реализующие нужное поведение. (Кстати, контроллер можно превратить и в настоящий управляющий объект.) В связи с этим мы рекомендуем использовать диаграмму пригодности как контрольный список, дабы убедиться, что на диаграммах последовательности учтены все требования к поведению системы. Вы просто вычеркиваете управляющий, объект по мере того, как соответствующие ему сообщения наносятся на диаграммы последовательности. Таким образом, вы избавите себя от ошибок типа «ой, про эту функцию я и позабыл», которые проявляются в самый неподходящий момент. Заметим, что один контроллер на диаграмме пригодности может транслироваться в несколько методов на диаграмме последовательности.

Существует два метода преобразования контроллеров: управление на экране и контроллер прецедента. Если вы последовательно придерживаетесь того или иного, подхода при составлении диаграмм последовательности для всех прецедентов, то можно сказать что вы пользуетесь паттернами. Идея в том, чтобы все члены коллектива, отвечающие за диаграммы, определили еще на ранних стадиях работы некие стандарты и следовали им при рассмотрении всех прецедентов.

Теперь взглянем на проблему с другой стороны. При моделировании взаимодействий между различными объектами большую пользу могут оказать стандартные паттерны, описанные, например, в книге Эриха Гаммы (Erich Gamma), Ричарда Хёлма (Richard Helm), Ральфа Джонсона (Ralph. Johnson) и Дзкона Влиесидеса (John Vlissides) «Design Patterns» (издательство Addison-Wesley; 1995)[1]. Возможно, вы сами разработаете новые паттерны для стандартизации решения задач, возникающих в нескольких прецедентах. Настало время обратиться к статической модели, отразить проектные решения на диаграммах классов, а затем нарисовать соответствующие диаграммы последовательности. Именно здесь и проявляется вся мощь объектно-ориентированяога проектирования.

Вы уже сверяли диаграммы пригодности; с текстами прецедентов. Сопоставление диаграмм последовательности и пригодности добавит уверенности, что вы проектируете то, что нужно пользователю.

[1] Русский перевод: «Паттерны проектирования» (Питер, ДМК, 2001)