Билет 26. Основные стратегии проектирования алгоритмов, их сравнительная характеристика.

Существуют две основные стратегии проектирования алгоритмов: восходящее ("снизу-вверх") и нисходящее ("сверху-вниз") проектирование.

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

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

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

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

- Преимущества нисходящей стратегии:

1. Дает лучшее понимание объектов проектирования, так как на каждом шаге выделяются основные понятия, а детали "упрятываются".

2. Делает более простым процесс модификации программы и сокращает

время отладки.

3. Упрощает доказательство корректности программы.

- Трудности нисходящей стратегии.

1. На ранних стадиях должна быть проделана интеллектуальная работа главным программистом, прежде чем программа будет распараллеливаться для всех программистов проекта.

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

Реально процесс проектирования не является простой схемой "сверху-вниз". Иногда приходится вернуться к предыдущему уровню и произвести коррекцию проекта. Умелое сочетание обеих стратегий и составляет искусство проектирования

Билет 27. Основные декомпозиционные структуры программ. Сегменты-блоки и сегменты-процедуры, их спецификация.

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

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

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

Сегмент - это алгоритм, содержащий абстракции. Именно наличием абстракции объясняется свойство сегмента порождать другой сегмент.

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

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

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

1. Концентрируйте внимание, прежде всего, на самом существенном, отвлекаясь от мелочей.

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

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

4. Если на каком-либо шаге встретились непредвиденные проблемы, постарайтесь еще раз пересмотреть решения, принятые на предыдущих шагах, и, если потребуется, поменять их на другие варианты.

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

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

При раскрытии абстракции используются две формы сегмента: форму блока (сегмент - блок) и форму процедуры (сегмент - процедура).

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

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

Билет 28. Рабочий проект программы. Top-down граф.

Билет 29. Правила получения окончательной программы. Документация проекта.

Билет 30. Начальные шаги проектирования программы. Связь с внешней спецификацией. Основные варианты абстракций верхних уровней.

Билет 31. Процедуры языка Паскаль. Типы процедур. Правила выбора, описания и использования процедур.

Процедура - это вспомогательный алгоритм, который описывает некоторое абстрактное действие и к которому можно обращаться по имени.

Процедура является важным средством программирования, традиционным назначением которой является экономия труда программиста. Например, зачем много раз писать программу вычисления sin(x), если ее можно написать один раз и многократно использовать для различных значений х.

Аппарат процедур в языках программирования состоит из двух частей: описание процедуры и вызов процедуры.

Описание процедуры (процедура) - это фрагмент программы, оформленный по определенным правилам и имеющий имя, по которому его можно вызвать.

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

Формальные параметры описывают входные и выходные данные процедуры.

В языке Паскаль существует два вида процедур: процедуры общего вида и функции.

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

Функция может вычислять только одно значение скалярного типа.

Вызов процедуры общего вида производится оператором процедуры.

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

Параметры, передаваемые процедуре при вызове, называются фактиче­скими параметрами.

Процедуры общего вида:

Описание процедуры помещается в конце раздела описаний и имеет следующую структуру:

{<Раскрываемая абстракция>}

<Заголовок>

<Тело процедуры>

<Раскрываемая абстракция> является комментарием, в котором кратко оп­ределена цель процедуры.

<Тело процедуры> описывает алгоритм.

<Заголовок процедуры> имеет вид:

procedure <имя процедуры> (<список описаний формальных параметров>)

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

Вызов процедуры осуществляется с помощью оператора процедуры:

<оператор процедуры>::=<имя процедуры>(<список фактических пара­метров>);

Вызов процедуры включает следующие шаги:

- среди описаний процедур ищется процедура с именем <имя процедуры>;

- вместо формальных параметров подставляются (передаются) соответствующие фактические параметры;

- выполняется модифицированное тело процедуры;

- управление возвращается из процедуры к оператору, следующему за операто­ром процедуры.

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