Методология разработки программного обеспечения RUP (Rational Unified Process)

Технология RUP

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

RUP постоянно развивается на основе единой базы знаний, пополняемой через интернет. Это – полезный инструмент, применимый к широкому спектру разрабатываемых приложений.

Отличительные черты RUP

• RUP – это итеративный процесс (Controlled Interactive);
• Предполагает сквозное применение аппарата Use Cases (Use Case Driven);
• Особое внимание уделяется разработке архитектуры (Architecture Centric);
• Включает управление требованиями и изменениями (Requirements Configuration and Change Management);
• Опирается на КБ концепцию разработки ПС (Component Based Development).
• Базируется на визуальном моделировании (Visual Modeling Techniques);

RUP предлагает итерационный подход к проектированию и разработке ПС, основанный на  спиральном  жизненном цикле . Весь жизненный цикл включает четыре фазы – вхождение в проект (исследование), развитие (уточнение плана), конструирование и развертывание.

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

Преимущества

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

• Итеративный подход способствует более полному повторному использованию программных элементов. Анализ результатов каждой итерации позволяет архитекторам ПС выделить фрагменты, потенциально подлежащие повторному использованию, а в следующей итерации оформить их как повторно используемые коды. Это свойство очень хорошо сочетается с идеями ОО и КБ проектирования.

RUP – процесс, направляемый вариантами использования

• Понятие use case, введенное в языке UML, является основой для выполнения всех этапов жизненного цикла, рассматриваемых в RUP. Понятие «business use case» (вид деятельности) является ключевым при бизнес-анализе .

На этапах анализа требований, проектирования и реализации use cases выступают в качестве вариантов использования системы (ВИ), При анализе требований, выделив ВИ, тем самым определяется требование или уровень иерархии требований к ПС. При детализации ВИ определяются объекты, и способы их взаимодействия, которые должны быть реализованы в программном коде.

Особую роль ВИ играют в планировании итераций. Чтобы определить, какая функциональность должна быть реализована в очередной итерациииспользуют диаграммы ВИ. Каждому ВИ можно приписать приоритет, определяющий, в какой итерации его следует реализовать. Можно показать все ВИ, реализуемые в очередной итерации, на отдельной диаграмме (или нескольких диаграммах).

RUP – процесс, основанный на архитектуре

Разработка архитектуры ПС в RUP преследует следующие цели:

• Описание организации ПС;
• Определение компонентов и их интерфейсов;
• Определение подсистем и объединение компонентов в подсистемы;
• Создание основы для повторного использования компонентов;
• Создание базиса для разработки;
• Контроль над проектом и поддержка целостности системы.

Архитектура ПС находит отражение в различных  архитектурных представлениях .

Логическое представление  отражает функциональные требования к системе. Оно определяет основные (архитектурно значимые) пакеты, подсистемы и классы проекта.

Реализационное представление  описывает организацию статических программных модулей (компонентов, файлов данных, исходного кода и др.) в терминах пакетов и уровней

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

Представление развертывания   показывает, как компоненты отображаются на базовые платформы и вычислительные узлы.

Use case представление   содержит ключевые ВИ и сценарии.

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

• Классы, моделирующие основные объекты деятельности;
• Механизмы, определяющие поведение этих классов;
• Уровни и подсистемы;
• Интерфейсы;

Основные процессы и управляющие потоки.

В RUP предусмотрено создание отдельного документа, содержащего описание архитектуры ПС.

Технологические процессы в RUP

В RUP определено 9  технологических процессов , для каждого из которых предложена методика выполнения. Технологические процессы делятся на две категории – основные процессы и процессы поддержки. К основным относятся:

• Бизнес-анализ,
• Управление требованиями,
• Анализ и проектирование,
• Реализация,
• Тестирование,
• Развертывание.

Вспомогательные  процессы включают: управление проектом, управление конфигурацией, управление средой.

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

RUP. Обследование организации (бизнес-анализ)

Цели

Цели бизнес-анализа заключаются в следующем:

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

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

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

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

Единственное дополнение состоит в том, что в модели бизнеса должны присутствовать  бизнес-исполнители  – специалисты обследуемой организации, отвечающие за выполнение тех или иных работ.

Роли

В моделировании бизнеса участвуют:

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

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

Артефакты

При моделировании создаются следующие артефакты в виде текстовых документов и моделей, описанных на UML:

• Документ «Видение бизнеса» – определяет цели проведение бизнес-анализа.
• Структура организации – статическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.
• Модель видов деятельности включает бизнес-актеров и виды деятельности организации.

• К числу бизнес-актеров относятся: заказчики, партнеры, поставщики, власти (представители закона, инспекция и др.), дочерние организации, собственники и инвесторы, внешние информационные системы
• Бизнес-актеры помогают определить границы организации, которую требуется описать. Виды деятельности представляют собой бизнес-процессы. Модель видов деятельности представляется с помощью use case диаграмм.
• Объектная модель включает бизнес-актеров, бизнес-исполнителей и бизнес-сущности, а также содержит описание их взаимодействий при реализации видов деятельности. Модель представляется на UML с помощью диаграмм классов и взаимодействий (последовательностей, коопераций, деятельностей), которые иногда называют технологическими сценариями.

• Модель предметной области является подмножеством объектной модели. Она описывает основные бизнес-сущности и связи между ними. Эта модель представляется в виде диаграмм классов.
• Глоссарий – текстовый документ, содержащий определения основных понятий, используемых в данном бизнесе.
• Оценка деятельности организации – текстовый документ, описывающий текущее состояние организации, в которой будет использоваться ПС.
• Бизнес-правила – текстовый документ, определяющий условия и ограничения, которым должен удовлетворять бизнес.
• Дополнительные спецификации – текстовый документ, содержащий описание свойств бизнеса, не включенных в бизнес-модель.

Процесс

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

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

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

Созданная в итоге бизнес-модель является основой для последующего моделирования ПС.

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

Откуда берутся требования к системе?

Один источник требований – это бизнес-анализ, проводимый в начальной фазе проекта. Вторым таким источником являются ПС, эксплуатируемые в организации. Разработка современных ПС редко когда начинается "с нуля". Чаще всего у заказчика имеется работающая (наследуемая) система, для которой требуется расширить состав выполняемых функций, перевести ее на другую, более современную платформу, обеспечить доступ через интернет, повысить производительность и т. д. При этом типичной является ситуация, когда наследуемая система плохо документирована (нет моделей и описания, частично или полностью отсутствуют исходные коды программ, устарела пользовательская документация и др.). В этом случае прежде чем браться за разработку новой системы, необходимо документировать наследуемую. В терминах RUP это означает, что необходимо построение модели, описывающей ПС с различных точек зрения.

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