25. Технологический процесс реализации

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

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

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

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

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

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

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

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

• Интеграция

• Прототипы

Конструкции

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

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

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

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

Интеграция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исполнители и артефакты

Основными исполнителями, участвующими в технологическом процессе реализа­ции, являются следующие.

• Конструктор, разрабатывающий компоненты и связанные с ними артефакты, а также выполняющий блочное тестирование

• Системный интегратор, создающий конструкции

В число иных исполнителей входят следующие.

• Архитектор, определяющий структуру модели реализации (организацию уров­ней и подсистем)

• Рецензент кода, проверяющий качество кода и его соответствие стандартам проекта

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

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

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

• Компонент

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

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

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

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

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

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

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

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

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