книги / Надежность программного обеспечения систем обработки данных

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

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

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

4.Прокрутка спецификаций. Эффективным методом по оценке подробной внешней спецификации являются гене­ рации тестовых случаев и последующее использование подробной внешней спецификации для имитации поведе­ ния системы. Этот процесс оценки документов проекти­ ровщика путем «выполнения» ее с тестовыми случаями называется прокруткой.

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

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

121

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

ПО.

Не существует каких-либо обоснованных подходов к оценке н (или) сопоставлению различных методов про­ верки спецификаций.

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

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

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

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

(22

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

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

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

Вопросы к главе 5

1Перечислите и охарактеризуйте основные принципы формулирования требований к ПО

2В чем состоит сущность анализа требований?

3Охарактеризуйте основные ошибки процесса разработки и описания целей

4Сформулируйте основные цели продукта

5Дайте оценку сильных и слабых сторон целей проекта

6 Какие виды информации специфицируются во внешнем проекте?

Г л а в а 6

ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ ПРИ ВНЕШНЕМ ПРОЕКТИРОВАНИИ

6 1. ЗАДАЧИ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ НА ЭТАПЕ ВНЕШНЕГО ПРОЕКТИРОВАНИЯ

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

123

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

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

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

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

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

Характерно, что при использовании данных два н более модуля могут пользоваться одними и теми жё'общими эле­ ментами. Самой важной структурной характеристикой эле­

134

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

сложность;

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

6.2. АРХИТЕКТУРА СИСТЕМЫ

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

Этот процесс необходим только при проектирования систем, но не при проектировании отдельных программ, т. е. если внешние спецификации описывают систему ПО то следующим шагом построения является разработка ар­ хитектуры, за которым следует процесс построения струк­ туры программы, если внешние спецификации описывают программу, то разработка архитектуры не производится.

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

Значительное количество разрабатываемых в настоя­ щее время систем ПО относится к традиционным систе­ мам пакетной обработки. Архитектура этих систем пред­ ставляет собой совокупность последовательных программ.

126

5) выделяемый уровень может содержать некоторые данные внутри системы. В системе управления данными уровень может представлять собой любой файл как древо­ видную структуру, тем самым изолируя действительную

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

ифакторов, относящихся к окружающей среде;

7)связи между уровнями ограничены определенными аргументами, допустимыми к передаче от одного уровня к другому. Желательно исключить использование глобаль­ ных данных в системе, чтобы снизить риск их неправиль­ ного использования;

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

ми , должны по возможности быть простыми элементами

данных, а ие сложными структурами.

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

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

структуру и содержание потока данных системы; иерархию подчинения задач при выполнении парал­

лельных процессов; структуру памяти системы;

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

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

12»

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

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

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

Естественно, что комбинация рассмотренных подходов является лучшим средством исключения ненадежности иа последующих процессах проектирования

6 3 СТРУКТУРА ПРОГРАММЫ

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

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

нии ее на небольшие автономные модули.

Модуль представляет собой закрытую подпрограмму, которая может вызываться любым другим модулем и мо­ жет быть оттранслирована отдельно. Автономность (или независимость) модуля может достигаться за счет макси­ мизации его внутренней связности и минимизации связей между модулями. На основе этого подхода в программе, состоящей из некоторого набора операторов, операторы должны быть взаимосвязаны между собой как в плане реализуемой функции, так и в плане использования инфор­ мации. Необходимо организовать объединение этих опера­ торов в небольшие по объему модули так, чтобы имелй место тесная связь между операторами внутри модуля И исключалась (сводилась к минимуму), связь между двумя операторами из разных модулей. Целью приемов декомпо­ зиции программы на модули является выделение отдель­ ной функции для каждого модуля и минимизация связей посредством данных за счет использования способов пере­ дачи формальных параметров.

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

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

Для выяснения разницы между функцией и логикой

130