Windows XP / 7 .

РАЗРАБОТКА СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ

Допущено Министерством образования Российской Федерации
в качестве учебного пособия для студентов высших учебных заведений,
обучающихся по направлению подготовки бакалавров и магистров
«Информатика и вычислительная техника»

Москва • Санкт-Петербург • Нижний Новгород • Воронеж
Ростов-на-Дону • Екатеринбург • Самара
Киев • Харьков • Минск
2002

Рецензенты:
Филиппович Ю. Н., канд. техн. наук, доцент Московского государственного Университета печати
Ревунков Г. И., канд. техн. наук, доцент Московского государственного технического Университета
им. Н Э. Баумана

Технологии разработки программного обеспечения: Учебник/ С. Орлов. — СПб.: Питер, 2002. — 464 с.: ил.
ISBN 5-94723-145-Х
Учебник посвящен систематическому изложению принципов, моделей и методов, используемых в инженерном цикле разработки сложных программных продуктов. Изложены классические основы программной инженерии, показаны последние научные и практические достижения, характеризующие динамику развития этой области; продемонстрирован комплексный подход к решению наиболее важных вопросов, возникающих в больших программных проектах. В основу материала положен двенадцатилетний опыт преподавания автором соответствующих дисциплин.
Книга допущена Министерством образования РФ в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки бакалавров и магистров «Информатика и вычислительная техника».

© ЗАО Издательский дом «Питер», 2002

Введение

Известно, что основной задачей первых трех десятилетий компьютерной эры являлось развитие аппаратных компьютерных средств. Это было обусловлено высокой стоимостью обработки и хранения данных. В 80-е годы успехи микроэлектроники привели к резкому увеличению производительности компьютера при значительном снижении стоимости.
Основной задачей 90-х годов и начала XXI века стало совершенствование качества компьютерных приложений, возможности которых целиком определяются программным обеспечением (ПО).
Современный персональный компьютер теперь имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.
Чрезвычайно актуальными стали следующие проблемы:
аппаратная сложность опережает наше умение строить ПО, использующее потенциальные возможности аппаратуры;
наше умение строить новые программы отстает от требований к новым программам;
нашим возможностям эксплуатировать существующие программы угрожает низкое качество их разработки.
Ключом к решению этих проблем является грамотная организация процесса создания ПО, реализация технологических принципов промышленного конструирования программных систем (ПС).
Настоящий учебник посвящен систематическому изложению принципов, моделей и методов (формирования требований, анализа, синтеза и тестирования), используемых в инженерном цикле разработки сложных программных продуктов.
В основу материала положен двенадцатилетний опыт постановки и преподавания автором соответствующих дисциплин в Рижском авиационном университете и Рижском институте транспорта и связи. Базовый курс «Технология конструирования программного обеспечения» прослушали больше тысячи студентов, работающих теперь в инфраструктуре мировой программной индустрии, в самых разных странах и на самых разных континентах.
Автор стремился к достижению трех целей:
изложить классические основы, отражающие накопленный мировой опыт программной инженерии;
показать последние научные и практические достижения, характеризующие динамику развития в области Software Engineering;
обеспечить комплексный охват наиболее важных вопросов, возникающих в больших программных проектах.
Компьютерные науки вообще и программная инженерия в частности — очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века — информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства — 40%. Именно поэтому специальности направления «Компьютерные науки и информационные технологии» гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: «Кто владеет информацией — тот владеет миром!»
Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 — Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.
Содержание данного учебника отвечает рекомендациям этих стандартов. Учебник состоит из 17 глав.
Первая глава посвящена организации классических, современных и перспективных процессов разработки ПО.
Вторая глава знакомит с вопросами руководства программными проектами — планированием, оценкой затрат. Вводятся размерно-ориентированные и функционально-ориентированные метрики затрат, обсуждается методика их применения, описывается наиболее популярная модель для оценивания затрат — СОСОМО II. Приводятся примеры предварительной оценки программного проекта и анализа чувствительности проекта к изменению условий разработки.
Третья глава рассматривает классические методы анализа при разработке ПО.
Четвертая глава отведена основам проектирования программных систем. Здесь обсуждаются архитектурные модели ПО, основные проектные характеристики: модульность, информационная закрытость, сложность, связность, сцепление и метрики для их оценки.
Пятая глава описывает классические методы проектирования ПО.
Шестая глава определяет базовые понятия структурного тестирования программного обеспечения (по принципу «белого ящика») и знакомит с наиболее популярными методиками данного вида тестирования: тестированием базового пути, тестированием ветвей и операторов отношений, тестированием потоков данных, тестированием циклов.
Седьмая глава вводит в круг понятий функционального тестирования ПО и описывает конкретные способы тестирования — путем разбиения по эквивалентности, анализа граничных значений, построения диаграмм причин-следствий.
Восьмая глава ориентирована на комплексное изложение содержания процесса тестирования: тестирование модулей, тестирование интеграции модулей в программную систему; тестирование правильности, при котором проверяется соответствие системы требованиям заказчика; системное тестирование, при котором проверяется корректность встраивания ПО в цельную компьютерную систему. Здесь же рассматривается организация отладки ПО (с целью устранения выявленных при тестировании ошибок).
Девятая глава посвящена принципам объектно-ориентированного представления программных систем — особенностям их абстрагирования, инкапсуляции, модульности, построения иерархии. Обсуждаются характеристики основных строительных элементов объектно-ориентированного ПО — объектов и классов, а также отношения между ними.
В десятой главе дается сжатое изложение базовых понятий языка визуального моделирования — UML, рассматривается его современная версия 1.4.
Одиннадцатая глава представляет инструментарий UML для задания статических моделей, описывающих структуру объектно-ориентированных программных систем.
Двенадцатая глава отображает самый многочисленный инструментарий UML — инструментарий для задания динамических моделей, описывающих поведение объектно-ориентированных программных систем. Впрочем, здесь излагаются и смежные вопросы: формирование модели требований к разработке ПО с помощью аппарата Use Case, фиксация комплексных динамических решений с помощью коопераций и паттернов, бизнес-моделирование как средство предпроектного анализа организации-заказчика.
Тринадцатая глава отведена моделям реализации, описывающим формы представления объектно-ориентированных программных систем в физическом мире. Помимо компонентов, узлов и соответствующих диаграмм их обитания здесь приводится пример современной компонентной модели от Microsoft — COM.
В четырнадцатой главе обсуждается метрический аппарат для оценки качества объектно-ориентированных проектных решений: метрики оценки объектно-ориентированной связности, сцепления; широко известные наборы метрик Чидамбера и Кемерера, Фернандо Абреу, Лоренца и Кидда; описывается методика их применения.
Пятнадцатая глава решает задачу презентации унифицированного процесса разработки объектно-ориентированных программных систем, на конкретном примере обучает методике применения этого процесса. Кроме того, здесь рассматриваются методика управления риском разработки, процесс разработки в стиле «экстремальное программирование».
Шестнадцатая глава обучает особенностям объектно-ориентированного тестирования, проведению такого тестирования на уровне визуальных моделей, уровне методов, уровне классов и уровне взаимодействия классов.
Семнадцатая глава демонстрирует возможности применения CASE-системы Rational Rose к решению задач автоматизации формирования требований, анализа, проектирования, компонентной упаковки и программирования программного продукта.
Учебник предназначен для студентов бакалаврского и магистерского уровней компьютерных специальностей, может быть полезен преподавателям, разработчикам промышленного программного обеспечения, менеджерам программных проектов.
Вот и все. Насколько удалась эта работа — судить Вам, уважаемый читатель.

Благодарности
Прежде всего, мои слова искренней любви родителям — Нине Николаевне и Александру Ивановичу Орловым (светлая им память).
Самые теплые слова благодарности моей семье, родным, любимым и близким мне людям — Лизе, Иванне, Жене. Без их долготерпения, внимания, поддержки, доброжелательности и сердечной заботы эта книга никогда не была бы написана. Моя признательность также и верному сеттеру Эльфу — это он внимательно следил за всеми моими ночными бдениями и клал мне лапу на плечо в особо трудные минуты.
Выход в свет этой работы был бы невозможен вне творческой атмосферы, бесчисленных вопросов и положительной обратной связи, которую создавали мои многочисленные студенты.
Хочется отметить, что корабль-учебник не прибыл бы в порт назначения без опытного капитана (руководителя проекта) Андрея Васильева. Автор искренне признателен талантливым сотрудникам издательства «Питер».
И конечно, огромное спасибо моим коллегам, всем людям, которые принимали участие в моем путешествии по городам, улицам и бесконечным переулкам страны ПРОГРАММНАЯ ИНЖЕНЕРИЯ.

От издательства
Ваши замечания, предложения, вопросы вы можете отправить по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение.
Все исходные тексты, приведенные в книге, вы можете найти по адресу http:// www.piter.com/download.
На web-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

ГЛАВА 1. Организация процесса конструирования

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

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

Технология конструирования программного обеспечения (ТКПО) — система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах [64], [69], [71].
Различают методы, средства и процедуры ТКПО.
Методы обеспечивают решение следующих задач:
планирование и оценка проекта;
анализ системных и программных требований;
проектирование алгоритмов, структур данных и программных структур;
кодирование;
тестирование;
сопровождение.
Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).
Процедуры являются «клеем», который соединяет методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки. Процедуры определяют:
порядок применения методов и утилит;
формирование отчетов, форм по соответствующим требованиям;
контроль, который помогает обеспечивать качество и координировать изменения;
формирование «вех», по которым руководители оценивают прогресс.
Процесс конструирования программного обеспечения состоит из последовательности шагов, использующих методы, утилиты и процедуры. Эти последовательности шагов часто называют парадигмами ТКПО.
Применение парадигм ТКПО гарантирует систематический, упорядоченный подход к промышленной разработке, использованию и сопровождению ПО. Фактически, парадигмы вносят в процесс создания ПО организующее инженерное начало, необходимость которого трудно переоценить.
Рассмотрим наиболее популярные парадигмы ТКПО.

Классический жизненный цикл

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970) [65].
Очень часто классический жизненный цикл называют каскадной или водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе (рис. 1.1).
Охарактеризуем содержание основных этапов.
Подразумевается, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла.
Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.
Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Рис. 1.1. Классический жизненный цикл разработки ПО

Проектирование состоит в создании представлений:
архитектуры ПО;
модульной структуры ПО;
алгоритмической структуры ПО;
структуры данных;
входного и выходного интерфейса (входных и выходных форм данных).
Исходные данные для проектирования содержатся в спецификации анализа, то есть в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
Кодирование состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.
Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений:
исправление ошибок;
адаптация к изменениям внешней для ПО среды;
усовершенствование ПО по требованиям заказчика.
Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе но не в разработке новой программы.
Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.
Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.
Недостатки классического жизненного цикла:
1) реальные проекты часто требуют отклонения от стандартной последовательности шагов;
2) цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);
3) результаты проекта доступны заказчику только в конце работы.

Макетирование

Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в приспосабливаемое™ продукта под операционную систему, форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование.
Основная цель макетирования — снять неопределенности в требованиях заказчика.
Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.
Модель может принимать одну из трех форм:
1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);
2) работающий макет (выполняет некоторую часть требуемых функций);
3) существующая программа (характеристики которой затем должны быть улучшены).
Как показано на рис. 1.2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.

Рис. 1.2. Макетирование

Последовательность действий при макетировании представлена на рис. 1.3. Макетирование начинается со сбора и уточнения требований к создаваемому ПО Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.
Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.
Быстрое проектирование приводит к построению макета.
Макет оценивается заказчиком и используется для уточнения требований к ПО.
Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано.
Достоинство макетирования: обеспечивает определение полных требований к ПО.
Недостатки макетирования:
заказчик может принять макет за продукт;
разработчик может принять макет за продукт.
Поясним суть недостатков. Когда заказчик видит работающую версию ПО, он перестает сознавать, что детали макета скреплены «жевательной резинкой и проволокой»; он забывает, что в погоне за работающим вариантом оставлены нерешенными вопросы качества и удобства сопровождения ПО. Когда заказчику говорят, что продукт должен быть перестроен, он начинает возмущаться и требовать, чтобы макет «в три приема» был превращен в рабочий продукт. Очень часто это отрицательно сказывается на управлении разработкой ПО.

Рис. 1.3. Последовательность действий при макетировании

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

Стратегии конструирования ПО

Существуют 3 стратегии конструирования ПО:
однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;
инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 1.1.

Таблица 1.1. Характеристики стратегий конструирования
Стратегия конструирования
В начале процесса определены все требования?
Множество циклов конструирования?
Промежуточное ПО распространяется?
Однократный проход
Инкрементная (запланированное улучшение продукта)
Эволюционная
Да
Да

Нет
Нет
Да

Да
Нет
Может быть

Да

Инкрементная модель

Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 1.4). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.
Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы.
Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными).
План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.

Рис. 1.4. Инкрементная модель

Забегая вперед, отметим, что современная реализация инкрементного подхода — экстремальное программирование ХР (Кент Бек, 1999) [10]. Оно ориентировано на очень малые приращения функциональности.

Быстрая разработка приложений

Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования (рис. 1.5).
RAD-модель обеспечивает экстремально короткий цикл разработки. RAD — высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:
бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?
моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;
моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;
генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;
тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

Рис. 1.5. Модель быстрой разработки приложений

Применение RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему.
Применение RAD имеет- и свои недостатки, и ограничения.
1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).
2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.
3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

Спиральная модель

Спиральная модель — классический пример применения эволюционной стратегии конструирования.
Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах [19].

Рис. 1.6. Спиральная модель: 1 — начальный сбор требований и планирование проекта;
2 — та же работа, но на основе рекомендаций заказчика; 3 — анализ риска на основе
начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход
к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета;
8 — сконструированная система; 9 — оценивание заказчиком

Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.
1. Планирование — определение целей, вариантов и ограничений.
2. Анализ риска — анализ вариантов и распознавание/выбор риска.
3. Конструирование — разработка продукта следующего уровня.
4. Оценивание — оценка заказчиком текущих результатов конструирования.
Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.
В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Достоинства спиральной модели:
1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
2) позволяет явно учитывать риск на каждом витке эволюции разработки;
3) включает шаг системного подхода в итерационную структуру разработки;
4) использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
1) новизна (отсутствует достаточная статистика эффективности модели);
2) повышенные требования к заказчику;
3) трудности контроля и управления временем разработки.

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

Рис. 1.7. Компонентно-ориентированная модель

Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку.
Достоинства компонентно-ориентированной модели:
1) уменьшает на 30% время разработки программного продукта;
2) уменьшает стоимость программной разработки до 70%;
3) увеличивает в полтора раза производительность разработки.

Тяжеловесные и облегченные процессы

В XXI веке потребности общества в программном обеспечении информационных технологий достигли экстремальных значений. Программная индустрия буквально «захлебывается» от потока самых разнообразных заказов. «Больше процессов разработки, хороших и разных!» — скандируют заказчики. «Сейчас, сейчас! Только об этом и думаем!» — отвечают разработчики.
Традиционно для упорядочения и ускорения программных разработок предлагались строго упорядочивающие тяжеловесные (heavyweight) процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующими (predictive) процессами. Порядок, который должен выполнять при этом человек-разработчик, чрезвычайно строг — «шаг вправо, шаг влево — виртуальный расстрел!». Иными словами, человеческие слабости в расчет не принимаются, а объем необходимой документации способен отнять покой и сон у «совестливого» разработчика.
В последние годы появилась группа новых, облегченных (lightweight) процессов [29]. Теперь их называют подвижными (agile) процессами [8], [25], [36]. Они привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов. Новые процессы должны воплотить в жизнь разумный компромисс между слишком строгой дисциплиной и полным ее отсутствием. Иначе говоря, порядка в них достаточно для того, чтобы получить разумную отдачу от разработчиков.
Подвижные процессы требуют меньшего объема документации и ориентированы на человека. В них явно указано на необходимость использования природных качеств человеческой натуры (а не на применение действий, направленных наперекор этим качествам).
Более того, подвижные процессы учитывают особенности современного заказчика, а именно частые изменения его требований к программному продукту. Известно, что для прогнозирующих процессов частые изменения требований подобны смерти. В отличие от них, подвижные процессы адаптируют изменения требований и даже выигрывают от этого. Словом, подвижные процессы имеют адаптивную природу.
Таким образом, в современной инфраструктуре программной инженерии существуют два семейства процессов разработки:
семейство прогнозирующих (тяжеловесных) процессов;
семейство адаптивных (подвижных, облегченных) процессов.
У каждого семейства есть свои достоинства, недостатки и область применения:
адаптивный процесс используют при частых изменениях требований, малочисленной группе высококвалифицированных разработчиков и грамотном заказчике, который согласен участвовать в разработке;
прогнозирующий процесс применяют при фиксированных требованиях и многочисленной группе разработчиков разной квалификации.

ХР-процесс

Экстремальное программирование (eXtreme Programming, XP) — облегченный (подвижный) процесс (или методология), главный автор которого — Кент Бек (1999) [11]. ХР-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.
Основная идея ХР — устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов* и реляционных баз данных. Поэтому ХР-процесс должен быть высокодинамичным процессом. ХР-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-цикле являются: кодирование, тестирование, выслушивание заказчика и проектирование. Динамизм обеспечивается с помощью четырех характеристик: непрерывной связи с заказчиком (и в пределах группы), простоты (всегда выбирается минимальное решение), быстрой обратной связи (с помощью модульного и функционального тестирования), смелости в проведении профилактики возможных проблем.
* Паттерн является решением типичной проблемы в определенном контексте.

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

Таблица 1.2. Экстремумы в экстремальном программировании
Практика здравого смысла
ХР-экстремум
ХР-реализация
Проверки кода
Код проверяется все время
Парное программирование
Тестирование
Тестирование выполняется все время, даже с помощью заказчиков
Тестирование модуля, функциональное тестирование
Проектирование
Проектирование является частью ежедневной деятельности каждого разработчика
Реорганизация (refactoring)
Простота
Для системы выбирается простейшее проектное решение, поддерживающее ее текущую функциональность
Самая простая вещь, которая могла бы работать
Архитектура
Каждый постоянно работает над уточнением архитектуры
Метафора
Тестирование интеграции
Интегрируется и тестируется несколько раз в день
Непрерывная интеграция
Короткие итерации
Итерации являются предельно короткими, продолжаются секунды, минуты, часы, а не недели, месяцы или годы
Игра планирования

Тот, кто принимает принцип «минимального решения» за хакерство, ошибается, в действительности ХР — строго упорядоченный процесс. Простые решения, имеющие высший приоритет, в настоящее время рассматриваются как наиболее ценные части системы, в отличие от проектных решений, которые пока не нужны, а могут (в условиях изменения требований и операционной среды) и вообще не понадобиться.
Базис ХР образуют перечисленные ниже двенадцать методов.
1. Игра планирования (Planning game) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс).
2. Частая смена версий (Small releases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
3. Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.
4. Простое проектирование (Simple design) — проектирование выполняется настолько просто, насколько это возможно в данный момент.
5. Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант.
6. Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.
7. Парное программирование (Pair programming) — весь код пишется двумя программистами, работающими на одном компьютере.
8. Коллективное владение кодом (Collective ownership) — любой разработчик может улучшать любой код системы в любое время.
9. Непрерывная интеграция (Continuous integration) — система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.
10. 40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.
11. Локальный заказчик (On-site customer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.
12. Стандарты кодирования (Coding standards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.
Игра планирования и частая смена версий зависят от заказчика, обеспечивающего набор «историй» (коротких описаний), характеризующих работу, которая будет выполняться для каждой версии системы. Версии генерируются каждые две недели, поэтому разработчики и заказчик должны прийти к соглашению о том, какие истории будут осуществлены в пределах двух недель. Полную функциональность, требуемую заказчику, характеризует пул историй; но для следующей двухнедельной итерации из пула выбирается подмножество историй, наиболее важное для заказчика. В любое время в пул могут быть добавлены новые истории, таким образом, требования могут быстро изменяться. Однако процессы двухнедельной генерации основаны на наиболее важных функциях, входящих в текущий пул, следовательно, изменчивость управляется. Локальный заказчик обеспечивает поддержку этого стиля итерационной разработки.
«Метафора» обеспечивает глобальное «видение» проекта. Она могла бы рассматриваться как высокоуровневая архитектура, но ХР подчеркивает желательность проектирования при минимизации проектной документации. Точнее говоря, ХР предлагает непрерывное перепроектирование (с помощью реорганизации), при котором нет нужды в детализированной проектной документации, а для инженеров сопровождения единственным надежным источником информации является программный код. Обычно после написания кода проектная документация выбрасывается. Проектная документация сохраняется только в том случае, когда заказчик временно теряет способность придумывать новые истории. Тогда систему помещают в «нафталин» и пишут руководство страниц на пять-десять по «нафталиновому» варианту системы. Использование реорганизации приводит к реализации простейшего решения, удовлетворяющего текущую потребность. Изменения в требованиях заставляют отказываться от всех «общих решений».
Парное программирование — один из наиболее спорных методов в ХР, оно влияет на ресурсы, что важно для менеджеров, решающих, будет ли проект использовать ХР. Может показаться, что парное программирование удваивает ресурсы, но исследования доказали: парное программирование приводит к повышению качества и уменьшению времени цикла. Для согласованной группы затраты увеличиваются на 15%, а время цикла сокращается на 40-50%. Для Интернет-среды увеличение скорости продаж покрывает повышение затрат. Сотрудничество улучшает процесс решения проблем, улучшение качества существенно снижает затраты сопровождения, которые превышают стоимость дополнительных ресурсов по всему циклу разработки.
Коллективное владение означает, что любой разработчик может изменять любой фрагмент кода системы в любое время. Непрерывная интеграция, непрерывное регрессионное тестирование и парное программирование ХР обеспечивают защиту от возникающих при этом проблем.
«Тестируй, а затем кодируй» — эта фраза выражает акцент ХР на тестировании. Она отражает принцип, по которому сначала планируется тестирование, а тестовые варианты разрабатываются параллельно анализу требований, хотя традиционный подход состоит в тестировании «черного ящика». Размышление о тестировании в начале цикла жизни — хорошо известная практика конструирования ПО (правда, редко осуществляемая практически).
Основным средством управления ХР является метрика, а среда метрик — «большая визуальная диаграмма». Обычно используют 3-4 метрики, причем такие, которые видимы всей группе. Рекомендуемой в ХР метрикой является «скорость проекта» — количество историй заданного размера, которые могут быть реализованы в итерации.
При принятии ХР рекомендуется осваивать его методы по одному, каждый раз выбирая метод, ориентированный на самую трудную проблему группы. Конечно, все эти методы являются «не более чем правилами» — группа может в любой момент поменять их (если ее сотрудники достигли принципиального соглашения по поводу внесенных изменений). Защитники ХР признают, что ХР оказывает сильное социальное воздействие, и не каждый может принять его. Вместе с тем, ХР — это методология, обеспечивающая преимущества только при использовании законченного набора базовых методов.
Рассмотрим структуру «идеального» ХР-процесса. Основным структурным элементом процесса является ХР-реализация, в которую многократно вкладывается базовый элемент — ХР-итерация. В состав ХР-реализации и ХР-итерации входят три фазы — исследование, блокировка, регулирование. Исследование (exploration) — это поиск новых требований (историй, задач), которые должна выполнять система. Блокировка (commitment) — выбор для реализации конкретного подмножества из всех возможных требований (иными словами, планирование). Регулирование (steering) — проведение разработки, воплощение плана в жизнь.
ХР рекомендует: первая реализация должна иметь длительность 2-6 месяцев, продолжительность остальных реализаций — около двух месяцев, каждая итерация длится приблизительно две недели, а численность группы разработчиков не превышает 10 человек. ХР-процесс для проекта с семью реализациями, осуществляемый за 15 месяцев, показан на рис. 1.8.
Процесс инициируется начальной исследовательской фазой.
Фаза исследования, с которой начинается любая реализация и итерация, имеет клапан «пропуска», на этой фазе принимается решение о целесообразности дальнейшего продолжения работы.
Предполагается, что длительность первой реализации составляет 3 месяца, длительность второй — седьмой реализаций — 2 месяца. Вторая — седьмая реализации образуют период сопровождения, характеризующий природу ХР-проекта. Каждая итерация длится две недели, за исключением тех, которые относят к поздней стадии реализации — «запуску в производство» (в это время темп итерации ускоряется).
Наиболее трудна первая реализация — пройти за три месяца от обычного старта (скажем, отдельный сотрудник не зафиксировал никаких требований, не определены ограничения) к поставке заказчику системы промышленного качества очень сложно.

Рис. 1.8. Идеальный ХР-процесс

Модели качества процессов конструирования

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/ IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model — СММ) Института программной инженерии при американском университете Карнеги-Меллон.
Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.
Базовым понятием модели СММ считается зрелость компании [61], [62]. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.
Напротив, в зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения.
Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов.
Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости (рис. 1.9) и предусмотрен плавный, поэтапный подход к совершенствованию процессов — можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости.

Рис. 1.9. Пять уровней зрелости модели СММ

Начальный уровень (уровень 1) означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный характер. Результат работы целиком и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается.
Для перехода на повторяемый уровень (уровень 2) необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов.
Следующий, определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.
С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.
Высший, оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.
Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:
предотвращения дефектов;
управления изменениями технологии;
управления изменениями процесса.
Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ.

Контрольные вопросы

1. Дайте определение технологии конструирования программного обеспечения.
2. Какие этапы классического жизненного цикла вы знаете?
3. Охарактеризуйте содержание этапов классического жизненного цикла.
4. Объясните достоинства и недостатки классического жизненного цикла.
5. Чем отличается классический жизненный цикл от макетирования?
6. Какие существуют формы макетирования?
7. Чем отличаются друг от друга стратегии конструирования ПО?
8. Укажите сходства и различия классического жизненного цикла и инкрементной модели.
9. Объясните достоинства и недостатки инкрементной модели.
10. Чем отличается модель быстрой разработки приложений от инкрементной модели?
11. Объясните достоинства и недостатки модели быстрой разработки приложений.
12. Укажите сходства и различия спиральной модели и классического жизненного цикла.
13. В чем состоит главная особенность спиральной модели?
14. Чем отличается компонентно-ориентированная модель от спиральной модели и классического жизненного цикла?
15. Перечислите достоинства и недостатки компонентно-ориентированной модели.
16. Чем отличаются тяжеловесные процессы от облегченных процессов?
17. Чем отличаются тяжеловесные процессы от прогнозирующих процессов?
18. Чем отличаются подвижные процессы от облегченных процессов?
19. Перечислите достоинства и недостатки тяжеловесных процессов.
20. Перечислите достоинства и недостатки облегченных процессов.
21. Приведите примеры тяжеловесных процессов.
22. Приведите примеры облегченных процессов.
23. Перечислите характеристики ХР-процесса.
24. Перечислите методы ХР-процесса.
25. В чем состоит главная особенность ХР-процесса?
26. Охарактеризуйте содержание игры планирования в ХР-процессе.
27. Охарактеризуйте назначение метафоры в ХР-процессе.
28. Какова особенность проектирования в ХР-процессе?
29. Какова особенность программирования в ХР-процессе?
30. Что такое реорганизация?
31. Что такое коллективное владение?
32. Какова особенность тестирования в ХР-процессе?
33. Чем отличается ХР-реализация от ХР-итерации?
34. Чем ХР-реализация похожа на ХР-итерацию?
35. Какова длительность ХР-реализации?
36. Какова длительность ХР-итерации?
37. Какова максимальная численность группы ХР-разработчиков?
38. Какие модели качества процессов конструирования вы знаете?
39. Охарактеризуйте модель СММ.
40. Охарактеризуйте уровень зрелости знакомой вам фирмы.

ГЛАВА 2. Руководство программным проектом

В этой главе детально рассматривается такой элемент процесса конструирования ПО, как руководство программным проектом. Читатель знакомится с вопросами планирования проекта, оценки затрат проекта. В данной главе обсуждаются размерно-ориентированные и функционально-ориентированные метрики затрат, методика их применения. Достаточно подробно описывается наиболее популярная модель для оценивания затрат — СОСОМО II. В качестве иллюстраций приводятся примеры предварительного оценивания проекта, анализа влияния на проект конкретных условий разработки.

Процесс руководства проектом

Руководство программным проектом — первый слой процесса конструирования ПО. Термин «слой» подчеркивает, что руководство определяет сущность процесса разработки от его начала до конца. Принцип руководства иллюстрирует рис. 2.1.

Рис. 2.1. Руководство в процессе конструирования ПО

На этом рисунке прямоугольник обозначает процесс конструирования, в нем выделены этапы, а вверху, над каждым из этапов, размещен слой деятельности «руководство программным проектом».
Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ [32], [64], [69].

Начало проекта

Перед планированием проекта следует:
установить цели и проблемную область проекта;
обсудить альтернативные решения;
выявить технические и управленческие ограничения.

Измерения, меры и метрики

Измерения помогают понять как процесс разработки продукта, так и сам продукт. Измерения процесса производятся в целях его улучшения, измерения продукта — для повышения его качества. В результате измерения определяется мера — количественная характеристика какого-либо свойства объекта. Путем непосредственных измерений могут определяться только опорные свойства объекта. Все остальные свойства оцениваются в результате вычисления тех или иных функций от значений опорных характеристик. Вычисления этих функций проводятся по формулам, дающим числовые значения и называемым метриками.
В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы.

Процесс оценки

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

Анализ риска

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

Планирование

Трассировка и контроль

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

Планирование проектных задач

Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.
Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для последующих параллельных задач.
Системный анализ проводится с целью:
1) выяснения потребностей заказчика;
2) оценки выполнимости системы;
3) выполнения экономического и технического анализа;
4) распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);
5) определения стоимости и ограничений планирования;
6) создания системной спецификации.
В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация.
Анализ требований дает возможность:
1) определить функции и характеристики программного продукта;
2) обозначить интерфейс продукта с другими системными элементами;
3) определить проектные ограничения программного продукта;
4) построить модели: процесса, данных, режимов функционирования продукта;
5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

Результаты анализа сводятся в спецификацию требований к программному продукту.
Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования. После получения всех модулей ПО решается задача тестирования интеграции — объединения элементов в единое целое. Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика.
Ромбиками на рис. 2.2 обозначены вехи — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи.
Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.
Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи.
Обычно используют следующие оценки:
1. Раннее время начала решения задачи (при условии, что все предыдущие задачи решены в кратчайшее время).
2. Позднее время начала решения задачи (еще не вызывает общую задержку проекта).
3. Раннее время конца решения задачи .
.
4. Позднее время конца решения задачи .
.
5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Тк.п.
Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач.
Рекомендуемое правило распределения затрат проекта — 40-20-40:
на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ — 5%);
на кодирование — 20%;
на тестирование и отладку — 40%.

Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте.
Исходные данные для расчета этих метрик сводятся в таблицу (табл. 2.1).

Таблица 2.1. Исходные данные для расчета LOC-метрик
Проект
Затраты, чел.-мес
Стоимость, тыс. $
KLOC, тыс. LOC
Прогр. док- ты, страниц
Ошибки
Люди
ааа01
24
168
12,1
365
29
3
bbb02
62
440
27,2
1224
86
5
ссс03
43
314
20,2
1050
64
6

Таблица содержит данные о проектах за последние несколько лет. Например, запись о проекте aaa01 показывает: 12 100 строк программы были разработаны за 24 человеко-месяца и стоили $168 000. Кроме того, по проекту aaa01 было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект aaa01 три человека.
На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):
;
;
;
.
Достоинства размерно-ориентированных метрик:
1) широко распространены;
2) просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
1) зависимы от языка программирования;
2) требуют исходных данных, которые трудно получить на начальной стадии проекта;
3) не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик.
1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.
3. Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы — каждый учитывается отдельно.
4. Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Вводы, выводы и запросы относят к категории транзакция. Транзакция — это элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программным приложением. В своей работе транзакции используют внутренние и внешние файлы. Приняты следующие определения.
Внешний ввод — элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения. Данные могут использоваться для обновления внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл.
Внешний вывод — элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложениям. Отчеты и файлы создаются на основе внутренних логических файлов и внешних интерфейсных файлов. Дополнительно этот процесс может использовать вводимые данные, их образуют критерии поиска и параметры, не поддерживаемые внутренними логическими файлами. Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле.
Внешний запрос — элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат — данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логические файлы, а выходная часть не несет данных, вычисляемых приложением (в этом и состоит отличие запроса от вывода).
Внутренний логический файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы.
Внешний интерфейсный файл — распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга.
Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входящих в файл.
Тип элемента-записи — подгруппа элементов данных, распознаваемая пользователем в пределах файла.
Тип элемента данных — уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем. В качестве примера рассмотрим табл. 2.2.
В этой таблице 10 элементов данных: День, Хиты, % от Сумма хитов, Сеансы пользователя, Сумма хитов (по рабочим дням), % от Сумма хитов (по рабочим дням), Сумма сеансов пользователя (по рабочим дням), Сумма хитов (по выходным дням), % от Сумма хитов (по выходным дням), Сумма сеансов пользователя (по выходным дням). Отметим, что поля День, Хиты, % от Сумма хитов, Сеансы пользователя имеют рекурсивные данные, которые в расчете не учитываются.

Таблица 2.2. Пример для расчета элементов данных
Уровень активности дня недели
День
Хиты
% от Сумма хитов
Сеансы пользователя
Понедельник
1887
16,41
201
Вторник
1547
13,45
177
Среда
1975
17,17
195
Четверг
1591
13,83
191
Пятница
2209
19,21
200
Суббота
1286
11,18
121
Воскресенье
1004
8,73
111
Сумма по рабочим дням
9209
80,08
964
Сумма по выходным дням
2290
19,91
232

Примеры элементов данных для различных характеристик приведены в табл. 2.3, а табл. 2.4 содержит правила учета элементов данных из графического интерфейса пользователя (GUI).

Таблица 2.3. Примеры элементов данных
Информационная характеристика
Элементы данных
Внешние Вводы
Внешние Выводы

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

Таблица 2.4. Правила учета элементов данных из графического интерфейса пользователя

Элемент данных
Правило учета
Группа радиокнопок

Группа флажков (переключателей)
Командные кнопки

Списки
Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных
Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных
Командная кнопка может определять действие добавления, изменения, запроса. Кнопка ОК может вызывать транзакции (различных типов). Кнопка Next может быть входным элементом запроса или вызывать другую транзакцию. Каждая кнопка считается отдельным элементом данных
Список может быть внешним запросом, но результат запроса может быть элементом данных внешнего ввода
Например, GUI для обслуживания клиентов может иметь поля Имя, Адрес, Город, Страна, Почтовый Индекс, Телефон, Email. Таким образом, имеется 7 полей или семь элементов данных. Восьмым элементом данных может быть командная кнопка (добавить, изменить, удалить). В этом случае каждый из внешних вводов Добавить, Изменить, Удалить будет состоять из 8 элементов данных (7 полей плюс командная кнопка).
Обычно одному экрану GUI соответствует несколько транзакций. Типичный экран включает несколько внешних запросов, сопровождающих внешний ввод.
Обсудим порядок учета сообщений. В приложении с GUI генерируются 3 типа сообщений: сообщения об ошибке, сообщения подтверждения и сообщения уведомления. Сообщения об ошибке (например, Требуется пароль) и сообщения подтверждения (например, Вы действительно хотите удалить клиента?) указывают, что произошла ошибка или что процесс может быть завершен. Эти сообщения не образуют самостоятельного процесса, они являются частью другого процесса, то есть считаются элементом данных соответствующей транзакции.
С другой стороны, уведомление является независимым элементарным процессом. Например, при попытке получить из банкомата сумму денег, превышающую их количество на счете, генерируется сообщение Не хватает средств для завершения транзакции. Оно является результатом чтения информации из файла счета и формирования заключения. Сообщение уведомления рассматривается как внешний вывод.
Данные для определения ранга и оценки сложности транзакций и файлов приведены в табл. 2.5-2.9 (числовая оценка указана в круглых скобках). Использовать их очень просто. Например, внешнему вводу, который ссылается на 2 файла и имеет 7 элементов данных, по табл. 2.5 назначается средний ранг и оценка сложности 4.

Таблица 2.5. Ранг и оценка сложности внешних вводов

Ссылки на файлы
Элементы данных

1-4
5-15
>15
0-1
2
>2
Низкий (3)
Низкий (3)
Средний (4)
Низкий (3)
Средний (4)
Высокий (6)
Средний (4)
Высокий (6)
Высокий (6)

Таблица 2.6. Ранг и оценка сложности внешних выводов

Ссылки на файлы
Элементы данных

1-4
5-19
>19
0-1
2-3
>3
Низкий (4)
Низкий (4)
Средний (5)
Низкий (4)
Средний (5)
Высокий (7)
Средний (5)
Высокий (7)
Высокий (7)

Таблица 2.7. Ранг и оценка сложности внешних запросов

Ссылки на файлы
Элементы данных

1-4
5-19
>19
0-1
2-3
>3
Низкий (3)
Низкий (3)
Средний (4)
Низкий (3)
Средний (4)
Высокий (6)
Средний (4)
Высокий (6)
Высокий (6)

Таблица 2.8. Ранг и оценка сложности внутренних логических файлов

Типы элементов-записей
Элементы данных

1-19
20-50
>50
1
2-5
>5
Низкий (7)
Низкий (7)
Средний (10)
Низкий (7)
Средний (10)
Высокий (15)
Средний (10)
Высокий (15)
Высокий (15)

Таблица 2.9. Ранг и оценка сложности внешних интерфейсных файлов
Типы элементов-записей
Элементы данных

1-19
20-50
>50
1
2-5
>5
Низкий (5)
Низкий (5)
Средний (7)
Низкий (5)
Средний (7)
Высокий (10)
Средний (7)
Высокий (10)
Высокий (10)
Отметим, что если во внешнем запросе ссылка на файл используется как на этапе ввода, так и на этапе вывода, она учитывается только один раз. Такое же правило распространяется и на элемент данных (однократный учет).
После сбора всей необходимой информации приступают к расчету метрики — количества функциональных указателей FP (Function Points). Автором этой метрики является А. Албрехт (1979) [7].
Исходные данные для расчета сводятся в табл. 2.10.

Таблица 2.10. Исходные данные для расчета FP-метрик

Имя характеристики
Ранг, сложность, количество

Низкий
Средний
Высокий
Итого
Внешние вводы
0x3 = __
0x4 = __
0x6 = __
= 0
Внешние выводы
0x4 = __
0x5 = __
0x7 = __
= 0
Внешние запросы
0х3 = __
0x4 = __
0x6 = __
= 0
Внутренние логические файлы
Внешние интерфейсные файлы
0x7 = __
0x5 = __
0x 10= __
0x7 = __
0x15 = __
0x10 = __
= 0
= 0
Общее количество
= 0

Таблица 2.11. Определение системных параметров приложения

№
Системный параметр
Описание
1
Передачи данных
Сколько средств связи требуется для передачи или обмена информацией с приложением или системой?
2
Распределенная обработка данных
Как обрабатываются распределенные данные и функции обработки?
3
Производительность
Нуждается ли пользователь в фиксации времени ответа или производительности?.
4
Распространенность используемой конфигурации
Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?
5
Скорость транзакций
Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц)
6
Оперативный ввод данных
Какой процент информации надо вводить в режиме онлайн?
7
Эффективность работы конечного пользователя
Приложение проектировалось для обеспечения эффективной работы конечного пользователя?
8
Оперативное обновление
Как много внутренних файлов обновляется в онлайновой транзакции?
9
Сложность обработки
Выполняет ли приложение интенсивную логическую или математическую обработку?
10
Повторная используемость
Приложение разрабатывалось для удовлетворения требований одного или многих пользователей?
11
Легкость инсталляции
Насколько трудны преобразование и инсталляция приложения?
12
Легкость эксплуатации
Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?
13
Разнообразные условия размещения
Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций?
14
Простота изменений
Была ли спроектирована, разработана и поддержана в приложении простота изменений?

После вычисления FP на его основе формируются метрики производительности, качества и т. д.:
;
;
;
.

Область применения метода функциональных указателей — коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО.
Для вычисления указателя свойств добавляется одна характеристика — количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 2.12.

Таблица 2.12. Исходные данные для расчета указателя свойств
№
Характеристика
Количество
Сложность
Итого
1
Вводы
0
х4
= 0
2
Выводы
0
х5
= 0
3
Запросы
0
х4
= 0
4
Логические файлы
0
х7
= 0
5
Интерфейсные файлы
0
х7
= 0
6
Количество алгоритмов
0
х3
= 0
Общее количество
= 0

После заполнения таблицы по формуле (2.1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.
Достоинства функционально-ориентированных метрик:
1. Не зависят от языка программирования.
2. Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения. FP-оценки легко пересчитать в LOC-оценки. Как показано в табл. 2.13, результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Таблица 2.13. Пересчет FP-оценок в LOC-оценки
Язык программирования
Количество операторов на один FP
Ассемблер
С
320
128
Кобол
106
Фортран
106
Паскаль
90
C++
64
Java
53
Ada 95
49
Visual Basic
32
Visual C++
34
Delphi Pascal
29
Smalltalk
22
Perl
21
HTML3
15
LISP
64
Prolog
64
Miranda
40
Haskell
38

Выполнение оценки в ходе руководства проектом

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

Выполнение оценки проекта на основе LOC- и FP-метрик

Цель этой деятельности — сформировать предварительные оценки, которые позволят:
предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;
составить план программного проекта.
При выполнении оценки возможны два варианта использования LOC- и FP-данных:
в качестве оценочных переменных, определяющих размер каждого элемента продукта;
в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы.
Обсудим шаги процесса оценки.
Шаг 1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально:
f1, f2,…,fn.
Шаг 2. Для каждой функции fi, планировщик формирует лучшую LOCлучшi (FРлучшi), худшую LOCхудшi (FРхудшi) и вероятную оценку LOCвероятнi (FРвероятнi). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.
Шаг 3. Для каждой функции/ в соответствии с -распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:
LOCожi =(LOCлучшi + LOCхудшi +4x LOCвероятнi )/ 6.
Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.
Используется один из трех подходов:
1) для всех функций принимается одна и та же метрика средней производительности ПРОИЗВср, взятая из метрического базиса;
2) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:
ПРОИЗВi =ПРОИЗВсрх(LOCср /LOCожi),
где LOCcp — средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);
3) для i-й функции настраиваемая величина производительности вычисляется по аналогу, взятому из метрического базиса:
ПРОИЗВi =ПРОИЗВанiх(LOCанi /LOCожi).
Первый подход обеспечивает минимальную точность (при максимальной простоте вычислений), а третий подход — максимальную точность (при максимальной сложности вычислений).
Шаг 5. Вычисляется общая оценка затрат на проект: для первого подхода
;
для второго и третьего подходов
.
Шаг 6. Вычисляется общая оценка стоимости проекта: для первого и второго подходов
,
где УД_СТОИМОСТЬср — метрика средней стоимости одной строки, взятая из метрического базиса.
для третьего подхода

где УД_СТОИМОСТЬанi — метрика стоимости одной строки аналога, взятая из метрического базиса. Пример применения данного процесса оценки приведем ниже.

Конструктивная модель стоимости

В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) —дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели [1].
Иерархию подмоделей Боэма (версии 1981 года) образуют:
базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;
промежуточная СОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;
усовершенствованная СОСОМО — объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).
Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:
распространенный тип — небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту;
полунезависимый тип — средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;
встроенный тип — программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.
Уравнения базовой подмодели имеют вид
Е=аbx(KLOC)[чел-мес];
D = cbx (E) [мес],
где Е — затраты в человеко-месяцах, D — время разработки, KLOC — количество строк в программном продукте.
Коэффициенты аb, bb, сb, db берутся из табл. 2.14.

Таблица 2.14. Коэффициенты для базовой подмодели СОСОМО 81
Тип проекта
аb
bb
сb
db
Распространенный
2,4
1,05
2,5
0,38
Полунезависимый
3,0
1,12
2,5
0,35
Встроенный
3,6
1,20
2,5
0,32

В 1995 году Боэм ввел более совершенную модель СОСОМО II, ориентированную на применение в программной инженерии XXI века [21].
В состав СОСОМО II входят:
модель композиции приложения;
модель раннего этапа проектирования;
модель этапа пост-архитектуры.
Для описания моделей СОСОМО II требуется информация о размере программного продукта. Возможно использование LOC-оценок, объектных указателей, функциональных указателей.

Модель композиции приложения

Модель композиции используется на ранней стадии конструирования ПО, когда:
рассматривается макетирование пользовательских интерфейсов;
обсуждается взаимодействие ПО и компьютерной системы;
оценивается производительность;
определяется степень зрелости технологии.
Модель композиции приложения ориентирована на применение объектных указателей.
Объектный указатель — средство косвенного измерения ПО, для его расчета определяется количество экранов (как элементов пользовательского интерфейса), отчетов и компонентов, требуемых для построения приложения. Как показано в табл. 2.15, каждый объектный экземпляр (экран, отчет) относят к одному из трех уровней сложности. Здесь места подстановки измеренных и вычисленных значений отмечены прямоугольниками (прямоугольник играет роль метки-заполнителя). В свою очередь, сложность является функцией от параметров клиентских и серверных таблиц данных (см. табл. 2.16 и 2.17), которые требуются для генерации экрана и отчета, а также от количества представлений и секций, входящих в экран или отчет.

Таблица 2.15. Оценка количества объектных указателей
Тип объекта
Количество
Вес


Итого


Простой
Средний
Сложный

Экран
0
х1
х2
х3
= 0
Отчет
0
х2
х5
х8
= 0
3GL компонент
0


х10
= 0
Объектные указатели




= 0

Таблица 2.16. Оценка сложности экрана
Экраны
Количество серверных (срв) и клиентских (клт) таблиц данных
Количество представлений
Всего < 4
(< 2 срв, <3клт)
Всего < 8
(2-3 срв, 3-5 клт)
Всего > 8
(>3срв, >5клт)
<3
Простой
Простой
Средний
3-7
Простой
Средний
Сложный
>8
Средний
Сложный
Сложный

Таблица 2.17. Оценка сложности отчета
Отчеты
Количество серверных (срв) и клиентских (клт) таблиц данных
Количество представлений
Всего < 4
(< 2 срв, < 3 клт)
Всего < 8
(2-3 срв, 3-5 клт)
Всего > 8
(>3срв, > 5 клт)
0 или 1
Простой
Простой
Средний
2 или 3
Простой
Средний
Сложный
>4
Средний
Сложный
Сложный

После определения сложности количество экранов, отчетов и компонентов взвешивается в соответствии с табл. 2.15. Количество объектных указателей определяется перемножением исходного числа объектных экземпляров на весовые коэффициенты и последующим суммированием промежуточных результатов.
Для учета реальных условий разработки вычисляется процент повторного использования программных компонентов %REUSE и определяется количество новых объектных указателей NOP:
NOP = (Объектные указатели) х [(100 - %REUSE) /100].
Для оценки затрат, основанной на величине NOP, надо знать скорость разработки продукта PROD. Эту скорость определяют по табл. 2.18, учитывающей уровень опытности разработчиков и зрелость среды разработки.
Проектные затраты оцениваются по формуле
ЗАТРАТЫ = NOP /PROD [чел.-мес],
где PROD — производительность разработки, выраженная в терминах объектных указателей.

Таблица 2.18. Оценка скорости разработки
Опытность / возможности разработчика
Зрелость / возможности среды разработки
PROD
Очень низкая
Очень низкая
4
Низкая
Низкая
7
Номинальная
Номинальная
13
Высокая
Высокая
25
Очень высокая
Очень высокая
50
В более развитых моделях дополнительно учитывается множество масштабных факторов, формирователей затрат, процедур поправок.

Модель раннего этапа проектирования

Разрешение архитектуры /риска RESL

Связность группы TEAM

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

В качестве иллюстрации рассмотрим компанию, которая берет проект в малознакомой проблемной области. Положим, что заказчик не определил используемый процесс разработки и не допускает выделения времени на всесторонний анализ риска. Для реализации этой программной системы нужно создать новую группу разработчиков. Компания имеет возможности, соответствующие 2-му уровню зрелости согласно модели СММ. Возможны следующие значения масштабных факторов:
предсказуемость. Это новый проект для компании — значение Низкий (4);
гибкость разработки. Заказчик требует некоторого согласования — значение Очень высокий (1);
разрешение архитектуры/риска. Не выполняется анализ риска, как следствие, малое разрешение риска — значение Очень низкий (5);
связность группы. Новая группа, нет информации — значение Номинальный (3);
зрелость процесса. Имеет место некоторое управление процессом — значение Номинальный (3).

Таблица 2.20. Оценка масштабных факторов

Масштабный фактор (Wi)
Очень низкий 5
Низкий 4
PRЕС
Полностью непредсказуемый проект
Главным образом, в значительной степени непредсказуемый
FLEX
Точный, строгий процесс разработки
Редкое расслабление в работе
RESL
Малое разрешение риска (20%)
Некоторое (40%)
TEAM
Очень трудное взаимодействие
Достаточно трудное взаимодействие
PREC
Полностью непредсказуемый проект
В значительной степени непредсказуемый
РМАТ
Взвешенное среднее значение от количества ответов «Yes» на вопросник СММ Maturity
Сумма этих значений равна 16, поэтому конечное значение степени В= 1,17. Вернемся к обсуждению основного уравнения модели раннего этапа проектирования. Множитель поправки Мe зависит от набора формирователей затрат, перечисленных в табл. 2.21.
Для каждого формирователя затрат определяется оценка (по 6-балльной шкале), где 1 соответствует очень низкому значению, а 6 — сверхвысокому значению. На основе оценки для каждого формирователя по таблице Боэма определяется множитель затрат EMi Перемножение всех множителей затрат формирует множитель поправки:
.
Слагаемое 3ATPATbIauto используется, если некоторый процент программного кода генерируется автоматически. Поскольку производительность такой работы значительно выше, чем при ручной разработке кода, требуемые затраты вычисляются отдельно, по следующей формуле:
ЗАТРАТЫаuto = (КALOC x (AT /100)) / ATPROD,
где:
KALOC — количество строк автоматически генерируемого кода (в тысячах строк);
AT — процент автоматически генерируемого кода (от всего кода системы);
ATPROD — производительность автоматической генерации кода.
Сомножитель AT в этой формуле позволяет учесть затраты на организацию взаимодействия автоматически генерируемого кода с оставшейся частью системы.
Далее затраты на автоматическую генерацию добавляются к затратам, вычисленным для кода, разработанного вручную.
Номинальный 3
Высокий 2
Очень высокий 1
Сверхвысокий 0
Отчасти
Большей частью
В значительной
Полностью знакомый
непредсказуемый
знакомый
степени знакомый

Некоторое расслабление в работе
Большей частью согласованный процесс
Некоторое согласование процесса
Заказчик определил только общие цели
Частое (60%)
Большей частью (75%)
Почти всегда (90%)
Полное (100%)
Среднее
Главным образом
Высокая
Безукоризненное
взаимодействие
кооперативность
кооперативность
взаимодействие
Отчасти непредсказуемый
Большей частью знакомый
В значительной степени знакомый
Полностью знакомый
Взвешенное среднее значение от количества ответов «Yes» на вопросник СММ Maturity

Таблица 2.21. Формирователи затрат для раннего этапа проектирования

Обозначение
Название
PERS
RCPX
RUSE
PDIF
PREX
FСIL
SCED
Возможности персонала (Personnel Capability)
Надежность и сложность продукта (Product Reliability and Complexity)
Требуемое повторное использование (Required Reuse)
Трудность платформы (Platform Difficulty)
Опытность персонала (Personnel Experience)
Средства поддержки (Facilities)
График (Schedule)

Модель этапа постархитектуры

Модель этапа постархитектуры используется в период, когда уже сформирована архитектура и выполняется дальнейшая разработка программного продукта.
Основное уравнение постархитектурной модели является развитием уравнения предыдущей модели и имеет следующий вид:
ЗАТРАТЫ = А х К~req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес],
где
коэффициент К~req учитывает возможные изменения в требованиях;
показатель В отражает нелинейную зависимость затрат от размера проекта (размер выражается в KLOC), вычисляется так же, как и в предыдущей модели;
в размере проекта различают две составляющие — новый код и повторно используемый код;
множитель поправки Мр зависит от 17 факторов затрат, характеризующих продукт, аппаратуру, персонал и проект.
Изменчивость требований приводит к повторной работе, требуемой для учета предлагаемых изменений, оценка их влияния выполняется по формуле
К~req =l + (BRAK/100),
где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований.
Размер проекта и продукта определяют по выражению
РАЗМЕР = PA3MEPnew + PA3MEPreuse [KLOC],
где
PA3MEPnew — размер нового (создаваемого) программного кода;
PA3MEPreuse — размер повторно используемого программного кода.
Формула для расчета размера повторно используемого кода записывается следующим образом:
PA3MEPreuse =KASLOC x ((100 - AT)/ 100) x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM) /100,
где
KASLOC — количество строк повторно используемого кода, который должен быть модифицирован (в тысячах строк);
AT — процент автоматически генерируемого кода;
DM — процент модифицируемых проектных моделей;
CM — процент модифицируемого программного кода;
IM — процент затрат на интеграцию, требуемых для подключения повторно используемого ПО;
SU — фактор, основанный на стоимости понимания добавляемого ПО; изменяется от 50 (для сложного неструктурированного кода) до 10 (для хорошо написанного объектно-ориентированного кода);
АА — фактор, который отражает стоимость решения о том, может ли ПО быть повторно используемым; зависит от размера требуемого тестирования и оценивания (величина изменяется от 0 до 8).
Правила выбора этих параметров приведены в руководстве по СОСОМО II.
Для определения множителя поправки Мр основного уравнения используют 17 факторов затрат, которые могут быть разбиты на 4 категории. Перечислим факторы затрат, сгруппировав их по категориям.
Факторы продукта:
1) требуемая надежность ПО — RELY;
2) размер базы данных — DATA;
3) сложность продукта — CPLX;
4) требуемая повторная используемость — RUSE;
5) документирование требований жизненного цикла — DOCU.
Факторы платформы (виртуальной машины):
6) ограничения времени выполнения — TIME;
7) ограничения оперативной памяти — STOR;
8) изменчивость платформы — PVOL.
Факторы персонала:
9) возможности аналитика — АСАР;
10) возможности программиста — РСАР;
11) опыт работы с приложением — АЕХР;
12) опыт работы с платформой — РЕХР;
13) опыт работы с языком и утилитами — LTEX;
14) непрерывность персонала — PCON.
Факторы проекта:
15) использование программных утилит — TOOL;
16) мультисетевая разработка — SITE;
17) требуемый график разработки — SCED.
Для каждого фактора определяется оценка (по 6-балльной шкале). На основе оценки для каждого фактора по таблице Боэма определяется множитель затрат ЕМi. Перемножение всех множителей затрат дает множитель поправки пост-архитектурной модели:
.
Значение Мр отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат.

ПРИМЕЧАНИЕ
Трудоемкость работы с факторами затрат минимизируется за счет использования специальных таблиц. Справочный материал для оценки факторов затрат приведен в приложении А.

От оценки затрат легко перейти к стоимости проекта. Переход выполняют по формуле:
СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ,
где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц.
После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо:
Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))] х SCEDPercentage/100 [мес],
где
В — ранее рассчитанный показатель степени;
SCEDPercentage — процент увеличения (уменьшения) номинального графика.
Если нужно определить номинальный график, то принимается SCEDPercentage =100 и правый сомножитель в уравнении обращается в единицу. Следует отметить, что СОСОМО II ограничивает диапазон уплотнения/растягивания графика (от 75 до 160%). Причина проста — если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска.
Рассмотрим пример. Положим, что затраты на проект равны 20 человеко-месяцев. Примем, что все масштабные факторы номинальны (имеют значения 3), поэтому, в соответствии с табл. 2.20, показатель степени 5=1,16. Отсюда следует, что номинальная длительность проекта равна
TDEV = 3, Ox (20)0,36 = 8,8 мес.
Отметим, что зависимость между затратами и количеством разработчиков носит характер, существенно отличающийся от линейного. Очень часто увеличение количества разработчиков приводит к возрастанию затрат. В чем причина? Ответ прост:
увеличивается время на взаимодействие и обучение сотрудников, согласование совместных решений;
возрастает время на определение интерфейсов между частями программной системы.
Удвоение разработчиков не приводит к двукратному сокращению длительности проекта. Модель СОСОМО II явно утверждает, что длительность проекта является функцией требуемых затрат, прямой зависимости от количества сотрудников нет. Другими словами, она устраняет миф нерадивых менеджеров в том, что добавление людей поможет ликвидировать отставание в проекте.
СОСОМО II предостерегает от определения потребного количества сотрудников путем деления затрат на длительность проекта. Такой упрощенный подход часто приводит к срыву работ. Реальная картина имеет другой характер. Количество людей, требуемых на этапе планирования и формирования требований, достаточно мало. На этапах проектирования и кодирования потребность в увеличении команды возрастает, после окончания кодирования и тестирования численность необходимых сотрудников достигает минимума.

Предварительная оценка программного проекта

В качестве иллюстрации применения методики оценки, изложенной в разделе «Выполнение оценки проекта на основе LOC- и FP-метрик», рассмотрим конкретный пример. Предположим, что поступил заказ от концерна «СУПЕРАВТО». Необходимо создать ПО для рабочей станции дизайнера автомобиля (РДА). Заказчик определил проблемную область проекта в своей спецификации:
ПО РДА должно формировать 2- и 3-мерные изображения для дизайнера;
дизайнер должен вести диалог с РДА и управлять им с помощью стандартизованного графического пользовательского интерфейса;
геометрические данные и прикладные данные должны содержаться в базе данных РДА;
модули проектного анализа рабочей станции должны формировать данные для широкого класса дисплеев SVGA;
ПО РДА должно управлять и вести диалог со следующими периферийными устройствами: мышь, дигитайзер (графический планшет для ручного ввода), плоттер (графопостроитель), сканер, струйный и лазерный принтеры.
Прежде всего надо детализировать проблемную область. Следует выделить базовые функции ПО и очертить количественные границы. Очевидно, нужно определить, что такое «стандартизованный графический пользовательский интерфейс», какими должны быть размер и другие характеристики базы данных РДА и т. д.
Будем считать, что эта работа проделана и что идентифицированы следующие основные функции ПО:
1. Средства управления пользовательским интерфейсом СУПИ.
2. Анализ двухмерной графики А2Г.
3. Анализ трехмерной графики А3Г.
4. Управление базой данных УБД.
5. Средства компьютерной дисплейной графики КДГ.
6. Управление периферией УП.
7. Модули проектного анализа МПА.
Теперь нужно оценить каждую из функций количественно, с помощью LOC-оценки. По каждой функции эксперты предоставляют лучшее, худшее и вероятное значения. Ожидаемую LOC-оценку реализации функции определяем по формуле
LOCожi =(LOCлучшi +LOCхудшi +4 х LOCвероятнi)/6,
результаты расчетов заносим в табл. 2.22.

Таблица 2.22. Начальная таблица оценки проекта
Функция
Лучш. [LOC]
Вероят. [LOC]
Худш. [LOC]
Ожид. [LOC]
Уд. стоимость [$/LОС]
Стоимость[$]
Произв. [LOC/ [чел-мес]
Затраты [чел-мес]
СУПИ
1800
2400
2650
2340

А2Г
4100
5200
7400
5380

АЗГ
4600
6900
8600
6800

УБД
2950
3400
3600
3350

КДГ
4050
4900
6200
4950

УП
2000
2100
2450
2140

МПА
6600
8500
9800
8400

Итого
33360

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

Таблица 2.23. Данные из метрического базиса фирмы
Функция
LOCанi
УД_СТОИМОСТЬанi[$ / LOC]
ПРОИЗВанi[LOC/чел-мес]
СУПИ
585
14
1260
А_Г
3000
20
440
УБД
1117
18
720
КДГ
2475
22
400
УП
214
28
1400
МПА
1400
18
1800

Считается, что удельная стоимость строки является константой и не изменяется от реализации к реализации. Следовательно, стоимость разработки каждой функции рассчитываем по формуле
СТОИМОСТЬi = LOCожi х УД_СТОИМОСТЬанi.
Для вычисления производительности разработки каждой функции выберем самый точный подход — подход настраиваемой производительности:
ПРОИЗВ i =ПРОИЗВанi х (LOC анi / LOCожi).
Соответственно, затраты на разработку каждой функции будем определять по выражению
ЗАТРАТЫ i = (LOCожi /ПРОИЗВ i)[чел.-мес].
Теперь мы имеем все необходимые данные для завершения расчетов. Заполним до конца таблицу оценки нашего проекта (табл. 2.24).

Таблица 2.24. Конечная таблица оценки проекта
Функция
Лучш.
Вероят.
Худш.
Ожид. [LOC]
Уд. стоимость [S/LOC]
Стоимость
[$]
Произв. [LOC/ чел.-мес]
Затраты [чел-мес]
СУПИ
1800
2400
2650
2340
14
32760
315
7,4
А2Г
4100
5200
7400
5380
20
107600
245
21,9
A3Г
4600
6900
8600
6800
20
136000
194
35,0
УБД
2950
3400
3600
3350
18
60300
240
13,9
КДГ
4050
4900
6200
4950
22
108900
200
24,7
УП
2000
2100
2450
2140
28
59920
140
15,2
МПА
6600
8500
9800
8400
18
151200
300
28,0
Итого



33360

656680

146

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

Таблица 2.25. Оценка информационных характеристик проекта
Характеристика
Лучш.
Вероят.
Худш.
Ожид.
Сложность
Количество
Вводы
20
24
30
24
х 4
96
Выводы
12
15
22
16
х 5
80
Запросы
16
22
28
22
х 4
88
Логические файлы
4
4
5
4
х 10
40
Интерфейсные файлы
2
2
3
2
х 7
14
Общее количество





318

Таблица 2.26. Оценка системных параметров проекта
Коэффициент регулировки сложности
Оценка
F1
Передачи данных
2
F2
Распределенная обработка данных
0
F3
Производительность
4
F4
Распространенность используемой конфигурации
3
F5
Скорость транзакций
4
F6
Оперативный ввод данных
5
F7
Эффективность работы конечного пользователя
5
F8
Оперативное обновление
3
F9
Сложность обработки
5
F10
Повторная используемость
4
F11
Легкость инсталляции
3
F12
Легкость эксплуатации
4
F13
Разнообразные условия размещения
5
F14
Простота изменений
5

Таким образом, получаем:
FР = Общее количество х (0,65+ 0,01 х) = 318 x 1,17 = 372.
Используя значение производительности, взятое в метрическом базисе фирмы,
Производительность = 2,55 [FP / чел.-мес],
вычисляем значения затрат и стоимости:
Затраты = FP / Производительность = 145,9 [чел.-мес],
Стоимость = Затраты х $4500 = $656500.
Итак, результаты проверки показали хорошую достоверность результатов. Но мы не будем останавливаться на достигнутом и организуем еще одну проверку, с помощью модели СОСОМО II.
Примем, что все масштабные факторы и факторы затрат имеют номинальные значения. В силу этого показатель степени В = 1,16, а множитель поправки Мp= 1. Кроме того, будем считать, что автоматическая генерация кода и повторное использование компонентов не предусматриваются. Следовательно, мы вправе применить формулу
ЗАТРАТЫ = A х РАЗМЕРB[чел.-мес]
и получаем:
ЗАТРАТЫ = 2,5(33,3)1,16 =145,87 [чел.-мес].
Соответственно, номинальная длительность проекта равна
Длительность = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))]=3(145,87)0,36 = 18[мес].
Подведем итоги. Выполнена предварительная оценка программного проекта. Для минимизации риска оценивания использованы три методики, доказавшие корректность полученных результатов.

Анализ чувствительности программного проекта

СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.
Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.
Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.
В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.
Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.
Из таблицы следует, что увеличение затрат в 1,3 раза из-за очень высокой сложности продукта уравновешивается их уменьшением вследствие высокой квалификации аналитика и программиста, а также активного использования программных утилит.

Таблица 2.27. Оценка пост-архитектурных факторов затрат
Фактор
Описание
Оценка
Множитель
RELY
Требуемая надежность ПО
Номинал.
1
DATA
Размер базы данных — 20 Кбайт
Низкая
0,93
CPLX
Сложность продукта
Очень высок.
1,3
RUSE
Требуемая повторная используемость
Номинал.
1
DOCU
Документирование жизненного цикла
Номинал.
1
TIME
Ограничения времени выполнения (70%)
Высокая
1,11
STOR
Ограничения оперативной памяти (45 из 64 Кбайт, 70%)
Высокая
1,06
PVOL
Изменчивость платформы (каждые 6 месяцев)
Номинал.
1
ACAP
Возможности аналитика (75%)
Высокая
0,83
PCAP
Возможности программиста (75%)
Высокая
0,87
AEXP
Опыт работы с приложением (1 год)
Номинал.
1
PEXP
Опыт работы с платформой (6 месяцев)
Низкая
1,12
LTEX
Опыт работы с языком и утилитами (1 год)
Номинал.
1
PCON
Непрерывность персонала ( 1 2% в год)
Номинал.
1
TOOL
Активное использование программных утилит
Высокая
0,86
SITE
Мультисетевая разработка (телефоны)
Низкая
1,1
SCED
Требуемый график разработки
Номинал.
1
Множитель поправки Мр
1,088

Рассчитаем затраты и стоимость проекта:
ЗАТРАТЫ = AхРАЗМЕРBхМр=2,5(10)1,16х1,088=36x1,088= 39[чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $234 000.
Таковы стартовые условия программного проекта. А теперь обсудим несколько сценариев возможного развития событий.

Сценарий понижения зарплаты

Положим, что заказчик решил сэкономить на зарплате разработчиков. Рычаг — понижение квалификации аналитика и программиста. Соответственно, зарплата сотрудников снижается до $5000. Оценки их возможностей становятся номинальными, а соответствующие множители затрат принимают единичные значения:
EMACAP=EMPCAP=1.
Следствием такого решения является возрастание множителя поправки Мр= 1,507, а также затрат и стоимости:
ЗАТРАТЫ = З6х 1,507 = 54 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х$5000 = $270 000,
Проигрыш_ в_стоимости = $36 000.

Положим, что разработчик предложил нарастить память — купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не 70%, а 47%), после чего фактор STOR снижается до номинального:
EMSTOR=1-> Мр =1,026,
ЗАТРАТЫ = 36x1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000,
Выигрыш_ в_стоимости = $ 12 000.

Сценарий использования нового микропроцессора

Положим, что заказчик предложил использовать новый, более дешевый МП (дешевле на $1000). К чему это приведет? Опыт работы с его языком и утилитами понижается от номинального до очень низкого и EMLTEX = 1,22, а разработанные для него утилиты (компиляторы, ассемблеры и отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого и EMТООL= 1,24):
Мр = (1,088 / 0,86) х 1,22 x 1,24 = 1,914,
ЗАТРАТЫ = 36х1,914 = 69[чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $414000,
Проигрыш_в_стоимости = $180000.

Сценарий уменьшения средств на завершение проекта

Положим, что к разработке принят сценарий с наращиванием памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета). После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об отсутствии у него достаточных денежных средств и о предоставлении на завершение разработки только $170 000 (15%-ное уменьшение оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на 15%.
Первое решение: уменьшение размера продукта (за счет исключения некоторых функций). Нам надо определить размер минимизированного продукта. Будем исходить из того, что затраты должны уменьшиться с 37 до 31,45 чел.-мес. Решим уравнение:
2,5 (НовыйРазмер)1,16= 31,45 [чел.-мес].
Очевидно, что
(НовыйРазмер)1,16 = 12,58,
(НовыйРазмер)1,16 = 12,581/1,16 = 8,872 [KLOC].
Другие решения:
уменьшить требуемую надежность с номинальной до низкой. Это сокращает стоимость проекта на 12% (EMRELY изменяется с 1 до 0,88). Такое решение приведет к увеличению затрат и трудностей при применении и сопровождении;
повысить требования к квалификации аналитиков и программистов (с высоких до очень высоких). При этом стоимость проекта уменьшается на 15-19%. Благодаря программисту стоимость может уменьшиться на (1 - 0,74/0,87) х 100% = 15%. Благодаря аналитику стоимость может понизиться на (1 - 0,67/0,83) х 100% = 19%. Основная трудность — поиск специалистов такого класса (готовых работать за те же деньги);
повысить требования к опыту работы с приложением (с номинальных до очень высоких) или требования к опыту работы с платформой (с низких до высоких). Повышение опыта работы с приложением сокращает стоимость проекта на (1- 0,81) х 100% = 19%; повышение опыта работы с платформой сокращает стоимость проекта на (1 - 0,88/1,12) х 100% = 21,4%. Основная трудность — поиск экспертов (специалистов такого класса);
повысить уровень мультисетевой разработки с низкого до высокого. При этом стоимость проекта уменьшается на (1 - 0,92/1,1) х 100% = 16,4%;
ослабить требования к режиму работы в реальном времени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс) х 70% = 47%, в результате чего фактор TIME уменьшится с высокого до номинального, что приведет к экономии затрат на (1- 1/1,11) х 100%= 10%;
учет других факторов затрат не имеет смысла. Некоторые факторы (размер базы данных, ограничения оперативной памяти, требуемый график разработки) уже имеют минимальные значения, для других трудно ожидать быстрого улучшения (использование программных утилит, опыт работы с языком и утилитами), третьи имеют оптимальные значения (требуемая повторная используемость, документирование требований жизненного цикла). На некоторые разработчик почти не может повлиять (сложность продукта, изменчивость платформы). Наконец, житейские неожиданности едва ли позволят улучшить принятое значение фактора «непрерывность персонала».
Какое же решение следует выбрать? Наиболее целесообразное решение — исключение отдельных функций продукта. Вторым (по предпочтительности) решением является повышение уровня мультисетевой разработки (все равно это придется сделать в ближайшее время). В качестве третьего решения можно рассматривать ослабление требований к режиму работы в реальном времени. Принятие же других решений зависит от наличия необходимых специалистов или средств разработки. Впрочем, окончательное решение должно выбираться в процессе переговоров с заказчиком, когда учитываются все соображения.
Выводы.
1. Факторы затрат оказывают существенное влияние на выходные параметры программного проекта.
2. Модель СОСОМО II предлагает широкий спектр факторов затрат, учитывающих большинство реальных ситуаций в «жизни» программного проекта.
3. Модель СОСОМО II обеспечивает перевод качественного обоснования решения менеджера на количественные рельсы, тем самым повышая объективность принимаемого решения.

Контрольные вопросы

1. Что такое мера?
2. Что такое метрика?
3. Что такое выполнение оценки программного проекта?
4. Что такое анализ риска?
5. Что такое трассировка и контроль?
6. Охарактеризуйте содержание Work Breakdown Structure.
7. Охарактеризуйте рекомендуемое правило распределения затрат проекта.
8. Какие размерно-ориентированные метрики вы знаете?
9. Для чего используют размерно-ориентированные метрики?
10. Определите достоинства и недостатки размерно-ориентированных метрик.
11. Что такое функциональный указатель?
12. От каких информационных характеристик зависит функциональный указатель?
13. Как вычисляется количество функциональных указателей?
14. Что такое коэффициенты регулировки сложности в метрике количества функциональных указателей?
15. Определите достоинства и недостатки функционально-ориентированных метрик.
16. Можно ли перейти от FP-оценок к LOC-оценкам?
17. Охарактеризуйте шаги оценки проекта на основе LOC- и FP-метрик. Чем отличается наиболее точный подход от наименее точного?
18. Что такое конструктивная модель стоимости? Для чего она применяется?
19. Чем отличается версия СОСОМО 81 от версии СОСОМО II?
20. В чем состоит назначение модели композиции? На каких оценках она базируется?
21. В чем состоит назначение модели раннего этапа проектирования?
22. Охарактеризуйте основное уравнение модели раннего этапа проектирования.
23. Охарактеризуйте масштабные факторы модели СОСОМО II.
24. Как оцениваются масштабные факторы?
25. В чем состоит назначение модели этапа пост-архитектуры СОСОМО II?
26. Чем отличается основное уравнение модели этапа пост-архитектуры от аналогичного уравнения модели раннего этапа проектирования?
27. Что такое факторы затрат модели этапа пост-архитектуры и как они вычисляются?
28. Как определяется длительность разработки в модели СОСОМО II?
29. Что такое анализ чувствительности программного проекта?
30. Как применить модель СОСОМО II к анализу чувствительности?

ГЛАВА 3. Классические методы анализа

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

Структурный анализ

Структурный анализ — один из формализованных методов анализа требований к ПО. Автор этого метода — Том Де Марко (1979) [27]. В этом методе программное изделие рассматривается как преобразователь информационного потока данных. Основной элемент структурного анализа — диаграмма потоков данных.

Диаграммы потоков данных

Диаграмма потоков данных ПДД — графическое средство для изображения информационного потока и преобразований, которым подвергаются данные при движении от входа к выходу системы. Элементы диаграммы имеют вид, показанный на рис. 3.1. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции.
Пример системы взаимосвязанных диаграмм показан на рис. 3.2.
Диаграмма высшего (нулевого) уровня представляет систему как единый овал со стрелкой, ее называют основной или контекстной моделью. Контекстная модель используется для указания внешних связей программного изделия. Для детализации (уточнения системы) вводится диаграмма 1-го уровня. Каждый из преобразователей этой диаграммы — подфункция общей системы. Таким образом, речь идет о замене преобразователя F на целую систему преобразователей.
Дальнейшее уточнение (например, преобразователя F3) приводит к диаграмме 2-го уровня. Говорят, что ПДД1 разбивается на диаграммы 2-го уровня.

Рис. 3.2. Система взаимосвязанных диаграмм потоков данных

ПРИМЕЧАНИЕ
Важно сохранить непрерывность информационного потока и его согласованность. Это значит, что входы и выходы у каждого преобразователя на любом уровне должны оставаться прежними. В диаграмме отсутствуют точные указания на последовательность обработки. Точные указания откладываются до этапа проектирования.

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

Описание потоков данных и процессов

Базовые средства диаграммы не обеспечивают полного описания требований к программному изделию. Очевидно, что должны быть описаны стрелки — потоки данных — и преобразователи — процессы. Для этих целей используются словарь требований (данных) и спецификации процессов.
Словарь требований (данных) содержит описания потоков данных и хранилищ данных. Словарь требований является неотъемлемым элементом любой CASE-утилиты автоматизации анализа. Структура словаря зависит от особенностей конкретной CASE-утилиты. Тем не менее можно выделить базисную информацию типового словаря требований.
Большинство словарей содержит следующую информацию.
1. Имя (основное имя элемента данных, хранилища или внешнего объекта).
2. Прозвище (Alias) — другие имена того же объекта.
3. Где и как используется объект — список процессов, которые используют данный элемент, с указанием способа использования (ввод в процесс, вывод из процесса, как внешний объект или как память).
4. Описание содержания — запись для представления содержания.
5. Дополнительная информация — дополнительные сведения о типах данных, допустимых значениях, ограничениях и т. д.
Спецификация процесса — это описание преобразователя. Спецификация поясняет: ввод данных в преобразователь, алгоритм обработки, характеристики производительности преобразователя, формируемые результаты.
Количество спецификаций равно количеству преобразователей диаграммы.

Расширения для систем реального времени

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

Рис. 3.3. Программное изделие как дискретная модель проблемной области

П. Вард и С. Меллор приспособили диаграммы потоков данных к следующим требованиям систем реального времени [73].
1. Информационный поток накапливается или формируется в непрерывном времени.
2. Фиксируется управляющая информация. Считается, что она проходит через систему и связывается с управляющей обработкой.
3. Допускается множественный запрос на одну и ту же обработку (из внешней среды).

Рис. 3.4. Расширения диаграмм для систем реального времени

Новые элементы имеют обозначения, показанные на рис. 3.4.
Приведем два примера использования новых элементов.
Пример 1. Использование потоков, непрерывных во времени.
На рис. 3.5 представлена модель анализа программного изделия для системы слежения за газовой турбиной.

Рис. 3.5. Модель ПО для системы слежения за газовой турбиной

Видим, что здесь наблюдаемая температура измеряется непрерывно до тех пор, пока не будет найдено дискретное значение в наборе эталонов температуры. Преобразователь формирует регулирующие воздействия как непрерывный во времени вывод. Чем полезна эта модель?
Во-первых, инженер делает вывод, что для приема-передачи квазинепрерывных значений нужно использовать аналого-цифровую и цифроаналоговую аппаратуру.
Во-вторых, необходимость организации высокоскоростного управления этой аппаратурой делает критичным требование к производительности системы.
Пример 2. Использование потоков управления.
Рассмотрим компьютерную систему, которая управляет роботом (рис. 3.6).

Рис. 3.6. Модель ПО для управления роботом

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

Расширение возможностей управления

Д. Хетли и И. Пирбхаи сосредоточили внимание на аспектах управления программным продуктом [34]. Они выделили системные состояния и механизм перехода из одного состояния в другое. Д. Хетли и И. Пирбхаи предложили не вносить в ПДД элементы управления, такие как потоки управления и управляющие процессы. Вместо этого они ввели диаграммы управляющих потоков (УПД).
Диаграмма управляющих потоков содержит:
обычные преобразователи (управляющие преобразователи исключены вообще);
потоки управления и потоки событий (без потоков данных).
Вместо управляющих преобразователей в УПД используются указатели — ссылки на управляющую спецификацию УСПЕЦ. Как показано на рис. 3.7, ссылка изображается как косая пунктирная стрелка, указывающая на окно УСПЕЦ (вертикальную черту).

Рис. 3.7. Изображение ссылки на управляющую спецификацию

УСПЕЦ управляет преобразователями в ПДД на основе события, которое проходит в ее окно (по ссылке). Она предписывает включение конкретных преобразователей как результат конкретного события.
Иллюстрация модели программной системы, использующей описанные средства, приведена на рис. 3.8.

Рис. 3.8. Композиция модели обработки и управления

В модель обработки входит набор диаграмм потоков данных и набор спецификаций процессов. Модель управления образует набор диаграмм управляющих потоков и набор управляющих спецификаций. Модель обработки подключается к модели управления с помощью активаторов процессов. Активаторы включают в конкретной ПДД конкретные преобразователи. Обратная связь модели обработки с моделью управления осуществляется с помощью условий данных. Условия данных формируются в ПДД (когда входные данные преобразуются в события).

Модель системы регулирования давления космического корабля

Обсудим модель системы регулирования давления космического корабля, представленную на рис. 3.9.
Начнем с диаграммы потоков данных. Основной процесс в ПДД — Слежение и регулирование давления. На его входы поступают: измеренное Давление в кабине и Мах давление: На выходе процесса — поток данных Изменение давления. Содержание процесса описывается в его спецификации ПСПЕЦ.
Спецификация процесса ПСПЕЦ может включать:
1) поясняющий текст (обязательно);
2) описание алгоритма обработки;
3) математические уравнения;
4) таблицы;
5) диаграммы.
Элементы со второго по пятый не обязательны.

Рис. 3.9. Модель системы регулирования давления космического корабля

С помощью ПСПЕЦ разработчик создает описание для каждого преобразователя, которое рассматривается как:
первый шаг создания спецификации требований к программному изделию;
руководство для проектирования программ, которые будут реализовывать процессы.
В нашем примере спецификация процесса имеет вид
если Давление в кабине > мах
то Избыточное давление:=11;
иначе Избыточное давление:=0;
алгоритм регулирования;
выч.Изменение давления;
конец если;
Таким образом, когда давление в кабине превышает максимум, генерируется управляющее событие Избыточное давление. Оно должно быть показано на диаграмме управляющих потоков УПД. Это событие входит в окно управляющей спецификации УСПЕЦ.
Управляющая спецификация моделирует поведение системы. Она содержит:
таблицу активации процессов (ТАП);
диаграмму переходов-состояний (ДПС).
Таблица активации процессов показывает, какие процессы будут вызываться (активироваться) в потоковой модели в результате конкретных событий.
ТАП включает три раздела — Входные события, Выходные события, Активация процессов. Логика работы ТАП такова: входное событие вызывает выходное событие, которое активирует конкретный процесс. Для нашей модели ТАП имеет вид, представленный в табл. 3.1.

Видим, что в нашем примере входных событий три: два внешних события (Включение системы, Норма) и одно — условие данных (Избыточное Давление). Работа ТАП инициируется входным событием, «втекающим» в окно УСПЕЦ. В результате ТАП вырабатывает выходное событие — активатор. В нашем примере активаторами являются события Работа и Тревога. Активатор «вытекает» из окна УСПЕЦ, запуская в УПД конкретный процесс.
Другой элемент УСПЕЦ — Диаграмма переходов-состояний. ДПС отражает состояния системы и показывает, как она переходит из одного состояния в другое.
ДПС для нашей модели показана на рис. 3.10.
Системные состояния показаны прямоугольниками. Стрелки показывают переходы между состояниями. Стрелки переходов подписывают следующим образом: в числителе — событие, которое вызывает переход, в знаменателе — процесс, запускаемый как результат события.

Изучая ДПС, разработчик может анализировать поведение модели и установить, нет ли «дыр» в определении поведения.

Методы анализа, ориентированные на структуры данных

Элементами проблемной области для любой системы являются потоки, процессы и структуры данных. При структурном анализе активно работают только с потоками данных и процессами.
Методы, ориентированные на структуры данных, обеспечивают:
1) определение ключевых информационных объектов и операций;
2) определение иерархической структуры данных;
3) компоновку структур данных из типовых конструкций — последовательности, выбора, повторения;
4) последовательность шагов для превращения иерархической структуры данных в структуру программы.
Наиболее известны два метода: метод Варнье-Орра и метод Джексона.
В методе Варнье-Орра для представления структур применяют диаграммы Варнье [54].
Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение (рис. 3.11) [74].

Рис. 3.11. Базовые элементы в диаграммах Варнье

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

Рис. 3.12. Структура газеты в виде диаграммы Варнье

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

Метод анализа Джексона

Как и метод Варнье-Орра, метод Джексона появился в период революции структурного программирования. Фактически оба метода решали одинаковую задачу: распространить базовые структуры программирования (последовательность, выбор, повторение) на всю область конструирования сложных программных систем. Именно поэтому основные выразительные средства этих методов оказались так похожи друг на друга.

Методика Джексона

Метод Джексона (1975) включает 6 шагов [39]. Три шага выполняются на этапе анализа, а остальные — на этапе проектирования.
1. Объект-действие. Определяются объекты — источники или приемники информации и действия — события реального мира, воздействующие на объекты.
2. Объект-структура. Действия над объектами представляются диаграммами Джексона.
3. Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром.
4. Доопределение функций. Выделяются и описываются сервисные функции.
5. Учет системного времени. Определяются и оцениваются характеристики планирования будущих процессов.
6. Реализация. Согласование с системной средой, разработка аппаратной платформы.

Шаг объект-действие

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

Шаг объект-структура

Структура объектов описывает последовательность действий над объектами (в условном времени).
Для представления структуры объектов Джексон предложил 3 типа структурных диаграмм. Они показаны на рис. 3.13. В первой диаграмме к объектам применяется такое действие, как последовательность, во второй — выбор, в третьей — повторение.
Рассмотрим объектную структуру для транспорта (см. рис. 3.14). Условимся, что начало и конец истории транспорта — у первой остановки. Действиями, влияющими на объект, являются Покинуть и Прибыть.

Рис. 3.13. Три типа структурных диаграмм Джексона

Рис. 3.14. Объектная структура для транспорта

Диаграмма показывает, что транспорт начинает работу у остановки 1, тратит основное время на перемещение между остановками 1 и 2 и окончательно возвращается на остановку 1. Прибытие на остановку, следующее за отъездом с другой остановки, представляется как пара действий Прибыть(i) и Покинуть(i). Заметим, что диаграмму можно сопровождать комментариями, которые не могут прямо представляться средствами метода. Например, «значение г в двух последовательных остановках должно быть разным».
Структурная диаграмма для объекта Кнопка показывает (рис. 3.15), что к нему многократно применяется действие Нажать.

Рис. 3.15. Структурная диаграмма для объекта Кнопка

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

Шаг начального моделирования

Начальное моделирование — это шаг к созданию описания системы как модели реального мира. Описание создается с помощью диаграммы системной спецификации.
Элементами диаграммы системной спецификации являются физические процессы (имеют суффикс 0) и их модели (имеют суффикс 1). Как показано на рис. 3.16, предусматриваются 2 вида соединений между физическими процессами и моделями.

Рис. 3.16. Соединения между физическими процессами и их моделями

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

ПРИМЕЧАНИЕ
При нажатии кнопки формируется импульс, который может быть передан в модель как элемент данных, поэтому для кнопки выбрано соединение потоком данных.
Датчики, регистрирующие прибытие и убытие транспорта, не формируют импульса, они воздействуют на электронный переключатель. Состояние переключателя может быть оценено. Поэтому для транспорта выбрано соединение по вектору состояний.

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

Для фиксации особенностей процессов-моделей Джексон предлагает специальное описание — структурный текст. Например, структурный текст для модели КНОПКА-1 имеет вид
КНОПКА-1
читать BD;
НАЖАТЬ цикл ПОКА BD
нажать;
читать ВD;
конец НАЖАТЬ;
конец КНОПКА-1;
Структура модели КНОПКА-1 отличается от структуры физического процесса КНОПКА-0 добавлением оператора для чтения буфера ВD, который соединяет физический мир с моделью.
Прежде чем написать структурный текст для модели ТРАНСПОРТ-1, мы должны сделать ряд замечаний.
Во-первых, состояние транспорта будем отслеживать по переменным ПРИБЫЛ, УБЫЛ. Они отражают состояние электронного переключателя физического транспорта.
Во-вторых, для учета инерционности процессов в физическом транспорте в модель придется ввести дополнительные операции:
ЖДАТЬ (ожидание в изменении состояния физического транспорта);
ТРАНЗИТ (операция задержки в модели на перемещение транспорта между остановками).
С учетом замечаний структурная диаграмма модели примет вид, изображенный на рис. 3.18.
Соответственно, структурный текст модели записывается в форме
ТРАНСПОРТ-1
опрос TSV;
ЖДАТЬ цикл ПОКА ПРИБЫЛ(1)
опрос TSV;
конец ЖДАТЬ;
покинуть(1);
ТРАНЗИТ цикл ПОКА УБЫЛ(1)
опрос TSV;
конец ТРАНЗИТ;
ТРАНСПОРТ цикл
ОСТАНОВКА
прибыть(i);
ЖДАТЬ цикл ПОКА ПРИБЫЛ(i)
опрос TSV;
конец ЖДАТЬ;
покинуть(i);
ТРАНЗИТ цикл ПОКА УБЫЛ(i)
опрос TSV;
конец ТРАНЗИТ;
конец ОСТАНОВКА;
конец ТРАНСПОРТ;
прибыть(1);
конец ТРАНСПОРТ-1;

Рис. 3.18. Структурная диаграмма модели транспорта

Контрольные вопросы

1. Какие задачи решает аппарат анализа?
2. Что такое диаграмма потоков данных?
3. Чем отличается диаграмма потоков данных от блок-схемы алгоритма?
4. Какие элементы диаграммы потоков данных вы знаете?
5. Как формируется иерархия диаграмм потоков данных?
6. Какую задачу решает диаграмма потоков данных высшего (нулевого) уровня? Почему ее называют контекстной моделью?
7. Чем нагружены вершины диаграммы потоков данных?
8. Чем нагружены дуги диаграммы потоков данных?
9. Как организован словарь требований?
10. С чем связана необходимость расширения диаграмм потоков данных для систем реального времени? Какие средства расширения вы знаете?
11. Как решается проблема расширения возможностей управления на базе диаграмм потоков данных?
12. Каковы особенности диаграммы управляющих потоков?
13. Поясните понятие активатора процесса.
14. Поясните понятие условия данных.
15. Поясните понятие управляющей спецификации.
16. Поясните понятие окна управляющей спецификации.
17. Как организована спецификация процесса?
18. Поясните назначение таблицы активации процессов.
19. Поясните организацию диаграммы переходов-состояний.
20. Какие задачи решают методы анализа, ориентированные на структуры данных?
21. Какие методы анализа, ориентированные на структуры данных, вы знаете?
22. Из каких базовых элементов состоят диаграммы Варнье?
23. Какие шаги выполняет метод Джексона на этапе анализа?
24. Какие типы структурных диаграмм Джексона вы знаете?
25. Как организовано в методе Джексона обнаружение объектов?
26. Что такое структура объектов Джексона?
27. Как создается структура объектов Джексона?
28. Поясните диаграмму системной спецификации Джексона.
29. Чем отличается соединение потоком данных от соединения по вектору состояний?
30. Какова задача структурного текста Джексона?

ГЛАВА 4. Основы проектирования программных систем

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

Особенности процесса синтеза программных систем

Известно, что технологический цикл конструирования программной системы (ПС) включает три процесса — анализ, синтез и сопровождение.
В ходе анализа ищется ответ на вопрос: «Что должна делать будущая система?». Именно на этой стадии закладывается фундамент успеха всего проекта. Известно множество неудачных реализаций из-за неполноты и неточностей в определении требований к системе.
В процессе синтеза формируется ответ на вопрос: «Каким образом система будет реализовывать предъявляемые к ней требования?». Выделяют три этапа синтеза: проектирование ПС, кодирование ПС, тестирование ПС (рис. 4.1).
Рассмотрим информационные потоки процесса синтеза.
Этап проектирования питают требования к ПС, представленные информационной, функциональной и поведенческой моделями анализа. Иными словами, модели анализа поставляют этапу проектирования исходные сведения для работы. Информационная модель описывает информацию, которую, по мнению заказчика, должна обрабатывать ПС. Функциональная модель определяет перечень функций обработки. Поведенческая модель фиксирует желаемую динамику системы (режимы ее работы). На выходе этапа проектирования — разработка данных, разработка архитектуры и процедурная разработка ПС.
Разработка данных — это результат преобразования информационной модели анализа в структуры данных, которые потребуются для реализации программной системы.

Рис. 4.1. Информационные потоки процесса синтеза ПС

Разработка архитектуры выделяет основные структурные компоненты и фиксирует связи между ними.
Процедурная разработка описывает последовательность действий в структурных компонентах, то есть определяет их содержание.
Далее создаются тексты программных модулей, проводится тестирование для объединения и проверки ПС. На проектирование, кодирование и тестирование приходится более 75% стоимости конструирования ПС. Принятые здесь решения оказывают решающее воздействие на успех реализации ПС и легкость, с которой ПС будет сопровождаться.
Следует отметить, что решения, принимаемые в ходе проектирования, делают его стержневым этапом процесса синтеза. Важность проектирования можно определить одним словом — качество. Проектирование — этап, на котором «выращивается» качество разработки ПС. Справедлива следующая аксиома разработки: может быть плохая ПС при хорошем проектировании, но не может быть хорошей ПС при плохом проектировании. Проектирование обеспечивает нас такими представлениями ПС, качество которых можно оценить. Проектирование — единственный путь, обеспечивающий правильную трансляцию требований заказчика в конечный программный продукт.

Особенности этапа проектирования

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

Рис. 4.2. Информационные связи процесса проектирования

Предварительное проектирование обеспечивает:
идентификацию подсистем;
определение основных принципов управления подсистемами, взаимодействия подсистем.
Предварительное проектирование включает три типа деятельности:
1. Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой понимается независимый программный компонент. Определяются взаимодействия подсистем.
2. Моделирование управления. Определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульные соединения.
Рассмотрим вопросы структурирования, моделирования и декомпозиции более подробно.

Структурирование системы

Известны четыре модели системного структурирования:
модель хранилища данных;
модель клиент-сервер;
трехуровневая модель;
модель абстрактной машины.
В модели хранилища данных (рис. 4.3) подсистемы разделяют данные, находящиеся в общей памяти. Как правило, данные образуют БД. Предусматривается система управления этой базой.

Рис. 4.3. Модель хранилища данных

Модель клиент-сервер используется для распределенных систем, где данные распределены по серверам (рис. 4.4). Для передачи данных применяют сетевой протокол, например TCP/IP.

Рис. 4.4. Модель клиент-сервер

Трехуровневая модель является развитием модели клиент-сервер (рис. 4.5).

Рис. 4.5. Трехуровневая модель

Уровень графического интерфейса пользователя запускается на машине клиента. Бизнес-логику образуют модули, осуществляющие функциональные обязанности системы. Этот уровень запускается на сервере приложения. Реляционная СУБД хранит данные, требуемые уровню бизнес-логики. Этот уровень запускается на втором сервере — сервере базы данных.
Преимущества трехуровневой модели:
упрощается такая модификация уровня, которая не влияет на другие уровни;
отделение прикладных функций от функций управления БД упрощает оптимизацию всей системы.
Модель абстрактной машины отображает многослойную систему (рис. 4.6).
Каждый текущий слой реализуется с использованием средств, обеспечиваемых слоем-фундаментом.

Рис. 4.6. Модель абстрактной машины

Известны два типа моделей управления:
модель централизованного управления;
модель событийного управления.
В модели централизованного управления одна подсистема выделяется как системный контроллер. Ее обязанности — руководить работой других подсистем. Различают две разновидности моделей централизованного управления: модель вызов-возврат (рис. 4.7) и Модель менеджера (рис. 4.8), которая используется в системах параллельной обработки.

Рис. 4.7. Модель вызов-возврат

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

Рис. 4.8. Модель менеджера

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

Рис. 4.9. Широковещательная модель

Рис. 4.10. Модель, управляемая прерываниями

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

Декомпозиция подсистем на модули

Известны два типа моделей модульной декомпозиции:
модель потока данных;
модель объектов.
В основе модели потока данных лежит разбиение по функциям.
Модель объектов основана на слабо сцепленных сущностях, имеющих собственные наборы данных, состояния и наборы операций.
Очевидно, что выбор типа декомпозиции должен определяться сложностью разбиваемой подсистемы.

Модульность

Модуль — фрагмент программного текста, являющийся строительным блоком для физической структуры системы. Как правило, модуль состоит из интерфейсной части и части-реализации.
Модульность — свойство системы, которая может подвергаться декомпозиции на ряд внутренне связанных и слабо зависящих друг от друга модулей.
По определению Г. Майерса, модульность — свойство ПО, обеспечивающее интеллектуальную возможность создания сколь угодно сложной программы [52]. Проиллюстрируем эту точку зрения.
Пусть С(х) — функция сложности решения проблемы х, Т(х) — функция затрат времени на решение проблемы х. Для двух проблем р1 и р2 из соотношения С(р1) > С(р2) следует, что
T(pl)>T(p2). (4.1)
Этот вывод интуитивно ясен: решение сложной проблемы требует большего времени.
Далее. Из практики решения проблем человеком следует:
С(р1+ р2)>С(р1) + С(р2).
Отсюда с учетом соотношения (4.1) запишем:
T(pl+p2)>T(pl) + T(p2). (4.2)
Соотношение (4.2) — это обоснование модульности. Оно приводит к заключению «разделяй и властвуй» — сложную проблему легче решить, разделив ее на управляемые части. Результат, выраженный неравенством (4.2), имеет важное значение для модульности и ПО. Фактически, это аргумент в пользу модульности.
Однако здесь отражена лишь часть реальности, ведь здесь не учитываются затраты на межмодульный интерфейс. Как показано на рис. 4.11, с увеличением количества модулей (и уменьшением их размера) эти затраты также растут.

Рис. 4.11. Затраты на модульность

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

Информационная закрытость

Принцип информационной закрытости (автор — Д. Парнас, 1972) утверждает: содержание модулей должно быть скрыто друг от друга [60]. Как показано на рис. 4.12, модуль должен определяться и проектироваться так, чтобы его содержимое (процедуры и данные) было недоступно тем модулям, которые не нуждаются в такой информации (клиентам).

Рис. 4.12. Информационная закрытость модуля

Информационная закрытость означает следующее:
1) все модули независимы, обмениваются только информацией, необходимой для работы;
2) доступ к операциям и структурам данных модуля ограничен.
Достоинства информационной закрытости:
обеспечивается возможность разработки модулей различными, независимыми коллективами;
обеспечивается легкая модификация системы (вероятность распространения ошибок очень мала, так как большинство данных и процедур скрыто от других частей системы).
Идеальный модуль играет роль «черного ящика», содержимое которого невидимо клиентам. Он прост в использовании — количество «ручек и органов управления» им невелико (аналогия с эксплуатацией телевизора). Его легко развивать и корректировать в процессе сопровождения программной системы. Для обеспечения таких возможностей система внутренних и внешних связей модуля должна отвечать особым требованиям. Обсудим характеристики внутренних и внешних связей модуля.

Связность модуля

Связность модуля (Cohesion) — это мера зависимости его частей [58], [70], [77]. Связность — внутренняя характеристика модуля. Чем выше связность модуля, тем лучше результат проектирования, то есть тем «черней» его ящик (капсула, защитная оболочка модуля), тем меньше «ручек управления» на нем находится и тем проще эти «ручки».
Для измерения связности используют понятие силы связности (СС). Существует 7 типов связности:
1. Связность по совпадению (СС=0). В модуле отсутствуют явно выраженные внутренние связи.
2. Логическая связность (СС=1). Части модуля объединены по принципу функционального подобия. Например, модуль состоит из разных подпрограмм обработки ошибок. При использовании такого модуля клиент выбирает только одну из подпрограмм.
Недостатки:
сложное сопряжение;
большая вероятность внесения ошибок при изменении сопряжения ради одной из функций.
3. Временная связность (СС=3). Части модуля не связаны, но необходимы в один и тот же период работы системы.
Недостаток: сильная взаимная связь с другими модулями, отсюда — сильная чувствительность внесению изменений.
4. Процедурная связность (СС=5). Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения.
5. Коммуникативная связность (СС=7). Части модуля связаны по данным (работают с одной и той же структурой данных).
6. Информационная (последовательная) связность (СС=9). Выходные данные одной части используются как входные данные в другой части модуля.
7. Функциональная связность (СС=10). Части модуля вместе реализуют одну функцию.
Отметим, что типы связности 1,2,3 — результат неправильного планирования архитектуры, а тип связности 4 — результат небрежного планирования архитектуры приложения.
Общая характеристика типов связности представлена в табл. 4.1.

Таблица 4.1. Характеристика связности модуля
Тип связности
Сопровождаемость
Роль модуля
Функциональная

«Черный ящик»
Информационная
( последовательная )
Лучшая сопровождаемость
Не совсем «черный ящик»
Кэммуникативная

«Серый ящик»
Процедурная

«Белый» или «просвечивающий ящик»
Временная
Худшая сопровождаемость

Логическая

«Белый ящик»
По совпадению

Функциональная связность

Функционально связный модуль содержит элементы, участвующие в выполнении одной и только одной проблемной задачи. Примеры функционально связных модулей:
Вычислять синус угла;
Проверять орфографию;
Читать запись файла;
Вычислять координаты цели;
Вычислять зарплату сотрудника;
Определять место пассажира.
Каждый из этих модулей имеет единичное назначение. Когда клиент вызывает модуль, выполняется только одна работа, без привлечения внешних обработчиков. Например, модуль Определять место пассажира должен делать только это; он не должен распечатывать заголовки страницы.
Некоторые из функционально связных модулей очень просты (например, Вычислять синус угла или Читать запись файла), другие сложны (например, Вычислять координаты цели). Модуль Вычислять синус угла, очевидно, реализует единичную функцию, но как может модуль Вычислять зарплату сотрудника выполнять только одно действие? Ведь каждый знает, что приходится определять начисленную сумму, вычеты по рассрочкам, подоходный налог, социальный налог, алименты и т. д.! Дело в том, что, несмотря на сложность модуля и на то, что его обязанность исполняют несколько подфункций, если его действия можно представить как единую проблемную функцию (с точки зрения клиента), тогда считают, что модуль функционально связен.
Приложения, построенные из функционально связных модулей, легче всего сопровождать. Соблазнительно думать, что любой модуль можно рассматривать как однофункциональный, но не надо заблуждаться. Существует много разновидностей модулей, которые выполняют для клиентов перечень различных работ, и этот перечень нельзя рассматривать как единую проблемную функцию. Критерий при определении уровня связности этих нефункциональных модулей — как связаны друг с другом различные действия, которые они исполняют.

Информационная связность

При информационной (последовательной) связности элементы-обработчики модуля образуют конвейер для обработки данных — результаты одного обработчика используются как исходные данные для следующего обработчика. Приведем пример:
Модуль Прием и проверка записи
прочитать запись из файла
проверить контрольные данные в записи
удалить контрольные поля в записи
вернуть обработанную запись
Конец модуля
В этом модуле 3 элемента. Результаты первого элемента (прочитать запись из файла) используются как входные данные для второго элемента (проверить контрольные данные в записи) и т. д.
Сопровождать модули с информационной связностью почти так же легко, как и функционально связные модули. Правда, возможности повторного использования здесь ниже, чем в случае функциональной связности. Причина — совместное применение действий модуля с информационной связностью полезно далеко не всегда.

Коммуникативная связность

При коммуникативной связности элементы-обработчики модуля используют одни и те же данные, например внешние данные. Пример коммуникативно связного модуля:
Модуль Отчет и средняя зарплата
используется Таблица зарплаты служащих
сгенерировать Отчет по зарплате
вычислить параметр Средняя зарплата
вернуть Отчет по зарплате. Средняя зарплата
Конец модуля
Здесь все элементы модуля работают со структурой Таблица зарплаты служащих.
С точки зрения клиента проблема применения коммуникативно связного модуля состоит в избыточности получаемых результатов. Например, клиенту требуется только отчет по зарплате, он не нуждается в значении средней зарплаты. Такой клиент будет вынужден выполнять избыточную работу — выделение в полученных данных материала отчета. Почти всегда разбиение коммуникативно связного модуля на отдельные функционально связные модули улучшает сопровождаемость системы.
Попытаемся провести аналогию между информационной и коммуникативной связностью.
Модули с коммуникативной и информационной связностью подобны в том, что содержат элементы, связанные по данным. Их удобно использовать, потому что лишь немногие элементы в этих модулях связаны с внешней средой. Главное различие между ними — информационно связный модуль работает подобно сборочной линии; его обработчики действуют в определенном порядке; в коммуникативно связном модуле порядок выполнения действий безразличен. В нашем примере не имеет значения, когда генерируется отчет (до, после или одновременно с вычислением средней зарплаты).

Процедурная связность

При достижении процедурной связности мы попадаем в пограничную область между хорошей сопровождаемостью (для модулей с более высокими уровнями связности) и плохой сопровождаемостью (для модулей с более низкими уровнями связности). Процедурно связный модуль состоит из элементов, реализующих независимые действия, для которых задан порядок работы, то есть порядок передачи управления. Зависимости по данным между элементами нет. Например:
Модуль Вычисление средних значений
используется Таблица-А. Таблица-В
вычислить среднее по Таблица-А
вычислить среднее по Таблица-В
вернуть среднееТабл-А. среднееТабл-В
Конец модуля
Этот модуль вычисляет средние значения для двух полностью несвязанных таблиц Таблица-А и Таблица-В, каждая из которых имеет по 300 элементов.
Теперь представим себе программиста, которому поручили реализовать данный модуль. Соблазнившись возможностью минимизации кода (использовать один цикл в интересах двух обработчиков, ведь они находятся внутри единого модуля!), программист пишет:
Модуль Вычисление средних значений
используется Таблица-А. Таблица-В
суммаТабл-А := 0
суммаТабл-В := 0
для i := 1 до 300
суммаТабл-А := суммаТабл-А + Таблица-А(i)
суммаТабл-В :- суммаТабл-В + Таблица-В(i)
конец для
среднееТабл-А := суммаТабл-А / 300
среднееТабл-В := суммаТабл-В / 300
вернуть среднееТабл-А, среднееТабл-В
Конец модуля
Для процедурной связности этот случай типичен — независимый (на уровне проблемы) код стал зависимым (на уровне реализации). Прошли годы, продукт сдали заказчику. И вдруг возникла задача сопровождения — модифицировать модуль под уменьшение размера таблицы В. Оцените, насколько удобно ее решать.

Временная связность

При связности по времени элементы-обработчики модуля привязаны к конкретному периоду времени (из жизни программной системы).
Классическим примером временной связности является модуль инициализации:
Модуль Инициализировать Систему
перемотать магнитную ленту 1
Счетчик магнитной ленты 1 := 0
перемотать магнитную ленту 2
Счетчик магнитной ленты 2 := 0
Таблица текущих записей : = пробел..пробел
Таблица количества записей := 0..0
Переключатель 1 : = выкл
Переключатель 2 := вкл
Конец модуля
Элементы данного модуля почти не связаны друг с другом (за исключением того, что должны выполняться в определенное время). Они все — часть программы запуска системы. Зато элементы более тесно взаимодействуют с другими модулями, что приводит к сложным внешним связям.
Модуль со связностью по времени испытывает те же трудности, что и процедурно связный модуль. Программист соблазняется возможностью совместного использования кода (действиями, которые связаны только по времени), модуль становится трудно использовать повторно.
Так, при желании инициализировать магнитную ленту 2 в другое время вы столкнетесь с неудобствами. Чтобы не сбрасывать всю систему, придется или ввести флажки, указывающие инициализируемую часть, или написать другой код для работы с лентой 2. Оба решения ухудшают сопровождаемость.
Процедурно связные модули и модули с временной связностью очень похожи. Степень их непрозрачности изменяется от темного серого до светло-серого цвета, так как трудно объявить функцию такого модуля без перечисления ее внутренних деталей. Различие между ними подобно различию между информационной и коммуникативной связностью. Порядок выполнения действий более важен в процедурно связных модулях. Кроме того, процедурные модули имеют тенденцию к совместному использованию циклов и ветвлений, а модули с временной связностью чаще содержат более линейный код.

Логическая связность

Элементы логически связного модуля принадлежат к действиям одной категории, и из этой категории клиент выбирает выполняемое действие. Рассмотрим следующий пример:
Модуль Пересылка сообщения
переслать по электронной почте
переслать по факсу
послать в телеконференцию
переслать по ftp-протоколу
Конец модуля
Как видим, логически связный модуль — мешок доступных действий. Действия вынуждены совместно использовать один и тот же интерфейс модуля. В строке вызова модуля значение каждого параметра зависит от используемого действия. При вызове отдельных действий некоторые параметры должны иметь значение пробела, нулевые значения и т. д. (хотя клиент все же должен использовать их и знать их типы).
Действия в логически связном модуле попадают в одну категорию, хотя имеют не только сходства, но и различия. К сожалению, это заставляет программиста «завязывать код действий в узел», ориентируясь на то, что действия совместно используют общие строки кода. Поэтому логически связный модуль имеет:
уродливый внешний вид с различными параметрами, обеспечивающими, например, четыре вида доступа;
запутанную внутреннюю структуру со множеством переходов, похожую на волшебный лабиринт.
В итоге модуль становится сложным как для понимания, так и для сопровождения.

Связность по совпадению

Элементы связного по совпадению модуля вообще не имеют никаких отношений друг с другом:
Модуль Разные функции (какие-то параметры)
поздравить с Новым годом (...)
проверить исправность аппаратуры (...)
заполнить анкету героя (...)
измерить температуру (...)
вывести собаку на прогулку (...)
запастись продуктами (...)
приобрести «ягуар» (...)
Конец модуля
Связный по совпадению модуль похож на логически связный модуль. Его элементы-действия не связаны ни потоком данных, ни потоком управления. Но в логически связном модуле действия, по крайней мере, относятся к одной категории; в связном по совпадению модуле даже это не так. Словом, связные по совпадению модули имеют все недостатки логически связных модулей и даже усиливают их. Применение таких модулей вселяет ужас, поскольку один параметр используется для разных целей.
Чтобы клиент мог воспользоваться модулем Разные функции, этот модуль (подобно всем связным по совпадению модулям) должен быть «белым ящиком», чья реализация полностью видима. Такие модули делают системы менее понятными и труднее сопровождаемыми, чем системы без модульности вообще!
К счастью, связность по совпадению встречается редко. Среди ее причин можно назвать:
бездумный перевод существующего монолитного кода в модули;
необоснованные изменения модулей с плохой (обычно временной) связностью, приводящие к добавлению флажков.

Определение связности модуля

Приведем алгоритм определения уровня связности модуля.
1. Если модуль — единичная проблемно-ориентированная функция, то уровень связности — функциональный; конец алгоритма. В противном случае перейти к пункту 2.
2. Если действия внутри модуля связаны, то перейти к пункту 3. Если действия внутри модуля никак не связаны, то перейти к пункту 6.
3. Если действия внутри модуля связаны данными, то перейти к пункту 4. Если действия внутри модуля связаны потоком управления, перейти к пункту 5.
4. Если порядок действий внутри модуля важен, то уровень связности — информационный. В противном случае уровень связности — коммуникативный. Конец алгоритма.
5. Если порядок действий внутри модуля важен, то уровень связности — процедурный. В противном случае уровень связности — временной. Конец алгоритма.
6. Если действия внутри модуля принадлежат к одной категории, то уровень связности — логический. Если действия внутри модуля не принадлежат к одной категории, то уровень связности — по совпадению. Конец алгоритма.
Возможны более сложные случаи, когда с модулем ассоциируются несколько уровней связности. В этих случаях следует применять одно из двух правил:
правило параллельной цепи. Если все действия модуля имеют несколько уровней связности, то модулю присваивают самый сильный уровень связности;
правило последовательной цепи. Если действия в модуле имеют разные уровни связности, то модулю присваивают самый слабый уровень связности.
Например, модуль может содержать некоторые действия, которые связаны процедурно, а также другие действия, связные по совпадению. В этом случае применяют правило последовательной цепи и в целом модуль считают связным по совпадению.

Сцепление модулей

Сцепление (Coupling) — мера взаимозависимости модулей поданным [58], [70], [77]. Сцепление — внешняя характеристика модуля, которую желательно уменьшать.
Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов сцепления.
1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В.
Все входные и выходные параметры вызываемого модуля — простые элементы данных (рис. 4.13).

Рис. 4.13. Сцепление поданным

2. Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных (рис. 4.14).

Рис. 4.14. Сцепление по образцу

3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные (рис. 4.15).

Рис. 4.15. Сцепление по управлению

4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.
5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных (рис. 4.16).
6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом (рис. 4.16).

Рис. 4.16. Сцепление по общей области и содержанию

На рис. 4.16 видим, что модули В и D сцеплены по содержанию, а модули С, Е и N сцеплены по общей области.

Сложность программной системы

В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться различными способами.
Например, М. Холстед (1977) предложил меру длины N модуля [33]:
N ? n1log2 (n1) + n2log2(n2),
где n1 — число различных операторов, п2 — число различных операндов.
В качестве второй метрики М. Холстед рассматривал объем V модуля (количество символов для записи всех операторов и операндов текста программы):
V = N x log2 (n1 + n2).
Вместе с тем известно, что любая сложная система состоит из элементов и системы связей между элементами и что игнорировать внутрисистемные связи неразумно.
Том МакКейб (1976) при оценке сложности ПС предложил исходить из топологии внутренних связей [49]. Для этой цели он разработал метрику цикломатической сложности:
V(G) = E-N + 2,
где Е — количество дуг, a.N — количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представляться как локальная структура, состоящая из элементов и связей между ними.
Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей, меру сложности внешних связей (между модулями) и меру сложности внутренних связей (внутри модулей) [28], [56]. Традиционно со внешними связями сопоставляют характеристику «сцепление», а с внутренними связями — характеристику «связность».
Вопросы комплексной оценки сложности обсудим в следующем разделе.

Характеристики иерархической структуры программной системы

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

Рис. 4.17. Иерархическая структура программной системы

Первичными характеристиками являются количество вершин (модулей) и количество ребер (связей между модулями). К ним добавляются две глобальные характеристики — высота и ширина:
высота — количество уровней управления;
ширина — максимальное из количеств модулей, размещенных на уровнях управления.
В нашем примере высота = 4, ширина = 6.
Локальными характеристиками модулей структуры являются коэффициент объединения по входу и коэффициент разветвления по выходу.
Коэффициент объединения по входу Fan_in(i) — это количество модулей, которые прямо управляют i-м модулем.
В примере для модуля n: Fan_in(n)=4.
Коэффициент разветвления по выходу Fan_out(i) — это количество модулей, которыми прямо управляет i-й модуль.
В примере для модуля m: Fan_out(m)=3.
Возникает вопрос: как оценить качество структуры? Из практики проектирования известно, что лучшее решение обеспечивается иерархической структурой в виде дерева.
Степень отличия реальной проектной структуры от дерева характеризуется невязкой структуры. Как определить невязку?
Вспомним, что полный граф (complete graph) с п вершинами имеет количество ребер
ес=n(n-1)/2,
а дерево (tree) с таким же количеством вершин — существенно меньшее количество ребер
et=n-l.
Тогда формулу невязки можно построить, сравнивая количество ребер полного графа, реального графа и дерева.
Для проектной структуры с п вершинами и е ребрами невязка определяется по выражению
.
Значение невязки лежит в диапазоне от 0 до 1. Если Nev = 0, то проектная структура является деревом, если Nev = 1, то проектная структура — полный граф.
Ясно, что невязка дает грубую оценку структуры. Для увеличения точности оценки следует применить характеристики связности и сцепления.
Хорошая структура должна иметь низкое сцепление и высокую связность.
Л. Констентайн и Э. Йордан (1979) предложили оценивать структуру с помощью коэффициентов Fan_in(i) и Fan_out(i) модулей [77].
Большое значение Fan_in(i) — свидетельство высокого сцепления, так как является мерой зависимости модуля. Большое значение Fan_out(i) говорит о высокой сложности вызывающего модуля. Причиной является то, что для координации подчиненных модулей требуется сложная логика управления.
Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игнорировании веса связи. Здесь рассматриваются только управляющие потоки (вызовы модулей). В то же время информационные потоки, нагружающие ребра структуры, могут существенно изменяться, поэтому нужна мера, которая учитывает не только количество ребер, но и количество информации, проходящей через них.
С. Генри и Д. Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j) [35]. Они учитывают количество элементов и структур данных, из которых i-й модуль берет информацию и которые обновляются j-м модулем соответственно.
Информационные коэффициенты суммируются со структурными коэффициентами sfan_in(i) и sfan_out( j), которые учитывают только вызовы модулей.
В результате формируются полные значения коэффициентов:
Fan_in (i) = sfan_in (i) + ifan_in (i),
Fan_out (j) = sfan_out (j) + ifan_out (j).
На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры:
S = length(i) x (Fan_in(i) + Fan_out(i))2,
где length(i) — оценка размера i-го модуля (в виде LOC- или FP-оценки).

1. Какова цель синтеза программной системы? Перечислите этапы синтеза.
2. Дайте определение разработки данных, разработки архитектуры и процедурной разработки.
3. Какие особенности имеет этап проектирования?
4. Решение каких задач обеспечивает предварительное проектирование?
5. Какие модели системного структурирования вы знаете?
6. Чем отличается модель клиент-сервер от трехуровневой модели?
7. Какие типы моделей управления вы знаете?
8. Какие существуют разновидности моделей централизованного управления?
9. Поясните разновидности моделей событийного управления.
10. Поясните понятия модуля и модульности. Зачем используют модули?
11. В чем состоит принцип информационной закрытости? Какие достоинства он имеет?
12. Что такое связность модуля?
13. Какие существуют типы связности?
14. Дайте характеристику функциональной связности.
15. Дайте характеристику информационной связности.
16. Охарактеризуйте коммуникативную связность.
17. Охарактеризуйте процедурную связность.
18. Дайте характеристику временной связности.
19. Дайте характеристику логической связности.
20. Охарактеризуйте связность по совпадению.
21. Что значит «улучшать связность» ?
22. Что такое сцепление модуля?
23. Какие существуют типы сцепления?
24. Дайте характеристику сцепления по данным.
25. Дайте характеристику сцепления по образцу.
26. Охарактеризуйте сцепление по управлению.
27. Охарактеризуйте сцепление по внешним ссылкам.
28. Дайте характеристику сцепления по общей области.
29. Дайте характеристику сцепления по содержанию.
30. Что значит «улучшать сцепление»?
31. Какие подходы к оценке сложности системы вы знаете?
32. Что определяет иерархическая структура программной системы?
33. Поясните первичные характеристики иерархической структуры.
34. Поясните понятия коэффициента объединения по входу и коэффициента раз ветвления по выходу.
35. Что определяет невязка структуры?
36. Поясните информационные коэффициенты объединения и разветвления.

ГЛАВА 5. Классические методы проектирования

В этой главе рассматриваются классические методы проектирования, ориентированные на процедурную реализацию программных систем (ПС). Повторим, что эти методы появились в период революции структурного программирования. Учитывая, что на современном этапе программной инженерии процедурно-ориентированные ПС имеют преимущественно историческое значение, конспективно обсуждаются только два (наиболее популярных) метода: метод структурного проектирования и метод проектирования Майкла Джексона (этот Джексон не имеет никакого отношения к известному певцу). Зачем мы это делаем? Да чтобы знать исторические корни современных методов проектирования.

Метод структурного проектирования

Исходными данными для метода структурного проектирования являются компоненты модели анализа ПС, которая представляется иерархией диаграмм потоков данных [34], [52], [58], [73], [77]. Результат структурного проектирования — иерархическая структура ПС. Действия структурного проектирования зависят от типа информационного потока в модели анализа.

Типы информационных потоков

Различают 2 типа информационных потоков:
1) поток преобразований;
2) поток запросов.
Как показано на рис. 5.1, в потоке преобразований выделяют 3 элемента: Входящий поток, Преобразуемый поток и Выходящий поток.
Потоки запросов имеют в своем составе особые элементы — запросы.
Назначение элемента-запроса состоит в том, чтобы запустить поток данных по одному из нескольких путей. Анализ запроса и переключение потока данных на один из путей действий происходит в центре запросов.
Структуру потока запроса иллюстрирует рис. 5.2.

Рис. 5.1. Элементы потока преобразований

Рис. 5.2. Структура потока запроса

Проектирование для потока данных типа «преобразование»

Шаг 1. Проверка основной системной модели. Модель включает: контекстную диаграмму ПДД0, словарь данных и спецификации процессов. Оценивается их согласованность с системной спецификацией.
Шаг 2. Проверки и уточнения диаграмм потоков данных уровней 1 и 2. Оценивается согласованность диаграмм, достаточность детализации преобразователей.
Шаг 3. Определение типа основного потока диаграммы потоков данных. Основной признак потока преобразований — отсутствие переключения по путям действий.
Шаг 4. Определение границ входящего и выходящего потоков, отделение центра преобразований. Входящий поток — отрезок, на котором информация преобразуется из внешнего во внутренний формат представления. Выходящий поток обеспечивает обратное преобразование — из внутреннего формата во внешний. Границы входящего и выходящего потоков достаточно условны. Вариация одного преобразователя на границе слабо влияет на конечную структуру ПС.
Шаг 5. Определение начальной структуры ПС. Иерархическая структура ПС формируется нисходящим распространением управления. В иерархической структуре:
модули верхнего уровня принимают решения;
модули нижнего уровня выполняют работу по вводу, обработке и выводу;
модули среднего уровня реализуют как функции управления, так и функции обработки.
Начальная структура ПС (для потока преобразования) стандартна и включает главный контроллер (находится на вершине структуры) и три подчиненных контроллера:
1. Контроллер входящего потока (контролирует получение входных данных).
2. Контроллер преобразуемого потока (управляет операциями над данными во внутреннем формате).
3. Контроллер выходящего потока (управляет получением выходных данных).
Данный минимальный набор модулей покрывает все функции управления, обеспечивает хорошую связность и слабое сцепление структуры.
Начальная структура ПС представлена на рис. 5.3.

Диаграмма потоков данных ПДД

Рис. 5.3. Начальная структура ПС для потока «преобразование»

Шаг 6. Детализация структуры ПС. Выполняется отображение преобразователей ПДД в модули структуры ПС. Отображение выполняется движением по ПДД от границ центра преобразования вдоль входящего и выходящего потоков. Входящий поток проходится от конца к началу, а выходящий поток — от начала к концу. В ходе движения преобразователи отображаются в модули подчиненных уровней структуры (рис. 5.4).
Центр преобразования ПДД отображается иначе (рис. 5.5). Каждый преобразователь отображается в модуль, непосредственно подчиненный контроллеру центра.
Проходится преобразуемый поток слева направо.
Возможны следующие варианты отображения:
1 преобразователь отображается в 1 модуль;
2-3 преобразователя отображаются в 1 модуль;
1 преобразователь отображается в 2-3 модуля.

Рис. 5.4. Отображение преобразователей ПДД в модули структуры

Рис. 5.5. Отображение центра преобразования ПДД

Для каждого модуля полученной структуры на базе спецификаций процессов модели анализа пишется сокращенное описание обработки.
Шаг 7. Уточнение иерархической структуры ПС. Модули разделяются и объединяются для:
1) повышения связности и уменьшения сцепления;
2) упрощения реализации;
3) упрощения тестирования;
4) повышения удобства сопровождения.

Проектирование для потока данных типа «запрос»
Шаг 1. Проверка основной системной модели. Модель включает: контекстную диаграмму ПДДО, словарь данных и спецификации процессов. Оценивается их согласованность с системной спецификацией.
Шаг 2. Проверки и уточнения диаграмм потоков данных уровней 1 и 2. Оценивается согласованность диаграмм, достаточность детализации преобразователей.
Шаг 3. Определение типа основного потока диаграммы потоков данных. Основной признак потоков запросов — явное переключение данных на один из путей действий.
Шаг 4. Определение центра запросов и типа для каждого из потоков действия. Если конкретный поток действия имеет тип «преобразование», то для него указываются границы входящего, преобразуемого и выходящего потоков.
Шаг 5. Определение начальной структуры ПС. В начальную структуру отображается та часть диаграммы потоков данных, в которой распространяется поток запросов. Начальная структура ПС для потока запросов стандартна и включает входящую ветвь и диспетчерскую ветвь.
Структура входящей ветви формируется так же, как и в предыдущей методике.
Диспетчерская ветвь включает диспетчер, находящийся на вершине ветви, и контроллеры потоков действия, подчиненные диспетчеру; их должно быть столько, сколько имеется потоков действий.

Диаграмма потоков данных

Рис. 5.6. Отображение в модульную структуру ПС потока действия 1

Шаг 6. Детализация структуры ПС. Производится отображение в структуру каждого потока действия. Каждый поток действия имеет свой тип. Могут встретиться поток-«преобразование» (отображается по предыдущей методике) и поток запросов. На рис. 5.6 приведен пример отображения потока действия 1. Подразумевается, что он является потоком преобразования.
Шаг 7. Уточнение иерархической структуры ПС. Уточнение выполняется для повышения качества системы. Как и при предыдущей методике, критериями уточнения служат: независимость модулей, эффективность реализации и тестирования, улучшение сопровождаемости.

Метод проектирования Джексона

Для иллюстрации проектирования по этому методу продолжим пример с системой обслуживания перевозок.
Метод Джексона включает шесть шагов [39]. Три первых шага относятся к этапу анализа. Это шаги: объект — действие, объект — структура, начальное моделирование. Их мы уже рассмотрели.

Доопределение функций

Следующий шаг — доопределение функций. Этот шаг развивает диаграмму системной спецификации этапа анализа. Уточняются процессы-модели. В них вводятся дополнительные функции. Джексон выделяет 3 типа сервисных функций:
1. Встроенные функции (задаются командами, вставляемыми в структурный текст процесса-модели).
2. Функции впечатления (наблюдают вектор состояния процесса-модели и вырабатывают выходные результаты).
3. Функции диалога.
Они решают следующие задачи:
наблюдают вектор состояния процесса-модели;
формируют и выводят поток данных, влияющий на действия в процессе-модели;
выполняют операции для выработки некоторых результатов.
Встроенную функцию введем в модель ТРАНСПОРТ-1. Предположим, что в модели есть панель с лампочкой, сигнализирующей о прибытии. Лампочка включается командой LON(i), а выключается командой LOFF(i). По мере перемещения транспорта между остановками формируется поток LAMP-команд. Модифицированный структурный текст модели ТРАНСПОРТ-1 принимает вид
ТРАНСПОРТ-1
LON(l);
опрос SV;
ЖДАТЬ цикл ПОКА ПРИБЫЛ(1)
опрос SV;
конец ЖДАТЬ;
LOFF(l);
покинуть(1);
ТРАНЗИТ цикл ПОКА УБЫЛ(1)
опрос SV;
конец ТРАНЗИТ;
ТРАНСПОРТ цикл
ОСТАНОВКА;
прибыть(i);
LON(i);
ЖДАТЬ цикл ПОКА ПРИБЫЛ(i)
опрос SV;
конец ЖДАТЬ;
LOFF(i);
покинуть(i);
ТРАНЗИТ цикл ПОКА УБЫЛ(i)
опрос SV;
конец ТРАНЗИТ;
конец ОСТАНОВКА;
конец ТРАНСПОРТ;
прибыть(1);
конец ТРАНСПОРТ-1;
Теперь введем функцию впечатления. В нашем примере она может формировать команды для мотора транспорта: START, STOP.
Условия выработки этих команд.
Команда STOP формируется, когда датчики регистрируют прибытие транспорта на остановку.
Команда START формируется, когда нажата кнопка для запроса транспорта и транспорт ждет на одной из остановок.
Видим, что для выработки команды STOP необходима информация только от модели транспорта. В свою очередь, для выработки команды START нужна информация как от модели КНОПКА-1, так и от модели ТРАНСПОРТ-1. В силу этого для реализации функции впечатления введем функциональный процесс М-УПРАВЛЕНИЕ. Он будет обрабатывать внешние данные и формировать команды START и STOP.
Ясно, что процесс М-УПРАВЛЕНИЕ должен иметь внешние связи с моделями ТРАНСПОРТ-1 и КНОПКА. Соединение с моделью КНОПКА организуем через вектор состояния BV. Соединение с моделью ТРАНСПОРТ-1 организуем через поток данных S1D.
Для обеспечения М-УПРАВЛЕНИЯ необходимой информацией опять надо изменить структурный текст модели ТРАНСПОРТ-1. В нем предусмотрим занесение сообщения Прибыл в буфер S1D:
ТРАНСПОРТ-1
LON(l);
опрос SV;
ЖДАТЬ цикл ПОКА ПРИБЫЛ(1)
опрос SV;
конец ЖДАТЬ;
LOFF(l);
Покинуть(1);
ТРАНЗИТ цикл ПОКА УБЫЛ(1)
опрос SV;
конец ТРАНЗИТ;
ТРАНСПОРТ цикл
ОСТАНОВКА;
прибыть(i):
записать Прибыл в S1D;
LON(i);
ЖДАТЬ цикл ПОКА ПРИБЫЛ(i)
опрос SV;
конец ЖДАТЬ;
LOFF(i);
покинуть(i);
ТРАНЗИТ цикл ПОКА УБЫЛ(i)
опрос SV;
конец ТРАНЗИТ;
конец ОСТАНОВКА;
конец ТРАНСПОРТ;
прибыть(1);
записать Прибыл в S1D;
конец ТРАНСПОРТ-1;
Очевидно, что при такой связи процессов необходимо гарантировать, что процесс ТРАНСПОРТ-1 выполняет операции опрос SV, а процесс М-УПРАВЛЕНИЕ читает сообщения Прибытия в S1D с частотой, достаточной для своевременной остановки транспорта. Временные ограничения, планирование и реализация должны рассматриваться в последующих шагах проектирования.
В заключение введем функцию диалога. Свяжем эту функцию с необходимостью развития модели КНОПКА-1. Следует различать первое нажатие на кнопку (оно формирует запрос на поездку) и последующие нажатия на кнопку (до того, как поездка действительно началась).
Диаграмма дополнительного процесса КНОПКА-2, в котором учтено это уточнение, показана на рис. 5.7.

Рис. 5.7. Диаграмма дополнительного процесса КНОПКА-2

Внешние связи модели КНОПКА-2 должны включать:
одно соединеннее моделью КНОПКА-1 — организуется через поток данных BID (для приема сообщения о нажатии кнопки);
два соединения с процессом М-УПРАВЛЕНИЕ — одно организуется через поток данных MBD (для приема сообщения о прибытии транспорта), другое организуется через вектор состояния BV (для передачи состояния переключателя Запрос).
Таким образом, КНОПКА-2 читает два буфера данных, заполняемых процессами КНОПКА-1 и М-УПРАВЛЕНИЕ, и формирует состояние внутреннего электронного переключателя Запрос. Она реализует функцию диалога.
Структурный текст модели КНОПКА-2 может иметь следующий вид:
КНОПКА-2
Запрос := НЕТ;
читать B1D;
ГрНАЖ цикл
ЖдатьНАЖ цикл ПОКА Не НАЖАТА
читать B1D;
конец ЖдатьНАЖ;
Запрос := ДА;
читать MBD;
ЖдатьОБСЛУЖ цикл ПОКА Не ПРИБЫЛ
читать MBD;
конец ЖдатьОБСЛУЖ;
Запрос := НЕТ; читать B1D;
конец ГрНАЖ;
конец КНОПКА-2;
Диаграмма системной спецификации, отражающая все изменения, представлена на рис. 5.8.

Рис. 5.8. Полная диаграмма системной спецификации

Встроенная в ТРАНСПОРТ-1 функция вырабатывает LAMP-команды, функция впечатления модели М-УПРАВЛЕНИЕ генерирует команды управления мотором, а модель КНОПКА-2 реализует функцию диалога (совместно с процессом М-УПРАВЛЕНИЕ).

Учет системного времени

На шаге учета системного времени проектировщик определяет временные ограничения, накладываемые на систему, фиксирует дисциплину планирования. Дело в том, что на предыдущих шагах проектирования была получена система, составленная из последовательных процессов. Эти процессы связывали только потоки данных, передаваемые через буфер, и взаимные наблюдения векторов состояния. Теперь необходимо произвести дополнительную синхронизацию процессов во времени, учесть влияние внешней программно-аппаратной среды и совместно используемых системных ресурсов.
Временные ограничения для системы обслуживания перевозок, в частности, включают:
временной интервал на выработку команды STOP; он должен выбираться путем анализа скорости транспорта и ограничения мощности;
время реакции на включение и выключение ламп панели.
Для рассмотренного примера нет необходимости вводить специальный механизм синхронизации. Однако при расширении может потребоваться некоторая синхронизация обмена данными.

Контрольные вопросы

1. В чем состоит суть метода структурного проектирования?
2. Какие различают типы информационных потоков?
3. Что такое входящий поток?
4. Что такое выходящий поток?
5. Что такое центр преобразования?
6. Как производится отображение входящего потока?
7. Как производится отображение выходящего потока?
8. Как производится отображение центра преобразования?
9. Какие задачи решают главный контроллер, контроллер входящего потока, контроллер выходящего потока и контроллер центра преобразования?
10. Поясните шаги метода структурного проектирования.
11. Что такое входящая ветвь?
12. Что такое диспетчерская ветвь?
13. Какие существуют различия в методике отображения потока преобразований и потока запросов?
14. Какие задачи уточнения иерархической структуры программной системы вы знаете?
15. Какие шаги предусматривает метод Джексона на этапе проектирования?
16. В чем состоит суть развития диаграммы системной спецификации Джексона?
17. Поясните понятие встроенной функции.
18. Поясните понятие функции впечатления.
19. Поясните понятие функции диалога.
20. В чем состоит учет системного времени (в методе Джексона)?

ГЛАВА 6. Структурное тестирование программного обеспечения

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

Основные понятия и принципы тестирования ПО

Тестирование — процесс выполнения программы с целью обнаружения ошибок. Шаги процесса задаются тестами.
Каждый тест определяет:
свой набор исходных данных и условий для запуска программы;
набор ожидаемых результатов работы программы.
Другое название теста — тестовый вариант. Полную проверку программы гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тестовых вариантов. Увы, но исчерпывающее тестирование во многих случаях остается только мечтой — срабатывают ресурсные ограничения (прежде всего, ограничения по времени).
Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки. Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.
Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.
Важен ответ на вопрос: что может тестирование?
Тестирование обеспечивает:
обнаружение ошибок;
демонстрацию соответствия функций программы ее назначению;
демонстрацию реализации требований к характеристикам программы;
отображение надежности как индикатора качества программы.
А чего не может тестирование? Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов). Важно помнить это (скорее печальное) утверждение при проведении тестирования.
Рассмотрим информационные потоки процесса тестирования. Они показаны на рис. 6.1.

Рис. 6.1. Информационные потоки процесса тестирования

На входе процесса тестирования три потока:
текст программы;
исходные данные для запуска программы;
ожидаемые результаты.
Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами. Когда обнаруживается несовпадение, фиксируется ошибка — начинается отладка. Процесс отладки непредсказуем по времени. На поиск места дефекта и исправление может потребоваться час, день, месяц. Неопределенность в отладке приводит к большим трудностям в планировании действий.
После сбора и оценивания результатов тестирования начинается отображение качества и надежности ПО. Если регулярно встречаются серьезные ошибки, требующие проектных изменений, то качество и надежность ПО подозрительны, констатируется необходимость усиления тестирования. С другой стороны, если функции ПО реализованы правильно, а обнаруженные ошибки легко исправляются, может быть сделан один из двух выводов:
качество и надежность ПО удовлетворительны;
тесты не способны обнаруживать серьезные ошибки.
В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).
Результаты, накопленные в ходе тестирования, могут оцениваться и более формальным способом. Для этого используют модели надежности ПО, выполняющие прогноз надежности по реальным данным об интенсивности ошибок.
Существуют 2 принципа тестирования программы:
функциональное тестирование (тестирование «черного ящика»);
структурное тестирование (тестирование «белого ящика»).

Тестирование «черного ящика»

Известны: функции программы.
Исследуется: работа каждой функции на всей области определения.
Как показано на рис. 6.2, основное место приложения тестов «черного ящика» — интерфейс ПО.

Рис. 6.2. Тестирование «черного ящика»

Эти тесты демонстрируют:
как выполняются функции программ;
как принимаются исходные данные;
как вырабатываются результаты;
как сохраняется целостность внешней информации.
При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 1010 тестовых вариантов. Отметим также, что тестирование «черного ящика» не реагирует на многие особенности программных ошибок.

Тестирование «белого ящика»

Известна: внутренняя структура программы.
Исследуются: внутренние элементы программы и связи между ними (рис. 6.3).

Рис. 6.3. Тестирование «белого ящика»

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

Особенности тестирования «белого ящика»

Обычно тестирование «белого ящика» основано на анализе управляющей структуры программы [2], [13]. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.
В этом случае формируются тестовые варианты, в которых:
гарантируется проверка всех независимых маршрутов программы;
проходятся ветви True, False для всех логических решений;
выполняются все циклы (в пределах их границ и диапазонов);
анализируется правильность внутренних структур данных.
Недостатки тестирования «белого ящика»:
1. Количество независимых маршрутов может быть очень велико. Например, если цикл в программе выполняется k раз, а внутри цикла имеется п ветвлений, то количество маршрутов вычисляется по формуле
.
При п = 5 и k = 20 количество маршрутов т = 1014. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.
2. Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.
3. В программе могут быть пропущены некоторые маршруты.
4. Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных (это ошибки, обусловленные выражениями типа if abs (a-b) < eps..., if(a+b+c)/3=a...).
Достоинства тестирования «белого ящика» связаны с тем, что принцип «белого ящика» позволяет учесть особенности программных ошибок:
1. Количество ошибок минимально в «центре» и максимально на «периферии» программы.
2. Предварительные предположения о вероятности потока управления или данных в программе часто бывают некорректны. В результате типовым может стать маршрут, модель вычислений по которому проработана слабо.
3. При записи алгоритма ПО в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических).
4. Некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.
Каждая из этих причин является аргументом для проведения тестирования по принципу «белого ящика». Тесты «черного ящика» не смогут реагировать на ошибки таких типов.

Способ тестирования базового пути

Тестирование базового пути — это способ, который основан на принципе «белого ящика». Автор этого способа — Том МакКейб (1976) [49].
Способ тестирования базового пути дает возможность:
получить оценку комплексной сложности программы;
использовать эту оценку для определения необходимого количества тестовых вариантов.
Тестовые варианты разрабатываются для проверки базового множества путей (маршрутов) в программе. Они гарантируют однократное выполнение каждого оператора программы при тестировании.

Потоковый граф

Для представления программы используется потоковый граф. Перечислим его особенности.
1. Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) операторы.
2. Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.
3. Дуги потокового графа отображают поток управления в программе (передачи управления между операторами). Дуга — это ориентированное ребро.
4. Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного — две дуги.
4. Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций (OR, AND).
5. Например, фрагмент программы
if a OR b
then x
else у
end if;
вместо прямого отображения в потоковый граф вида, показанного на рис. 6.4, отображается в преобразованный потоковый граф (рис. 6.5).

Рис. 6.4. Прямое отображение в потоковый граф

Рис. 6.5. Преобразованный потоковый граф

6. Замкнутые области, образованные дугами и узлами, называют регионами.
7. Окружающая граф среда рассматривается как дополнительный регион. Например, показанный здесь граф имеет три региона — Rl, R2, R3.
Пример 1. Рассмотрим процедуру сжатия:
процедура сжатие
1 выполнять пока нет EOF
1 читать запись;
2 если запись пуста
3 то удалить запись:
4 иначе если поле а >= поля b
5 то удалить b;
6 иначе удалить а;
7а конец если;
7а конец если;
7b конец выполнять;
8 конец сжатие;

Рис. 6.6. Преобразованный потоковый граф процедуры сжатия

Она отображается в потоковый граф, представленный на рис. 6.6. Видим, что этот потоковый граф имеет четыре региона.

Цикломатическая сложность

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

Перечислим независимые пути для потокового графа из примера 1:
Путь 1: 1-8.
Путь 2: 1-2-3-7а-7b-1-8.
Путь 3: 1-2-4-5-7а-7b-1-8.
Путь 4: 1-2-4-6-7а-7b-1-8.
Заметим, что каждый новый путь включает новую дугу.
Все независимые пути графа образуют базовое множество.
Свойства базового множества:
1) тесты, обеспечивающие его проверку, гарантируют:
однократное выполнение каждого оператора;
выполнение каждого условия по True-ветви и по False-ветви;
2) мощность базового множества равна цикломатической сложности потокового графа.
Значение 2-го свойства трудно переоценить — оно дает априорную оценку количества независимых путей, которое имеет смысл искать в графе.
Цикломатическая сложность вычисляется одним из трех способов:
1) цикломатическая сложность равна количеству регионов потокового графа;
2) цикломатическая сложность определяется по формуле
V(G)-E-N+2,
где Е — количество дуг, N — количество узлов потокового графа;
3) цикломатическая сложность формируется по выражению V(G) =p+ 1, где р — количество предикатных узлов в потоковом графе G.
Вычислим цикломатическую сложность графа из примера 1 каждым из трех способов:
1) потоковый граф имеет 4 региона;
2) V(G) = 11 дуг - 9 узлов + 2 = 4;
3) V(G) = 3 предикатных узла +1=4.
Таким образом, цикломатическая сложность потокового графа из примера 1 равна четырем.

Шаги способа тестирования базового пути

Для иллюстрации шагов данного способа используем конкретную программу — процедуру вычисления среднего значения:
процедура сред;
1 i := 1;
1 введено := 0;
1 колич := 0;
1 сум := 0;
вып пока 2 -вел( i ) <> stop и введено <=500 - 3
4 введено:= введено + 1;
если 5 -вел( i ) >= мин и вел( i ) <= макс - 6
7 то колич := колич + 1;
7 сум := сум + вел( i );
8 конец если;
8 i := i + 1;
9 конец вып;
10 если колич > 0
11 то сред := сум / колич;
12 иначе сред := stop;
13 конец если;
13 конец сред;
Заметим, что процедура содержит составные условия (в заголовке цикла и условном операторе). Элементы составных условий для наглядности помещены в рамки.
Шаг 1. На основе текста программы формируется потоковый граф:
нумеруются операторы текста (номера операторов показаны в тексте процедуры);
производится отображение пронумерованного текста программы в узлы и вершины потокового графа (рис. 6.7).

Рис. 6.7. Потоковый граф процедуры вычисления среднего значения

Шаг 2. Определяется цикломатическая сложность потокового графа — по каждой из трех формул:
1) V(G) = 6 регионов;
2) V(G) = 17 дуг - 13 узлов + 2 = 6;
3) V(G) = 5 предикатных узлов + 1 = 6.
Шаг 3. Определяется базовое множество независимых линейных путей:
Путь 1: 1-2-10-11-13; /вел=stор, колич>0.
Путь 2: 1-2-10-12-13;/вел=stop, колич=0.
Путь 3: 1-2-3-10-11-13; /попытка обработки 501-й величины.
Путь 4: 1-2-3-4-5-8-9-2-... /вел<мин.
Путь 5: 1-2-3-4-5-6-8-9-2-... /вел>макс.
Путь 6: 1-2-3-4-5-6-7-8-9-2-... /режим нормальной обработки.

ПРИМЕЧАНИЕ
Для удобства дальнейшего анализа по каждому пути указаны условия запуска. Точки в конце путей 4, 5, 6 указывают, что допускается любое продолжение через остаток управляющей структуры графа.

Шаг 4. Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.
Каждый тестовый вариант формируется в следующем виде:
Исходные данные (ИД):
Ожидаемые результаты (ОЖ.РЕЗ.):
Исходные данные должны выбираться так, чтобы предикатные вершины обеспечивали нужные переключения — запуск только тех операторов, которые перечислены в конкретном пути, причем в требуемом порядке.
Определим тестовые варианты, удовлетворяющие выявленному множеству независимых путей.
Тестовый вариант для пути 1 ТВ1:
ИД: вел(k) = допустимое значение, где k < i; вел(i) = stop, где 2 < i < 500.
ОЖ.РЕЗ.: корректное усреднение основывается на k величинах и правильном подсчете.

ПРИМЕЧАНИЕ
Путь не может тестироваться самостоятельно, а должен тестироваться как часть путей 4, 5, 6 (трудности проверки 11-го оператора).

Тестовый вариант для пути 2 ТВ2:
ИД: вел(1)=stор.
ОЖ.РЕЗ.: сред=stор, другие величины имеют начальные значения.
Тестовый вариант для пути 3 ТВЗ:
ИД: попытка обработки 501-й величины, первые 500 величин должны быть правильными.
ОЖ.РЕЗ.: корректное усреднение основывается на k величинах и правильном подсчете.
Тестовый вариант для пути 4 ТВ4:
ИД: вел(i)=допустимое значение, где i ? 500; вел(k) < мин, где k < i.
ОЖ.РЕЗ.: корректное усреднение основывается на k величинах и правильном подсчете.
Тестовый вариант для пути 5 ТВ5:
ИД: вел(i)=допустимое значение, где i ? 500; вел(k) > макс, где k < i.
ОЖ.РЕЗ.: корректное усреднение основывается на п величинах и правильном подсчете.
Тестовый вариант для пути 6 ТВ6:
ИД: вел(i)=допустимое значение, где i ? 500.
ОЖ.РЕЗ.: корректное усреднение основывается на п величинах и правильном подсчете.
Реальные результаты каждого тестового варианта сравниваются с ожидаемыми результатами. После выполнения всех тестовых вариантов гарантируется, что все операторы программы выполнены по меньшей мере один раз.
Важно отметить, что некоторые независимые пути не могут проверяться изолированно. Такие пути должны проверяться при тестировании другого пути (как часть другого тестового варианта).

Способы тестирования условий

Цель этого семейства способов тестирования — строить тестовые варианты для проверки логических условий программы. При этом желательно обеспечить охват операторов из всех ветвей программы.
Рассмотрим используемую здесь терминологию.
Простое условие — булева переменная или выражение отношения.
Выражение отношения имеет вид
Е1 <оператор отношения> E2,
где El, Е2 — арифметические выражения, а в качестве оператора отношения используется один из следующих операторов: <, >, =, , .
Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.
Таким образом, элементами условия являются: булев оператор, булева переменная, пара скобок (заключающая простое или составное условие), оператор отношения, арифметическое выражение. Эти элементы определяют типы ошибок в условиях.
Если условие некорректно, то некорректен по меньшей мере один из элементов условия. Следовательно, в условии возможны следующие типы ошибок:
ошибка булева оператора (наличие некорректных / отсутствующих / избыточных булевых операторов);
ошибка булевой переменной;
ошибка булевой скобки;
ошибка оператора отношения;
ошибка арифметического выражения.
Способ тестирования условий ориентирован на тестирование каждого условия в программе. Методики тестирования условий имеют два достоинства. Во-первых, достаточно просто выполнить измерение тестового покрытия условия. Во-вторых, тестовое покрытие условий в программе — это фундамент для генерации дополнительных тестов программы.
Целью тестирования условий является определение не только ошибок в условиях, но и других ошибок в программах. Если набор тестов для программы А эффективен для обнаружения ошибок в условиях, содержащихся в А, то вероятно, что этот набор также эффективен для обнаружения других ошибок в А. Кроме того, если методика тестирования эффективна для обнаружения ошибок в условии, то вероятно, что эта методика будет эффективна для обнаружения ошибок в программе.
Существует несколько методик тестирования условий.
Простейшая методика — тестирование ветвей. Здесь для составного условия С проверяется:
каждое простое условие (входящее в него);
Тruе-ветвь;
False-ветвь.
Другая методика — тестирование области определения. В ней для выражения отношения требуется генерация 3-4 тестов. Выражение вида
Е1 <оператор отношения> Е2
проверяется тремя тестами, которые формируют значение Е1 большим, чем Е2, равным Е2 и меньшим, чем Е2.
Если оператор отношения неправилен, а Е1 и Е2 корректны, то эти три теста гарантируют обнаружение ошибки оператора отношения.
Для определения ошибок в Е1 и Е2 тест должен сформировать значение Е1 большим или меньшим, чем Е2, причем обеспечить как можно меньшую разницу между этими значениями.
Для булевых выражений с п переменными требуется набор из 2n тестов. Этот набор позволяет обнаружить ошибки булевых операторов, переменных и скобок, но практичен только при малом п. Впрочем, если в булево выражение каждая булева переменная входит только один раз, то количество тестов легко уменьшается.
Обсудим способ тестирования условий, базирующийся на приведенных выше методиках.

Тестирование ветвей и операторов отношений

Способ тестирования ветвей и операторов отношений (автор К. Таи, 1989) обнаруживает ошибки ветвления и операторов отношения в условии, для которого выполняются следующие ограничения [72]:
все булевы переменные и операторы отношения входят в условие только по одному разу;
в условии нет общих переменных.
В данном способе используются естественные ограничения условий (ограничения на результат). Для составного условия С, включающего п простых условий, формируется ограничение условия:
ОУс = (d1,d2,d3.....dn),
где di — ограничение на результат i-го простого условия.
Ограничение на результат фиксирует возможные значения аргумента (переменной) простого условия (если он один) или соотношения между значениями аргументов (если их несколько).
Если i-e простое условие является булевой переменной, то его ограничение на результат состоит из двух значений и имеет вид
di = (true, false).
Если j-е простое условие является выражением отношения, то его ограничение на результат состоит из трех значений и имеет следующий вид:
dj= (>,<,=).
Говорят, что ограничение условия ОУc (для условия С) покрывается выполнением С, если в ходе этого выполнения результат каждого простого условия в С удовлетворяет соответствующему ограничению в ОУc.
На основе ограничения условия ОУ создается ограничивающее множество ОМ, элементы которого являются сочетаниями всех возможных значений d1, d2, d3, ..., dn.
Ограничивающее множество — удобный инструмент для записи задания на тестирование, ведь оно составляется из сведений о значениях переменных, которые влияют на значение проверяемого условия. Поясним это на примере. Положим, надо проверить условие, составленное из трех простых условий:
b&(х>у)&а.
Условие принимает истинное значение, если все простые условия истинны. В терминах значений простых условий это соответствует записи
(true, true, true),
а в терминах ограничений на значения аргументов простых условий — записи
(true, >, true).
Ясно, что вторая запись является прямым руководством для написания теста. Она указывает, что переменная b должна иметь истинное значение, значение переменной х должно быть больше значения переменной у, и, наконец, переменная а должна иметь истинное значение.
Итак, каждый элемент ОМ задает отдельный тестовый вариант. Исходные данные тестового варианта должны обеспечить соответствующую комбинацию значений простых условий, а ожидаемый результат равен значению составного условия.
Пример 1. В качестве примера рассмотрим два типовых составных условия:
С& = а & Ь, Сor =а or b,
где а и b — булевы переменные. Соответствующие ограничения условий принимают вид
ОУ&=( d1,d2), ОУor=( d1,d2),
где d1 = d2 = (true, false).
Ограничивающие множества удобно строить с помощью таблицы истинности (табл. 6.1).

Таблица 6.1. Таблица истинности логических операций
Вариант
а
b
a & b
a or b
1
false
false
false
false
2
false
true
false
true
3
true
false
false
true
4
true
true
true
true

Видим, что таблица задает в ОМ четыре элемента (и соответственно, четыре тестовых варианта). Зададим вопрос — каковы возможности минимизации? Можно ли уменьшить количество элементов в ОМ?
С точки зрения тестирования, нам надо оценивать влияние составного условия на программу. Составное условие может принимать только два значения, но каждое из значений зависит от большого количества простых условий. Стоит задача — избавиться от влияния избыточных сочетаний значений простых условий.
Воспользуемся идеей сокращенной схемы вычисления — элементы выражения вычисляются до тех пор, пока они влияют на значение выражения. При тестировании необходимо выявить ошибки переключения, то есть ошибки из-за булева оператора, оперируя значениями простых условий (булевых переменных). При таком инженерном подходе справедливы следующие выводы:
для условия типа И (а & b) варианты 2 и 3 поглощают вариант 1. Поэтому ограничивающее множество имеет вид:
ОМ& = {(false, true), (true, false), (true, true)};
для условия типа ИЛИ (а or b) варианты 2 и 3 поглощают вариант 4. Поэтому ограничивающее множество имеет вид:
ОМor = {(false, false), (false, true), (true, false)}.
Рассмотрим шаги способа тестирования ветвей и операторов отношений.
Для каждого условия в программе выполняются следующие действия:
1) строится ограничение условий ОУ;
2) выявляются ограничения результата по каждому простому условию;
3) строится ограничивающее множество ОМ. Построение выполняется путем подстановки в константные формулы ОМ& или OMOR выявленных ограничений результата;
4) для каждого элемента ОМ разрабатывается тестовый вариант.
Пример 2. Рассмотрим составное условие С1 вида:
В1 &(E1,E2),
где В1 — булево выражение, E1, Е2 — арифметические выражения.
Ограничение составного условия имеет вид
ОУ =( d1,d2),
где ограничения простых условий равны
d1 = (true, false), d2 = (=, <, >).
Проводя аналогию между С1 и С& (разница лишь в том, что в С1 второе простое условие — это выражение отношения), мы можем построить ограничивающее множество для С1 модификацией
ОМ& = {(false, true), (true, false), (true, true)}.
Заметим, что true для (E1= E2) означает =, a false для (E1 = E2) означает или <, или >. Заменяя (true, true) и (false, true), ограничениями (true, =) и (false, =) соответственно, a (true, false) — ограничениями (true, <) и (true, >), получаем ограничивающее множество для С1:
ОМ = {(false,=),(true,<),(true,>),(true,=)}.
Покрытие этого множества гарантирует обнаружение ошибок булевых операторов и операторов отношения в С1.
Пример 3. Рассмотрим составное условие С2 вида
(E3 >E4)&(E1=E2),
где E1, Е2, Е3, Е4 — арифметические выражения. Ограничение составного условия имеет вид
ОУ =( d1,d2),
где ограничения простых условий равны
d1=(=,<,>), d2 =(=,<,>).
Проводя аналогию между С2 и С1 (разница лишь в том, что в С2 первое простое условие — это выражение отношения), мы можем построить ограничивающее множество для С2 модификацией ОМ:
ОМ = {(=, =), (<, =), (>, <),(>, >),(>, =)}.
Покрытие этого ограничивающего множества гарантирует обнаружение ошибок операторов отношения в С2.

Способ тестирования потоков данных

В предыдущих способах тесты строились на основе анализа управляющей структуры программы. В данном способе анализу подвергается информационная структура программы.
Работу любой программы можно рассматривать как обработку потока данных, передаваемых от входа в программу к ее выходу.
Рассмотрим пример.
Пусть потоковый граф программы имеет вид, представленный на рис. 6.8. В нем сплошные дуги — это связи по управлению между операторами в программе. Пунктирные дуги отмечают информационные связи (связи по потокам данных). Обозначенные здесь информационные связи соответствуют следующим допущениям:
в вершине 1 определяются значения переменных а, b;
значение переменной а используется в вершине 4;
значение переменной b используется в вершинах 3, 6;
в вершине 4 определяется значение переменной с, которая используется в вершине 6.

Рис. 6.8. Граф программы с управляющими и информационными связями

В общем случае для каждой вершины графа можно записать:
множество определений данных
DEF(i) = { х | i -я вершина содержит определение х};
множество использований данных:
USE (i) = { х | i -я вершина использует х}.
Под определением данных понимают действия, изменяющие элемент данных. Признак определения — имя элемента стоит в левой части оператора присваивания:
x:=f(…).
Использование данных — это применение элемента в выражении, где происходит обращение к элементу данных, но не изменение элемента. Признак использования — имя элемента стоит в правой части оператора присваивания:
?:=f(x).
Здесь место подстановки другого имени отмечено прямоугольником (прямоугольник играет роль метки-заполнителя).
Назовём DU-цепочкой (цепочкой определения-использования) конструкцию [х, i,j], где i,j — имена вершин; х определена в i-й вершине (х DЕF(i)) и используется в j -й вершине (х USE(j)).
В нашем примере существуют следующие DU-цепочки:
[а,1,4],[b, 1,3], [b, 1,6], [с, 4, 6].
Способ DU-тестирования требует охвата всех DU-цепочек программы. Таким образом, разработка тестов здесь проводится на основе анализа жизни всех данных программы.
Очевидно, что для подготовки тестов требуется выделение маршрутов — путей выполнения программы на управляющем графе. Критерий для выбора пути — покрытие максимального количества DU-цепочек.
Шаги способа DU-тестирования:
1) построение управляющего графа (УГ) программы;
2) построение информационного графа (ИГ);
3) формирование полного набора DU-цепочек;
4) формирование полного набора отрезков путей в управляющем графе (отображением набора DU-цепочек информационного графа, рис. 6.9);

Рис. 6.9. Отображение DU-цепочки в отрезок пути

5) построение маршрутов — полных путей на управляющем графе, покрывающих набор отрезков путей управляющего графа;
6) подготовка тестовых вариантов.
Достоинства DU-тестирования:
простота необходимого анализа операционно-управляющей структуры программы;
простота автоматизации.
Недостаток DU-тестирования: трудности в выборе минимального количества максимально эффективных тестов.
Область использования DU-тестирования: программы с вложенными условными операторами и операторами цикла.

Тестирование циклов

Цикл — наиболее распространенная конструкция алгоритмов, реализуемых в ПО. Тестирование циклов производится по принципу «белого ящика», при проверке циклов основное внимание обращается на правильность конструкций циклов.
Различают 4 типа циклов: простые, вложенные, объединенные, неструктурированные. Структура циклов приведена на рис. 6.10.

Рис. 6.10. Типовые структуры циклов

Простые циклы

Для проверки простых циклов с количеством повторений п может использоваться один из следующих наборов тестов:
1) прогон всего цикла;
2) только один проход цикла;
3) два прохода цикла;
4) т проходов цикла, где т<п;
5) п - 1, п, п + 1 проходов цикла.

Вложенные циклы

С увеличением уровня вложенности циклов количество возможных путей резко возрастает. Это приводит к нереализуемому количеству тестов [13]. Для сокращения количества тестов применяется специальная методика, в которой используются такие понятия, как объемлющий и вложенный циклы (рис. 6.11).

Рис. 6.11. Объемлющий и вложенный циклы

Порядок тестирования вложенных циклов иллюстрирует рис. 6.12.

Рис. 6.12. Шаги тестирования вложенных циклов

Шаги тестирования.
1. Выбирается самый внутренний цикл. Устанавливаются минимальные значения параметров всех остальных циклов.
2. Для внутреннего цикла проводятся тесты простого цикла. Добавляются тесты для исключенных значений и значений, выходящих за пределы рабочего диапазона.
3. Переходят в следующий по порядку объемлющий цикл. Выполняют его тестирование. При этом сохраняются минимальные значения параметров для всех внешних (объемлющих) циклов и типовые значения для всех вложенных циклов.
4. Работа продолжается до тех пор, пока не будут протестированы все циклы.

Объединенные циклы

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

Неструктурированные циклы

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

Контрольные вопросы
1. Определите понятие тестирования.
2. Что такое тест? Поясните содержание процесса тестирования.
3. Что такое исчерпывающее тестирование?
4. Какие задачи решает тестирование?
5. Каких задач не решает тестирование?
6. Какие принципы тестирования вы знаете? В чем их отличие друг от друга?
7. В чем состоит суть тестирования «черного ящика»?
8. В чем состоит суть тестирования «белого ящика»?
9. Каковы особенности тестирования «белого ящика»?
10. Какие недостатки имеет тестирование «белого ящика»?
11. Какие достоинства имеет тестирование «белого ящика»?
12. Дайте характеристику способа тестирования базового пути.
13. Какие особенности имеет потоковый граф?
14. Поясните понятие независимого пути.
15. Поясните понятие цикломатической сложности.
16. Что такое базовое множество?
17. Какие свойства имеет базовое множество?
18. Какие способы вычисления цикломатической сложности вы знаете?
19. Поясните шаги способа тестирования базового пути.
20. Поясните достоинства, недостатки и область применения способа тестирования базового пути.
21. Дайте общую характеристику способов тестирования условий.
22. Какие типы ошибок в условиях вы знаете?
23. Какие методики тестирования условий вы знаете?
24. Поясните суть способа тестирования ветвей и операторов отношений. Какие он имеет ограничения?
25. Что такое ограничение на результат?
26. Что такое ограничение условия?
27. Что такое ограничивающее множество? Чем удобно его применение?
28. Поясните шаги способа тестирования ветвей и операторов отношений.
29. Поясните достоинства, недостатки и область применения способа тестирования ветвей и операторов отношений.
30. Поясните суть способа тестирования потоков данных.
31. Что такое множество определений данных?
32. Что такое множество использований данных?
33. Что такое цепочка определения-использования?
34. Поясните шаги способа тестирования потоков данных.
35. Поясните достоинства, недостатки и область применения способа тестирования потоков данных.
36. Поясните особенности тестирования циклов.
37. Какие методики тестирования простых циклов вы знаете?
38. Каковы шаги тестирования вложенных циклов?

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

Особенности тестирования «черного ящика»

Тестирование «черного ящика» (функциональное тестирование) позволяет получить комбинации входных данных, обеспечивающих полную проверку всех функциональных требований к программе [14]. Программное изделие здесь рассматривается как «черный ящик», чье поведение можно определить только исследованием его входов и соответствующих выходов. При таком подходе желательно иметь:
набор, образуемый такими входными данными, которые приводят к аномалиям поведения программы (назовем его IT);
набор, образуемый такими выходными данными, которые демонстрируют дефекты программы (назовем его ОТ).
Как показано на рис. 7.1, любой способ тестирования «черного ящика» должен:
выявить такие входные данные, которые с высокой вероятностью принадлежат набору IT;
сформулировать такие ожидаемые результаты, которые с высокой вероятностью являются элементами набора ОТ.
Во многих случаях определение таких тестовых вариантов основывается на предыдущем опыте инженеров тестирования. Они используют свое знание и понимание области определения для идентификации тестовых вариантов, которые эффективно обнаруживают дефекты. Тем не менее систематический подход к выявлению тестовых данных, обсуждаемый в данной главе, может использоваться как полезное дополнение к эвристическому знанию.

Рис. 7.1. Тестирование «черного ящика»

Принцип «черного ящика» не альтернативен принципу «белого ящика». Скорее это дополняющий подход, который обнаруживает другой класс ошибок.
Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:
1) некорректных или отсутствующих функций;
2) ошибок интерфейса;
3) ошибок во внешних структурах данных или в доступе к внешней базе данных;
4) ошибок характеристик (необходимая емкость памяти и т. д.);
5) ошибок инициализации и завершения.
Подобные категории ошибок способами «белого ящика» не выявляются.
В отличие от тестирования «белого ящика», которое выполняется на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования. При тестировании «черного ящика» пренебрегают управляющей структурой программы. Здесь внимание концентрируется на информационной области определения программной системы.
Техника «черного ящика» ориентирована на решение следующих задач:
сокращение необходимого количества тестовых вариантов (из-за проверки не статических, а динамических аспектов системы);
выявление классов ошибок, а не отдельных ошибок.

Способ разбиения по эквивалентности

Разбиение по эквивалентности — самый популярный способ тестирования «черного ящика» [3], [14].
В этом способе входная область данных программы делится на классы эквивалентности. Для каждого класса эквивалентности разрабатывается один тестовый вариант.
Класс эквивалентности — набор данных с общими свойствами. Обрабатывая разные элементы класса, программа должна вести себя одинаково. Иначе говоря, при обработке любого набора из класса эквивалентности в программе задействуется один и тот же набор операторов (и связей между ними).
На рис. 7.2 каждый класс эквивалентности показан эллипсом. Здесь выделены входные классы эквивалентности допустимых и недопустимых исходных данных, а также классы результатов.
Классы эквивалентности могут быть определены по спецификации на программу.

Рис. 7.2. Разбиение по эквивалентности

Например, если спецификация задает в качестве допустимых входных величин 5-разрядные целые числа в диапазоне 15 000...70 000, то класс эквивалентности допустимых ИД (исходных данных) включает величины от 15 000 до 70 000, а два класса эквивалентности недопустимых ИД составляют:
числа меньшие, чем 15 000;
числа большие, чем 70 000.
Класс эквивалентности включает множество значений данных, допустимых или недопустимых по условиям ввода.
Условие ввода может задавать:
1) определенное значение;
2) диапазон значений;
3) множество конкретных величин;
4) булево условие.
Сформулируем правила формирования классов эквивалентности.
1. Если условие ввода задает диапазон п...т, то определяются один допустимый и два недопустимых класса эквивалентности:
V_Class={n.. .т} — допустимый класс эквивалентности;
Inv_С1аss1={x|для любого х: х < п} — первый недопустимый класс эквивалентности;
Inv_С1аss2={y|для любого у: у > т} — второй недопустимый класс эквивалентности.
2. Если условие ввода задает конкретное значение а, то определяется один допустимый и два недопустимых класса эквивалентности:
V_Class={a};
Inv_Class1 ={х|для любого х: х < а};
Inv_С1аss2={y|для любого у: у > а}.
3. Если условие ввода задает множество значений {а, b, с}, то определяются один допустимый и один недопустимый класс эквивалентности:
V_Class={a, b, с};
Inv_С1аss={x|для любого х: (х а)&(х b)&(х с)}.
4. Если условие ввода задает булево значение, например true, то определяются один допустимый и один недопустимый класс эквивалентности:
V_Class={true};
Inv_Class={false}.
После построения классов эквивалентности разрабатываются тестовые варианты. Тестовый вариант выбирается так, чтобы проверить сразу наибольшее количество свойств класса эквивалентности.

Способ анализа граничных значений

Как правило, большая часть ошибок происходит на границах области ввода, а не в центре. Анализ граничных значений заключается в получении тестовых вариантов, которые анализируют граничные значения [3], [14], [69]. Данный способ тестирования дополняет способ разбиения по эквивалентности.
Основные отличия анализа граничных значений от разбиения по эквивалентности:
1) тестовые варианты создаются для проверки только ребер классов эквивалентности;
2) при создании тестовых вариантов учитывают не только условия ввода, но и область вывода.
Сформулируем правила анализа граничных значений.
1. Если условие ввода задает диапазон п...т, то тестовые варианты должны быть построены:
для значений п и т;
для значений чуть левее п и чуть правее т на числовой оси.
Например, если задан входной диапазон -1,0...+1,0, то создаются тесты для значений - 1,0, +1,0, - 1,001, +1,001.
2. Если условие ввода задает дискретное множество значений, то создаются тестовые варианты:
для проверки минимального и максимального из значений;
для значений чуть меньше минимума и чуть больше максимума.
Так, если входной файл может содержать от 1 до 255 записей, то создаются тесты для О, 1, 255, 256 записей.
3. Правила 1 и 2 применяются к условиям области вывода.
Рассмотрим пример, когда в программе требуется выводить таблицу значений. Количество строк и столбцов в таблице меняется. Задается тестовый вариант для минимального вывода (по объему таблицы), а также тестовый вариант для максимального вывода (по объему таблицы).
4. Если внутренние структуры данных программы имеют предписанные границы, то разрабатываются тестовые варианты, проверяющие эти структуры на их границах.
5. Если входные или выходные данные программы являются упорядоченными множествами (например, последовательным файлом, линейным списком, таблицей), то надо тестировать обработку первого и последнего элементов этих множеств.
Большинство разработчиков используют этот способ интуитивно. При применении описанных правил тестирование границ будет более полным, в связи с чем возрастет вероятность обнаружения ошибок.
Рассмотрим применение способов разбиения по эквивалентности и анализа граничных значений на конкретном примере. Положим, что нужно протестировать программу бинарного поиска. Нам известна спецификация этой программы. Поиск выполняется в массиве элементов М, возвращается индекс I элемента массива, значение которого соответствует ключу поиска Key.
Предусловия:
1) массив должен быть упорядочен;
2) массив должен иметь не менее одного элемента;
3) нижняя граница массива (индекс) должна быть меньше или равна его верхней границе.
Постусловия:
1) если элемент найден, то флаг Result=True, значение I — номер элемента;
2) если элемент не найден, то флаг Result=False, значение I не определено.
Для формирования классов эквивалентности (и их ребер) надо произвести разбиение области ИД — построить дерево разбиений. Листья дерева разбиений дадут нам искомые классы эквивалентности. Определим стратегию разбиения. На первом уровне будем анализировать выполнимость предусловий, на втором уровне — выполнимость постусловий. На третьем уровне можно анализировать специальные требования, полученные из практики разработчика. В нашем примере мы знаем, что входной массив должен быть упорядочен. Обработка упорядоченных наборов из четного и нечетного количества элементов может выполняться по-разному. Кроме того, принято выделять специальный случай одноэлементного массива. Следовательно, на уровне специальных требований возможны следующие эквивалентные разбиения:
1) массив из одного элемента;
2) массив из четного количества элементов;
3) массив из нечетного количества элементов, большего единицы.
Наконец на последнем, 4-м уровне критерием разбиения может быть анализ ребер классов эквивалентности. Очевидно, возможны следующие варианты:
1) работа с первым элементом массива;
2) работа с последним элементом массива;
3) работа с промежуточным (ни с первым, ни с последним) элементом массива.
Структура дерева разбиений приведена на рис. 7.3.

Рис. 7.3. Дерево разбиений области исходных данных бинарного поиска

Это дерево имеет 11 листьев. Каждый лист задает отдельный тестовый вариант. Покажем тестовые варианты, основанные на проведенных разбиениях.
Тестовый вариант 1 (единичный массив, элемент найден) ТВ1:
ИД: М=15; Кеу=15.
ОЖ.РЕЗ.: Resutt=True; I=1.
Тестовый вариант 2 (четный массив, найден 1-й элемент) ТВ2:
ИД: М=15, 20, 25,30,35,40; Кеу=15.
ОЖ.РЕЗ.: Result=True; I=1.
Тестовый вариант 3 (четный массив, найден последний элемент) ТВЗ:
ИД: М=15, 20, 25, 30, 35, 40; Кеу=40.
ОЖ.РЕЗ:. Result=True; I=6.
Тестовый вариант 4 (четный массив, найден промежуточный элемент) ТВ4:
ИД: М=15,20,25,30,35,40; Кеу=25.
ОЖ.РЕЗ.: Result-True; I=3.
Тестовый вариант 5 (нечетный массив, найден 1-й элемент) ТВ5:
ИД: М=15, 20, 25, 30, 35,40, 45; Кеу=15.
ОЖ.РЕЗ.: Result=True; I=1.
Тестовый вариант 6 (нечетный массив, найден последний элемент) ТВ6:
ИД: М=15, 20, 25, 30,35, 40,45; Кеу=45.
ОЖ.РЕЗ.: Result=True; I=7.
Тестовый вариант 7 (нечетный массив, найден промежуточный элемент) ТВ7:
ИД: М=15, 20, 25, 30,35, 40, 45; Кеу=30.
ОЖ.РЕЗ.: Result=True; I=4.
Тестовый вариант 8 (четный массив, не найден элемент) ТВ8:
ИД: М=15, 20, 25, 30, 35,40; Кеу=23.
ОЖ.РЕЗ.: Result=False; I=?
Тестовый вариант 9 (нечетный массив, не найден элемент) ТВ9;
ИД: М=15, 20, 25, 30, 35, 40, 45; Кеу=24.
ОЖ.РЕЗ:. Result=False; I=?
Тестовый вариант 10 (единичный массив, не найден элемент) ТВ10:
ИД: М=15; Кеу=0.
ОЖ.РЕЗ.: Result=False; I=?
Тестовый вариант 11 (нарушены предусловия) ТВ11:
ИД: М=15, 10, 5, 25, 20, 40, 35; Кеу=35.
ОЖ.РЕЗ.: Аварийное донесение: Массив не упорядочен.

Способ диаграмм причин-следствий

Диаграммы причинно-следственных связей — способ проектирования тестовых вариантов, который обеспечивает формальную запись логических условий и соответствующих действий [3], [64]. Используется автоматный подход к решению задачи.
Шаги способа:
1) для каждого модуля перечисляются причины (условия ввода или классы эквивалентности условий ввода) и следствия (действия или условия вывода). Каждой причине и следствию присваивается свой идентификатор;
2) разрабатывается граф причинно-следственных связей;
3) граф преобразуется в таблицу решений;
4) столбцы таблицы решений преобразуются в тестовые варианты.
Изобразим базовые символы для записи графов причин и следствий (cause-effect graphs).
Сделаем предварительные замечания:
1) причины будем обозначать символами сi, а следствия — символами еi;
2) каждый узел графа может находиться в состоянии 0 или 1 (0 — состояние отсутствует, 1 — состояние присутствует).
Функция тождество (рис. 7.4) устанавливает, что если значение с1 есть 1, то и значение е1 есть 1; в противном случае значение е1 есть 0.

Рис. 7.4. Функция тождество

Функция не (рис. 7.5) устанавливает, что если значение с1 есть 1, то значение e1 есть 0; в противном случае значение е1 есть 1.

Рис. 7.5. Функция не

Функция или (рис. 7.6) устанавливает, что если с1 или с2 есть 1, то е1 есть 1, в противном случае e1 есть 0.

Рис. 7.6. Функция или

Функция и (рис. 7.7) устанавливает, что если и с1 и с2 есть 1, то е1 есть 1, в противном случае е1 есть 0.
Часто определенные комбинации причин невозможны из-за синтаксических или внешних ограничений. Используются перечисленные ниже обозначения ограничений.

Рис. 7.7. Функция и

Ограничение Е (исключает, Exclusive, рис. 7.8) устанавливает, что Е должно быть истинным, если хотя бы одна из причин — а или b — принимает значение 1 (а и b не могут принимать значение 1 одновременно).

Рис. 7.8. Ограничение Е (исключает, Exclusive)

Ограничение I (включает, Inclusive, рис. 7.9) устанавливает, что по крайней мере одна из величин, а, b, или с, всегда должна быть равной 1 (а, b и с не могут принимать значение 0 одновременно).

Рис. 7.9. Ограничение I (включает, Inclusive)

Ограничение О (одно и только одно, Only one, рис. 7.10) устанавливает, что одна и только одна из величин а или b должна быть равна 1.

Рис. 7.10. Ограничение О (одно и только одно, Only one)

Ограничение R (требует, Requires, рис. 7.11) устанавливает, что если а принимает значение 1, то и b должна принимать значение 1 (нельзя, чтобы а было равно 1, a b - 0).

Рис. 7.11. Ограничение R (требует, Requires)

Часто возникает необходимость в ограничениях для следствий.
Ограничение М (скрывает, Masks, рис. 7.12) устанавливает, что если следствие а имеет значение 1, то следствие b должно принять значение 0.

Рис. 7.12. Ограничение М (скрывает, Masks)

Для иллюстрации использования способа рассмотрим пример, когда программа выполняет расчет оплаты за электричество по среднему или переменному тарифу.
При расчете по среднему тарифу:
при месячном потреблении энергии меньшем, чем 100 кВт/ч, выставляется фиксированная сумма;
при потреблении энергии большем или равном 100 кВт/ч применяется процедура А планирования расчета.
При расчете по переменному тарифу:
при месячном потреблении энергии меньшем, чем 100 кВт/ч, применяется процедура А планирования расчета;
при потреблении энергии большем или равном 100 кВт/ч применяется процедура В планирования расчета.
Шаг 1. Причинами являются:
1) расчет по среднему тарифу;
2) расчет по переменному тарифу;
3) месячное потребление электроэнергии меньшее, чем 100 кВт/ч;
4) месячное потребление электроэнергии большее или равное 100 кВт/ч.
На основе различных комбинаций причин можно перечислить следующие следствия:
101 — минимальная месячная стоимость;
102 — процедура А планирования расчета;
103 — процедура В планирования расчета.
Шаг 2. Разработка графа причинно-следственных связей (рис. 7.13).
Узлы причин перечислим по вертикали у левого края рисунка, а узлы следствий — у правого края рисунка. Для следствия 102 возникает необходимость введения вторичных причин — 11 и 12, — их размещаем в центральной части рисунка.

Рис. 7.13. Граф причинно-следственных связей

Шаг 3. Генерация таблицы решений. При генерации причины рассматриваются как условия, а следствия — как действия.
Порядок генерации.
1. Выбирается некоторое следствие, которое должно быть в состоянии «1».
2. Находятся все комбинации причин (с учетом ограничений), которые устанавливают это следствие в состояние «1». Для этого из следствия прокладывается обратная трасса через граф.
3. Для каждой комбинации причин, приводящих следствие в состояние «1», строится один столбец.
4. Для каждой комбинации причин доопределяются состояния всех других следствий. Они помещаются в тот же столбец таблицы решений.
5. Действия 1-4 повторяются для всех следствий графа.
Таблица решений для нашего примера показана в табл. 7.1.
Шаг 4. Преобразование каждого столбца таблицы в тестовый вариант. В нашем примере таких вариантов четыре.
Тестовый вариант 1 (столбец 1) ТВ1:
ИД: расчет по среднему тарифу; месячное потребление электроэнергии 75 кВт/ч.
ОЖ.РЕЗ.: минимальная месячная стоимость.
Тестовый вариант 2 (столбец 2) ТВ2:
ИД: расчет по переменному тарифу; месячное потребление электроэнергии 90 кВт/ч.
ОЖ.РЕЗ.: процедура A планирования расчета.
Тестовый вариант 3 (столбец 3) ТВЗ:
ИД: расчет по среднему тарифу; месячное потребление электроэнергии 100 кВт/ч.
ОЖ.РЕЗ.: процедура А планирования расчета.
Тестовый вариант 4 (столбец 4) ТВ4:
ИД: расчет по переменному тарифу; месячное потребление электроэнергии 100 кВт/ч.
ОЖ.РЕЗ.: процедура В планирования расчета.

Таблица 7.1. Таблица решений для расчета оплаты за электричество
Номера столбцов — >
1
2
3
4
Условия
Причины
1
1
0
1
0

2
0
1
0
1

3
1
1
0
0

4
0
0
1
1

Вторичные причины
11
0
0
1
0

12
0
1
0
0
Действия
Следствия
101
1
0
0
0

102
0
1
1
0

103
0
0
0
1

1. Каковы особенности тестирования методом «черного ящика»?
2. Какие категории ошибок выявляет тестирование методом «черного ящика»?
3. Какие достоинства имеет тестирование методом «черного ящика»?
4. Поясните суть способа разбиения по эквивалентности.
5. Что такое класс эквивалентности?
6. Что может задавать условие ввода?
7. Какие правила формирования классов эквивалентности вы знаете?
8. Как выбирается тестовый вариант при тестировании по способу разбиения по эквивалентности?
9. Поясните суть способа анализа граничных значений.
10. Чем способ анализа граничных значений отличается от разбиения по эквивалентности?
11. Поясните правила анализа граничных значений.
12. Что такое дерево разбиений? Каковы его особенности?
13. В чем суть способа диаграмм причин-следствий?
14. Что такое причина?
15. Что такое следствие?
16. Дайте общую характеристику графа причинно-следственных связей.
17. Какие функции используются в графе причин и следствий?
18. Какие ограничения используются в графе причин и следствий?
19. Поясните шаги способа диаграмм причин-следствий.
20. Какую структуру имеет таблица решений в способе диаграмм причин-следствий?
21. Как таблица решений преобразуется в тестовые варианты?

ГЛАВА 8. Организация процесса тестирования программного обеспечения

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

Методика тестирования программных систем

Процесс тестирования объединяет различные способы тестирования в спланированную последовательность шагов, которые приводят к успешному построению программной системы (ПС) [3], [13], [64], [69]. Методика тестирования ПС может быть представлена в виде разворачивающейся спирали (рис. 8.1).
В начале осуществляется тестирование элементов (модулей), проверяющее результаты этапа кодирования ПС. На втором шаге выполняется тестирование интеграции, ориентированное на выявление ошибок этапа проектирования ПС. На третьем обороте спирали производится тестирование правильности, проверяющее корректность этапа анализа требований к ПС. На заключительном витке спирали проводится системное тестирование, выявляющее дефекты этапа системного анализа ПС.
Охарактеризуем каждый шаг процесса тестирования.
1. Тестирование элементов. Цель — индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

Рис. 8.1. Спираль процесса тестирования ПС

2. Тестирование интеграции. Цель — тестирование сборки модулей в программную систему. В основном применяют способы тестирования «черного ящика».
3. Тестирование правильности. Цель — проверить реализацию в программной системе всех функциональных и поведенческих требований, а также требования эффективности. Используются исключительно способы тестирования «черного ящика».
4. Системное тестирование. Цель — проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.
Организация процесса тестирования в виде эволюционной разворачивающейся спирали обеспечивает максимальную эффективность поиска ошибок. Однако возникает вопрос — когда заканчивать тестирование?
Ответ практика обычно основан на статистическом критерии: «Можно с 95%-ной уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы ЦП с программным изделием в течение 1000 часов составляет по меньшей мере 0,995».
Научный подход при ответе на этот вопрос состоит в применении математической модели отказов. Например, для логарифмической модели Пуассона формула расчета текущей интенсивности отказов имеет вид:
, (8.1)
где — текущая интенсивность программных отказов (количество отказов в единицу времени); — начальная интенсивность отказов (в начале тестирования); р — экспоненциальное уменьшение интенсивности отказов за счет обнаруживаемых и устраняемых ошибок; t —время тестирования.
С помощью уравнения (8.1) можно предсказать снижение ошибок в ходе тестирования, а также время, требующееся для достижения допустимо низкой интенсивности отказов.

Тестирование элементов

Объектом тестирования элементов является наименьшая единица проектирования ПС — модуль. Для обнаружения ошибок в рамках модуля тестируются его важнейшие управляющие пути. Относительная сложность тестов и ошибок определяется как результат ограничений области тестирования элементов. Принцип тестирования — «белый ящик», шаг может выполняться для набора модулей параллельно.
Тестированию подвергаются:
интерфейс модуля;
внутренние структуры данных;
независимые пути;
пути обработки ошибок;
граничные условия.
Интерфейс модуля тестируется для проверки правильности ввода-вывода тестовой информации. Если нет уверенности в правильном вводе-выводе данных, нет смысла проводить другие тесты.
Исследование внутренних структур данных гарантирует целостность сохраняемых данных.
Тестирование независимых путей гарантирует однократное выполнение всех операторов модуля. При тестировании путей выполнения обнаруживаются следующие категории ошибок: ошибочные вычисления, некорректные сравнения, неправильный поток управления [3].
Наиболее общими ошибками вычислений являются:
1) неправильный или непонятый приоритет арифметических операций;
2) смешанная форма операций;
3) некорректная инициализация;
4) несогласованность в представлении точности;
5) некорректное символическое представление выражений.
Источниками ошибок сравнения и неправильных потоков управления являются:
1) сравнение различных типов данных;
2) некорректные логические операции и приоритетность;
3) ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной;
4) некорректное сравнение переменных;
5) неправильное прекращение цикла;
6) отказ в выходе при отклонении итерации;
7) неправильное изменение переменных цикла.
Обычно при проектировании модуля предвидят некоторые ошибочные условия. Для защиты от ошибочных условий в модуль вводят пути обработки ошибок. Такие пути тоже должны тестироваться. Тестирование путей обработки ошибок можно ориентировать на следующие ситуации:
1) донесение об ошибке невразумительно;
2) текст донесения не соответствует, обнаруженной ошибке;
3) вмешательство системных средств регистрации аварии произошло до обработки ошибки в модуле;
4) обработка исключительного условия некорректна;
5) описание ошибки не позволяет определить ее причину.
И, наконец, перейдем к граничному тестированию. Модули часто отказывают на «границах». Это означает, что ошибки часто происходят:
1) при обработке n-го элемента n-элементного массива;
2) при выполнении m-й итерации цикла с т проходами;
3) при появлении минимального (максимального) значения.
Тестовые варианты, ориентированные на данные ситуации, имеют высокую вероятность обнаружения ошибок.
Тестирование элементов обычно рассматривается как дополнение к этапу кодирования. Оно начинается после разработки текста модуля. Так как модуль не является автономной системой, то для реализации тестирования требуются дополнительные средства, представленные на рис. 8.2.

Рис. 8.2. Программная среда для тестирования модуля

Дополнительными средствами являются драйвер тестирования и заглушки. Драйвер — управляющая программа, которая принимает исходные данные (InData) и ожидаемые результаты (ExpRes) тестовых вариантов, запускает в работу тестируемый модуль, получает из модуля реальные результаты (OutData) и формирует донесения о тестировании. Алгоритм работы тестового драйвера приведен на рис. 8.3.

Рис. 8.3. Алгоритм работы драйвера тестирования

Заглушки замещают модули, которые вызываются тестируемым модулем. Заглушка, или «фиктивная подпрограмма», реализует интерфейс подчиненного модуля, может выполнять минимальную обработку данных, имитирует прием и возврат данных.
Создание драйвера и заглушек подразумевает дополнительные затраты, так как они не поставляются с конечным программным продуктом.
Если эти средства просты, то дополнительные затраты невелики. Увы, многие модули не могут быть адекватно протестированы с помощью простых дополнительных средств. В этих случаях полное тестирование может быть отложено до шага тестирования интеграции (где драйверы или заглушки также используются).
Тестирование элемента просто осуществить, если модуль имеет высокую связность. При реализации модулем только одной функции количество тестовых вариантов уменьшается, а ошибки легко предсказываются и обнаруживаются.

Тестирование интеграции

Тестирование интеграции поддерживает сборку цельной программной системы.
Цель сборки и тестирования интеграции: взять модули, протестированные как элементы, и построить программную структуру, требуемую проектом [3].
Тесты проводятся для обнаружения ошибок интерфейса. Перечислим некоторые категории ошибок интерфейса:
потеря данных при прохождении через интерфейс;
отсутствие в модуле необходимой ссылки;
неблагоприятное влияние одного модуля на другой;
подфункции при объединении не образуют требуемую главную функцию;
отдельные (допустимые) неточности при интеграции выходят за допустимый уровень;
проблемы при работе с глобальными структурами данных.
Существует два варианта тестирования, поддерживающих процесс интеграции: нисходящее тестирование и восходящее тестирование. Рассмотрим каждый из них.

Нисходящее тестирование интеграции

В данном подходе модули объединяются движением сверху вниз по управляющей иерархии, начиная от главного управляющего модуля. Подчиненные модули добавляются в структуру или в результате поиска в глубину, или в результате поиска в ширину.
Рассмотрим пример (рис. 8.4). Интеграция поиском в глубину будет подключать все модули, находящиеся на главном управляющем пути структуры (по вертикали). Выбор главного управляющего пути отчасти произволен и зависит от характеристик, определяемых приложением. Например, при выборе левого пути прежде всего будут подключены модули Ml, М2, М5. Следующим подключается модуль М8 или Мб (если это необходимо для правильного функционирования М2). Затем строится центральный или правый управляющий путь.
При интеграции поиском в ширину структура последовательно проходится по уровням-горизонталям. На каждом уровне подключаются модули, непосредственно подчиненные управляющему модулю — начальнику. В этом случае прежде всего подключаются модули М2, М3, М4. На следующем уровне — модули М5, Мб и т. д.

Рис. 8.4. Нисходящая интеграция системы

Опишем возможные шаги процесса нисходящей интеграции.
1. Главный управляющий модуль (находится на вершине иерархии) используется как тестовый драйвер. Все непосредственно подчиненные ему модули временно замещаются заглушками.
2. Одна из заглушек заменяется реальным модулем. Модуль выбирается поиском в ширину или в глубину.
3. После подключения каждого модуля (и установки на нем заглушек) проводится набор тестов, проверяющих полученную структуру.
4. Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера (поиском в ширину или в глубину).
5. Выполняется возврат на шаг 2 (до тех пор, пока не будет построена целая структура).
Достоинство нисходящей интеграции: ошибки в главной, управляющей части системы выявляются в первую очередь.
Недостаток: трудности в ситуациях, когда для полного тестирования на верхних уровнях нужны результаты обработки с нижних уровней иерархии.
Существуют 3 возможности борьбы с этим недостатком:
1) откладывать некоторые тесты до замещения заглушек модулями;
2) разрабатывать заглушки, частично выполняющие функции модулей;
3) подключать модули движением снизу вверх.
Первая возможность вызывает сложности в оценке результатов тестирования.
Для реализации второй возможности выбирается одна из следующих категорий заглушек:
заглушка А — отображает трассируемое сообщение;
заглушка В — отображает проходящий параметр;
заглушка С — возвращает величину из таблицы;
заглушка D — выполняет табличный поиск по ключу (входному параметру) и возвращает связанный с ним выходной параметр.

Рис. 8.5. Категории заглушек

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

Восходящее тестирование интеграции

При восходящем тестировании интеграции сборка и тестирование системы начинаются с модулей-атомов, располагаемых на нижних уровнях иерархии. Модули подключаются движением снизу вверх. Подчиненные модули всегда доступны, и нет необходимости в заглушках.
Рассмотрим шаги методики восходящей интеграции.
1. Модули нижнего уровня объединяются в кластеры (группы, блоки), выполняющие определенную программную подфункцию.
2. Для координации вводов-выводов тестового варианта пишется драйвер, управляющий тестированием кластеров.
3. Тестируется кластер.
4. Драйверы удаляются, а кластеры объединяются в структуру движением вверх. Пример восходящей интеграции системы приведен на рис. 8.6.
Модули объединяются в кластеры 1,2,3. Каждый кластер тестируется драйвером. Модули в кластерах 1 и 2 подчинены модулю Ма, поэтому драйверы D1 и D2 удаляются и кластеры подключают прямо к Ма. Аналогично драйвер D3 удаляется перед подключением кластера 3 к модулю Mb. В последнюю очередь к модулю Мс подключаются модули Ма и Mb.
Рассмотрим различные типы драйверов:
драйвер А — вызывает подчиненный модуль;
драйвер В — посылает элемент данных (параметр) из внутренней таблицы;
драйвер С —отображает параметр из подчиненного модуля;
драйвер D — является комбинацией драйверов В и С.
Очевидно, что драйвер А наиболее прост, а драйвер D наиболее сложен в реализации. Различные типы драйверов представлены на рис. 8.7.

Рис. 8.7. Различные типы драйверов

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

Сравнение нисходящего и восходящего тестирования интеграции

Нисходящее тестирование:
1) основной недостаток— необходимость заглушек и связанные с ними трудности тестирования;
2) основное достоинство — возможность раннего тестирования главных управляющих функций.
Восходящее тестирование:
1) основной недостаток — система не существует как объект до тех пор, пока не будет добавлен последний модуль;
2) основное достоинство — упрощается разработка тестовых вариантов, отсутствуют заглушки.
Возможен комбинированный подход. В нем для верхних уровней иерархии применяют нисходящую стратегию, а для нижних уровней — восходящую стратегию тестирования [3], [13].
При проведении тестирования интеграции очень важно выявить критические модули. Признаки критического модуля:
1) реализует несколько требований к программной системе;
2) имеет высокий уровень управления (находится достаточно высоко в программной структуре);
3) имеет высокую сложность или склонность к ошибкам (как индикатор может использоваться цикломатическая сложность — ее верхний разумный предел составляет 10);
4) имеет определенные требования к производительности обработки.
Критические модули должны тестироваться как можно раньше. Кроме того, к ним должно применяться регрессионное тестирование (повторение уже выполненных тестов в полном или частичном объеме).

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

После окончания тестирования интеграции программная система собрана в единый корпус, интерфейсные ошибки обнаружены и откорректированы. Теперь начинается последний шаг программного тестирования — тестирование правильности. Цель — подтвердить, что функции, описанные в спецификации требований к ПС, соответствуют ожиданиям заказчика [64], [69].
Подтверждение правильности ПС выполняется с помощью тестов «черного ящика», демонстрирующих соответствие требованиям. При обнаружении отклонений от спецификации требований создается список недостатков. Как правило, отклонения и ошибки, выявленные при подтверждении правильности, требуют изменения сроков разработки продукта.
Важным элементом подтверждения правильности является проверка конфигурации ПС. Конфигурацией ПС называют совокупность всех элементов информации, вырабатываемых в процессе конструирования ПС. Минимальная конфигурация ПС включает следующие базовые элементы:
1) системную спецификация;
2) план программного проекта;
3) спецификацию требований к ПС; работающий или бумажный макет;
4) предварительное руководство пользователя;
5) спецификация проектирования;
6) листинги исходных текстов программ;
7) план и методику тестирования; тестовые варианты и полученные результаты;
8) руководства по работе и инсталляции;
9) ехе-код выполняемой программы;
10) описание базы данных;
11) руководство пользователя по настройке;
12) документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;
13) стандарты и методики конструирования ПС.
Проверка конфигурации гарантирует, что все элементы конфигурации ПС правильно разработаны, учтены и достаточно детализированы для поддержки этапа сопровождения в жизненном цикле ПС.
Разработчик не может предугадать, как заказчик будет реально использовать ПС. Для обнаружения ошибок, которые способен найти только конечный пользователь, используют процесс, включающий альфа- и бета-тестирование.
Альфа-тестирование проводится заказчиком в организации разработчика. Разработчик фиксирует все выявленные заказчиком ошибки и проблемы использования.
Бета-тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование — это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику. Бета-тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПС и тем самым подготавливает продукт полностью на базе заказчика.

Системное тестирование

Системное тестирование подразумевает выход за рамки области действия программного проекта и проводится не только программным разработчиком. Классическая проблема системного тестирования — указание причины. Она возникает, когда разработчик одного системного элемента обвиняет разработчика другого элемента в причине возникновения дефекта. Для защиты от подобного обвинения разработчик программного элемента должен:
1) предусмотреть средства обработки ошибки, которые тестируют все вводы информации от других элементов системы;
2) провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса ПС;
3) записать результаты тестов, чтобы использовать их как доказательство невиновности в случае «указания причины»;
4) принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование ПС.
В конечном счете системные тесты должны проверять, что все системные элементы правильно объединены и выполняют назначенные функции. Рассмотрим основные типы системных тестов [13], [52].

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

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

Тестирование безопасности

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

Стрессовое тестирование

На предыдущих шагах тестирования способы «белого» и «черного ящиков» обеспечивали полную оценку нормальных программных функций и качества функционирования. Стрессовые тесты проектируются для навязывания программам ненормальных ситуаций. В сущности, проектировщик стрессового теста спрашивает, как сильно можно расшатать систему, прежде чем она откажет?
Стрессовое тестирование производится при ненормальных запросах на ресурсы системы (по количеству, частоте, размеру-объему).
Примеры:
генерируется 10 прерываний в секунду (при средней частоте 1,2 прерывания в секунду);
скорость ввода данных увеличивается прямо пропорционально их важности (чтобы определить реакцию входных функций);
формируются варианты, требующие максимума памяти и других ресурсов;
генерируются варианты, вызывающие переполнение виртуальной памяти;
проектируются варианты, вызывающие чрезмерный поиск данных на диске.
По существу, испытатель пытается разрушить систему. Разновидность стрессового тестирования называется тестированием чувствительности. В некоторых ситуациях (обычно в математических алгоритмах) очень малый диапазон данных, содержащийся в границах правильных данных системы, может вызвать ошибочную обработку или резкое понижение производительности. Тестирование чувствительности обнаруживает комбинации данных, которые могут вызвать нестабильность или неправильность обработки.

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

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

Искусство отладки

Отладка — это локализация и устранение ошибок. Отладка является следствием успешного тестирования. Это значит, что если тестовый вариант обнаруживает ошибку, то процесс отладки уничтожает ее.
Итак, процессу отладки предшествует выполнение тестового варианта. Его результаты оцениваются, регистрируется несоответствие между ожидаемым и реальным результатами. Несоответствие является симптомом скрытой причины. Процесс отладки пытается сопоставить симптом с причиной, вследствие чего приводит к исправлению ошибки. Возможны два исхода процесса отладки:
1) причина найдена, исправлена, уничтожена;
2) причина не найдена.
Во втором случае отладчик может предполагать причину. Для проверки этой причины он просит разработать дополнительный тестовый вариант, который поможет проверить предположение. Таким образом, запускается итерационный процесс коррекции ошибки.
Возможные разные способы проявления ошибок:
1) программа завершается нормально, но выдает неверные результаты;
2) программа зависает;
3) программа завершается по прерыванию;
4) программа завершается, выдает ожидаемые результаты, но хранимые данные испорчены (это самый неприятный вариант).
Характер проявления ошибок также может меняться. Симптом ошибки может быть:
постоянным;
мерцающим;
пороговым (проявляется при превышении некоторого порога в обработке — 200 самолетов на экране отслеживаются, а 201-й — нет);
отложенным (проявляется только после исправления маскирующих ошибок).
В ходе отладки мы встречаем ошибки в широком диапазоне: от мелких неприятностей до катастроф. Следствием увеличения ошибок является усиление давления на отладчика — «найди ошибки быстрее!!!». Часто из-за этого давления разработчик устраняет одну ошибку и вносит две новые ошибки.
Английский термин debugging (отладка) дословно переводится как «ловля блох», который отражает специфику процесса — погоню за объектами отладки, «блохами». Рассмотрим, как может быть организован этот процесс «ловли блох» [3], [64].
Различают две группы методов отладки:
аналитические;
экспериментальные.
Аналитические методы базируются на анализе выходных данных для тестовых прогонов. Экспериментальные методы базируются на использовании вспомогательных средств отладки (отладочные печати, трассировки), позволяющих уточнить характер поведения программы при тех или иных исходных данных.
Общая стратегия отладки — обратное прохождение от замеченного симптома ошибки к исходной аномалии (месту в программе, где ошибка совершена).
В простейшем случае место проявления симптома и ошибочный фрагмент совпадают. Но чаще всего они далеко отстоят друг от друга.
Цель отладки — найти оператор программы, при исполнении которого правильные аргументы приводят к неправильным результатам. Если место проявления симптома ошибки не является искомой аномалией, то один из аргументов оператора должен быть неверным. Поэтому надо перейти к исследованию предыдущего оператора, выработавшего этот неверный аргумент. В итоге пошаговое обратное прослеживание приводит к искомому ошибочному месту.
В разных методах прослеживание организуется по-разному. В аналитических методах — на основе логических заключений о поведении программы. Цель — шаг за шагом уменьшать область программы, подозреваемую в наличии ошибки. Здесь определяется корреляция между значениями выходных данных и особенностями поведения.
Основное преимущество аналитических методов отладки состоит в том, что исходная программа остается без изменений.
В экспериментальных методах для прослеживания выполняется:
1. Выдача значений переменных в указанных точках.
2. Трассировка переменных (выдача их значений при каждом изменении).
3. Трассировка потоков управления (имен вызываемых процедур, меток, на которые передается управление, номеров операторов перехода).
Преимущество экспериментальных методов отладки состоит в том, что основная рутинная работа по анализу процесса вычислений перекладывается на компьютер. Многие трансляторы имеют встроенные средства отладки для получения информации о ходе выполнения программы.
Недостаток экспериментальных методов отладки — в программу вносятся изменения, при исключении которых могут появиться ошибки. Впрочем, некоторые системы программирования создают специальный отладочный экземпляр программы, а в основной экземпляр не вмешиваются.

Контрольные вопросы

1. Поясните суть методики тестирования программной системы.
2. Когда и зачем выполняется тестирование элементов? Какой этап конструирования оно проверяет?
3. Когда и зачем выполняется тестирование интеграции? Какой этап конструирования оно проверяет?
4. Когда и зачем выполняется тестирование правильности? Какой этап конструирования оно проверяет?
5. Когда и зачем выполняется системное тестирование? Какой этап конструирования оно проверяет?
6. Поясните суть тестирования элементов.
7. Перечислите наиболее общие ошибки вычислений.
8. Перечислите источники ошибок сравнения и неправильных потоков управления.
9. На какие ситуации ориентировано тестирование путей обработки ошибок?
10. Что такое драйвер тестирования?
11. Что такое заглушка?
12. Поясните порядок работы драйвера тестирования.
13. В чем цель тестирования интеграции?
14. Какие категории ошибок интерфейса вы знаете?
15. В чем суть нисходящего тестирования интеграции?
16. Поясните шаги процесса нисходящей интеграции.
17. Поясните достоинства и недостатки нисходящей интеграции.
18. Какие категории заглушек вы знаете?
19. В чем суть восходящего тестирования интеграции?
20. Поясните шаги процесса восходящей интеграции.
21. Поясните достоинства и недостатки восходящей интеграции.
22. Какие категории драйверов вы знаете?
23. Какова комбинированная стратегия интеграции?
24. Каковы признаки критического модуля?
25. Что такое регрессионное тестирование?
26. В чем суть тестирования правильности?
27. Какие элементы включает минимальная конфигурация программной системы?
28. Что такое альфа-тестирование?
29. Что такое бета-тестирование?
30. В чем суть системного тестирования?
31. Как защищаться от проблемы «указание причины»?
32. В чем суть тестирования восстановления?
33. В чем суть тестирования безопасности?
34. В чем суть стрессового тестирования?
35. В чем суть тестирования производительности?
36. Что такое отладка?
37. Какие способы проявления ошибок вы знаете?
38. Какие симптомы ошибки вы знаете?
39. В чем суть аналитических методов отладки?
40. Поясните достоинства и недостатки аналитических методов отладки.
41. В чем суть экспериментальных методов отладки?
42. Поясните достоинства и недостатки экспериментальных методов отладки.

Девятая глава вводит в круг вопросов объектно-ориентированного представления программных систем. В этой главе рассматриваются: абстрагирование понятий проблемной области, приводящее к формированию классов; инкапсуляция объектов, обеспечивающая скрытность их характеристик; модульность как средство упаковки набора классов; особенности построения иерархической структуры объектно-ориентированных систем. Последовательно обсуждаются объекты и классы как основные строительные элементы объектно-ориентированного ПО. Значительное внимание уделяется описанию отношений между объектами и классами.

Принципы объектно-ориентированного представления программных систем

Рассмотрение любой сложной системы требует применения техники декомпозиции — разбиения на составляющие элементы. Известны две схемы декомпозиции: алгоритмическая декомпозиция и объектно-ориентированная декомпозиция.
В основе алгоритмической декомпозиции лежит разбиение по действиям — алгоритмам. Эта схема представления применяется в обычных ПС.
Объектно-ориентированная декомпозиция обеспечивает разбиение по автономным лицам — объектам реального (или виртуального) мира. Эти лица (объекты) — более «крупные» элементы, каждый из них несет в себе и описания действий, и описания данных.
Объектно-ориентированное представление ПС основывается на принципах абстрагирования, инкапсуляции, модульности и иерархической организации. Каждый из этих принципов не нов, но их совместное применение рассчитано на проведение объектно-ориентированной декомпозиции. Это определяет модификацию их содержания и механизмов взаимодействия друг с другом. Обсудим данные принципы [22], [32], [41], [59], [64], [66].

Абстрагирование

Аппарат абстракции — удобный инструмент для борьбы со сложностью реальных систем. Создавая понятие в интересах какой-либо задачи, мы отвлекаемся (абстрагируемся) от несущественных характеристик конкретных объектов, определяя только существенные характеристики. Например, в абстракции «часы» мы выделяем характеристику «показывать время», отвлекаясь от таких характеристик конкретных часов, как форма, цвет, материал, цена, изготовитель.
Итак, абстрагирование сводится к формированию абстракций. Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные понятийные границы.
Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта.от его реализации. Абстракцию удобно строить путем выделения обязанностей объекта.
Пример: физический объект — датчик скорости, устанавливаемый на борту летательного аппарата (ЛА). Создадим его абстракцию. Для этого сформулируем обязанности датчика:
знать проекцию скорости ЛА в заданном направлении;
показывать текущую скорость;
подвергаться настройке.
Теперь опишем абстракцию датчика. Описание сформулируем как спецификацию класса на языке Ada 95 [4]:
Package Класс_ДатчикСкорости is
subtype Скорость is Float range ...
subtype Направление is Natural range ...
type ДатчикСкорости is tagged private;
function НовыйДатчик(нокер: Направление)
return ДатчикСкорости:
function ТекущаяСкорость (the: ДатчикСкорости)
return Скорость;
procedure Настраивать(the: in out ДатчикСкорости;
ДействитСкорость: Скорость);
private — закрытая часть спецификации
-- полное описание типа ДатчикСкорости
end Класс_ДатчикСкорости;
Здесь Скорость и Направление — вспомогательные подтипы, обеспечивающие задание операций абстракции (НовыйДатчик, ТекущаяСкорость, Настраивать). Приведенная абстракция — это только спецификация класса датчика, настоящее его представление скрыто в приватной части спецификации и теле класса. Класс ДэтчикСкорости — еще не объект. Собственно датчики — это его экземпляры, и их нужно создать, прежде чем с ними можно будет работать. Например, можно написать так:
ДатчикПродольнойСкорости : ДатчикСкорости;
ДатчикПоперечнойСкорости : ДатчикСкорости;
ДатчикНормальнойСкорости : ДатчикСкорости;

Инкапсуляция

Инкапсуляция и абстракция — взаимодополняющие понятия: абстракция выделяет внешнее поведение объекта, а инкапсуляция содержит и скрывает реализацию, которая обеспечивает это поведение. Инкапсуляция достигается с помощью информационной закрытости. Обычно скрываются структура объектов и реализация их методов.
Инкапсуляция является процессом разделения элементов абстракции на секции с различной видимостью. Инкапсуляция служит для отделения интерфейса абстракции от ее реализации.
Пример: физический объект регулятор скорости.
Обязанности регулятора:
включаться;
выключаться;
увеличивать скорость;
уменьшать скорость;
отображать свое состояние.
Спецификация класса Регулятор скорости примет вид
with Кяасс_ДатчикСкорости. Класс_Порт;
use Класс_ДатчикСкорости. Класс_Порт;
Package Класс_РегуляторСкорости is
type Режим is (Увеличение, Уменьшение);
subtype Размещение is Natural range ...
type РегуляторСкорости is tagged private;
function НовРегуляторСкорости (номер: Размещение;
напр: Направление; порт; Порт)
return РегуляторСкорости;
procedure Включить(the: in out РегуляторСкорости);
procedure Выключить(1пе: in out РегуляторСкорости);
procedure УвеличитьСкорость(1г1е: in out
РегуляторСкорости);
procedure УменьшитьСкорость(the: in out
РегуляторСкорости);
Function OnpocCocтояния(the: РегуляторСкорости)
eturn Режим;
private
type укз_наПорт is access all Порт;
type РегуляторСкорости is tagged record
Номер; Размещение;
Состояние: Режим;
Управление: укз_наПорт;
end record;
end Класс_РегуляторСкорости;
Здесь вспомогательный тип Режим используется для задания основного типа класса, класс ДатчикСкорости обеспечивает класс регулятора описанием вспомогательного типа Направление, класс Порт фиксирует абстракцию порта, через который посылаются сообщения для регулятора. Три свойства: Номер, Состояние, Управление — формулируют инкапсулируемое представление основного типа класса РегуляторСкорости. При попытке клиента получить доступ к этим свойствам фиксируется семантическая ошибка.
Полное инкапсулированное представление класса РегуляторСкорости включает описание реализаций его методов — оно содержится в теле класса. Описание тела для краткости здесь опущено.

Модульность

В языках C++, Object Pascal, Ada 95 абстракции классов и объектов формируют логическую структуру системы. При производстве физической структуры эти абстракции помещаются в модули. В больших системах, где классов сотни, модули помогают управлять сложностью. Модули служат физическими контейнерами, в которых объявляются классы и объекты логической разработки.
Модульность определяет способность системы подвергаться декомпозиции на ряд сильно связанных и слабо сцепленных модулей.
Общая цель декомпозиции на модули: уменьшение сроков разработки и стоимости ПС за счет выделения модулей, которые проектируются и изменяются независимо. Каждая модульная структура должна быть достаточно простой, чтобы быть полностью понятой. Изменение реализации модулей должно проводиться без знания реализации других модулей и без влияния на их поведение.
Определение классов и объектов выполняется в ходе логической разработки, а определение модулей — в ходе физической разработки системы. Эти действия сильно взаимосвязаны, осуществляются итеративно.
В Ada 95 мощным средством обеспечения модульности является пакет.
Пример: пусть имеется несколько программ управления полетом летательного аппарата (ЛА) — программа угловой стабилизации ЛА и программа управления движением центра масс ЛА. Нужно создать модуль, чье назначение — собрать все эти программы. Возможны два способа.
1. Присоединение с помощью указателей контекста:
with Класс_УгловСтабил, Класс_ДвиженЦентраМасс;
use Класс_УгловСтабил, Класс_ДвиженЦентраМасс;
Package Класс_УпрПолетом is
…
2. Встраивание программ управления непосредственно в объединенный модуль:
Package Класс_УпрПолетом is
type УгловСтабил is tagged private;
type ДвиженЦентраМасс is tagged private;
-------------------------

Иерархическая организация

Мы рассмотрели три механизма для борьбы со сложностью:
абстракцию (она упрощает представление физического объекта);
инкапсуляцию (закрывает детали внутреннего представления абстракций);
модульность (дает путь группировки логически связанных абстракций).
Прекрасным дополнением к этим механизмам является иерархическая организация — формирование из абстракций иерархической структуры. Определением иерархии в проекте упрощаются понимание проблем заказчика и их реализация — сложная система становится обозримой человеком.
Иерархическая организация задает размещение абстракций на различных уровнях описания системы.
Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются:
структура из классов («is a»-иерархия);
структура из объектов («part of»-иерархия).
Чаще всего «is а»-иерархическая структура строится с помощью наследования. Наследование определяет отношение между классами, где класс разделяет структуру или поведение, определенные в одном другом (единичное наследование) или в нескольких других (множественное наследование) классах.
Пример: положим, что программа управления полетом 2-й ступени ракеты-носителя в основном похожа на программу управления полетом 1-й ступени, но все же отличается от нее. Определим класс управления полетом 2-й ступени, который инкапсулирует ее специализированное поведение:
with Класс_УпрПолетом1; use Класс_УпрПолетом1;
Package Класс_УпрПолетом2 is
type Траектория is (Гибкая. Свободная);
type УпрПолетом2 is new УпрПолетом1 with private;
procedure Установиться: in out УпрПолетом2:
тип: Траектория; ориентация : Углы;
параметры: Координаты_Скорость; команды: График);
procedure УсловияОтделенияЗступени (the: УпрПолетом2;
критерий:КритерийОтделения);
function ПрогнозОтделенияЗступени (the: УпрПолетом2)
return БортовоеВремя;
function ИсполнениеКоманд(the: УпрПолетом2)
return Boolean;
private
type УпрПолетом2 is new УпрПолетом1
with record
типТраектории: Траектория; доОтделения: БортовоеВремя;
выполнениеКоманд: Boolean;
end record;
end Класс_УпрПолетом2;
Видим, что класс УпрПолетом2 — это «is а»-разновидность класса УпрПолетом1, который называется родительским классом или суперклассом.
В класс УпрПолетом2 добавлены:
авспомогательный тип Траектория;
три новых свойства (типТраектории, доОтделения, выполнениеКоманд);
три новых метода (УсловияОтделенияЗступени, ПрогнозОтделенияЗступени, ИсполнениеКоманд).
Кроме того, в классе УпрПолетом2 переопределен метод суперкласса Установить. Подразумевается, что в наследство классу УпрПолетом2 достался набор методов и свойств класса УпрПолетом1. В частности, тип УпрПолетом2 включает поля типа УпрПолетом1, обеспечивающие прием данных о координатах и скорости ракеты-носителя, ее угловой ориентации и графике выдаваемых команд, а также о критерии отделения следующей ступени.
Классы УпрПолетом1и УпрПолетом2 образуют наследственную иерархическую организацию. В ней общая часть структуры и поведения сосредоточены в верхнем, наиболее общем классе (суперклассе). Суперкласс соответствует общей абстракции, а подкласс — специализированной абстракции, в которой элементы суперкласса дополняются, изменяются и даже скрываются. Поэтому наследование часто называют отношением обобщение-специализация.
Иерархию наследования можно продолжить. Например, используя класс УпрПолетом2, можно объявить еще более специализированный подкласс — УпрПолетомКосмическогоАппарата.
Другая разновидность иерархической организации — «part of»-иерархическая структура — базируется на отношении агрегации. Агрегация не является понятием, уникальным для объектно-ориентированных систем. Например, любой язык программирования, разрешающий структуры типа «запись», поддерживает агрегацию. И все же агрегация особенно полезна в сочетании с наследованием:
1) агрегация обеспечивает физическую группировку логически связанной структуры;
2) наследование позволяет легко и многократно использовать эти общие группы в других абстракциях.
Приведем пример класса ИзмерительСУ (измеритель системы управления ЛА):
with Класс_НастройкаДатчиков. Класс_Датчик;
use Класс_НастройкаДатчиков, Класс_Датчик;
Package Класс_ИзмерительСУ is
type ИзмерительСУ is tagged private;
-- описание методов
private
type укз_наДатчик is access all Датчик'Class;
type ИзмерительСУ is record
датчики: array(1..30) of укз_наДатчик;
процедураНастройки: НастройкаДатчиков;
end record;
end Класс_ИзмерительСУ;
Очевидно, что объекты типа ИзмерительСУ являются агрегатами, состоящими из массива датчиков и процедуры настройки. Наша абстракция ИзмерительСУ позволяет использовать в системе управления различные датчики. Изменение датчика не меняет индивидуальности измерителя в целом. Ведь датчики вводятся в агрегат с помощью указателей, а не величин. Таким образом, объект типа ИзмерительСУ и объекты типа Датчик имеют относительную независимость. Например, время жизни измерителя и датчиков независимо друг от друга. Напротив, объект типа НастройкаДатчиков физически включается в объект типа ИзмерительСУ и независимо существовать не может. Отсюда вывод — разрушая объект типа ИзмерительСУ, мы, в свою очередь, разрушаем экземпляр НастройкиДатчиков.
Интересно сравнить элементы иерархий наследования и агрегации с точки зрения уровня сложности. При наследовании нижний элемент иерархии (подкласс) имеет больший уровень сложности (большие возможности), при агрегации — наоборот (агрегат ИзмерительСУ обладает большими возможностями, чем его элементы — датчики и процедура настройки).

Объекты

Рассмотрим более пристально объекты — конкретные сущности, которые существуют во времени и пространстве.

Общая характеристика объектов

Объект — это конкретное представление абстракции. Объект обладает индивидуальностью, состоянием и поведением. Структура и поведение подобных объектов определены в их общем классе. Термины «экземпляр класса» и «объект» взаимозаменяемы. На рис. 9.1 приведен пример объекта по имени Стул, имеющего определенный набор свойств и операций.
Индивидуальность — это характеристика объекта, которая отличает его от всех других объектов.
Состояние объекта характеризуется перечнем всех свойств объекта и текущими значениями каждого из этих свойств (рис. 9.1).

Рис. 9.1. Представление объекта с именем Стул

Объекты не существуют изолированно друг от друга. Они подвергаются воздействию или сами воздействуют на другие объекты.
Поведение характеризует то, как объект воздействует на другие объекты (или подвергается воздействию) в терминах изменений его состояния и передачи сообщений. Поведение объекта является функцией как его состояния, так и выполняемых им операций (Купить, Продать, Взвесить, Переместить, Покрасить). Говорят, что состояние объекта представляет суммарный результат его поведения.
Операция обозначает обслуживание, которое объект предлагает своим клиентам. Возможны пять видов операций клиента над объектом:
1) модификатор (изменяет состояние объекта);
2) селектор (дает доступ к состоянию, но не изменяет его);
3) итератор (доступ к содержанию объекта по частям, в строго определенном порядке);
4) конструктор (создает объект и инициализирует его состояние);
5) деструктор (разрушает объект и освобождает занимаемую им память). Примеры операций приведены в табл. 9.1.

Таблица 9.1. Разновидности операций
Вид операции
Пример операции
Модификатор Селектор Итератор Конструктор Деструктор
Пополнеть (кг)
КакойВес ( ) : integer
ПоказатьАссортиментТоваров ( ) : string
СоздатьРобот (параметры)
УничтожитьРобот ( )

В чистых объектно-ориентированных языках программирования операции могут объявляться только как методы — элементы классов, экземплярами которых являются объекты. Гибридные языки (C++, Ada 95) позволяют писать операции как свободные подпрограммы (вне классов). Соответствующие примеры показаны на рис. 9.2.

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

Рис. 9.3. Пространство поведения объекта

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

Рис.9.4. Активные и пассивные объекты

Активный объект имеет собственный канал (поток) управления, пассивный — нет. Активный объект автономен, он может проявлять свое поведение без воздействия со стороны других объектов. Пассивный объект, наоборот, может изменять свое состояние только под воздействием других объектов.

Виды отношений между объектами

В поле зрения разработчика ПО находятся не объекты-одиночки, а взаимодействующие объекты, ведь именно взаимодействие объектов реализует поведение системы. У Г. Буча есть отличная цитата из Галла: «Самолет — это набор элементов, каждый из которых по своей природе стремится упасть на землю, но ценой совместных непрерывных усилий преодолевает эту тенденцию» [22]. Отношения между парой объектов основываются на взаимной информации о разрешенных операциях и ожидаемом поведении. Особо интересны два вида отношений между объектами: связи и агрегация.

Связи

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

Рис. 9.5. Связи между объектами

Как участник связи объект может играть одну из трех ролей:
актер — объект, который может воздействовать на другие объекты, но никогда не подвержен воздействию других объектов;
сервер — объект, который никогда не воздействует на другие объекты, он только используется другими объектами;
агент — объект, который может как воздействовать на другие объекты, так и использоваться ими. Агент создается для выполнения работы от имени актера или другого агента.
На рис. 9.5 Том — это актер, Мери, Колонки — серверы, Музыкальный центр — агент.
Приведем пример. Допустим, что нужно обеспечить следующий график разворота первой ступени ракеты по углу тангажа, представленный на рис. 9.6.
Запишем абстракцию графика разворота:
with Класс_ДатчикУглаТангажа;
use Класс_ДатчикУглаТангажа;
Package Класс_ГрафикРазворота is
subtype Секунда is Natural range ...
type ГрафикРазворота is tagged private;
procedure Очистить (the: in out ГрафикРазворота);
procedure Связать (the: In out ГрафикРазворота;
teta: Угол: si: Секунда: s2: Секунда);
function УголНаМомент (the: ГрафикРазворота;
s: Секунда) return Угол;
private
…
end Класс_ГрафикРазворота;

Рис. 9.6. График разворота первой ступени ракеты

Для решения задачи надо обеспечить сотрудничество трех объектов: экземпляра класса ГрафикРазворота, РегулятораУгла и КонтроллераУгла.
Описание класса КонтроллерУгла может иметь следующий вид:
with Класс_ГрафикРазворота. Класс_РегуляторУгла;
use Класс_ГрафикРазворота. Класс_РегуляторУгла;
Package Класс_КонтроллерУгла is
type укз_наГрафик is access all ГрафикРазворота;
type КонтроллерУгла is tagged private;
procedure Обрабатывать (the: in out КонтроллерУгла;
уг: укз_наГрафик);
function Запланировано (the: КонтроллерУгла;
уг: укз_наГрафик) return Секунда;
private
type КонтроллерУгла is tagged record
регулятор: РегуляторУгла := НовРегуляторУгла
(1.1.10);
…
end Класс_КонтроллерУгла:

ПРИМЕЧАНИЕ
Операция Запланировано позволяет клиентам запросить у экземпляра Контроллера-Угла время обработки следующего графика.

И наконец, описание класса РегуляторУгла представим в следующей форме:
with Класс_ДатчикУгла. Класс_Порт;
use Класс_ДатчикУгла. Класс_Порт;
Package Класс_РегуляторУгла is
type Режим is (Увеличение. Уменьшение);
subtype Размещение is Natural range ...
type РегуляторУгла is tagged private;
function НовРегуляторУгла (номер: Размещение;
напр: Направление: порт: Порт)
return РегуляторУгла;
procedure Включить(the: in out РегуляторУгла);
procedure Выключить(the: in out РегуляторУгла);
procedure УвеличитьУгол(№е: in out
РегуляторУгла);
procedure УменьшитьУгол(the: in out
РегуляторУгла);
function ОпросСостояния(the: РегуляторУгла)
return Режим:
private
type укз_наПорт is access all Порт;
type РегуляторУгла is tagged record
Номер: Размещение;
Состояние: Режим;
Управление: укз_наПорт;
end record;
end Класс_РегуляторУгла;
Теперь, когда сделаны необходимые приготовления, объявим нужные экземпляры классов, то есть объекты:
РабочийГрафик: aliased ГрафикРазворота;
РабочийКонтроллер: aliased Контроллеругла;
Далее мы должны определить конкретные параметры графика разворота
Связать (РабочийГрафик. 30. 60. 90);
а затем предложить объекту-контроллеру выполнить этот график:
Обрабатывать (РабочийКонтроллер. РабочийГрафикАссеss);
Рассмотрим отношение между объектом РабочийГрафик и объектом РабочийКонтроллер. РабочийКонтроллер — это агент, отвечающий за выполнение графика разворота и поэтому использующий объект РабочийГрафик как сервер. В данном отношении объект РабочийКонтроллер использует объект РабочийГрафик как аргумент в одной из своих операций.

Видимость объектов

Рассмотрим два объекта, А и В, между которыми имеется связь. Для того чтобы объект А мог послать сообщение в объект В, надо, чтобы В был виден для А.
В примере из предыдущего подраздела объект РабочийКонтроллер должен видеть объект РабочийГрафик (чтобы иметь возможность использовать его как аргумент в операции Обрабатывать).
Различают четыре формы видимости между объектами.
1. Объект-поставщик (сервер) глобален для клиента.
2. Объект-поставщик (сервер) является параметром операции клиента.
3. Объект-поставщик (сервер) является частью объекта-клиента.
4. Объект-поставщик (сервер) является локально объявленным объектом в операции клиента.
На этапе анализа вопросы видимости обычно опускают. На этапах проектирования и реализации вопросы видимости по связям обязательно должны рассматриваться.

Агрегация

Связи обозначают равноправные (клиент-серверные) отношения между объектами. Агрегация обозначает отношения объектов в иерархии «целое/часть». Агрегация обеспечивает возможность перемещения от целого (агрегата) к его частям (свойствам).
В примере из подраздела «Связи» объект РабочийКонтроллер имеет свойство регулятор, чьим классом является РегуляторУгла. Поэтому объект РабочийКонтроллер является агрегатом (целым), а экземпляр РегулятораУгла — одной из его частей. Из РабочегоКонтроллера всегда можно попасть в его регулятор. Обратный же переход (из части в целое) обеспечивается не всегда.
Агрегация может обозначать, а может и не обозначать физическое включение части в целое. На рис. 9.7 приведен пример физического включения (композиции) частей (Двигателя, Сидений, Колес) в агрегат Автомобиль. В этом случае говорят, что части включены в агрегат по величине.

Рис. 9.7. Физическое включение частей в агрегат

На рис. 9.8 приведен пример нефизического включения частей (Студента, Преподавателя) в агрегат Вуз. Очевидно, что Студент и Преподаватель являются элементами Вуза, но они не входят в него физически. В этом случае говорят, что части включены в агрегат по ссылке.

Рис. 9.8. Нефизическое включение частей в агрегат

Итак, между объектами существуют два вида отношений — связи и агрегация. Какое из них выбрать?
При выборе вида отношения должны учитываться следующие факторы:
связи обеспечивают низкое сцепление между объектами;
агрегация инкапсулирует части как секреты целого.

Классы

Понятия объекта и класса тесно связаны. Тем не менее существует важное различие между этими понятиями. Класс — это абстракция существенных характеристик объекта.

Общая характеристика классов

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

Рис. 9.9. Структуре представления класса

Интерфейс может быть разделен на 3 части:
1) публичную (public), объявления которой доступны всем клиентам;
2) защищенную (protected), объявления которой доступны только самому классу, его подклассам и друзьям;
3) приватную (private), объявления которой доступны только самому классу и его друзьям.
Другом класса называют класс, который имеет доступ ко всем частям этого класса (публичной, защищенной и приватной). Иными словами, от друга у класса нет секретов.

ПРИМЕЧАНИЕ
Другом класса может быть и свободная подпрограмма.

Реализация класса описывает секреты поведения класса. Она включает реализации всех операций, определенных в интерфейсе класса.

Виды отношений между классами

Классы, подобно объектам, не существуют в изоляции. Напротив, с отдельной проблемной областью связывают ключевые абстракции, отношения между которыми формируют структуру из классов системы.
Всего существует четыре основных вида отношений между классами:
ассоциация (фиксирует структурные отношения — связи между экземплярами классов);
зависимость (отображает влияние одного класса на другой класс);
обобщение-специализация («is а»-отношение);
целое-часть («part of»-отношение).
Для покрытия основных отношений большинство объектно-ориентированных языков программирования поддерживает следующие отношения:
1) ассоциация;
2) наследование;
3) агрегация;
4) зависимость;
5) конкретизация;
6) метакласс;
7) реализация.
Ассоциации обеспечивают взаимодействия объектов, принадлежащих разным классам. Они являются клеем, соединяющим воедино все элементы программной системы. Благодаря ассоциациям мы получаем работающую систему. Без ассоциаций система превращается в набор изолированных классов-одиночек.
Наследование — наиболее популярная разновидность отношения обобщение-специализация. Альтернативой наследованию считается делегирование. При делегировании объекты делегируют свое поведение родственным объектам. При этом классы становятся не нужны.
Агрегация обеспечивает отношения целое-часть, объявляемые для экземпляров классов.
Зависимость часто представляется в виде частной формы — использования, которое фиксирует отношение между клиентом, запрашивающим услугу, и сервером, предоставляющим эту услугу.
Конкретизация выражает другую разновидность отношения обобщение-специализация. Применяется в таких языках, как Ada 95, C++, Эйфель.
Отношения метаклассов поддерживаются в языках SmallTalk и CLOS. Метакласс — это класс классов, понятие, позволяющее обращаться с классами как с объектами.
Реализация определяет отношение, при котором класс-приемник обеспечивает свою собственную реализацию интерфейса другого класса-источника. Иными словами, здесь идет речь о наследовании интерфейса. Семантически реализация — это «скрещивание» отношений зависимости и обобщения-специализации.

Ассоциации классов

Ассоциация обозначает семантическое соединение классов.
Пример: в системе обслуживания читателей имеются две ключевые абстракции — Книга и Библиотека. Класс Книга играет роль элемента, хранимого в библиотеке. Класс Библиотека играет роль хранилища для книг.

Рис. 9.10. Ассоциация

Отношение ассоциации между классами изображено на рис. 9.10. Очевидно, что ассоциация предполагает двухсторонние отношения:
для данного экземпляра Книги выделяется экземпляр Библиотеки, обеспечивающий ее хранение;
для данного экземпляра Библиотеки выделяются все хранимые Книги.
Здесь показана ассоциация один-ко-многим. Каждый экземпляр Книги имеет указатель на экземпляр Библиотеки. Каждый экземпляр Библиотеки имеет набор указателей на несколько экземпляров Книги.
Ассоциация обозначает только семантическую связь. Она не указывает направление и точную реализацию отношения. Ассоциация пригодна для анализа проблемы, когда нам требуется лишь идентифицировать связи. С помощью создания ассоциаций мы приводим к пониманию участников семантических связей, их ролей, мощности (количества элементов).
Ассоциация один-ко-многим, введенная в примере, означает, что для каждого экземпляра класса Библиотека есть 0 или более экземпляров класса Книга, а для каждого экземпляра класса Книга есть один экземпляр Библиотеки. Эту множественность обозначает мощность ассоциации. Мощность ассоциации бывает одного из трех типов:
один-к-одному;
один-ко-многим;
многие-ко-многим.
Примеры ассоциаций с различными типами мощности приведены на рис. 9.11, они имеют следующий смысл:
у европейской жены один муж, а у европейского мужа одна жена;
у восточной жены один муж, а у восточного мужа сколько угодно жен;
у заказа один клиент, а у клиента сколько угодно заказов;
человек может посещать сколько угодно зданий, а в здании может находиться сколько угодно людей.

Рис. 9.11. Ассоциации с различными типами мощности

Наследование

Наследование — это отношение, при котором один класс разделяет структуру и поведение, определенные в одном другом (простое наследование) или во многих других (множественное наследование) классах.
Между п классами наследование определяет иерархию «является» («is а»), при которой подкласс наследует от одного или нескольких более общих суперклассов. Говорят, что подкласс является специализацией его суперкласса (за счет дополнения или переопределения существующей структуры или поведения).
Пример: дана система для записи параметров полета в «черный ящик», установленный в самолете. Организуем систему в виде иерархии классов, построенной на базе наследования. Абстракция «верхнего» класса иерархии имеет вид
with ...;...
use ...; ...
Package Класс_ПараметрыПолета is
type ПараметрыПолета is tagged private;
function Инициировать return ПараметрыПолета;
procedure Записывать (the: in out ПараметрыПолета);
function ТекущВремя (the: ПараметрыПолета)
return БортовоеВремя;
private
type ПараметрыПолета is tagged record
Имя: integer;
ОтметкаВремени: БортовоеВремя;
end record;
end Класс_ПараметрыПолета;
Запись параметров кабины самолета может обеспечиваться следующим классом:
with Класс_ПараметрыПолета; ...
use Класс_ПараметрыПолета; ...
Package Класс_Кабина is
type Кабина is new ПараметрыПолета with private;
function Инициировать (Д:Давление; К:Кислород;
Т:Температура) return Кабина;
procedure Записывать (the: in out Кабина);
function ПерепадДавления (the: Кабина) return Давление;
private
type Кабина is new ПараметрыПолета
with record
параметр1: Давление;
параметр2: Кислород;
параметр3: Температура
end record;
end Класс_Кабина;
Этот класс наследует структуру и поведение класса ПараметрыПолета, но наращивает его структуру (вводит три новых элемента данных), переопределяет его поведение (процедура Записывать) и дополняет его поведение (функция ПерепадДавления).
Иерархическая структура классов системы для записи параметров полета, находящихся в отношении наследования, показана на рис. 9.12.

Рис. 9.12. Иерархия простого наследования

Здесь ПараметрыПолета — базовый (корневой) суперкласс, подклассами которого являются Экипаж, ПараметрыДвижения, Приборы, Кабина. В свою очередь, класс ПараметрыДвижения является суперклассом для его подклассов Координаты, Скорость, Ориентация.