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

рассмотрим модуль с функцией «компиляции ПЛ/1 -прог­ раммы». Этот модуль может быть головным для компиля тора, состоящего из множества подчиненных модулей, или единственным модулем компилятора. В обоих слу­ чаях функция модуля остается одной и той же, но логика совершенно различна. Функцию модуля можно рассматри­ вать как совокупность логики модуля и функций всех подчиненных (вызываемых) модулей. Это рекурсивное оп­ ределение может быть применено к любому модулю в рассматриваемой иерархии программы.

Целью проектирования является такое разделение прбЬракийь? нв! мбдули, при котором каждый из них по возможности выполняет только одну функцию, т. е. обла­ дает функциональной связностью. Рассмотрим в этой свя­ зи класснфикациониую схему категорий внутренней связ­ ности модулей, начиная с самой слабой связности.

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

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

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

5'

131

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

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

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

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

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

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

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

вдругом контексте и других программах.

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

132

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

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

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

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

Группа модулей обладает общей связностью, если они обращаются к одной общей структуре данных. Набор модулей ПЛ/1, работающих со структурой данных, объяв­ ленной как EXTERNAL, будет обладать общей связностью. Модули Фортрана, обращающиеся к данным в общей области, и модули, работающие с данными в абсолютных адресах (включая регистры), также могут быть примерами общей связности.

Ряд проблем имеет отношение к общей связности. Все модули зависят от физического порядка элементов в структуре, учитывая, что изменение размера одного эле­ мента данных окажет влияние на все модули. Использо­ вание общих данных приводит к неудачам попытки конт­ роля обращения каждого модуля к данным. Например, в системе ОС/360 имеется общая структура данных, называемая таблицей векторов связи, для которой невоз­ можно организовать контроль доступа. Оригинально зако-

133

дированиые имена общих переменных связывают модули Это значит, что использование модулей с общей связ ностыо в других программах затруднено или невозможна Группа модулей обладает внешней связностью, если они обращаются к одному общему элементу данных (оди­ ночная переменная). Например, набор модулей П Л /|, обращающийся к переменной (не к структуре), обладает внешней связностью К внешней связности относится большинство проблем, ассоциирующихся с общей связ ностыо Однако проблема зависимости от физического порядка элементов в структуре в этом случае отсутствует Два модуля обладают контрольной связностью, если один в явной форме контролирует функционирование дру­ гого, например, посредством функционального кода Конт­ рольная связность и логическая внутренняя связность обычно существуют совместно Таким образом, здесь имеется проблема, аналогичная рассмотренной при анали­ зе логической внутренней связности использование од­ ного сложного интерфейса для отражения одной из мно­ жества функций. Контрольная связность предполагает, что вызывающий модуль имеет некоторую информацию о

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

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

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

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

Два модуля связаны посредством данных, если один вызывает другой и все входные и выходные данные вызы­ ваемого модуля являются параметрами элементов данных (а не структур).

134

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

Меры внутренней и внешней связности могут исполь­

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

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

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

1) сложность взаимосвязи модуля с другими модулями должна быть меньше сложности внутренней структуры модуля;

2)хороший модуль снаружи проще, чем внутри;

3)хорошим модулем легче пользоваться, чем создать

его

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

135

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

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

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

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

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

136

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

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

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

1) представления структуры задачи в виде набора про­ цессов, основанных на потоке информации задачи;

2)идентификации основного входного и выходного по­ токов данных задачи,

3)анализа пути основного входного потока данных задачи по набору процессов По ходу выполнения процес­ сов входной поток исчезает. Точка, в которой последний

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

4)описания выделенных частей задачи как функций

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

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

очевидной логической структурой объемом в пределах 50 операторов исходного языка

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

137

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

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

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

1Сформулируйте основные задачи обеспечения надежности на этапе внешнего проектирования

2В чем состоит сущность разработки архитектуры системы’

3Содержание описания структуры системы

4Дайте характеристику внутренней связности модуля

5Дайте классификационную схему межмодульных связей

6Перечислите н охарактеризуйте шаги декомпозиции задач на модули

Г л а в а 7

ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ ПРИ РАЗРАБОТКЕ МОДУЛЕЙ

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

7.1. ЗАДАЧИ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ

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

138

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

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

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

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

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

139

бования разрабатываемой системы и возможности сущест­ вующих баз данных.

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

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

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

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

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

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

НО