UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
2.3. Рождение UP Рассматривая историю UP, представленную на рис. 2.3, следует отме тить, что его развитие тесно связано с карьерой одного человека, Айва ра Джекобсона (Ivar Jacobson). Его часто называют отцом UP. Это ни как не умоляет заслуги всех остальных специалистов (особенно Гради Буча), участвовавших в развитии UP, скорее, это подчеркивает значи мость вклада Джекобсона. Общее описание и требования Процесс разработки программного обеспечения Программное обеспечение Рис. 2.2. Процесс производства ПО Предыстория Джекобсон работает на Ericsson Джекобсон учреждает Objectory AB 1967 1976 1987 1995 UML становится промышленным стандартом Rational покупает Objectory AB 1997 1998 1999 2001 2004 Метод Ericsson Язык спецификации и описания Objectory Подход Rational Rational Objectory Process Унифици рованный процесс компании Rational (RUP) Унифициро ванный процесс разработки ПО RUP 2001 Дальнейшее развитие RUP Рис. 2.3. История UP 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» «trace» «trace» «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. Более подробно потоки определения требований, анализа, проектирования и реализации (тестирование выходит за рамки обсуж дения) будут рассмотрены несколько позже. Хотя в каждой итерации могут присутствовать все пять рабочих пото ков, в зависимости от местоположения итерации в жизненном цикле проекта внимание может быть акцентировано на каком либо одном рабочем потоке. Разбиение проекта на серию итераций обеспечивает возможность гиб кого подхода к его планированию. Самый простой подход – упорядо ченная во времени последовательность итераций, в которой каждая последующая итерация является результатом предыдущей. Однако часто итерации можно расположить параллельно. Это предполагает понимание зависимостей между артефактами каждой итерации и тре бует основанного на архитектуре и моделировании подхода к разра ботке ПО. Преимущество параллельных итераций – меньшее время вывода нового изделия на рынок и, возможно, более рациональное ис пользование команды, но при этом первостепенным является тща тельное планирование. |