Главная » UML » Технологический процесс реализации

0

В главе описывается технологический процесс реализации. Здесь вводятся понятия прототипов и поэлементной интеграции.

Цель

Существует четыре основные цели технологического процесса реализации.

ш   Определить структуру кода через подсистемы реализации, организованные в уровни.

•       Реализовать классы и объекты через компоненты (исходные файлы, двоичные
коды, исполняемые файлы и др.).

•       Провести блочное тестирование разработанных компонентов.

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

Тестирование в технологическом процессе реализации ограничено блочным тестированием отдельных компонентов. Тестирование системы и тестирование интеграции будут описаны в технологическом процессе тестирования (см. главу 12). Такое разделение происходит вследствие того, что за блочное тестирование отвечает не испытатель (основной исполнитель технологического процесса тестирования), а конструктор (основной исполнитель технологического процесса реализации). В то же время следует помнить, что на практике эти технологические процессы обычно переплетаются.

Для уяснения особенностей технологического процесса реализации в Rational Unified Process необходимо ввести три следующих ключевых понятия.

•       Конструкция

•       Интеграция

•       Прототипы

•        

Конструкции

Конструкция— это функциональная версия системы или части системы, демонстрирующая сокращенный вариант возможностей конечного продукта.

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

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

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

Интеграция

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

•       Для интеграции результатов работы команды, занимающейся одной подсис
темой реализации, до того, как эта подсистема будет предоставлена системным
интеграторам.

•       Для интеграции подсистем в целостную систему.

Согласно подходу к реализации, принятому в Rational Unified Process, программное обеспечение интегрируется поэлементно. Поэлементная интеграция означает, что коды пишутся и тестируются небольшими блоками, после чего они объединяются в рабочее целое путем постепенного добавления блоков.

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

Использование поэлементной интеграции имеет следующие преимущества.

•   Ошибки легче локализовать. При появлении в процессе поэлементной интегра
ции новой проблемы наиболее вероятным ее источником является новый или
измененный компонент (или его взаимодействие с ранее интегрированными
компонентами). Кроме того, такая интеграция делает более вероятным выявле
ние дефектов по одному, что иногда облегчает определение неполадок.

 

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

•    Некоторые части системы раньше эксплуатируются. Это оказывает положитель
ное воздействие на моральное состояние разработчиков, которые могут увидеть
результаты своей работы сразу, не дожидаясь глобального тестирования. Кроме
того, это позволяет раньше организовать обратную связь по вопросам проек
тирования, использования инструментальных средств, правил или стиля.

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

Прототип

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

•       Коммерческая жизнеспособность разрабатываемого проекта

•       Устойчивость или производительность ключевой технологии

•       Обязательства по проекту или финансирование проекта (для этого создается
небольшой испытательный прототип)

•       Понимание требований

м Впечатление и ощущение от продукта (в конечном счете — удобство и простота] использования)

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

В то же время природа и цель прототипа должны оставаться ясными в течение всего жизненного цикла проекта. Если прототип не планировалось развивать в реальный j продукт, то не стоит, глядя на его прекрасную работоспособность, внезапно решать, что он должен быть преобразован в окончательный продукт. Например, пробные и поведенческие прототипы крайне редко развиваются в сильный, жизнеспособный продукт; их цель — всего лишь быстрая проверка пользовательского интерфейса.

Типы прототипов

Прототипы можно рассматривать двояко: через то, что они изучают, и через то, как они развиваются (их результаты). В первом случае прототипы можно разделить на две группы.

•       Поведенческие,  акцентирующие  внимание  на  исследовании  определенного
поведения системы

•       Структурные, исследующие архитектурные или технологические вопросы

•        

Во втором случае также имеется два типа прототипов.

•       Пробные  прототипы,   также   называемые   временными   или   одноразовыми,
которые отбрасываются непосредственно после завершения и предоставления
требуемых от них знаний

•       Эволюционные прототипы, развивающиеся в конечную систему

Поведенческие прототипы

Поведенческие прототипы, как правило, являются пробными; в них не пытаются воспроизвести архитектуру разрабатываемой системы, основное внимание обращается на то, что система будет делать с точки зрения пользователей ("кожа"). Довольно часто прототипы этого типа "лепятся наспех" и не соответствуют стандартам проек-ти.. HamjMM/yp,, в> KaJWLTjyt. чяыка. шрлт.оташя- млжкх иглллъзлвят.ьг.я_ vlsj ml. НазАл,, чапъ ъ разрабатываемом проекте обязательным является язык C++.

Структурные прототипы

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

Rational Unified Process "отстаивает" развитие эволюционных структурных прототипов в фазе уточнения плана с параллельной разработкой нескольких пробных прототипов. Примером пробного прототипа является прототип пользовательского интерфейса, представленный в главе 9.

Пробные прототипы

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

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

Эволюционные прототипы

Эволюционные прототипы, как явствует из названия, эволюционируют при переходе от одной итерации к другой. Хотя изначально их качество далеко от идеального, коды этих прототипов перерабатываются по мере развития продукта. Для управляемости этой переработки прототипы стараются разрабатывать и тестировать формально,

Глава 11.            163

Ключевыми артефактами процесса реализации являются следующие.

•    Подсистема реализации

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

•    Компонент

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

•    План проведения интеграции

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

Технологический процесс

Обратимся к рис. 11.2, на котором представлен технологический процесс реализации, и кратко рассмотрим основные виды деятельности этого процесса.

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

При каждой итерации необходимо обратить внимание на следующие моменты.

•       Необходимо запланировать, какие подсистемы должны быть реализованы, и
определить порядок интеграции подсистем для текущей итерации. Все это
выполняется при планировании итерации.

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

•       В модели проектирования конструкторы реализуют классы и объекты — пишут
исходные коды, настраивают существующие компоненты, компилируют, связы
вают и исполняют. При обнаружении конструкторами изъянов проекта органи
зовывается обратная связь для его доработки.

•       Конструкторы   также   корректируют  дефекты   кода   и   выполняют   блочное
тестирование для проверки внесенных изменений. После этого код рецензи
руется — проверяется его качество и соответствие программным директивам.

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

Системный интегратор, придерживаясь плана проведения интеграции, выполняет интеграцию системы путем добавления выпущенных подсистем в область интеграции и создания конструкций. Затем каждая конструкция тестируется испытателем интеграции, а после последнего добавления конструкция превращается в систему и тестируется испытателем системы.

 

Реализация неразрывно связана с проектированием, вследствие чего весьма легко проследить преобразование элементов проекта в элементы реализации (например, классов в код).

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

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

Инструментальная поддержка

Традиционно, при реализации используются классические средства разработки программного обеспечения — редакторы, компиляторы, компоновщики и отладчики. Сейчас эти средства собраны в комплексные среды разработки и имеют общую семантику. Например, среда разработки Rational Apex для языков Ada или C++.

Инструментальное средство Rational Rose обеспечивает циклическое проектирование, в результате чего тесно переплетаются процессы проектирования и реализации. Средства, подобные Purify или Quantify, позволяют выявлять дефекты кода. Средство ClearCase обеспечивает поддержку индивидуальных рабочих сред и рабочих сред для создания подсистем и интеграции системы. Рекомендуемым средством отслеживания дефектов и запросов на внесение изменений с последующим поиском их в исходном коде является ClearQuest.

Резюме

•       Характерной особенностью Rational  Unified Process является поэлементная
интеграция в течение всего жизненного цикла.

•       В фазе построения создается эволюционный структурный прототип, со време
нем развивающийся в конечную систему.

•       Параллельно создается несколько одноразовых поведенческих прототипов для
проведения    определенных    исследований     (например,     пользовательского
интерфейса).

•       Циклическое    проектирование—   это    технология,    поддерживаемая    таким
инструментальным средством, как Rational Rose; она тесно связывает процессы
проектирования и реализации.

•        

По теме:

  • Комментарии