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

Подождите немного. Документ загружается.

2.3. Рождение UP 51

Работа над SEP, целью которой было развитие его до уровня UP, нача

лась в 1967 г. в компании Ericsson.

Датой рождения UP можно считать 1967 год, а отправной точкой – под

ход Ericsson, который являлся радикальным шагом в моделировании

сложных систем и рассматривал их как набор взаимосвязанных бло

ков. Меньшие блоки связывались между собой, образуя блоки больше

го размера, составляющие всю систему. Основополагающий принцип

этого подхода – «разделяй и властвуй». Он является предтечей того,

что сегодня известно как компонентноориентированная разработка.

Система, рассматриваемая как единое целое, может быть сложной для

понимания. Для упрощения ее можно разбить на блоки меньшего раз

мера и разобраться в предлагаемых каждым блоком сервисах (в совре

менной терминологии – в интерфейсе компонента). Затем можно по

нять, как эти блоки совмещаются. В UML большие блоки называются

подсистемами, и каждая подсистема реализуется меньшими блоками,

называемыми компонентами.

Другим нововведением в подходе Ericsson был способ определения бло

ков через создание «вариантов трафика», описывающих, как предпо

лагается использовать систему. Со временем варианты трафика эволю

ционировали, и в настоящее время в UML они называются прецеден

тами. В результате этого процесса появилось архитектурное представ

ление, описывающее все блоки и их объединение. Это было предтечей

статической модели UML.

Наряду с представлением требований (варианты трафика) и статиче

ским представлением (описание архитектуры) у Ericsson было динами

ческое представление, описывающее, как все блоки взаимодействуют

во времени. Это представление состояло из диаграмм последовательно

стей взаимодействия и состояний (конечных автоматов). Все они по

прежнему есть в UML, хотя и в намного более совершенном виде.

Следующий крупный шаг в развитии производства ОО программного

обеспечения был сделан в 1980 г. с выходом в свет Языка специфика

ции и описания (Specification and Description Language, SDL) от меж

дународной организации по стандартизации CCITT. SDL был одним из

первых языков визуального моделирования, основанных на концепции

объектов. В 1992 г. он был расширен и стал объектноориентирован

ным языком с классами и наследованием. Этот язык был разработан

для отображения поведения телекоммуникационных систем. Системы

моделировались как набор блоков, общающихся друг с другом с помо

щью посылаемых сигналов. SDL92 был первым широко принятым

стандартом объектного моделирования, он используется и сегодня.

В 1987 г. Джекобсон основывает компанию Objectory AB в Стокголь

ме. Компанией был разработан и продан процесс производства ПО, ос

нованный на методе Ericsson и названный Objectory (сокращение от

«Object Factory» (фабрика объектов)). SEP компании Objectory включал

52 Глава 2. Что такое Унифицированный процесс?

набор документации, уникальное инструментальное средство и необхо

димую консультацию, предоставляемую Objectory AB.

Вероятно, самым важным нововведением того времени было то, что сам

по себе SEP компании Objectory рассматривался как система. Потоки

работ (требования, анализ, разработка, реализация и тестирование) бы

ли представлены в виде набора диаграмм. Другими словами, процесс Ob

jectory был смоделирован и разработан как программная система. Это

проложило путь к будущей разработке процесса. Objectory, как и UP,

был еще и каркасом (framework) процесса и требовал существенной до

работки перед применением в конкретном проекте. Процесс Objectory

поставлялся с несколькими шаблонами для различных типов проектов

разработки программного обеспечения, однако ему неизменно требова

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

разработке программного обеспечения разные, и поэтому идея созда

ния универсального SEP не была реальной и востребованной.

Когда в 1995 г. компания Rational приобрела Objectory AB, Джекобсон

занялся объединением процесса Objectory с большим количеством

наработок, выполненных в Rational. Было создано 4+1 представление

архитектуры, базирующееся на четырех отдельных представлениях

(логическом, процессов, физическом и разработки) плюс сводное пред

ставление прецедентов. Это до сих пор образует основу подхода UP к ар

хитектуре системы. Кроме того, итеративная разработка была форма

лизована в последовательность фаз (Начало, Уточнение, Построение,

Внедрение), объединивших в себе упорядоченность водопадного жиз

ненного цикла с динамизмом итеративной и инкрементной разработ

ки. Основными создателями этой системы были Уолкер Ройс (Walker

Royce), Рич Рейтман (Rich Reitmann), Гради Буч (Grady Booch) (созда

тель метода Буча) и Филипп Крухтен (Philippe Kruchten). В частности,

опыт Буча и его идеи в отношении архитектуры были объединены

в Rational Approach (подход компании Rational) (превосходное обсуж

дение его идей можно найти в [Booch 1]).

Rational Objectory Process (ROP) был результатом объединения подхо

да Objectory с исследованиями процессов компании Rational. В частно

сти, ROP усовершенствовал области, в которых Objectory был слаб: тре

бования, не входящие в прецеденты, реализация, тестирование, управ

ление проектом, развертывание, управление конфигурацией и среда

разработки. Было введено понятие риска (risk) как управляющего ме

ханизма ROP, а «архитектура» получила точное определение как по

ставляемое «архитектурное представление». В это время в компании

Rational Буч, Джекобсон и Рамбо разрабатывали UML. Он стал язы

ком, в котором были представлены модели ROP и сам ROP.

Начиная с 1997 г. Rational присоединила множество компаний, объе

динив опыт в определении требований, управлении конфигурацией,

тестировании и т. д. Это привело к выходу в 1998 г. Унифицированно

го процесса компании Rational (Rational Unified Process, RUP). С тех

2.4. UP и Унифицированный процесс компании Rational 53

пор свет увидели множество версий RUP, каждая из которых неизмен

но лучше предыдущих. Более подробную информацию можно найти

по адресу www.rational.com и в книге [Kruchten 1].

UP – это сложившийся открытый SEP от авторов UML.

В 1999 г. была опубликована важная книга «Unified Software Develop

ment Process» [Jacobson 1], описывающая Унифицированный процесс.

Если RUP – это процесс, являющийся продуктом компании Rational, то

UP – открытый SEP от авторов UML. Не удивительно, что UP и RUP

тесно взаимосвязаны. В нашем изложении мы решили использовать

UP, а не RUP, поскольку он является открытым SEP, доступным для

всех и не привязанным к конкретному продукту или производителю.

2.4. UP и Унифицированный процесс

компании Rational

RUP – это коммерческий продукт, расширяющий UP.

Унифицированный процесс компании Rational (Rational Unified Pro

cess, RUP) – это коммерческая версия UP от IBM, которая поглотила

Rational Corporation в 2003 году. Он предоставляет стандарты, инстру

ментальные средства и остальные необходимые элементы, которые не

включены в UP и которые пользователям в противном случае пришлось

бы искать самостоятельно. Он также поставляется с богатым вебокру

жением, включающим всю документацию процесса и полные руково

дства для каждого инструментального средства.

У процессов UP и RUP больше общего, чем отличий.

В 1999 г. 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 моделирует понятие «что» в виде деятельностей и артефактов. Дея

тельности – это задачи, которые будут выполняться в проекте отдель

Исполнитель Роль

Деятельность

Рабочий

поток

Дисциплина

Деталь

рабочего потока

Деталь рабочего потока

«trace»

– роль, выполняемая в проекте

отдельным индивидуумом

или командой

– единица работы,

осуществляемая исполнителем

(ролью), или артефакт,

производимый в проекте

– последовательность

взаимосвязанных действий,

составляющих основную

ценность проекта

UP RUP Семантика

Артефакт Артефакт

«trace»

Кто

Что

Когда

Рис. 2.4. Соответствие пиктограмм UP и RUP

2.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. Аксиомы UP

UP базируется на трех аксиомах. Он является:

• управляемым требованиями и риском;

• архитектуроцентричным;

• итеративным и инкрементным.

Прецеденты будут подробно рассмотрены в главе 4. Здесь стоит заме

тить, что прецеденты – это способ записи требований. Таким образом,

можно с уверенностью утверждать, что UP является управляемым

требованиями.

UP – это современный SEP, который управляется требованиями пользо

вателя и риском.

Риск – это еще один управляющий механизм UP, поскольку если не

атаковать риски, они будут атаковать вас! Все, кто участвовал в проек

тах по разработке ПО, без сомнения, согласятся с этим утверждением.

UP решает эту проблему, заложив анализ рисков в основу создания ПО.

Вообще говоря, решение этой проблемы – дело руководителя проекта

и архитектора, поэтому не будем останавливаться на этом подробно.

Подход UP к разработке программных систем заключается в создании

и развитии надежной архитектуры системы. Архитектура описывает

стратегические аспекты разбиения системы на компоненты, а также

взаимодействия и развертывания этих компонентов на аппаратных

средствах. Очевидно, что качественно разработанная архитектура обе

спечит создание работоспособной системы, а не просто наспех скомпо

нованного набора кустарного исходного кода.

И наконец, UP является итеративным и инкрементным. Итеративный

аспект UP означает, что проект разбивается на небольшие подпроекты

(итерации), которые обеспечивают функциональность системы по час

тям, или инкрементам, приводя к созданию полнофункциональной сис

темы. Другими словами, ПО создается путем пошаговой детализации.

Такой подход сильно отличается от старого водопадного жизненного

цикла. Последний включал в себя анализ, разработку и построение, ко

торые следовали в более или менее прямой последовательности друг за

другом. Фактически к ключевым рабочим потокам UP, таким как ана

лиз, мы возвращаемся по нескольку раз в течение проекта.

2.7. UP – итеративный и инкрементный процесс 57

2.7. UP – итеративный и инкрементный процесс

Чтобы понять UP, необходимо понять итерации. Идея, по существу,

крайне проста: история показывает, что людям, вообще говоря, решать

маленькие проблемы легче, чем большие. Поэтому мы разбиваем боль

шой проект по разработке ПО на несколько меньших «минипроек

тов», которыми легче управлять и успешно выполнить. Каждый из

этих «минипроектов» и есть итерация. Основной момент: каждая ите

рация включает все элементы обычного проекта по разработке ПО:

• Планирование

• Анализ и проектирование

• Построение

• Интеграция и тестирование

• Версия для внутреннего или внешнего использования

Цель UP – пошагово построить надежную архитектуру системы.

Каждая итерация создает базовую версию, включающую в себя час+

тично завершенную версию целевой системы и документацию проекта.

В ходе последовательных итераций базовые версии наращиваются до

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

Разница между двумя последующими базовыми версиями и есть ин

кремент. Вот почему UP называют итеративным и инкрементным жиз

ненным циклом.

Как мы увидим в разделе 2.8, итерации группируются в фазы. Фазы

образуют макроструктуру UP.

2.7.1. Рабочие потоки итерации

В UP пять основных рабочих потоков.

В каждой итерации пять основных рабочих потоков определяют, что

должно быть сделано и какие навыки для этого необходимы. Наряду

с пятью основными рабочими потоками будут присутствовать и дру

гие, такие как планирование, оценка и все, что характерно для этой

конкретной итерации. Однако эти этапы не выделены в UP.

К пяти основным рабочим потокам относятся:

• определение требований – сбор данных о том, что должна делать

система;

• анализ – уточнение и структурирование требований;

• проектирование – реализация требований в архитектуре системы;

• реализация – построение программного обеспечения;

• тестирование – проверяется, отвечает ли реализация предъявляе

мым требованиям.

58 Глава 2. Что такое Унифицированный процесс?

Некоторые возможные рабочие потоки итерации изображены на

рис. 2.5. Более подробно потоки определения требований, анализа,

проектирования и реализации (тестирование выходит за рамки обсуж

дения) будут рассмотрены несколько позже.

Хотя в каждой итерации могут присутствовать все пять рабочих пото

ков, в зависимости от местоположения итерации в жизненном цикле

проекта внимание может быть акцентировано на какомлибо одном

рабочем потоке.

Разбиение проекта на серию итераций обеспечивает возможность гиб

кого подхода к его планированию. Самый простой подход – упорядо

ченная во времени последовательность итераций, в которой каждая

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

часто итерации можно расположить параллельно. Это предполагает

понимание зависимостей между артефактами каждой итерации и тре

бует основанного на архитектуре и моделировании подхода к разра

ботке ПО. Преимущество параллельных итераций – меньшее время

вывода нового изделия на рынок и, возможно, более рациональное ис

пользование команды, но при этом первостепенным является тща

тельное планирование.

2.7.2. Базовые версии и инкременты

Каждая итерация UP формирует базовую версию. Это версия для внут

реннего (или внешнего) использования набора рассмотренных и утвер

жденных артефактов, сгенерированных в данной итерации. Каждая

базовая версия:

• предоставляет базу для дальнейшего рассмотрения и разработки;

Определение

требований

Анализ Проектирование Реализация Тестирование

UP определяет пять основных рабочих потоков

Оценка Планирование

Характерные

для проекта...

Итерация

другие рабочие потоки

Рис. 2.5. Возможные рабочие потоки итерации

2.8. Структура UP 59

• может изменяться только через формальные процедуры управле

ния конфигурацией и изменениями.

Инкременты – это просто разница между двумя последовательными

базовыми версиями. Это шаги по направлению к окончательной вы

пускаемой системе.

2.8. Структура UP

В UP четыре фазы, каждая из которых имеет свои контрольные точки.

На рис. 2.6 показана структура UP. Жизненный цикл проекта разделен

на четыре фазы: Начало, Уточнение, Построение и Внедрение, каждая

из которых имеет свои контрольные точки. В каждой фазе может быть

одна или более итераций, в каждой итерации выполняются пять ос

новных и любое количество дополнительных рабочих потоков. Точное

число итераций в фазе зависит от размера проекта, но каждая итера

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

мер является типовым для среднего проекта продолжительностью

около 18 месяцев.

Как видно из рис. 2.6, UP состоит из последовательности четырех фаз,

каждая из которых завершается важной контрольной точкой:

• Начало (Inception) – цели жизненного цикла;

• Уточнение (Elaboration) – архитектура жизненного цикла;

• Построение (Construction) – базовая функциональность;

• Внедрение (Transition) – выпуск продукта.

По мере прохождения этих фаз UP объем работы, выполняемый в каж

дом из пяти рабочих потоков, меняется.

Рисунок 2.7 – ключ к пониманию принципа работы UP. Вверху пока

заны фазы. В крайнем левом столбце – пять основных рабочих пото

ков. Внизу изображены итерации. Кривые показывают относитель

Цели

жизненного

цикла

Начало

Архитектура

жизненного

цикла

Уточнение

Базовая

функцио!

нальность

Построение

Выпуск

продукта

Внедрение

Контрольная

точка

Фаза

Итерации

Итер 1 Итер 2 Итер 3 Итер 4 Итер 5 Итер 6

П Р TAТ

Пять основных

рабочих потоков

... ... ... ... ...

Рис. 2.6. Структура UP

60 Глава 2. Что такое Унифицированный процесс?

ный объем работы, выполняемый в каждом из пяти основных рабочих

потоков по мере прохождения проекта по фазам.

Объем работы, выполняемый в каждом из основных рабочих потоков,

меняется в зависимости от фазы.

Как показано на рис. 2.7, в фазе Начало большая часть работы выпада

ет на определение требований и анализ. В фазе Уточнение основной

акцент перемещается на требования, анализ и проектирование. Оче

видно, что в фазе Построение основное внимание направлено на проек

тирование и реализацию. И наконец, в фазе Внедрение главными ста

новятся реализация и тестирование.

UP – процесс, ориентированный на цели в большей степени, чем на соз

дание поставляемых артефактов.

Одной из замечательных особенностей UP является то, что он ориенти

рован на цели, а не на создание поставляемых артефактов. Каждая фа

за завершается контрольной точкой, состоящей из набора условий, ко

торым надо удовлетворить, и эти условия могут включать или не

включать, в зависимости от конкретных потребностей проекта, созда

ние отдельного, готового к поставке продукта.

Далее приводится краткий обзор каждой фазы UP.

Начало Уточнение Построение Внедрение

Определение

требований

Анализ

Проектирование

Реализация

Тестирование

Предварительные

итерации

Шаг

n+1

Шаг

n+2

Шаг

m+1

Объем

работы

Рис. 2.7. Относительный объем работы, выполняемый в каждом из пяти

рабочих потоков по мере прохождения проекта по фазам. Адаптировано

с рис. 1.5 [Jacobson 1] с разрешения издательства Addison+Wesley