Реклама:

Глава 12

Рассмотрение кодирования

«Сойдем же и смешаем там язык их, так чтобы один не понимал речи другого»^

12.1. Какова связь кодирования с конструированием программ?

После того как мы сконструировали свои программы, нам все еще предстоит процесс их написания на языке, понятном компьютеру. К сожалению, генерируемое процессом конструирования структурированное изложение все же недоступно пониманию большинства компьютерных систем. Его нужно перевести на такой язык, как Кобол, ПЛ/1, Паскаль или же (не дай бог!) на язык ассемблера.

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

Кроме того, на рынке появляется все больше пакетов программ, которые автоматически транслируют структурированное изложение на тот или иной язык программирования. В частности, такой пакет предоставляется фирмой М.Джексона Michael Jackson Systems Limited.

Кодирование - это неизбежное зло, и как бы оно ни реализовывалось, должны существовать правила преобразования программных структур в «исходный код», т.е. в окончательную версию программы на языке программирования. В любой организации эти правила должны быть таковы, чтобы различные программисты, преобразующие в исходный код одно и то же структурированное изложение, получали идентичные операторы. Основное преимущество подобного набора правил состояло бы в создании такой окончательной среды программирования, которая порождала бы точный, эффективный и понятный всем программистам в данной организации код программы. Даже по современным стандартам это достижение было бы необычным. Выгоды оказались бы весьма далеко идущими, потому что теперь программисты тратят много времени, иногда впустую, пытаясь понять чужие коды программ, чтобы внести в них изменения, исправления или улучшения. Большая часть горячо обсуждаемой деятельности «по сопровождению», на которую тратятся от 70 до 90 процентов ресурсов во многих организациях по обработке данных, в сущности сводится к попыткам понять чей-то чужой код, чтобы «сопровождать» его. Если все кодируют одинаковым способом, значительная доля этих усилий оказалась бы необязательной.

Весьма простодушны программисты, которые протестуют против того, что такие правила «лишили бы их творческого начала». В большинстве случаев творческое кодирование в самую последнюю очередь требуется при организации разработки систем. Творчество стоит приберечь для этапов анализа и конструирования, а не для рутинной, канцелярской работы по кодированию.

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


⇐ Предыдущая страница| |Следующая страница ⇒