Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 12

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

Что такое Унифицированный процесс?И UP, и RUP моделируют кто, когда и что в процессе разработки программного обеспечения, но делают это немного поразному. Самая последняя версия RUP имеет некоторые отличия от UP в терминологиии синтаксисе, хотя семантика элементов процесса остается, по сути,прежней.На рис. 2.4 показано, каким пиктограммам RUP соответствуют пиктограммы UP, используемые в книге. Обратите внимание, что междупиктограммами RUP и оригинальными пиктограммами UP установлено отношение «trace» (след). В UML отношение «trace» является особымтипом зависимости между элементами модели, указывающим на то,что элементисточник отношения «trace» является результатом исторического развития элемента, на который указывает стрелка. Это идеальное описывает отношения между элементами моделей UP и RUP.Для моделирования SEPпонятия «кто» UP вводит концепцию исполнителя (worker).

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

2.4. Соответствие пиктограмм UP и RUP2.5. Настройка UP для вашего проекта55ными индивидуумами или командами. При осуществлении определенной деятельности эти индивидуумы или команды всегда будут прини+мать конкретные роли. Поэтому для любой деятельности UP (и RUP)может указать исполнителей (роли), участвующих в ней. В случае необходимости деятельности могут быть разбиты на более мелкие уровнидетализации. Артефакты – это сущности, являющиеся входными данными и результатами проекта.

Это может быть исходный код, исполняемые программы, стандарты, документация и т. д. Для обозначенияартефактов используются различные пиктограммы в зависимости оттипа артефакта. На рис. 2.4 приведена универсальная пиктограмма документа.UP моделирует понятие «когда» в виде рабочих потоков, которые представляют собой последовательности взаимосвязанных деятельностей,осуществляемых исполнителями. В RUP рабочим потокам высокогоуровня, таким как Требования или Тестирование, присвоено специальное имя – дисциплины (disciplines). Рабочие потоки могут быть разбиты на одну или более составляющих, которые описывают деятельности, роли и артефакты, участвующие в рабочем потоке. Эти составляющие рабочего потока в UP обозначаются только по имени, а в RUPони имеют собственные пиктограммы.2.5. Настройка UP для вашего проектаUP и RUP должны настраиваться под каждый конкретный проект.UP – универсальный процесс разработки ПО, который должен настраиваться для определенной организации и для каждого конкретногопроекта.

Тем самым признается, что все проекты по разработке ПОразные и что подход «один размер для всех» в случае с SEP не работает. Процесс настройки включает определение и объединение:• внутренних стандартов;• шаблонов документов;• инструментальных средств – компиляторов, инструментов управления конфигурацией и т. д.;• баз данных – отслеживание ошибок, слежение за проектом и т. д.;• изменений жизненного цикла – например более сложные меры контроля качества для систем с особыми требованиями к обеспечениюбезопасности.Детали процесса настройки выходят за рамки рассмотрения книги, ноих можно найти в [Rumbaugh 1].Даже несмотря на то, что RUP намного более полный, чем UP, он все жедолжен подвергаться такой же подгонке и настройке.

Однако необходимый для этого объем работы оказывается намного меньшим, чем еслиначинать с исходного UP. Кстати, для любого процесса производства56Глава 2. Что такое Унифицированный процесс?программного обеспечения нужно ожидать определенных затрат времени и средств на его настройку. Возможно придется обратиться за помощью к поставщику SEP и оплатить услуги консультанта.2.6.

Аксиомы UPUP базируется на трех аксиомах. Он является:• управляемым требованиями и риском;• архитектуроцентричным;• итеративным и инкрементным.Прецеденты будут подробно рассмотрены в главе 4. Здесь стоит заметить, что прецеденты – это способ записи требований. Таким образом,можно с уверенностью утверждать, что UP является управляемымтребованиями.UP – это современный SEP, который управляется требованиями пользователя и риском.Риск – это еще один управляющий механизм UP, поскольку если неатаковать риски, они будут атаковать вас! Все, кто участвовал в проектах по разработке ПО, без сомнения, согласятся с этим утверждением.UP решает эту проблему, заложив анализ рисков в основу создания ПО.Вообще говоря, решение этой проблемы – дело руководителя проектаи архитектора, поэтому не будем останавливаться на этом подробно.Подход UP к разработке программных систем заключается в созданиии развитии надежной архитектуры системы.

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

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

Фактически к ключевым рабочим потокам UP, таким как анализ, мы возвращаемся по нескольку раз в течение проекта.2.7. UP – итеративный и инкрементный процесс572.7. UP – итеративный и инкрементный процессЧтобы понять UP, необходимо понять итерации. Идея, по существу,крайне проста: история показывает, что людям, вообще говоря, решатьмаленькие проблемы легче, чем большие. Поэтому мы разбиваем большой проект по разработке ПО на несколько меньших «минипроектов», которыми легче управлять и успешно выполнить.

Каждый изэтих «минипроектов» и есть итерация. Основной момент: каждая итерация включает все элементы обычного проекта по разработке ПО:• Планирование• Анализ и проектирование• Построение• Интеграция и тестирование• Версия для внутреннего или внешнего использованияЦель UP – пошагово построить надежную архитектуру системы.Каждая итерация создает базовую версию, включающую в себя час+тично завершенную версию целевой системы и документацию проекта.В ходе последовательных итераций базовые версии наращиваются дотех пор, пока не будет создан окончательный полный вариант системы.Разница между двумя последующими базовыми версиями и есть инкремент. Вот почему UP называют итеративным и инкрементным жизненным циклом.Как мы увидим в разделе 2.8, итерации группируются в фазы.