Выделяют 2 этапа программирования:

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

2) ТП – осн. внимание уделяется ТП, т.е. совершенств-ю профф культуры программирования, организации и упорядыч труда самого программиста, независимо от используемого ЯП и типа ЭВМ.

Начиная с 70-х годов сформировались основные технологии:

· Модульное – осн. черта: стандартизация, строгое документирование интерфейса м\у отдельными программными единицами. Модуль – функционально законченная программн единица, к-рая структурно оформл-ся станд. образом, как по отношению к компилятору, так и по отношению к возможному объединению его с другими программными единицами входе загрузки. Паспорт модуля включает: ЯП, объём, входн и выходн данные, точка входа в модуль, параметры настройки. Фактически модульное прогр. можно трактовать как: технологию разбиения задачи на нек-рое кол-во модулей, умение широко использовать станд. модулей путём их параметрической настройки, автоматизация сборки готовых модулей из библиотек.

· Структурное – осн идея: в нём фиксируется нек-рый набор управляющих стр-р, причём другие стр-ры использовать запрещено, причём это требование предъявляется ко всем этапам проектирования и написания прог. Осн. структуры: следование, если- иначе, выбор, while do, repeat until. Техн структ прогр определ работу программ как суперпозицию указанных управляющих структур, при этом разрешается неограниченное вложение названных стр-р др в др-га, при нек-рых подходах разрешается рекурсия, те можно уменьшить кол-во управл стр-р до 2-х. побочным результатом является отсутствие goto. Написанная по этой технологии программа как правило имеет древовидную структуру, т.е легко читается и модифицируется, также нет переходов вперёд- назад. В результате резко сокращается отладка и время решения задачи

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

· Hipo технология - в ней разработаны шаблоны, бланки и типовые диаграммы, к-рых обычно 3:

1) блок схемы высоких уровней иерархии – этот тип диаграмм вспомогат, он играет роль оглавл всего проекта(обычно в процессе написания проги активно не участвуют).

2) иерархическая блок схема, к-рая аналог. предыдущей – описывает соподчинённость отдельных частей проги этот тип указывает связи м\у отдельными блоками и задаёт способы сбора диаграмм 3-го типа.

3) ipo-диаграммы – осн.(включают вход, процесс, выход). Процесс их заполнения жестко не указывается, указывается что делает каждый модуль, а не как. Проект разбивается на подсистемы, в виде дерева, также могут быть добавлены нек-рые рекомендации. Все ipo диагр имеют строго формализ систему ссылок к-рая наглядно задаётся на диагр 2-го уровня, если блок уточн другим, то ему присв-ся соотв номер, когда блок без номера то его следует кодировать. Проектирование заканч только после окончания заполн всех диаграмм и увязки их друг с другом, но кодир, отладка идёт на автомате даже мб спецами более низкой квалиф.

· Метод главного программиста (ГП) – наиболее распространён: при реализации программного проекта от начала до конца осущ под руководством ГП(отвечает за проект), к-рый стоит во главе 3-10 челов. Если прогр проект большой то включ-ся 1-3 ассистента, к-рые выполн его задачи, но не отвечают за проект.

· R- технология – двумерная технология прогр., это название обусловлено тем что в её основе лежит представление программного продукта виде спец оформленного графа.

Стиль программирования.

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

Стандартизация стиля – правило: если сущ более одного способа сделать что-то и выбор произволен, то остановиться на одном и способе и всегда его придерживаться. Делая одно и тоже всегда одинаково легче избежать путаницы, однако процессу стандартизации свойственны и недостатки т.к. применение стандартов может замедлить работу, стандарты могут оказаться огранич или громоздкими для написания. Станд стиля – результат здравого смысла и опыта программистов, а не закреплённое раз и на всегда правило.

Комментарии – их редко вставляют в прогу, но потом авторы понимают что не помнят программу. Хорошее правило – включать комментарии в процессе написания проги, именно в это время программёр более всего шарит в проге.

Виды:

· Вводные – каждая прога должна включать: назначение, синтаксис вызова, список и назначение осн. переменных и массивов, указание по вводу выводу, список всех файлов, список использ подпрограмм, название методов, список литературы, объём памяти, специфические указания оператору, сведения об авторе

· Оглавление– если прога очень большая, то в её начале помещают оглавление виде комментариев(название, размещение и функции каждой подпрограммы)

· Пояснительные комментарии – сопровождают те части проги, к-рые трудно понять без комментариев. Норма – одна строка на 10 строк текста, комментарии должны описывать цель, а не объяснять синтаксис.

Расположение комментариев – выделяются пустыми строками, заключ-ся в прямоугольники, располагайте комментарии так, чтобы это не делало её менее наглядной. Коментарии должны быть должны быть правильными и изменяться в процессе изменения проги. Неправ комментарии хуже чем их отсутств.

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

Пробелы облегчают чтение, рекоменд ставить пробелу между элементами списка, +,-,:=.

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

Стандартные сокращения позволяют программистам понимать тексты прог. Соглашения Джексона: каждое значимое слово должно сокращаться но не больше 3-х, в аббревиатуру всегда должна включаться 1-я буква, согласные важнее гласных, начало важнее конца, аббревиатура должна включать 6-15 букв. Алгоритм: из слова удаляются все гласные с правого конца, пока либо все гласные не будут удалены, кроме первой, либо слово не уменьшиться до требуемого размера, если слово больше то удаляются согласные.

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

Размещение операторов – одного оператора в строке достаточно.

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

Скобки – в сомнительных случаях ставьте скобки, это не только делает прогу более понятной но и предотвращает ошибки, скобки обходятся дешевле ошибки.

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

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

9. Проектирование программ. Структурный подход.

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

Программу снабжают комментариями, делят на параграфы, она становится ясной и точной. Одна из систем – один пишет, 2-й пытается понять написанное. Если 1-й не в состоянии дописать то 2-ой доделает.

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

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

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

Универсальностью будем н-ть независимость программы от конкретного набора данных. Хорошая универсальная программа должна обрабатывать вырожденные случаи и печатать сообщение об ошибке. Используйте в качестве параметров переменные, а не константы. Должна быть независимость проги от конкретного набора данных. { For i:=1 to 25 do read(a[i]), лучше Const N = 25;… For i:=1 to N do read(a[i]) }

Процедура изменения констант на новые значения отнимает много времени, может вызвать появление ошибок. Переменные вместо констант: размер таблиц, массивов, устройств ввода- вывода. В простой проге переменные можно поместить в начале. Если сложная то полезно выделить подпрограмму, которая задавала бы начальные значения всех параметров. Параметры могут быть полезны в процессе отладки. Создавайте универсальные программы, при этом можно предугадать возможные изменения её спецификации.

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

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

Важное обстоятельство – удобство работы с программой ее пользователя. Следует интересоваться, как продвигается работа у оператора и не возникает ли каких-либо проблем

Более скромные по целям работающие программы полезнее неоконченных грандиозных проектов.

Цели: высокий уровень надёжности, выполнение нек-рого объёма данных к определ дате, миним время разработки или стоимость, эффект., универсальность, модифицируемость. Если прога должна быть сделана быстро и потом не будет модифицироваться то не надо усложнять. Наиболее важные параметры время и память, но есть ещё и сложность. Чем сложнее программа, тем труднее ее контролировать, тестировать, отлаживать и эксплуатировать. Устанавливайте цели проекта заблаговременно и точно.

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

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

· Модульное программирование – процесс разбиения проги на модули и последующее их программирование. Каждая задача должна делиться на модули. Цели: необх добиться того, чтобы програмн модуль был правильным и не зависим от контекста, следует стремиться к тому чтобы из модулей можно было строить большие проги. Требования к модулям: короткие лучше длинных, независимость. Хороший модуль должен быть подобен математ функции.

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

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