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

4.1. Дайте определение модуля. Какие требования предъявляются к модулям?

Модуль — функционально законченный фрагмент программы, оформленный в виде отдельного файла с исходным кодом или поименованной непрерывной её части (например, Active Oberon), предназначенный для использования в других программах. Модули позволяют разбивать сложные задачи на более мелкие в соответствии с принципом модульности. Обычно проектируются таким образом, чтобы предоставлять программистам удобную для многократного использования функциональность (интерфейс) в виде набора функций, классов, констант. Модули могут объединяться в пакеты и, далее, в библиотеки. Удобство использования модульной архитектуры заключается в возможности обновления (замены) модуля, без необходимости изменения остальной системы. В большинстве случаев различные модули могут запускаться как на одном сервере, так и на разных, для распределения нагрузки и создания распределенной архитектуры.

 

 

4.2. Что понимают под связностью и сцеплением модулей? Какие типы связности и сцепления считаются допустимыми и почему?

Сцепление является мерой взаимозависимости модулей, которая
определяет, насколько хорошо модули отделены друг от друга. Модули независимы, если каждый
из них не содержит о другом никакой информации. Чем больше информации о других модулях
хранит модуль, тем больше он с ними сцеплен.
Различают пять типов сцепления модулей:
• по данным

• по образцу

• по управлению

• по общей области данных

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

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

• при ссылке к данным в общей области модули используют конкретные имена, что уменьшает гибкость разрабатываемого программного обеспечения.
Различают библиотеки ресурсов двух типов: библиотеки подпрограмм и библиотеки классов.
Библиотеки подпрограмм реализуют функции, близкие по назначению, например, библиотека графического вывода информации. Связность подпрограмм между собой в такой библиотеке – логическая, а связность самих подпрограмм – функциональная, так как каждая из них обычно реализует одну функцию.
Библиотеки классов реализуют близкие по назначению классы. Связность элементов класса – информационная, связность классов между собой может быть функциональной – для родственных или ассоциированных классов и логической – для остальных.
В качестве средства улучшения технологических характеристик библиотек ресурсов в
настоящее время широко используют разделение тела модуля на интерфейсную часть и область реализации секции Interface и Implementation – в Pascal, h и срр-файлы в C++ и в Java.

 

4.3. Чем нисходящий подход к разработке отличается от восходящего? Перечислите достоинства и недостатки этих подходов.

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

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

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

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

 

4.4. Что называют структурным программированием и почему? Назовите основные и дополнительные структуры. Какие способы описания структурных алгоритмов существуют? Приведите примеры структурных алгоритмов.

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

• позволяет использовать неструктурные способы передачи управления, причем часто на схеме
алгоритма они выглядят проще, чем эквивалентные структурные.
Способы: блок-схема, псевдокод, flow-формы, Диаграммы Насси-Шнейдермана.

 

 

4.5. Дайте определения понятию “заглушка модуля”.

Что отражает схема иерархии?

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

4.6. Назовите критерии оценки качества схемы иерархии.

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

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

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

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

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

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

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

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

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

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

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

Двенадцатый — удачное распределение модулей по компилируемым файлам программы и библиотекам.

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

Итак, хорошая структура программы обеспечивает сокращение общего объема текстов в 2 или 3 раза, что соответственно удешевляет проект; на несколько порядков удешевляет тестирование (на тестирование обычно приходится не менее 60% от общих затрат проекта), а также облегчает и удешевляет сопровождение программы.