При проектировании, реализации и тестировании компонентов структурной иерархии, полученной при декомпозиции, применяют следующие подходы:
• восходящий;
• нисходящий;
• расширяющегося ядра.
Восходящая разработка ПО
Сначала проектируют и реализуют компоненты нижнего уровня, затем предыдущего и т.д. По мере завершения тестирования и отладки компонентов осуществляют их сборку. Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы.
Подход имеет следующие недостатки:
• увеличение вероятности несогласованности компонентов вследствие неполноты спецификаций;
• позднее проектирование интерфейса, а соответственно невозможность продемонстрировать его заказчику для уточнения спецификаций и т.д.
Нисходящий подход к разработке ПО
Нисходящий подход предполагает, что проектирование и последующая реализация компонентов выполняется «сверху-вниз», т.е. вначале проектируют (затем и реализуют) компоненты верхних уровней иерархии, затем следующих и так далее до самых нижних уровней. При этом в процессе программирования компоненты нижних, еще не реализованных уровней заменяют специально разработанными отладочными модулями – «заглушками», что позволяет тестировать и отлаживать уже реализованную часть.
Для определения последовательности проектирования и реализации компонентов в нисходящем подходе применяют методы :
• Иерархический – разработка идет строго по уровням. Недостатки: большое количество сложных заглушек, основная масса модулей разрабатывается и реализуется в конце работы над проектом;
• Операционный - последовательность разработки модулей совпадает с порядком их выполнения при запуске программы. Недостатки: модули вывода результатов должны разрабатываться первыми, чтобы не проектировать сложную заглушку, при тестировании;
• Комбинированный.
Комбинированный метод учитывает следующие факторы, влияющие на последовательность разработки:
• достижимость модуля – наличие всех модулей в цепочке вызова данного модуля;
• зависимость по данным – модули, формирующие некоторые данные, должны создаваться раньше обрабатывающих, модули вывода результатов должны создаваться раньше обрабатывающих;
• готовность вспомогательных модулей – вспомогательные модули должны создаваться раньше обрабатывающих
• сложные модули должны разрабатываться прежде простых.
• если некоторый компонент нижнего уровня используется многими компонентами более высоких уровней, то его рекомендуют проектировать и разрабатывать раньше, чем вызывающие его компоненты
Преимущества нисходящего подхода:
• максимально полное определение спецификаций проектируемого компонента и согласованность компонентов между собой;
• раннее определение интерфейса пользователя, демонстрация которого заказчику позволяет уточнить требования к создаваемому программному обеспечению;
• возможность нисходящего тестирования и комплексной отладки.
68 Модульное программирование. Модули и их свойства. Сцепление модулей. Связность модулей.
При проектировании сложного ПО выполняют декомпозицию компонентов (в соотвеств с подходом) до получения простых элементов. При этом используют два способа декомпозиции: процедурный (структурный), объектный.
Результатом процедурной декомпозиции является иерархия подпрограмм (процедур), в которой верхние уровни - процедуры, связанные с принятием решения, а нижние уровни - процедуры обработки.
Результатом объектной декомпозиции является совокупность объектов, представляющих собой поля и методы, работающие с этими полями.
Таким образом, при любом способе декомпозиции получают набор процедур , которые в процессе реализации организуют в модули.
Модули и их свойства
Термин «модуль» используется в двух смыслах. Первоначально – это подпрограммы (они компилировались отдельно). В настоящее время - это набор программных ресурсов (констант, переменных, описаний типов, классов и подпрограмм) компилируемый автономно.
Чем выше степень независимости модулей, тем:
• легче разобраться в модуле, тестировать, отлаживать и модифицировать его;
• меньше «волновой» эффект - новые ошибки при исправлении старых
• проще организовать разработку ПО группой программистов.
Таким образом, уменьшение зависимости модулей улучшает технологичность проекта.
Степень независимости модулей (как подпрограмм, так и библиотек) оценивают двумя критериями: сцеплением и связностью.
Сцепление - мера взаимозависимости модулей, определяющая, насколько хорошо модули отделены друг от друга. Модули независимы, если каждый из них не содержит о другом никакой информации. Чем больше информации о других модулях хранит модуль, тем больше он с ними сцеплен.
Различают пять типов сцепления модулей:
• по данным - модули обмениваются только скалярными данными ;
• по образцу - модули обмениваются структурами данных;
• по управлению - один модуль посылает другому сигнал (флаг), предназначенный для управления внутренней логикой модуля, что снижает наглядность взаимодействия модулей;
• по общей области данных - модули работают с общей областью данных. Этот тип сцепления считается недопустимым, поскольку: программы сложны при сопровождении; есть зависимость от истории вызовов; ошибка одного модуля может проявиться при выполнении другого (усложняется локализация ошибок); используются конкретные имена;
• по содержимому - один модуль содержит обращения к внутренним компонентам другого, это противоречит блочно-иерархическому подходу. Отдельный модуль в этом случае уже не является «черным ящиком»: его содержимое должно учитываться в процессе разработки другого модуля. Pascal не поддерживают данного типа сцепления, но в Ассемблере это возможно.
Как правило, модули сцепляются между собой несколькими способами. Качество ПО принято определять по типу сцепления с худшими характеристиками.
Так, если использовано сцепление по данным и сцепление по управлению, то определяющим считают сцепление по управлению
Связность – степень взаимосвязи элементов, реализуемых одним модулем.
Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи и взаимное влияние модулей.
Размещение же сильно связанных элементов в разные модули усиливает межмодульные связи и усложняет понимание их взаимодействия.
Объединение слабо связанных элементов также уменьшает технологичность модулей, так как ими сложнее мысленно манипулировать.
Различают следующие виды связности (в порядке убывания уровня):
• функциональную - все объекты модуля предназначены для выполнения одной функции ;
• последовательную - выход одной функции служит исходными данными для другой функции ;
• информационно - связанными считают функции, обрабатывающие одни и те же данные ;
• процедурную - функции или данные, которые являются частями одного процесса. Обычно модули с процедурной связностью функций получают, если в модуле объединены функции альтернативных частей программы
• временную - функций подразумевает, что эти функции выполняются параллельно или в течение некоторого периода времени;
• логическую - объединении данных или функций в одну логическую группу;
• случайную - если связь между элементами мала или отсутствует.
69 Структурное программирование. Стиль оформления программы. Правила именования объектов программы. Правила оформления модулей.
Любой линейный алгоритм может быть реализован в виде комбинаций трех типовых структур алгоритмов: линейной, ветвящейся и циклической.
Слово «структурное» в данном названии подчеркивает тот факт, что при программировании использованы только перечисленные конструкции (структуры). Отсюда и понятие «программирование без go to».
Способы описания алгоритмов.
Стиль оформления программы
Технологичным считают стиль оформления программы, облегчающий ее восприятие самим автором и другими программистами.
Хороший стиль оформления программы включает:
• правила именования объектов программы (переменных, функций, типов, и т.п.);
• правила оформления модулей;
стиль оформления текстов модулей.
Правила именования объектов программы
Имя объекта должно соответствовать его содержанию. Например: Maxltem - максимальный элемент.
Если позволяет язык программирования, можно использовать символ «_» для визуального разделения имен, состоящих из нескольких слов Max_ltem, Next_Item.
Необходимо избегать близких по написанию имен, например: Index и InDec.
Правила оформления модулей
Каждый модуль должен предваряться комментарием, который, содержит:
- название модуля;
- краткое описание его назначения;
- краткое описание входных и выходных параметров;
- краткое описание алгоритма (метода) и ограничений;
- ФИО автора программы, идентифицирующую информацию (номер версии и/или дату последней корректировки). Например:
{*****************************************************}
{* Функция: Length_Path(n:word; L: array of real):real *}
{* Цель: определение суммарной длины отрезков *}
{* Исходные данные: *}
{* L - массив длин отрезков (в метрах) *}
{* Результат: длина (в метрах) *}
{* Вызываемые модули: нет *}
{* Описание алгоритма: *}
{* отрезки суммируются методом накопления, n > О *}
{* Дата: 25.12.2001 Версия 1.01. ' *}
{* Автор: Иванов И.И. *}
{* Исправления: нет *}
{*********************************}
Стиль оформления текстов модулей.
Стиль оформления текстов модулей определяет использование комментариев, пропусков строк и отступов, облегчающих понимание программы.
Пропуски строк и комментарии используют для визуального разделения частей модуля.
Комментарии должны содержать цели выполнения тех или иных действий и некоторую дополнительную (неочевидную) информацию.
Использование отступов позволяет прояснить структуру программы - дополнительный отступ обозначает вложение операторов.
Дата: 2019-07-25, просмотров: 269.
