Introduction to the ICONIX Process of Software Modeling

Doug Rosenberg, Kendall Scott

http://www.informit.com/articles/article.aspx?p=167902

Если Rational Unified Process покажется Вам слишком громоздким, а экстремальное программирование слишком простым, попробуйте золотую середину — ICONIX.

Методология разработки ICONIX находится где-то посередине между очень сложной RUP (Rational Unified Process) и очень простой — XP (eXtreme Programming). ICONIX, как и RUP, предполагает разработку через варианты использования, но её отличие в том, что она избавлена от множества накладных расходов, сопутствующих применению RUP и в то же время так же легковесна, как и XP. ICONIX основана на рациональном использовании UML и уделяет пристальное внимание к трассируемости требований.

Описываемый здесь подход вобрал в себя лучшее из трех общеизвестных методологий разработки, увидивших свет в начале 90-ых годов благодаря Ивару Якобсону, Джиму Рамбо и Гради Бучу. Подход использует подмножество UML, основанное на анализе анализе Дага этих трёх методологий.

«Вы можете смоделировать 80% всех задач, используя 20% средств UML» – пишут сами авторы в своей книге «The Unified Modelling Language User Guide» (глава 32). Ирония в том, что в книге не указано, про какие 20 процентов языка идёт речь. Подмножество языка UML, используемое в ICONIX, состоит из ключевых средств, пригодных для большей части работ по созданию моделей. Также часть этой книги посвещена тому, где взять другие элементы UML, как ими пользоваться и где применить.

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

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

В этом разделе авторы пытаются продемонстрировать, как добраться от контрольной точки А до контрольной точки назначения Б за кратчайшее возможное время. (В действительности они не ставили цели продираться через все тернии к звёздам на пути к коду, но приблизиться к ним настолько, чтобы читатели их ощутили). О точке А можно думать, как о некоем состоянии, в котором известно, что система должна уметь делать и какие предполагаются примерные варианты использования этой системы. В свою очередь, точка Б будет представлять собой нечто завершённое, протестированное и работающее, причем работающее так, как в действительности оно и ожидалось. Эта книга посвещена тому, как перейти от неопределённого состояния «Мне кажется, оно должно работать как-то так» к однозначной, завершённой и строгой постановке задачи, позволяющей разработать надёжную архитектуру и чистый код. Далее будут рассмотрены шаги в обратном порядке, начиная с кода и будет объяснено, почему предложенный набор шагов достаточен для закрытия пустоты между вариантами использования и кодом.

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

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

Далее рассматривается переход от вариантов использования к диаграммам последовательностей. Особенность этого перехода в том, что варианты использования по сути являют собой требования к системе, а диаграмма последовательностей находится на следующем уровне — уровне высокодетализированного дизайна.

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

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

Следует пытаться описать сценарии использования системы в контексте объектной модели. Откуда же ей взяться? Предполагается, что на входе имеется модель предметной области, состоящая из объектов и отношений между ними. Саму объектную модель авторы рекомендую строить по методологии OMT (Object Modeling Technique).

В диаграмме устойчивости также используется понятие граничных объектов. Граничными объектами могут быть, например, пользовательские интерфейсы, служащие посредником между пользователем и объектами предметной области.

Одно из отличий описываемого в этой книге процесса разработки в том, что он начинается с составления предметной области. Создание вариантов использования на основе множества существительных из предметной области позволяет однозначно вывести ряд терминов, на которые можно опираться при составлении текстового описания вариантов использования. Это особенно полезно в случае, когда разные части команды работают над разными частями системы. Принятие общего для всех частей набора терминов обеспечивает ясность создаваемых моделей и их безболезненную сшивку на границах. В терминах UML модель предметной области это диаграмма классов со слабой детализацией (отсутствуют атрибуты и операции). Это вызвано необходимостью обобщённого взгляда на систему на данном этапе проектирования.

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

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

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

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

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

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

За время развития процесса разработки ICONIX сформировался ряд характерных для него вопросов, ответы на которые ищутся во время применения этого процесса:

• Кто является пользователями системы и что они пытаются сделать?
• Каковы объекты реального мира (предметной области) и отношения между ними?
• Какие объекты нужны для каждого варианта использования?
• Как взаимодействуют объекты в рамках варианта использования?
• Как будет организовано управление системой?
• Как будет устроена низкоуровневая часть системы?
• Касательно этих вопросов стоит понимать, что они не являются строго обязательными. Многие проекты утратили себя попытках придерживаться жестких ограничений, поэтому всегда следовать одной и той же фиксированной схеме не имеет смысла. С другой стороны отсутствие ответов на эти вопросы повышает риски того, что в будущем придется возвращаться назад и что-то менять.

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

• Выявлены и описаны все варианты использования системы
• Произведён тщательный поиск многократно используемых абстракций, участвующих в нескольких сценариях
• Определена предметная область задачи и проработана возможность повторного использования системы
• В дизайне учтены все функциональные требования системы
• Была продумана связь поведения системы с обозначенными абстракциями и учтены общие принципы проектирования, такие как слабая связанность, сильная согласованность, обобщения, достаточность и т. д.

Помимо этих контрольных точек можно выделить следующие фундаментальные требования к процессу разработки:

1. Гибкость, позволяющая подстроиться под разные виды задач
2. Поддержка используемой личным составом практики работы
3. Удобство в освоении менее опытными членами команды
4. Возможность демонстрации результатов разработки в единообразной обобщённой форме

Описанная методология разработки предполагает собой комбинацию легковесности XP и рациональности RUP. Отличительной особенностью данного процесса является выделение ключевой части средств UML — 4 вида диаграмм (вариантов использования, устойчивости, последовательностей, классов) — для эффективного применения в разработке. В статье объясняется, как организовать процесс разработки, отталкиваясь от постановки требований и заканчивая написанием программного кода. Описанный подход является гибким и не требует строгого следования ему, лишь синхронизации в небольшом количестве контрольных точек.