Введение
Род деятельности программирования?
В 60-х – 70-х годах XX века данный вопрос активно обсуждался на научных конференциях. Существовало две популярных точки зрения:
- программирование это искусство,
- программирование это наука.
Дело в том, что разработка программного обеспечения (ПО) имеет ряд специфических особенностей
1. Неформальный характер требований к ПО (постановка задачи), но формализованный объект разработки (программы). Тем самым, разработка ПО содержит определенные этапы формализации.
2. Разработка ПО носит творческий характер. Тем самым, эта разработка ближе к процессу проектирования сложных устройств, но не к их массовому производству.
Естественно, что отдельный человек не в состоянии полностью осмыслить и построить программное обеспечение большой системы. Для управления ходом разработки больших программных систем выделяются шесть этапов, составляющих цикл разработки (цикл жизни) программного обеспечения:
1) анализ требований, предъявляемых к системе;
2) определение спецификаций;
3) проектирование;
4) кодирование;
5) тестирование:
а) автономное;
б) комплексное;
6) эксплуатация и сопровождение.
На диаграмме показано приблизительное распределение затрат на реализацию отдельных этапов разработки. Рассмотрим определение каждого из этих этапов.
Анализ требований, предъявляемых к системе
На первом этапе, часто неоправданно опускаемом, определяются требования, которые позволяют получить приемлемое решение проблемы.
На этом этапе формулируются целевое назначение и основные свойства разрабатываемой программной системы. Процесс выполнения работ и оформление результатов на этом этапе проработаны гораздо в меньшей степени, чем на других, и в общем случае не являются объектом деятельности профессиональных программистов.
Если предметом разработки является не программная система, а более сложный объект (например, система управления технологическим процессом), включающий программы только в качестве составной части, требования формируются ко всему предмету разработки.
Одним из самых эффективных методов исходных описаний является метод структурного анализа, сущность которого сводится к декомпозиции исходного объекта на его составные части.
Таким образом, создается иерархия связанных подсистем (обязательно непересекающихся). В общем случае, анализ требований, предъявляемых к системе, должен быть сосредоточен на интерфейсе между человеком (пользователем) и инструментом (ЭВМ).
При этом для программных систем можно выделить лишь базовые требования: - время обработки (работы) программы; - стоимость обработки; - вероятность ошибки; - реакция на непредсказуемые действия оператора (за- щита от дурака и др.). При декомпозиции требований следует делать различия между жесткими требованиями и требованиями, выполнение которых не является строго обязательным. Особое внимание следует уделять пространственно-временным ограничениям и средствам системы, которые в будущем могут претерпеть изменения. К важнейшим требованиям относятся ресурсные требования и затраты на реализацию системы.
Фактически, анализ требований завершается составлением развернутого технического задания на систему, которое в терминологии классического САПР называется аван-проектом.
2.2 Определение спецификаций На этапе определения спецификаций осуществляется точное описание функций, реализуемых ЭВМ, а также задаются структура входных и выходных данных, методы и средства их размещения. Определяются алгоритмы обработки данных.
Центральным вопросом определения спецификаций является проблема организации базы данных. При этом решается комплекс вопросов, имеющих отношение к структуре файлов, организации доступа к ним, модификации и удалению.
В случае, когда новая система создается на основе существующих, составной частью спецификаций является схема (алгоритм) приведения существующей базы данных к новому формату.
Такое преобразование может потребовать разработку специальной программы, которая становится ненужной после ее первого и единственного использования.
Все эти вопросы должны быть отражены в функциональных спецификациях, которые представляют собой документ, являющийся основополагающим в процессе разработки системы, так как содержит конкретное описание последней.
Чем подробней составлены спецификации, тем меньше вероятность возникновения ошибок. В спецификациях должны быть представлены данные для тестирования элементов системы и системы в целом. Это требование является объективным и обязательным, т.к. на данном этапе на параметры тестирования не будет оказывать влияние конкретная реализация системы.
Так как функциональные спецификации описывают принятые решения в целом, данный документ можно использовать для начальных оценок временных затрат, числа специалистов и других ресурсов, необходимых для проведения работ. В общем случае, спецификации определяют те функции, которые должна выполнять система, не указывая, каким образом это достигается. Составление подробных алгоритмов на этом этапе преждевременно и может вызвать нежелательные осложнения.
2.3 Проектирование
На стадии проектирования разрабатываются алгоритмы, задаваемые спецификациями, и формируется общая структура вычислительной системы. При этом система разбивается (при необходимости) на составные части таким образом, чтобы ответственность за реализацию каждой составной части можно было бы возложить на одного разработчика (или группу исполнителей). При этом для каждого определенного таким образом модуля системы должны быть сформированы предъявляемые к нему требования: - реализуемые функции; - размеры; - время выполнения и др. В целом соотношения «требования — спецификация — проектирование» можно проиллюстрировать следующей схемой (слайд).
Прежде всего Заказчик анализирует и формулирует требования реальности, которые находят отображение в требованиях, предъявляемых к программной системе. Однако ЭВМ не способна решить задачу непосредственно, реальные данные необходимо каким-то образом закодировать и ввести в ЭВМ.
Подобная модель решаемой задачи представляет собой абстрактное выражение реального мира и отражается в спецификациях. Если спецификации программы определены, возникает необходимость в описании процесса обработки информации, что относится к этапу проектирования.
Поскольку программа должна использоваться для реальной задачи, то на этапе реализации проекта (кодирование, тестирование) осуществляется перевод формального проекта в выполняемую программу.
И наконец, пользователь может сравнить планируемую функцию программы с реализованной функцией. Эти функции очень редко совпадают полностью. Таким образом, сопровождение замыкает цикл проектирования и позволяет изменить системные требования, спецификации, проекты программ и т.п.
Поскольку в начале этапа проектирования решение ряда функциональных задач зачастую не определено, процесс разбиения на подзадачи может быть весьма сложным.
В проектировании программных систем обычной является ситуация, когда Заказчик не знает, что точно он хочет. Особенно это относится к процессам, слабо поддающимся формализации (медицина, системы военного назначения и т.д.). По мере разра- ботки проекта Заказчик меняет спецификации. Если это происходит часто, разработка системы существенно усложняется.
Кодирование
Данный этап является наиболее простым, а его реализа- ция существенно облегчается при использовании алгоритмических языков высокого уровня. Кодирование — это этап разработки программного обеспечения, доставляющий наименьшее беспокойство разработчику. По имеющимся статистическим данным 64 % всех ошибок вносятся на этапах проектирования и лишь 36 % на этапе кодирования. Однако эти ошибки могут быть очень дорогостоящими.
В общем случае кодирование освоено лучше, чем другие этапы создания программ, и очень четко формализовано.
Тестирование
Этап тестирования обычно в финансовых затратах составляет половину расходов на создание системы. Плохо спланированное тестирование приводит к существенному увеличению сроков разработки системы и является основной причиной срывов графиков разработки. В процессе тестирования используются данные, характерные для системы в рабочем состоянии, т.е. данные для тестирования выбираются случайным образом.
План проведения испытаний должен быть составлен заранее, обычно на этапе проектирования.
Тестирование подразумевает три стадии:
- автономное;
- комплексное
- системное.
При автономном тестировании модуль проверяется с помощью данных, подготовленных программистом. При этом программная среда модуля имитируется с помощью программ управления тестированием, содержащих фиктивные программы вместо реальных подпрограмм, с которыми имеется обращение из данного модуля (заглушки). Подобную процедуру называют программным тестированием, а программу тестирования — UUT (тестирующей программой). Модуль, прошедший автономное тестирование, подвергается комплексному тестированию.
В процессе комплексного тестирования проводится совместная проверка групп программных компонент. В результате имеем полностью проверенную систему. На данном этапе тестирование обнаруживает ошибки, пропущенные на стадии автономного тестирования. Исправление этих ошибок может составлять до ¼ от общих затрат.
Системное (или оценочное) тестирование — это завершающая стадия проверки системы, т.е. проверка системы в целом с помощью независимых тестов. Независимость тестов является главным требованием. Обычно Заказчик на стадии приемки работ настаивает на проведении собственного системного тестирования. Для случая, когда сравниваются характеристики нескольких систем (имеется альтернативная разработка), такая процедура известна как сравнительное тестирование.
В процессе тестирования, для определения правильности выполнения программы вводится ряд критериев:
1) каждый оператор должен быть выполнен, по крайней мере, один раз для заданного набора тестов, и программа должна выдать правильный результат;
2) каждая ветвь программы должна быть опробована, и программа при этом должна выдать правильный результат;
3) каждый путь в программе должен быть испытан хотя бы один раз с использованием набора тестовых данных, и программа должна выдать правильный результат;
4) для каждой спецификации программы необходимо располагать набором тестовых данных, позволяющих установить, что программа правильно реализует данную спецификацию.
Хотя критерии 1) и 2) кажутся схожими, в действительности они сильно разнятся. Например, арифметический оператор IF в Fortran: IF (Выражение) N1, N2, N3. Критерий 1) подразумевает, что IF должен быть выполнен, в то время как 2) подразумевает различные наборы данных, для того чтобы выполнились условия N1, N2, N3 (т.е. передачу на эти метки). В общем случае не существует единого программного критерия, определяющего «хорошо проверенную» программу.
Тесно связаны с тестированием понятия «верификация» и «испытание». Испытание системы осуществляется посредством тестирования. Цель такой проверки — показать, что система функционирует в соответствии с разработанными на нее спецификациями.
Верификация заключается в выполнении доказательств, что программа удовлетворяет своим спецификациям. Современный процесс разработки программ не позволяет реализовать обе указанные концепции. Для ситуаций, не контролируемых тестовыми данными, система, прошедшая испытания, может дать неверные результаты.
После проведения верификации система работает правильно лишь относительно первоначальных спецификаций и допущений о поведении окружающей среды; формальные доказательства правильности программ весьма сложны и слабо разработаны.
Общий процесс создания правильных программ с помощью процедур испытания и верификации называется аттестацией. Различаются три вида отклонения от нормальной работы системы.
Сбой системы — это явление, связанное с нарушением системой установленных на нее спецификаций. Данные, при обработке которых правильными алгоритмами системы происходит сбой, называются выбросом. Исправление выброса можно предусмотреть в программе, так что не каждый выброс может приводить к сбою.
Ошибка — это алгоритмический дефект, который создает выброс (программная ошибка). Различают понятия «правильная» и «надежная» программа. Правильная программа — это та, что удовлетворяет своим спецификациям. Что касается надежной программы, то она не обязательно является правильной, но выдает приемлемый результат даже в том случае, когда входные данные либо условия ее использования не удовлетворяют принятым допущениям. Естественно стремление иметь «живую» (robustness) систему, т.е. систему, способную воспринимать широкий спектр вход- ных данных при неблагоприятных условиях. Система является правильной, если в системе нет ошибок, а ее внутренние данные не содержат выбросов. Система называ- ется надежной, если, несмотря на сбои, она продолжает удовле- творительно функционировать. Это особо видно на примере операционной системы (ОС), включающей систему обработки сбоев.
При обнаружении выброса такая система прекращает ра- боту с сохранением текущей информации и возможности про- должения работы после устранения выброса.
2.6 Эксплуатация и сопровождение
С учетом затрат на эксплуатацию и сопровождение временные затраты на разработку программной системы можно представить так (рис. 2.5):
1) анализ требований;
2) определение спецификаций;
3) проектирование;
4) кодирование;
5) автономное тестирование;
6) комплексное тестирование;
7) сопровождение
Ни одна из вычислительных систем не остается неизмен- ной по мере ее эксплуатации. Это объясняется несколькими причинами, среди которых можно выделить следующие: 1. Заказчик обычно не может четко сформулировать свои требования, редко бывает удовлетворен созданной си- стемой и поэтому настаивает на внесении изменений в готовую систему. 2. Могут быть обнаружены ошибки, пропущенные при тестировании. Анализ требований (3%) Определение спецификаций (3%) Проектирование (5%) Кодирование (7%) Автономное тестирование (8%) Комплексное тестирование (7%) Сопровождение (67%) 18 3. Могут потребоваться специальные модификации си- стемы для частных условий функционирования, свя- занные с различными применениями. 4. Сопровождение многочисленных компонентов систе- мы. Рассмотрим затраты, оказывающие наибольшее влияние на процесс разработки системы. В первую очередь следует от- метить, что методы разработки, стимулирующие раннее завер- шение проекта, могут привести к весьма высоким затратам по сопровождению. Поэтому не следует ориентироваться на воз- можно ранний переход на этап кодирования. Хотя написание кодов и создает иллюзию благополучия у руководителя проек- та, однако это чревато такими последствиями, как многократное тестирование и возникновение большого числа проблем на бо- лее позднем этапе сопровождения.
3 МЕТОДЫРАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Функциональное программирование
Логическое программирование
Автоматное программирование
Процедурное программирование
Объектно-ориентированное программирование
Прототипное программирование
Аспектно-ориентированное программирование
Компонентно-ориентированное программирование
Структу́рное программи́рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 1970-х годах Э. Дейкстрой и др.
В соответствии с данной методологией любая программа строится без использования оператора goto из трёх базовых управляющих структур: последовательность, ветвление, цикл; кроме того, используются подпрограммы. При этом разработка программы ведётся пошагово, методом «сверху вниз».
Методология структурного программирования появилась как следствие возрастания сложности решаемых на компьютерах задач, и соответственно, усложнения программного обеспечения. В 1970-е годы объёмы и сложность программ достигли такого уровня, что традиционная (неструктурированная) разработка программ перестала удовлетворять потребностям практики. Программы становились слишком сложными, чтобы их можно было нормально сопровождать. Поэтому потребовалась систематизация процесса разработки и структуры программ.
Методология структурной разработки программного обеспечения была признана «самой сильной формализацией 70-х годов».
По мнению Бертрана Мейера, «Революция во взглядах на программирование, начатая Дейкстрой, привела к движению, известному как структурное программирование, которое предложило систематический, рациональный подход к конструированию программ. Структурное программирование стало основой всего, что сделано в методологии программирования, включая и объектное программирование».
Принцип 1. Следует отказаться от использования оператора безусловного перехода goto.
Принцип 2. Любая программа строится из трёх базовых управляющих конструкций: последовательность, ветвление, цикл.
- Последовательность — однократное выполнение операций в том порядке, в котором они записаны в тексте программы.
Бертран Мейер поясняет: «Последовательное соединение: используйте выход одного элемента как вход к другому, подобно тому, как электрики соединяют выход сопротивления со входом конденсатора»[17].
- Ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения заданного условия.
- Цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется заданное условие (условие продолжения цикла).
Принцип 3. В программе базовые управляющие конструкции могут быть вложены друг в друга произвольным образом. Никаких других средств управления последовательностью выполнения операций не предусматривается.
Принцип 4. Повторяющиеся фрагменты программы можно оформить в виде подпрограмм (процедур и функций). Таким же образом (в виде подпрограмм) можно оформить логически целостные фрагменты программы, даже если они не повторяются.
- В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция «Вызов подпрограммы». При выполнении такой инструкции работает вызванная подпрограмма. После этого продолжается исполнение основной программы, начиная с инструкции, следующей за командой «Вызов подпрограммы».
- Бертран Мейер поясняет: «Преобразуйте элемент, возможно, с внутренними элементами, в подпрограмму, характеризуемую одним входом и одним выходом в потоке управления ».
Принцип 5. Каждую логически законченную группу инструкций следует оформить как блок (block). Блоки являются основой структурного программирования.
Блок — это логически сгруппированная часть исходного кода, например, набор инструкций, записанных подряд в исходном коде программы. Понятие блок означает, что к блоку инструкций следует обращаться как к единой инструкции. Блоки служат для ограничения области видимости переменных и функций. Блоки могут быть пустыми или вложенными один в другой. Границы блока строго определены. Например, в if-инструкции блок ограничен кодом BEGIN..END (в языке Паскаль) или фигурными скобками {...} (в языке C) или отступами (в языке Питон).
Принцип 6. Все перечисленные конструкции должны иметь один вход и один выход.
Произвольные управляющие конструкции (такие, как в блюде спагетти) могут иметь произвольное число входов и выходов. Ограничив себя управляющими конструкциями с одним входом и одним выходом, мы получаем возможность построения произвольных алгоритмов любой сложности с помощью простых и надежных механизмов[17].
Принцип 7. Разработка программы ведётся пошагово, методом «сверху вниз»
Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).
Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательное изменение состояний (в значении, подобном таковому в теории автоматов). При необходимости, в функциональном программировании вся совокупность последовательных состояний вычислительного процесса представляется явным образом, например, как список.
Функциональное программирование предполагает обходиться вычислением результатов функций от исходных данных и результатов других функций, и не предполагает явного хранения состояния программы. Соответственно, не предполагает оно и изменяемость этого состояния (в отличие от императивного, где одной из базовых концепций является переменная, хранящая своё значение и позволяющая менять его по мере выполнения алгоритма).
На практике отличие математической функции от понятия «функции» в императивном программировании заключается в том, что императивные функции могут опираться не только на аргументы, но и на состояние внешних по отношению к функции переменных, а также иметь побочные эффекты и менять состояние внешних переменных. Таким образом, в императивном программировании при вызове одной и той же функции с одинаковыми параметрами, но на разных этапах выполнения алгоритма, можно получить разные данные на выходе из-за влияния на функцию состояния переменных. А в функциональном языке при вызове функции с одними и теми же аргументами мы всегда получим одинаковый результат: выходные данные зависят только от входных. Это позволяет средам выполнения программ на функциональных языках кэшировать результаты функций и вызывать их в порядке, не определяемом алгоритмом и распараллеливать их без каких-либо дополнительных действий со стороны программиста (что обеспечивают функции без побочных эффектов — чистые функции).
Процеду́рное программи́рование — программирование на императивном языке, при котором последовательно выполняемые операторы можно собрать в подпрограммы, то есть более крупные целостные единицы кода, с помощью механизмов самого языка.
Процедурное программирование является отражением архитектуры традиционных ЭВМ, которая была предложена фон Нейманом в 1940-х годах. Теоретической моделью процедурного программирования служит абстрактная вычислительная система под названием машина Тьюринга.
Литература ________________________________________
______________________________________________________
______________________________________________________
Разработал: старший преподаватель С.Приступа
«» ______________ ___ г.