Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Шпоры по технологии программирования (Гвоздев) - файл 1.doc


Шпоры по технологии программирования (Гвоздев)
скачать (254.3 kb.)

Доступные файлы (16):

10.doc34kb.27.01.2006 23:07скачать
12-13.doc36kb.27.01.2006 23:13скачать
14.doc44kb.27.01.2006 23:30скачать
16.doc23kb.27.01.2006 23:33скачать
18.doc23kb.27.01.2006 19:24скачать
1.doc43kb.27.01.2006 20:28скачать
20.doc32kb.27.01.2006 23:43скачать
21-22.doc22kb.27.01.2006 22:00скачать
26-27.doc107kb.27.01.2006 19:49скачать
2.doc68kb.27.01.2006 22:25скачать
3.doc82kb.27.01.2006 20:21скачать
4.doc25kb.27.01.2006 20:19скачать
5.doc24kb.27.01.2006 19:51скачать
6.doc27kb.27.01.2006 21:20скачать
7.doc25kb.27.01.2006 20:52скачать
8.doc23kb.27.01.2006 22:49скачать

1.doc

Первый этап - «стихийное» программирование. Этот этап охватыва­ет период от момента появления первых вычислительных машин до середи­ны 60-х годов XX в. В этот период практически отсутствовали сформулиро­ванные технологии, и программирование фактически было искусством. Пер­вые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных (рис. 1.2). Сложность программ в машинных кодах ограничивалась способ­ностью программиста одновременно мысленно отслеживать последователь­ность выполняемых операций и местонахождение данных при программиро­вании.

Появление ассемблеров позволило вместо двоичных или 16-ричных ко­дов использовать символические имена данных и мнемоники кодов опера­ций. В результате программы стали более «читаемыми».

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

программ.

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

Типичная программа того време­
ни состояла из основной программы,
области глобальных данных и набора подпрограмм (в основном библиотечных), выполняющих обработку всех данных или их части (рис. 1.3).

Слабым местом такой архитектуры было то, что при увеличении коли­
чества подпрограмм возрастала вероятность искажения части глобальных
данных какой-либо подпрограммой. Например, подпрограмма поиска корней
уравнения на заданном интервале по методу деления отрезка пополам меня­
ет величину интервала. Если при выходе из подпрограммы не предусмотреть
восстановления первоначального интервала, то в глобальной области ока­
жется неверное значение интервала. Чтобы сократить количество таких оши­
бок, было предложено в подпрограммах размещать локальные данные
(рис. 1.4).

Сложность разрабатываемого программного обеспечения при использо­
вании подпрограмм с локальными данными по-прежнему ограничивалась
возможностью программиста от- -

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

В начале 60-х годов XX в. раз­разился «кризис программирова­ния». Он выражался в том, что

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

ния проектов [8]. Проект устаревал

> локальными данными

раньше, чем был готов к внедрению, увеличивалась его стоимость, и в ре­зультате многие проекты так никогда и не были завершены,

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

Анализ причин возникновения большинства ошибок позволил сформу­
лировать новый подход к программированию, который был назван «струк­
турным» [19, 23].


Скачать файл (254.3 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации