Сергей Трофимов

Обновлено 14.04.2003

 

Уже после публикации первой версии статьи на сайте, мной были получены дополнительные  подробности от ICONIX Software Engineering, Inc,, которые и легли в основу обновления статьи.

Сергей Трофимов

Существуют различные процессы разработки программного обеспечения. Здесь уже рассматривался RUP и пока не рассматривался процесс Экстремального программирования (eХtreme Рrogramming) как альтернатива Rational Unified Process.

Где-то посередине этих полюсов и располагается процесс ICONIX, хотя, как считают разработчики, он все-таки несколько ближе к RUP.

ICONIX разработал Дуг Розенберг (Doug Rosenberg)  в компании ICONIX Software Engineering, Inc В большей степени процесс был разработан благодаря его личным качаствам, и его нелюбви к XP.

Хотя название процесса пишется прописными буквами, оно не является аббревиатурой как разъяснили мне в ICONIX Software. По их словам, этот процесс был создан даже раньше, чем UML получил широкое распространение. В то время, когда  UML только создавался усилиями "трех друзей" из Rational Software, пропагандировавших объектно-ориентированные методы разработки, Дуг  Розенберг создавал средство объектного моделирования - ObjectModeler. Он обнаружил, что люди, покупавшие его средство не всегда успешно могли его применить, поскольку  ObjectModeler требовал специального обучения для работы с ним. Особенно это касалось тех, кто только начинал работать с этим средством и плохо разбирался в объектных технологиях.

Розенберг стал проводить обучение компаний Объектно-ориентированному анализу и дизайну. За несколько лет до того, как был разработан UML, еще в 1992 году он  разработал собственный процесс и назвал его ICONIX, взяв все лучшее, из оригинальных методик Буча, Румбаха и Якобсона ( Booch, Rumbaugh, Jacobson).

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

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

ICONIX, как и RUP базируется на UML, однако создатели сознательно использует только 20%  типов UML диаграмм и в этом его основное отличие. Особенностью этого процесса, по словам автора, будет простое использование UML. Процесс ICONIX компактнее, легче в изучении и больше подходит для небольших проектов по сравнению с RUP.

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

Основные этапы процесса следующие:

• Анализ требований
• Предварительное проектирование
• Проектирование
• Реализация

Процесс основан на построении минимального количества моделей, которые отражают будущую систему. Это динамические и статические модели (см рис.).

На этапе анализа создаются модели прецедентов (Use Case), модель пользовательского интерфейса и модель сущностей предметной области.

На этапе предварительного проектирования создается диаграмма пригодности (Robustness Diagram). Также дополняется модель прецедентов и модель сущностей предметной области.

Диаграмма пригодности похожа на диаграмму кооперации (Collaboration Diagram), однако имеет существенное отличие, поскольку на ней изображаются не экземпляры, а классы со стереотипами «актер», «граничный объект», «сущность», «контроллер». Эта диаграмма, по мнению Розенберга, является связующим звеном между прецедентами и ответом на вопрос «что нужно» и классами и ответом на вопрос «как это сделать».

На этапе детального проектирования создается диаграмма  последовательности (Sequence Diagram) и создается диаграмма классов.

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

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

 Основные принципы процесса ICONIX:

1. Движемся внутри, отталкиваясь от требований пользователя.
2. Движемся наружу, отталкиваясь от основных абстракций предметной области.
3. Спускаемся вниз от высокоуровневых моделей к детальному проекту.

Процесс ICONIX полезен для ответа на следующие вопросы о системе:

• Каковы пользователи системы (актеры) и что они пытаются сделать;
• Что такое объекты "реального мира" (предметной области) и какие между ними ассоциации;
• Какие объекты участвуют в каждом прецеденте;
• Как учесть ограничения, налагаемые режимом реального времени;
• Как будет выглядеть система на самом нижнем уровне.