Структурное и «неструктурное» программирование. Средства описания структурных алгоритмов

1.

Структурное и «неструктурное»
программирование. Средства описания
структурных алгоритмов.
Линейная структура - для получения результата
необходимо выполнить некоторые операции в
определенной последовательности.
Разветвленная структура - конкретная
последовательность операций зависит от
значений одной или нескольких переменных.
Циклическая структура - для получения
результата некоторые действия необходимо
выполнить несколько раз.
Для изображения схем алгоритмов таких программ
разработан ГОСТ 19.701-90, согласно которому
каждой группе действий ставится в соответствие
специальный блок

2.

3.

В 60-х годах XX в. было доказано, что любой сколь угодно
сложный алгоритм можно представить с использованием
трех основных управляющих конструкций.
Базовые управляющие конструкции:
следование - последовательное выполнение действий
ветвление - выбор одного из двух вариантов действий
цикл-пока - повторение действий, пока не будет нарушено
условие, выполнение которого проверяется в начале цикла
Еще три конструкции, которые можно составить из базовых:
выбор - выбор одного варианта из нескольких в зависимости
от значения некоторой величины;
цикл-до - повторение некоторых действий до выполнения
заданного условия, проверка которого осуществляется
после выполнения действий в цикле;
цикл с заданным числом повторений (счетный цикл) повторение некоторых действий указанное количество раз.
Любая из дополнительных конструкций легко реализуется через
базовые.

4.

5.

Стиль оформления программы
Хорошим считают стиль оформления
программы, облегчающий ее восприятие
как самим автором, так и другими
программистами.
«Помните, программы читаются людьми»,
Д. Ван Тассел.
Стиль оформления программы включает:
• правила именования объектов
программы (переменных, функций, типов,
данных и т.п.);
• правила оформления модулей;
• стиль оформления текстов модулей.

6.

Правила именования объектов программы
При выборе имен программных объектов следует
придерживаться правил:
• имя объекта должно соответствовать его
содержанию:
Maxltem - максимальный элемент;
Nextltem - следующий элемент;
• использовать символ «_» для визуального
разделения имен, состоящих из нескольких
слов:
Max_ltem, Next_Item;
• необходимо избегать близких по написанию
имен:
Index и InDec.

7.

Правила оформления модулей
Каждый модуль должен предваряться заголовком,
который содержит:
• название модуля;
• краткое описание его назначения;
• краткое описание входных и выходных
параметров с указанием единиц измерения;
• список используемых (вызываемых) модулей;
• краткое описание алгоритма (метода) и/или
ограничений;
• ФИО автора программы:
• идентифицирующую информацию (номер
версии и/или дату последней корректировки).

8.

Стиль оформления текстов модулей
определяет использование отступов, пропусков
строк и комментариев, облегчающих понимание
программы.
Пропуски строк и комментарии используют для
визуального разделения частей модуля.
Для языков Pascal, C++ и Java, использование
отступов позволяет прояснить структуру
программы: обычно дополнительный отступ
обозначает вложение операторов языка:
атах:=а[1,1];
for i:=1 to n do
for j:=1 to m do
if a[i,j]>amax then amax:=a[i,j];

9.

Комментарии
Переводить с английского языка каждый оператор
программы не нужно. Комментировать следует цели
выполнения действий, а также группы операторов,
связанные общим действием, т.е. комментарии должны
содержать некоторую дополнительную (неочевидную)
информацию, например:
{проверка условия и выход, если условие не выполняется}
if n<0 then
begin
WriteLn('Количество отрезков отрицательно');
exit;
end;
Для языков низкого уровня (Ассемблера) может оказаться
целесообразным комментировать и блоки операторов,
и каждый оператор

10.

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

11.

Программирование «с защитой от ошибок»
Любая из ошибок программирования, которая не
обнаруживается на этапах компиляции и компоновки
программы, в конечном счете может проявиться тремя
способами: привести к выдаче системного сообщения
об ошибке, «зависанию» компьютера и получению
неверных результатов.
Целесообразно проверять:
правильность выполнения операций ввода-вывода;
допустимость промежуточных результатов (значений
управляющих переменных, значений индексов, типов
данных, значений числовых аргументов и т.д.).

12.

Способы проявления ошибок

13.

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

14.

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

15.

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

16.

ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПО
И ИСХОДНЫХ ДАННЫХ
ДЛЯ ЕГО ПРОЕКТИРОВАНИЯ
Этап постановки задачи – один из наиболее ответственных
этапов создания программного продукта.
На этом этапе формулируют основные требования к
разрабатываемому ПО.
От того, насколько полно определены функции и
эксплуатационные требования, насколько правильно
приняты принципиальные решения, определяющие
процесс проектирования, во многом зависит стоимость
разработки и ее качество.
Каждый программный продукт предназначен для
выполнения определенных функций.
По назначению все программные продукты можно
разделить на группы: системные, прикладные и
гибридные

17.

18.

АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПО
ПРИ СТРУКТУРНОМ ПОДХОДЕ
Разработка ПО начинается с анализа требований к будущему
программному продукту.
В результате анализа получают спецификации разрабатываемого
ПО: выполняют декомпозицию и содержательную постановку
решаемых задач, уточняют их взаимодействие и
эксплуатационные ограничения.
В процессе определения спецификаций строят общую модель
предметной области как некоторой части реального мира, с
которой будет взаимодействовать разрабатываемое ПО, и
конкретизируют его основные функции.
Спецификации представляют собой полное и точное описание
функций и ограничений разрабатываемого ПО.
Функциональные спецификаций описывает функции
разрабатываемого ПО.
Эксплуатационные - определяет требования к техническим
средствам, надежности, информационной безопасности и др.

19.

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

20.

21.

ПРОЕКТИРОВАНИЕ ПО ПРИ СТРУКТУРНОМ ПОДХОДЕ
Сущность структурного подхода - декомпозиция программы
или программной системы по функциональному
принципу.
Все методы декомпозиции рассчитаны на анализ и
проектирование структур данных и обрабатывающих их
программ.
Первичным считают проектирование обрабатывающих
компонентов, проектирование структур данных
выполняют параллельно.
Альтернативный подход - первичным считают
проектирование данных, а обрабатывающие
программы получают, анализируя полученные
структуры данных.
В любом случае проектирование ПО начинают с
определения его структуры.

22.

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

23.

24.

Более полное представление о
проектируемом ПО с т.зр.
взаимодействия его компонентов
между собой и с внешней средой
дает функциональная схема.
Функциональная схема или схема
данных (ГОСТ 19.701 -90) – схема
взаимодействия компонентов ПО с
описанием информационных
потоков, состава данных в потоках и
указанием используемых файлов и
устройств.
Для изображения функциональных
схем используют специальные
обозначения, установленные
стандартом.
Функциональные схемы более
информативны, чем структурные.

25.

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

26.

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