Структурное программирование. Нисходящая и восходящая концепции. Модульное программирование

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

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

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

Придумал это Дейкстра (1968). Основные принципы: Программа должна создаваться мелкими шагами. Сложная задача должна разбиваться на ряд шагов, достаточно простых и легко воспринимаемых, имеющих 1 вход и 1 выход. 3. Как можно меньше переходов типа GOTO. 4. Логика программы, должна управляться на минимальное число достаточно простых Базовых управляющих структур. Принцип Суперпозиции - базовые управляющие структуры можно вкладывать одну в другую. Достоинства: Простой и логически ясный способ программирования. Все конструкции выглядят естественно с точки зрения человека. Простота обнаружения и исправления ошибок. Возможность отладки программы по частям.