Из проектной модели

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

исполняемой системы: исполняемые компоненты, файлы компонентов (исходный

код, сценарии для командного процессора и т. п.), табличные компоненты

(элементы баз данных) и т. д. Компонентом мы называем физическую заменяемую

часть системы, которая использует и обеспечивает реализацию некоторого набора

интерфейсов. Модель реализации состоит из компонентов, в число которых входят

все исполняемые файлы (приложение А, см. также главу 10), как-то: компоненты

ActiveX, JavaBeans и другие виды компонентов.

Пример. Компоненты в модели реализации. На рис. 3.12 изображены компоненты,

реализующие классы проектирования из модели проектирования (подразел «Создание

модели проектирования из аналитической модели» данной главы).

Так, файл компонента dispenser.c содержит исходный текст (и таким образом

реализует) три класса, Подаватель устройства выдачи, Датчик устройства выдачи

и Счетчик купюр. Этот файл компилируется и компонуется с файлом компонента

client.c в компонент client.exe, который является исполняемым файлом.

Рис. 3.12. Компоненты реализуют классы проектирования

Архитектурный контекст компонента определяется его интерфейсами. Компоненты

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

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

и использует те же самые интерфейсы, что и старый. Стандартным является

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

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

если, согласно модели развертывания, сервисная подсистема всегда размещается

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

более чем на один тип узлов сервисная подсистема обычно разделяется —

чаще всего путем разделения некоторых классов — на столько частей, сколько имеется

типов узлов. Каждая из частей сервисной подсистемы в этом случае реализуется

в виде отдельного компонента.

Пример. Реализация подсистемы компонентами. Предположим, что мы выбрали

для нашего примера с банкоматом решение на основе архитектуры клиент/

сервер (см. подраздел «Определение узлов и сетевых конфигураций» главы

9). Тогда мы можем разместить части сервисной подсистемы Менеджер получения

(см. рис. 3.11), содержащие класс Получение^ и на клиенте, и на сервере.

В этом случае Менеджер получения необходимо было бы реализовать в виде двух

компонентов — «Получение на Клиенте^ и «Получение на Сервере»,

Если компоненты реализуются с применением объектно-ориентированного

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

класс проектирования соответствует классу реализации, типа классов С ++ или

Java. Каждый файл компонента может содержать один или несколько этих классов,

что зависит от правил выбранного языка программирования.

Однако для создания рабочей системы недостаточно только разработать код.

Разработчики, ответственные за реализацию компонентов, отвечают также и за то,

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

были протестированы.__

Тестирование вариантов использования

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

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

примеров и процедур тестирования (приложение В; см. также главу И),

а затем выполняем тестовые процедуры, чтобы удостовериться, что система работает

так, как мы и ожидали. Тестовый пример — это набор тестовых исходных данных,

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

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

или проверить соблюдение определенного требования. Тестовая процедура —

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

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

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

Затем определяется приоритетность обнаруженных проблем, и они решаются

в порядке их важности.

Мы начали разработку в подразделе «Определение вариантов использования»

с определения вариантов использования, затем в подразделе «Анализ, проектирование

и разработка при реализации варианта использования» мы проанализировали,

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

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

осуществлены правильно. В каком-то смысле в этом нет ничего нового. Разработчики

всегда проверяли варианты использования, даже раньше, чем появился сам

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

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

проверки функций системы. Но, с другой стороны, это и новый подход. Новым

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

в рабочем процессе определения требований) до начала проектирования

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

Пример. Определение тестового примера на основе варианта использования. На

рисунке 3.13 изображен тестовый пример Снять деньги со счета — основной процесс,

который описывает порядок проверки основного процесса варианта использования

Рис. 3.13. Тестовый пример из модели тестирования, определяющей, как тестировать вариант

использования (Снять деньги со счета) из модели вариантов использования

Заметим, что сейчас мы ввели новый стереотип для вариантов использования,

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

варианты использования на диаграммах (см. главу 11).

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

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

Снять деньги со счета.

Исходные данные.

О Счет клиента банка имеет номер 12-121-1211 и на балансе счета $350.

О Клиент банка идентифицирует себя верно.

О Клиент банка запрашивает к выдаче $200 со счета 12-121-1211. В банкомате

достаточно денег (минимум $200).

Результат:

О Баланс счета 12-121-1211 Клиентабанкауменьшается до $150.

О Клиент банка получает из банкомата $200.

Условия:

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

не имеют доступа к счету 12-121-1211.

Отметим, что этот тестовый пример основан на описании варианта использования

Снять деньги со счета, описанного в подразделе «Варианты использования

определяют систему». Рано определяя варианты использования, мы рано начинаем

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

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

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

утилиты вообще генерируют тестовые примеры по модели проектирования

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

теста.

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

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

когда тестовый пример строится для проверки того, что экземпляры классов, участвующих

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

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

требования хоть в какой-то степени определятся.

Существуют также и другие виды тестов, например системные тесты, тесты приемки

и тесты документации. Подробнее мы поговорим о тестировании в главе И.