6930

Хаотическое и структурное программирование

Доклад

Информатика, кибернетика и программирование

Хаотическое и структурное программирование Для начального периода развития программотехники, когда программы были штучным продуктом, характерен стиль программирования, который впоследствии получил название хаотическое программирование....

Русский

2013-01-10

107 KB

2 чел.

Хаотическое и структурное программирование

Для начального периода развития программотехники, когда программы были штучным продуктом, характерен стиль программирования, который впоследствии получил название “хаотическое” программирование. Суть его в том, чтобы из операторов языка программирования сконструировать программу, выполняющую некоторое (заданное) преобразование данных. Ни набор операторов, ни порядок их применения никак не регламентировался. В общем случае для такого программирования, чем больше операторов в языке программирования, тем лучше.

Главный недостаток разработанного таким образом ПО – большие трудности его сопровождения. Программы, написанные без регламентации применения операторов языка программирования, имеют структуру “итальянского спагетти” из-за частого применения в таких программах оператора перехода goto. Как правило, в таких программах может разобраться только автор, они плохо пригодны для тиражирования и превращения в товар.

В конце 60-х начале 70-х годов в сфере ПО обозначились трудности, порожденные расширением области применения компьютеров. Возросшая мощность вычислительной техники и появление языков высокого уровня позволили приступить к автоматизации процессов, с которыми люди перестали справляться или к которым еще не приступали из-за их высокой вычислительной сложности. Примерами таких задач могут служить автоматизированные системы управления безопасностью полетов или управления движением по железнодорожным магистралям. Такие системы разрабатывались в течение месяцев и лет. Стоимость ПО доходила до 80% всех затрат, однако обеспечить требуемый уровень их надежности не всегда удавалось.

Знаменательной датой в истории программирования стал 1968 год. Тогда создавшееся в программировании положение обсуждалось на международной конференции, получившей название “Кризис программного обеспечения”. В этом году Чарльз Хоар и Николаус Вирт впервые указали на необходимость придания языку программирования свойств, которые превратили бы его в “инструмент надежного создания сложных программ”. Однако настоять на этом им не удалось.

Несколько позже автор структурного программирования голландский ученый Дийкстра (в некоторых источниках Дейкстра) выпустил работу под названием “заметки по структурному программированию”, в которой доказывал, что большинство программ сложны и неуправляемы из-за отсутствия в них четкой математической структуры. Интуитивному и бессознательному (“хаотическому”) программированию он последовательно противопоставлял логически строгую методологию, предполагавшую ко всему прочему личную дисциплинированность и ответственность программиста. Одним из его кардинальных предложений было признание оператора перехода goto недопустимым в программировании. Сначала это предложение смутило и удивило почти всех программистов, но затем они убедились в том, что доводы Дийкстры весьма основательны. Способствовало этому то обстоятельство, что Якопини и Ципнер доказали теорему о том, что теоретически любую программу можно написать без goto. Чтобы изложить эту историю о революции в программировании до конца, следует упомянуть, что в 1974 году на защиту оператора goto выступил американец Кнут и показал, что в некоторых случаях использование этого оператора желательно.

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

Перечислим эти принципы:

  1.  Каждый программный модуль (блок, функция, процедура) должен иметь только один вход и один выход.

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

  1.  В программах рекомендуется применять  4 типа конструкций:

а)  последовательность (модулей, операторов)

         

         б)  разветвление (условный оператор)

                                     

Перечеркивание означает, что Q может отсутствовать.

    в)  цикл

  1.  с предусловием

  1.  с постусловием

          г)  выбор из нескольких альтернатив (или переключатель)

              

  1.   разработку программ рекомендуется вести сверху – вниз или по нисходящей стратегии.

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

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

Этот подход воплощен в методике, называемой «построением прототипа», или макетированием. Такую методику независимо предложили англичанка Черер и американец Мартин. Они назвали свои методы “prototyping” и “maketing” соответственно. Суть их методов в том, что разработку сложной программы необходимо начать с ее макета, который воплощал бы в себе основные ее конструкции, функции или элементы в их взаимосвязи, но без подробной детализации. Детализация осуществляется на более поздних этапах и по принципу “сверху-вниз” Достоинства такого макета в следующем:

а) макет дает наглядное представление о будущем программном продукте;

б) на макете просматриваются основные функции, выполняемые программой;

в) не загроможденный деталями макет четко характеризует программное изделие и способы достижения поставленных целей проекта;

г) если макет демонстрирует недостаточное удовлетворение требований, его легко переделать на ранних стадиях проекта;

д) одобренный макет – основа документации к будущей программной системе;

е) по макету проще спланировать разделение труда исполнителей, скоординировать и проконтролировать выполнение работы.

Нисходящее проектирование и его реализация (макетирование) первоначально как бы встраивались в структурное программирование, но впоследствии они были выделены и встроены в CASE-технологии.

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


        Р

        Р

       Q


 

А также другие работы, которые могут Вас заинтересовать

11614. Решение задач в MatLab 324.86 KB
  Лабораторная работа №2. Решение задач в MatLab Цель лабораторной работы закрепление практических навыков решения задач в среде математического пакета MatLab необходимых для выполнения лабораторных работ по дисциплине ТИПиС. Этап I. Решение уравнений в пакете MatLa...
11615. Создание собственных функций на MatLa 147.39 KB
  Создание собственных функций Необходимо создать программу на MatLab. При этом все операции с матрицами должны производиться без использования стандартных функций. Создание функции сложения матриц: function C=addmAB d1=sizeA; d2=sizeB; if d11==d21||d12==d22 n=d11; m=d12; ...
11616. ПЕРЕХОДНЫЕ ПРОЦЕССЫ В ЛИНЕЙНЫХ ЭЛЕКТРИЧЕСКИХ ЦЕПЯХ С СОСРЕДОТОЧЕННЫМИ ПАРАМЕТРАМИ 2.14 MB
  Лабораторная работа №7 ПЕРЕХОДНЫЕ ПРОЦЕССЫ В ЛИНЕЙНЫХ ЭЛЕКТРИЧЕСКИХ ЦЕПЯХ С СОСРЕДОТОЧЕННЫМИ ПАРАМЕТРАМИ Целью работы является исследование переходных процессов в линейных электрических цепях содержащих сопротивления индуктивность и емкость при действии и...
11617. Изучение рентгеновских трубок и аппаратов 629.5 KB
  ЛАБОРАТОРНАЯ РАБОТА №1. Изучение рентгеновских трубок и аппаратов. РЕНТГЕНОВЧСКИЕ ТРУБКИ. Рентгеновская трубка является источником рентгеновских лучей возникающих в ней в результате взаимодействия быстро летящих электронов с атомами анода установленного...
11618. Мерология. Лабораторный практикум 1.36 MB
  Мерология. Лабораторный практикум Учебнометодическое пособие для студентов приборостроительного факультета Лабораторный практикум предназначен для использования в высших учебных заведениях при подготовке инженеров по специальности Метрология стандартизация и...
11619. Исследование напряженно-деформированного состояния стержня при кручении 405.5 KB
  ЛАБОРАТОРНАЯ РАБОТА ПО МЕХАНИКЕ СПЛОШНЫХ СРЕД № 2 Тема: Исследование напряженно-деформированного состояния стержня при кручении Задание Для заданной упругой системы рис. 1 исследовать напряженнодеформированное состояние при растяжениисж
11620. Исследование напряженно-деформированного состояния стержня переменного сечения при растяжении-сжатии 632.5 KB
  ЛАБОРАТОРНАЯ РАБОТА ПО МЕХАНИКЕ СПЛОШНЫХ СРЕД № 1 Часть 1 Механика деформируемого твердого тела Тема Исследование напряженно-деформированного состояния стержня переменного сечения при растяжении-сжатии Задание Для заданной упругой системы рис. 1...
11621. Исследование напряженно-деформированного состояния стержня при поперечном изгибе 570.5 KB
  ЛАБОРАТОРНАЯ РАБОТА ПО МЕХАНИКЕ СПЛОШНЫХ СРЕД № 3 Тема:Исследование напряженно-деформированного состояния стержня при поперечном изгибе Задание Для заданной упругой системы рис. 1 исследовать напряженно-деформированное состояние при поперечном изг...
11622. Особенности разработки диаграмм вариантов использования в среде IBM Rational Rose 2003 249 KB
  Лабораторная работа №1 Особенности разработки диаграмм вариантов использования в среде IBM Rational Rose 2003 Работа над моделью в среде IBM Rational Rose начинается с общего анализа проблемы и построения диаграммы вариантов использования которая отражает функциональное назначение...