Технология программирования. Структурное и «неструктурное» программирование. Средства описания структурных алгоритмов. Линейная структура - для получения. - презентация

1 Технология программирования

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

3

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

5

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

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

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

9 Стиль оформления текстов модулей Стиль оформления текстов модулей определяет использование отступов, пропусков строк и комментариев, облегчающих понимание программы. Пропуски строк и комментарии используют для визуального разделения частей модуля. Для таких языков, как 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];

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

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

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

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

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

15

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

17 защищенность – обеспечение конфиденциальности информации; программная совместимость – возможность совместного функционирования с другим ПО; аппаратная совместимость – возможность совместного функционирования с некоторым оборудованием; эффективность – использование минимально возможного количества ресурсов технических средств, например, времени микропроцессора или объема оперативной памяти; адаптируемость – возможность быстрой модификации с целью приспособления к изменяющимся условиям функционирования; повторная сходимость – возможность повторного выполнения без перезагрузки с диска; реентерабельность – возможность «параллельного» использования несколькими процессами.

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

19 Стандарт ГОСТ «Техническое задание. Требования к содержанию и оформлению» ТЗ должно содержать разделы: введение; основания для разработки; назначение разработки; требования к программе или программному изделию; требования к программной документации; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приемки.

20 Принципиальные решения начальных этапов проектирования: выбор структуры ПО; выбор типа ПИ и технологии работы с документами; выбор подхода к разработке (структурного или объектного); выбор языка и среды программирования. Эти решения определяют, что проектируется, с какими потребительскими характеристиками, как и какими средствами. Часть решений может быть определена в ТЗ, образовав группу технологических требований, остальные должны быть приняты как можно раньше, так как представляют собой исходные данные для процесса проектирования.

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

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

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

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

25

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

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

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

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

30 При объектном подходе, как и при структурном, сразу можно выполнить декомпозицию только очень простого ПО. На заре эпохи ООП были предложены различные методы анализа и проектирования ПО в рамках объектного подхода, использующие различные модели и нотации. Спорить о достоинствах и недостатках этих методов и моделей можно было бесконечно - «война методов».

31 Конец «войне методов» положило появление в 1995 г. первой версии языка UML (Unified Modeling Language - унифицированный язык моделирования), который признан стандартным средством описания проектов, создаваемых с использованием ООП. Его создатели - Гради Буч, Ивар Якобсон и Джеймс Рамбо, использовали в языке все лучшее, что появилось во время «войны методов». Спецификация разрабатываемого ПО при использовании UML объединяет несколько моделей: использования, логическую, реализации, процессов, развертывания. UML предлагает 9 диаграмм, входящих в различные модели: диаграммы вариантов использования; диаграммы классов; диаграммы пакетов; диаграммы последовательностей действий; диаграммы кооперации; диаграммы деятельностей; диаграммы состояний объектов; диаграммы компонентов; диаграммы размещения. Диаграммы используют единую графическую нотацию, что облегчает их понимание. Спецификация также включает словарь терминов, различные описания и текстовые спецификации.

32 ПРОЕКТИРОВАНИЕ ПО ПРИ ОБЪЕКТНОМ ПОДХОДЕ Основная задача логического проектирования при объектном подходе - разработка классов для реализации объектов, полученных при объектной декомпозиции, что предполагает полное описание полей и методов каждого класса. Физическое проектирование включает объединение клас­сов и других программных ресурсов в программные компоненты, а также размещение этих компонентов на конкретных вычислительных устройствах.

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

34

35