28. Основные концепции и укрупненная схема процесса 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. Связь между анализом и проектированием
Основные элементы анализа пригодности
Анализ пригодности выполняет следующие задачи в процессе ICONIX:
является средством контроля на отсутствие в текстах вариантов использования тривиальных ошибок, помогая удостовериться в том, что тексты вариантов использования корректны и нет ошибок описания поведения системы. Такое уточнение текста меняет природу варианта использования: если раньше вариант использования выступал в роли руководства пользователя, то теперь становится описанием порядка применения в контексте объектной модели;
является средством проверки полноты и правильности, давая уверенность в том, что в вариантах использования описаны все необходимые альтернативные последовательности событий;
позволяет обнаруживать новые объекты, пропущенные на этапе моделирования предметной области. Корректировать спецификации классов, а также выявлять граничные и сущностные классы до рисования диаграмм последовательности;
выполняет функции предварительного проектирования.
Анализ пригодности для варианта использования выполняется путем исследования его текста, акторов, граничных и сущностных объектов и контроллеров, а также связей между различными элементами на диаграмме.