Унифицированный процесс разработки программного обеспесчения

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

3. Определение вариантов использования

 

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

4. Анализ, проектирование и  разработка при реализации варианта использования

 

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

1. Создание  по вариантам использования аналитической модели

 

     Модель  анализа последовательно разрастается по мере анализа все новых и  новых вариантов использования. На каждой итерации мы выбираем варианты использования, которые будем включать в модель анализа. Мы строим систему  в виде структуры, состоящей из классификаторов (классов анализа) и отношений  между ними. Мы также описываем  кооперации, реализующие варианты использования, то есть реализации вариантов использования. На следующей итерации мы выбираем для проработки  следующие  варианты   использования и добавляем их к результатам предыдущей итерации. В подразделах «Итеративный подход —управляемый рисками» и «Расстановка  приоритетов  вариантов использования» мы рассматриваем, как на первых итерациях идентифицировать и выбрать «важнейшие» варианты использования, чтобы построить стабильную архитектуру на ранних стадиях жизненного цикла системы.

     Работа  обычно выполняется так: сначала идентифицируются   и описываются варианты использования текущей итерации, затем в соответствии с описанием для каждого варианта использования предлагаются классификаторы и ассоциации, необходимые для реализации этого варианта использования. Мы проделываем эту работу для всех вариантов использования текущей итерации. В зависимости от того, в какой точке жизненного цикла мы находимся и с какой итерацией работаем, архитектура может уже быть определена, тогда она поможет нам обнаруживать новые классификаторы и повторно использовать существующие. Каждый классификатор играет в реализации варианта использования одну или несколько ролей. Каждая роль классификатора определяет обязанности, атрибуты и другие характеристики, которыми классификатор будет обладать в реализации варианта использования. Мы можем считать эти роли зародышами классификаторов. В UML роль является классификатором сама по себе. Например, мы можем думать о роли класса как о представлении этого класса. Таким образом, она включает содержимое этого класса, то есть обязанности, атрибуты и другие характеристики, но только те, которые имеют отношение к его роли в реализации варианта использования. Другой способ описать роль класса состоит в том, чтобы рассматривать ее как то, что остается от класса после наложения на него фильтра, отсекающего все то, что относится к другим ролям класса, за исключением совместно выполняемых обязанностей. Такой подход к роли кратко описан в этой главе. Для упрощения понимания материала во второй части этой книги, где классификаторы обсуждаются подробнее, этот подход не используется.

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

 

     В ходе тестирования мы проверяем правильность реализации системой первоначальной спецификации. Мы создаем модель тестирования, которая состоит из тестовых примеров  и процедур тестирования, а затем выполняем тестовые процедуры, чтобы удостовериться, что система работает так, как мы и ожидали. Тестовый пример — это набор тестовых исходных данных, условий выполнения и ожидаемых результатов, разработанный с определенной целью, например, реализовать некий путь выполнения варианта использования или проверить соблюдение определенного требования. Тестовая процедура — это описание подготовки, выполнения и оценки результатов конкретного тестового примера. Тестовые процедуры могут быть получены из вариантов использования. Для локализации проблемы обнаруженные дефекты следует проанализировать. Затем определяется приоритетность обнаруженных проблем, и они решаются в порядке их важности.

     Опишем, как проверить, что варианты использования были осуществлены правильно. В каком-то смысле в этом нет ничего нового. Разработчики всегда проверяли варианты использования, даже раньше, чем появился сам термин «вариант использования». Тестирование возможности использования системы осмысленным для   пользователей способом было традиционным способом проверки  функций   системы.  Но, с другой  стороны, это и новый  подход. Новым является то, что мы идентифицируем тестовые примеры (как варианты использования в рабочем процессе определения требований) до начала проектирования системы и что мы уверены, что наш проект действительно реализует варианты использования.

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

       

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

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

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

• Счет клиента банка имеет номер 12-121-1211 и на балансе счета $350.
• Клиент банка идентифицирует себя верно.
• Клиент   банка запрашивает   к выдаче  $200 со счета   12-121-1211. В банкомате достаточно денег (минимум $200).

     Результат:

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

Условия:

     Никакие другие варианты использования в ходе выполнения тестового примера не имеют доступа к счету 12-121-1211. Отметим, что этот тестовый пример основан на описании варианта использования Снять деньги со счета, описанного в подразделе «Варианты использования определяют систему». Рано определяя варианты использования, мы рано начинам планировать тестирование и рано находим эффективные тестовые примеры. Эти тестовые примеры могут усложняться по ходу проекта, по мере того, как мы расширяем наше понимание осуществления системой вариантов использования. Некоторые утилиты вообще генерируют тестовые примеры по модели проектирования вручную остается ввести только тестовые данные, необходимые для запуска теста.

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

6. Резюме

 

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

3. Архитектурно-центрированный процесс

1. Введение  в архитектуру

 

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

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

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

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

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

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

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

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

     В описании архитектуры нет ничего сверхъестественного. Оно похоже на полное описание системы со всеми моделями только меньше. Насколько оно велико? Никаких абсолютных величин для описания архитектуры не существует, но по нашему опыту для большо­го спектра систем достаточно от 50 до 100 страниц. Это диапазон для отдельных прикладных систем описания архитектуры для комплектов прикладных программ будут больше.

2. Необходимость архитектуры

 

     Для того чтобы у разработчиков складывалась единая концепция большой и сложной программной системы, необходим архитектор. Сложно представить себе программную систему, не существующую в нашем трехмерном мире. Программные системы часто бывают в какой-то степени беспрецедентны или уникальны. Нередко они используют прогрессивные технологии или новое сочетание технологий. Часто они используют существующие технологии на пределе их возможностей. Кроме этого, они должны быть построены так, чтобы адаптироваться к огромному количеству вероятных в будущем изменений. Поскольку системы стали более сложными, «проблема проектирования находится вне алгоритмов и структур данных: проектирование и определение общей структуры системы является проблемой иного типа»