Роль нотации
Нотация является важной составляющей любой модели - она служит связующим звеном между процессами. "Нотация выполняет три функции:
является языком для описания взаимодействий, которые неочевидны или не могут быть получены непосредственно из кода;
обеспечивает достаточную семантику, позволяющую охватить важные стратегические и тактические решения;
предлагает конкретную форму, помогающую человеку рассуждать о предметной области, а средствам моделирования воплощать описанные идеи".
Унифицированный язык моделирования (Unified Modeling Language - UML) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию. Определенные элементы нотации (например, классы, связи, агрегаты, наследование) используются на этапе анализа. Другие элементы (индикаторы реализации и свойства) вводятся на стадии проектирования.
История UML
В 90-е годы появилось большое количество различных методологий с собственными наборами нотаций. Самые популярные - ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону). Каждая из них имела свои преимущества. Методика ОМТ отличалась хорошими средствами анализа и слабыми сторонами в проектировании, а методика Booch 1991, наоборот, более подходила для проектирования, чем для анализа. В методике OOSE основное внимание уделено развитым средствам поведенческого анализа, а в других областях отмечено много недостатков.
Спустя некоторое время Буч опубликовал второе издание, в котором собрал лучшие идеи и решения в области анализа, предлагавшиеся в том числе Рамбо и Джекобсоном. В свою очередь, Рамбо написал серию статей, известных как методика ОМТ-2, куда вошли предложения Буча в области проектирования. Перечисленные методики были достаточно похожи, но отличались разными нотациями - один и тот же символ имел в них различные значения. Например, закрашенный круг был индикатором множественности в методике ОМТ и символом агрегата в нотации Буча. Вы, наверное, слышали фразу "война методов", употреблявшуюся в период, когда класс обозначался либо в виде облака, либо в виде прямоугольника? Трудно понять, что же лучше.
Конец войне методов положила нотация, принятая в языке UML. "Язык UML служит для определения, отображения и описания элементов объектно-ориентированных систем в процессе их создания. Он объединяет объектную модель, нотации Буча и ОМТ, а также лучшие идеи, предложенные авторами других методик (рис. 1.2). Таким образом, язык UML является стандартом де-факто в области объектно-ориентированного анализа и проектирования".
Универсальный язык UML - это попытка стандартизировать инструменты анализа и проектирования семантических моделей, синтаксических нотаций и диаграмм. Первая общедоступная версия (0.8) появилась в октябре 1995 года. Джекобсон и другие разработчики предложили несколько вариантов, которые были реализованы в последующих двух версиях (0.9 - в июле и 0.91 - в октябре 1996 года). Версия 1.0 была представлена для стандартизации в ассоциацию Object Management Group (OMG) в июле 1997 года. Дополнительные улучшения сделаны в версии 1.1, которая вышла в сентябре того же года, а в ноябре UML был утвержден ассоциацией OMG в качестве стандартного языка моделирования.
Рис. 1.2. Составные части языка UМL
Роль процессов
Успешно разработанный проект удовлетворяет или превосходит ожидание заказчика, выполняется в срок с оптимальными затратами и может быть адаптирован к изменению условий. Жизненный цикл разработки должен способствовать творческим и новаторским идеям. В то же время для своевременного завершения процесс разработки должен контролироваться. "Творчество естественно для создания всех хорошо структурированных объектно-ориентированных архитектур, но если разработчиков не контролировать, то они, возможно, никогда не достигнут конечного результата. Значит, для эффективной работы коллектива нужна дисциплина. Но слишком жесткая дисциплина приводит к развитию бюрократии, которая, в свою очередь, душит новаторские идеи". Правильно управляемый итеративный и инкрементальный жизненный цикл обеспечивает необходимый контроль и поддерживает творческий процесс на нужном уровне.
Что такое итеративная и инкрементальная разработка
В итеративном и инкрементальном жизненном цикле (см. рис. 1.3) разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса: построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение. Разработчики допускают, что не все требования к системе известны в начале жизненного цикла. Корректировки возможны на любом этапе.
Рис. 1.3. Итеративная и инкрементальная разработка
Такой тип жизненного цикла позволяет уменьшить риск. Технические риски оцениваются и группируются по приоритетам на ранней стадии цикла и корректируются во время разработки каждой версии. Риски закреплены за каждой версией таким образом, что успешное завершение версии уменьшает риск, закрепленный за ней. Процесс планируется так, чтобы наибольшие риски были рассмотрены в первую очередь. Построение системы подобным образом выявляет и уменьшает риски на раннем этапе жизненного цикла. Результат такой модели жизненного цикла - уменьшение риска и затрат.
Методология Rational Unified Process
Для поддержки управления итеративным и инкрементальным жизненным циклом разработки используется методика Rational Unified Process, с помощью которой можно подробно описать технические и организационные аспекты создания программного обеспечения на стадиях определения требований к системе, анализа и проектирования.
Методология Rational Unified Process структурирована в двух направлениях:
время (разделение жизненного цикла на фазы и версии);
компоненты процесса (создание необходимого набора средств для выполнения четко определенных задач).
Оба направления должны быть хорошо проработаны для получения успешного проекта.
Работа над проектом состоит из следующих временных этапов:
задумка (inception) - определение общей идеи проекта;
проработка (elaboration) - планирование необходимых работ и ресурсов, указание особенностей и создание архитектуры;
создание (construction) - построение продукта при помощи серии последовательных версий;
переходный период (transition) - поставка продукта пользователям (производство, распространение, обучение).
В разрезе компонентов процесс делится на следующие стадии:
построение бизнес-модели (business modeling) - определение необходимых возможностей системы и потребностей пользователей;
определение требований к системе (requirements) - изложение общей идеи системы совместно с функциональными и нефункциональными условиями ее работы;
анализ (analysis) и проектирование (design) - описание способов исполнения системы на этапе реализации;
реализация (implementation) - кодирование и генерация работающих программных модулей системы;
тестирование (test) - проверка функционирования системы;
внедрение (deployment) - поставка системы конечным пользователям и их обучение.
Каждая стадия в разрезе компонентов процесса обычно применяется к конкретной фазе временного направления (см. рис. 1.4.). Однако степень применения каждого компонента зависит от этапа разработки. Например, вы можете испытать концептуальный прототип системы на стадии задумки, и тогда вам потребуется не только определение требований - необходимо будет провести анализ, проектирование, реализацию и тестирование, чтобы завершить создание прототипа. Важность анализа выявляется на этапе проработки.