Абстрактность

Важным достижением было изобретение "языка высокого уровня". Это опять была программа-переводчик, но более мощная. Высокоуровневые языки делают возможным для программистов записывать выражения вида:

X = Y ( 456 / A ) - 2

которые сильно похожи на алгебраические. Благодаря языкам высокого уровня инженеры, а не только странноватые бит-жокеи, смогли начать писать программы. BASIC и FORTRAN -- примеры высокоуровневых языков.

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

Реальные инструкции зависят от каждого "выражения" в исходном тексте, взятом как единое целое. Операторы вроде + и = сами по себе не имеют смысла. Они -- просто часть сложной символики, которая зависит от синтаксиса и позиции оператора в тексте.

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

Автоматическая передача данных

Во-вторых, передача данных происходит сама собой. Механизм, производящий такой эффект -- это стек данных Форта. Форт автоматически загружает числа на стек; слова, требующие на входе числа, автоматически снимают их оттуда; слова, выдающие на выходе значения, автоматически кладут их на стек. Слова ПОЛОЖИТЬ-НА-СТЕК и ВЗЯТЬ-СО-СТЕКА в Форте на высоком уровне не существуют.

Таким образом, мы можем написать:

: ВЫПОЛНИТЬ ПОЛУЧИТЬ-С ПРЕОБРАЗОВАТЬ-в-D ВЫДАТЬ-D ;

где ПОЛУЧИТЬ-С считывает "С" и оставляет его на стеке, ПРЕОБРАЗОВАТЬ-в-D берет "С" со стека, преобразует и оставляет на стеке как "D". Наконец, ВЫДАТЬ-D берет "D" со стека и записывает его. Форт скрывает акт передачи данных в нашем коде, позволяя сконцентрироваться на функциональных шагах преобразования информации.

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

Форт убирает из наших программ детали о том, `как` вызываются слова и `как` передаются данные. Что же остается ? Остаются только слова, описывающие нашу задачу.

Имея слова, мы можем полностью воспользоваться рекомендациями Парнаса -- разбивать задачу в соответствии с частями, которые могут измениться, и формировать каждый "модуль" из стольких маленьких функций, сколько их потребуется для упрятывания информации об этом модуле. На Форте мы можем написать для этого столь много слов, сколько для этого нужно, независимо от простоты каждого из них.

Строка из типичной для Форта задачи может выглядеть так:

20 ПОВЕРНУТЬ ВЛЕВО БАШНЯ-ТАНКА

Немногие другие языки могут вдохновить Вас на сочетание подпрограммы с именем ВЛЕВО, простo модификатором, с подпрограммой БАШНЯ-ТАНКА, просто именем части аппаратуры.

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

Автоматические вызовы

Во-первых, вызовы производятся автоматически. Нет необходимости писать CALL ОВСЯНКА, достаточно просто ОВСЯНКА. В Форте определение ОВСЯНКА "знает", какого типа словом оно является и какую процедуру надо вызвать для исполнения себя.

Таким образом переменные и константы, системные функции, утилиты, так же, как и определенные пользователем команды или структуры данных, могут быть "вызваны" просто по имени.

Функциональная мощность

Первый фактор -- нечто, называемое "функциональной мощностью" -- выражает единообразие назначения всего внутри модуля. Если все эти выражения в совокупности могут быть представлены как выполняющие единую задачу, то они являются функционально ограниченными (связными).

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

Является ли описание составным предложением ? Встречаются ли в нем слова -- описатели времени, такие, как "сначала", "затем", "потом" и т.д. ? Используется ли после глагола существительное общего или неспециального назначения ? Есть ли в нем слова типа "инициализировать", предполагающие выполнение множества различных функций одновременно ?

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

`Совпадающая связность` (выражения встречаются несколько раз в одном модуле) `Логическая связность` (в модуле содержится несколько родственных функций и необходим флаг или параметр для решения о том, какую конкретно выполнять) `Связность по времени` (имеется группа выражений, исполняющихся одновременно, например, инициализация, но не имеющих иной связи) `Коммуникационная связность` (в модуле содержится группа выражений, работающих с одним и тем же набором данных) `Последовательная связность` (когда результат одного выражения служит входными данными для следующего)

Наш модуль "приготовление-овсянки" демонстрирует функциональную связность, поскольку его можно представить как единое целое, несмотря даже на то, что он состоит из нескольких подчиненных задач.

Философия Форта

Форт является языком и операционной системой. Но это не все: он также и воплощение философии. Обычно философию не рассматривают как нечто, отдельное от Форта. Она не предшествовала Форту и не описывалась где-либо вне рассуждений о Форте, и даже не имеет другого имени, кроме как "Форт".

Что она такое ? Как ее можно применять для решения задач программирования ?

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

Иерархическое проектирование по принципу "вход-обработка-выход"

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

Рис.1-6. Представление структурной диаграммы, из статьи "Структурированная разработка". (Structured Design, IBM Systems Journal).

+-----------+ | ВЫПОЛНИТЬ | +--+----+---+ | | +-------+---------------|----+--+-------------+-----------+ |... |5 |6 ...| 7| ...| +---|--------+ +---|-------|-------+ +--|-------+ | ПОЛУЧИТЬ С | | ПРЕОБРАЗОВАТЬ в D | | ВЫДАТЬ D | +----+-------+ +-------------------+ +---+------+ | | +---+--------+ +---+--------+ |3 |4 |8 |9 +----|-----+ +----|------+ +-------|---+ +-----|--+ | ПОЛУЧИТЬ | | ПРЕОБРАЗ. | | ПРЕОБРАЗ. | | ВЫДАТЬ | | B | | в C | | в E | | E | +----+-----+ +-----------+ +-----------+ +-+------+ | | +-+---------+ +-------------+---+ |1 |2 |10 |11 +--|------+ +--|------------+ +------|--------+ +------|---+ | СЧИТАТЬ | | ПРЕОБРАЗОВАТЬ | | ПРЕОБРАЗОВАТЬ | | ЗАПИСАТЬ | | | | в В | | в F | | | +---------+ +---------------+ +---------------+ +----------+

+--------------+ | вход | выход | |------+-------| 1 | | A | 2 | A | B | 3 | B | | 4 | B | C | 5 | C | | 6 | C | D | 7 | D | | 8 | D | E | 9 | E | | 10 | E | F | 11 | F | | +------+-------+

Для того, чтобы помочь разработчикам думать в этом направлении, было предложено графическое представление, названное "структурными диаграммами". (Несколько измененная форма так называемых "иерархических диаграмм"). Эти диаграммы состоят из двух частей: иерархической схемы и таблицы входов-выходов.

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

Числа в иерархической диаграмме соответствуют строкам в таблице входов-выходов. В точке 1 (модуль СЧИТАТЬ) выходом является величина А. В точке 2 (модуль ПРЕОБРАЗОВАТЬ-в-В), на вход подается А, выходом является В.

Быть может, наибольшим вкладом такого подхода является осознание того, что решения о передаче управления не должны доминировать в проекте. Как мы убедимся, поток управления -- это поверхностный аспект проблемы. Мизерные изменения в исходных требованиях могут существенно изменить структуры управления в программе и потребовать многих лет ее углубленного "перекапывания". Но, если проект программы ориентирован на что-то другое, например, на потоки данных, то изменения в планах не будут столь разрушительными.

Форт часто характеризуется как необычный,

Форт часто характеризуется как необычный, совершенно непохожий на любой другой популярный язык программирования -- как по своей структуре, так и по философии. Однако Форт включает в себя многие из принципов, которыми щеголяют большинство современных языков. Структурированная разработка, модульность и упрятывание информации -- среди ключевых слов сегодняшнего дня.
Некоторые новейшие языки близко подходят к духу Форта. Язык С, например, как и Форт, дает возможность программисту определять новые функции либо на С, либо на ассемблере. И, как и Форт, большая часть С определена в терминах функций.
Но Форт расширяет концепции модульности и упрятывания информации в большей степени, чем любой другой современный язык. Форт даже скрывает способ, которым вызываются слова и способ, по которому передаются локальные аргументы.
Результирующий код становится концентрированной смесью слов, чистейшим выражением абстрактного замысла. Как результат, Форт-программисты обычно продуктивнее, и пишут более плотные, эффективные и лучше управляемые программы.
Форт может не быть единственным возможным языком. Но я думаю, что подобный язык, если такая вещь возможна, был бы ближе к Форту, чем любой другой современный язык.

Язык проектирования

Форт -- язык для проектирования. Воспитаннику традиционной компьютерной науки такое утверждение кажется противоречивым. "Нельзя проектировать с помощью языка, с его помощью реализуют. Проектирование предваряет реализацию."

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

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

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

По этим причинам Форт-программисты тратят меньше времени на планирование, чем их коллеги классического толка -- праведники планирования. Для них отсутствие такового кажется безрассудным и безответственным. Традиционные окружения вынуждают программистов планировать, поскольку традиционные языки не готовы к восприятию перемен.

К сожалению, человеческое предвидение ограничено даже при наилучших условиях. Слишком сильное планирование становится непродуктивным.

Конечно, Форт не исключает планирования. Он позволяет создавать прототипы. Конструирование прототипа -- лучший способ планирования, так же, как и макетирование в электронике.

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

Литература

O.J. Dahl, E.W. Dijkstra, and C.A.R. Hoare, `Structured Programming`, London, Academic Press, 1972. Niklaus Wirth, "Program Development by Stepwise Refinement," `Communications of ACM`, 14, No.4(1971), 221-27. W.P. Stevens, G.J. Myers, and L.L. Constantine, "Structured Design," `IBM Systems Journal`, Vol.13, No.2, 1974. David L. Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules," `Communications of the ACM`, December 1972. Barbara H. Liskov and Stephen N. Zilles, "Specification Techniques for Data Abstractions," `IEEE Transactions on Software Engineering`, March 1975. David L. Parnas, "Designing Software for Ease of Extension and Construction," `IEEE Transactions on Software Engineering`, March 1979. Dewey Val Shorre, "Adding Modules to FORTH," 1980 FORML Proceedings, p.71. Mark Bernstein, "Programming in the Laboratory," unpublished paper, 1983. James R. Bell, "Threaded Code", `Communications of ACM`, Vol.16, No.6, 370-72. Robert B.K. DeWar, "Indirect Threaded Code," `Communications of ACM`, Vol.18, No.6, 331. Peter M. Kogge, "An Architectual Trail to Threaded-Code Systems," `Computer`, March, 1982. Randy Dumse, "The R65F11 FORTH Chip," `FORTH Dimensions`, Vol.5, No.2, p.25.

Модульность

Существенное движение вперед произошло с внедрением "структурированного программирования", методологии, основанной на том, что, как показал опыт, большие задачи проще решаются, если рассматривать их как совокупность меньших задач [1]. Каждый такой кусочек называется `модулем`. Программы состоят из модулей внутри других модулей.

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

Например, на рис.1-2 показана блок-схема модуля под названием "приготовление завтрака", который состоит из четырех подмодулей. Внутри каждого подмодуля можно найти новый уровень сложности, которую вовсе не нужно показывать на нашем уровне.

Рис.1-2. Проект структурированной программы.

Приготовление завтрака | +------------------------|------------------------+ | +-----------+----------+ | | | Решение: Вы спешите? | | | +----------------------+ | | / \ | | да нет | | +-----------/--------------+ +--\-----------+ | | | Остановиться на холодной | | Сварить яйца | | | | овсянке | | | | | +-------------------\------+ +--/-----------+ | | \ / | | +-\---------/---+ | | | Вымыть посуду | | | +-------|-------+ | +-----------------------------|-------------------+ |

Решение о переходе внутри нашего модуля принимается при выборе между модулем "холодная овсянка" и модулем "яйца", но линии переходов входят только в наружный модуль.

Структурированное программирование имеет три преимущества:

Каждая программа представляется линейной последовательностью содержательных функций, называемых `модулями`. Каждый модуль имеет ровно один вход и ровно один выход. Каждый модуль состоит из одной или нескольких функций, каждая из которых имеет также ровно один вход и ровно один выход и сама может рассматриваться как модуль. Модуль может содержать:

операции или другие модули; структуры принятия решений (выражения типа ЕСЛИ ТО); структуры для организации циклов.

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

В "приготовлении завтрака" Вы либо останавливаетесь на овсянке, либо варите яйца, но не одновременно. А потом Вы обязательно моете посуду. (Насколько мне известно, некоторые программисты обходят этот последний модуль, переезжая на новую квартиру каждые три месяца.)

Структурированное программирование было изначально задумано как подход к проектированию. Модули были воображаемыми обектами, которые существовали в голове программиста или разработчика и не были частями реального кода. Когда техника структурированного программирования применяется к неструктурированным языкам типа Бейсика, результат получается похожим на то, что показано на рис.1-3.

Рис.1-3. Структурированное программирование на неструктурированном языке.

10 ИНСТРУКЦИЯ 20 ИНСТРУКЦИЯ ' Решить - спешим? 30 ЕСЛИ Н=ВЕРНО ТО ПЕРЕЙТИ К 80 ' если да, то на 80 40 ИНСТРУКЦИЯ 50 ИНСТРУКЦИЯ ' Варка яиц 60 ИНСТРУКЦИЯ 70 ПЕРЕЙТИ К 110 ' на 110 80 ИНСТРУКЦИЯ 90 ИНСТРУКЦИЯ ' Приготовление овсянки 100 ИНСТРУКЦИЯ 110 ИНСТРУКЦИЯ ' Мытье посуды 120 ИНСТРУКЦИЯ

Мощность

Программирование на языке ассемблера характеризуется соответствием "один-в-один" между каждой командой, которую набивает программист, и командой, которую исполняет процессор.

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

Это пожелание было удовлетворено "макроассемблером", более сложным ассемблером, который мог распознавать не только нормальные инструкции, но также специальные имена ("макро"). Для каждого из них макроассемблер транслирует пять или десять машинных команд, представленных этим именем, так, как будто программист написал их все полностью.

Но высокоуровневый ли это язык ?

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

Выводит ли это Форт из рядов языков высокого уровня ? Перед тем, как ответить, давайте исследуем преимущества Форт-подхода.

Вот что по этому поводу есть сказать у изобретателя Форта Чарльза Мура:

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

В философском смысле, я думаю, это означает, что машина "понимает" слово. Она понимает слово DUP, быть может, лучше вашего, поскольку в ее мозгах никогда не возникает сомнение по поводу того, что DUP означает.

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

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

С точки зрения методологии программирования, преимущество Форт-подхода состоит в том, что `новые` слова и `новые` синтаксисы могут легко добавляться. Нельзя говорить, что Форт `ищет` слова -- он находит слова и исполняет их. Если Вы добавляете новые слова, Форт с тем же успехом найдет и исполнит их. Нет различия между существующими словами и теми, которые добавили Вы.

Более того, такая "расширяемость" подходит к любым типам слов, а не только к словам-действиям. К примеру, Форт позволяет Вам добавлять новые `компилирующие` слова -- такие, как IF и THEN, которые обеспечивают структурированный поток управления.
Вам также не составляет труда добавить оператор выбора по множеству вариантов или циклическую структуру со множеством выходов, если они Вам понадобятся или, что тоже важно, убрать их, если они не нужны.

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

Исследователи в лабораториях называют гибкость и расширяемость Форта среди его наиболее важных преимуществ для их работы. Можно разрабатывать лексиконы для сокрытия информации об огромном разнообразии тестового оборудования, присоединенного к компьютеру. Когда такая работа проделана более опытным программистом, исследователи могут использовать свой "программный инструментарий" маленьких слов для написания простых экспериментальных программ. При появлении нового оборудования добавляются новые лексиконы.

Марк Бернстейн описал проблему использования готовой целевой библиотеки процедур в лаборатории [8]: "Компьютер, а не пользователь, доминирует в эксперименте". Но, как он пишет, с помощью Форта "компьютер действительно подвигает ученых на изменение, исправление и улучшение программного обеспечения, для экспериментирования и изучения особенностей своего оборудования. Инициатива снова становится прерогативой исследователя."

Тех, кто упорствует в том, что Форт нельзя назвать языком высокого уровня, последний снабжает дополнительными аргументами. В то время, когда мощная проверка на синтаксис и типы данных становится одним из главных направлений в современных языках программирования, Форт вообще почти не производит синтаксический анализ. Предоставляя ту гибкость и свободу, которую мы описали, он не может указать Вам, что Вы собирались написать КРАСНЫЙ ЯБЛОКИ вместо ЯБЛОКИ КРАСНЫЙ. Ведь Вы сами придумали такой синтаксис !

Зато Форт более чем искупает это упущение, позволяя Вам компилировать каждое определение по отдельности и в течение считанных секунд.Вы обнаруживаете свою ошибку достаточно быстро -- когда Ваше определение не срабатывает. Кроме того, при желании Вы можете добавить в свои определения подходящие синтаксические проверки.

Кисть артиста не может защитить его от ошибки, художник сам будет судить об этом. Сковорода повара и рояль композитора остаются простыми и производительными. Зачем же позволять языку программирования пытаться быть умнее Вас ?

Так является ли Форт высокоуровневым языком ? По вопросу проверки синтаксиса он не проходит. По вопросу уровня абстрагирования и мощности он кажется языком `безграничного` уровня -- поддерживающим все -- от манипуляции с битами в порту вывода до задач бизнеса.

Решаете Вы. (Форту все равно.)

От кого прятать ?

Поскольку современные языки программирования дают несколько иное толкование выражения "упрятывание информации", нам придется внести ясность. От чего, от кого мы прячем информацию ?

Новейшие традиционные языки (такие как Модула-2) напрягают свои силы для обеспечения упрятывания в модуле информации о его внутренних алгоритмах и структурах данных от других модулей. Целью является достижение независимости модуля (минимальной связности). Создается впечатление, что модули стараются атаковать друг друга как враждебные антитела. Или по-другому, что злобные банды модулей-мародеров выходят на большую дорогу грабить драгоценное семейство структур данных.

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

Форт-программисты обычно предпочитают держать свою программу под личным контролем и не использовать технику физического упрятывания структур данных. (Несмотря на это, великолепно простой способ -- всего в три строки исходного текста -- добавления к Форту Модула-подобных модулей был предложен Дьювеем Валь Шорром [7].)

Подпрограммы

Мы обсуждали "модули" только как абстрактные объекты. Но любые высокоуровневые языки имеют аппарат, позволяющий кодировать модули проекта как модули реального кода -- отдельные куски, которым можно дать имена и "вызывать" из других кусков кода. Эти куски называются подпрограммами, процедурами или функциями, в зависимости от языка программирования и способа реализации.

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

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

Мы можем также написать и "варку-яиц", и "мытье-посуды" в виде подпрограмм. В этом случае можно определить "приготовление-завтрака" как простую программу, которая вызывает эти подпрограммы:

процедура приготовление-завтрака переменная С: булевская (означает спешку) `проверить наличие спешки` если С=истина, то вызвать приготовление-овсянки иначе вызвать варку-яиц конец вызвать мытье-посуды конец

Фраза "вызвать приготовление-овсянки" заставляет выполниться подпрограмму с таким именем. Когда выполнение заканчивается, управление возвращается назад в вызывающую программу в точку, следующую за вызовом. Подпрограммы повинуются законам структурированного программирования.

Как можно видеть, эффект при использовании подпрограмм такой же, как если бы тело этих подпрограмм присутствовало бы в вызывающем модуле. Но, в отличие от кода, производимого макроассемблером, подпрограмма может быть скомпилирована где угодно в памяти, после чего на нее можно просто ссылаться. Не обязательно компилировать ее внутри реального кода главной программы (см. рис. 1-5).

Рис.1-5. Главная программа и подпрограмма в памяти.

Главная программа |-----------------------| ____ |_______________________| / \/ Подпрограмма |_______________________| / +-----------------------+ |_______________________| / | Приготовление-овсянки | | вызвать |/ |_______________________| | приготовление-овсянки | |_______________________| |_______________________|\ |_______________________| |_______________________| \ |_______________________| | | \_____/

Постепенная детализация

Один из подходов, существенно опирающихся на использование подпрограмм, называется "постепенной детализацией" [2]. Идея состоит в том, что Вы начинаете с написания скелетной версии программы, использующей естественные имена процедур и структур данных. Затем Вы пишете версии для каждой из именованных процедур. Процесс продолжается в сторону большего уровня детализации до тех пор, пока процедуры не смогут быть выражены непосредственно на компьютерном языке.

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

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

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

Заметьте также: постепенная детализация заставляет Вас прорабатывать все детали структур управления на данном уровне перед переходом на следующий уровень вниз.

Поверхностность структуры

Парнас предлагает два критерия разбиения:

возможное (хотя пока и незапланированное) использование и возможное (хотя и незапланированное) изменение.

Этот новый взгляд на "модуль" отличается от традиционного. Такой "модуль" -- собрание кусочков, обычно очень маленьких, которые вместе прячут информацию о некоторой стороне проблемы.

Двое других авторов описывают ту же идею по-другому, используя выражение "абстрагирование данных" [5]. Они приводят в пример стековую структуру. Стековый "модуль" состоит из процедур для очистки стека, отправки значения в стек, снятия значения оттуда и определения пустоты стека. Этот "многопроцедурный" модуль скрывает информацию о том как оргазизован стек от остальных частей программы. При этом он считается единым модулем потому, что его процедуры взаимозависимы. Нельзя изменить способ загрузки значения в стек без изменения способа снятия его оттуда.

Слово `использовать` играет важную роль в этой концепции. Парнас пишет в своей более поздней статье [6]:

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

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

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

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

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

Программирование на уровне компонентов

Наличие большого набора простых слов делает простым использование техники, которую мы назовем "программирование на уровне компонентов". Для пояснения давайте вначале прoсмотрим те объединения, которые мы неопределенно описали как "части, которые могут быть изменены". В типовой системе почти все может быть подвержено изменениям: устройства ввода/вывода, такие, как терминалы и принтеры, интерфейсы типа микросхем ПЛМ, операционные системы, любые структуры данных или их представление, любые алгоритмы и т.д.

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

Ответом является: "наименьший набор взаимовлияющих структур данных и алгоритмов, которые разделяют знание о том, как они в совокупности работают." Мы будем называть такое объединение "компонентом".

Компонент является ресурсом. Он может быть частью аппаратуры, например, ПЛМ или аппаратным стеком. Или компонент может быть программным ресурсом, таким, как очередь, словарь или программный стек.

Все компоненты включают в себя объекты данных и алгоритмы. Не имеет значения, физический ли это объект данных (такой, как аппаратный регистр) или абстрактный (как вершина стека или поле в базе данных). Безразлично, описан ли алгоритм в машинном коде или проблемно-ориентированными словами типа ОВСЯНКА или ЯЙЦА.

Рисунок 1-7 сопоставляет результаты структурированной разработки с результатами разработки на уровне компонентов. Вместо `модулей` под названиями ЧИТАТЬ-ЗАПИСЬ, РЕДАКТИРОВАТЬ-ЗАПИСЬ и ПИСАТЬ-ЗАПИСЬ мы сосредоточены на `компонентах`, описывающих структуру записей, реализующих систему команд редактора и обеспечивающих процедуры чтения/записи.

Что мы сделали ? Мы ввели новый этап в процесс разработки: разбили на компоненты во время `проектирования`, затем описали последовательность, иерархию и линию вход-обработка-выход при `реализации`. Да, это еще один шаг, однако мы получили дополнительное измерение для проведения разреза -- не только по слоям, но и `в клеточку`.

Производительный язык

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

Размеры

Здесь имеются два соображения: размер корневой Форт-системы и размеры скомпилированных задач.

Ядро Форта является чрезвычайно гибким. Для встроенных применений часть Форта, необходимая для запуска программы, может уместиться всего в 1 Кбайт. В полной инструментальной среде многозадачная Форт-система с интерпретатором, компилятором, ассемблером, редактором, операционной системой и другими утилитами поддержки занимает около 16 Кбайт. При этом остается много места для задач. (А некоторые Форты на новых процессорах имеют 32-х разрядную адресацию, что позволяет писать невообразимо большие программы.)

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

Одной из наиболее впечатляющих новых областей применения Форта является производство Форт-кристаллов, таких как Форт-микропроцессор Rockwell R65F11 [12]. На кристалле имеются не только аппаратные средства, но также исполняемая часть языка Форт и операционной системы для сложных применений. Только архитектура Форта и его компактность делают возможным создание микропроцессоров, основанных на Форте.

Разработка "с вершины"

Как приступать к разработке подобных модулей ? Методология, называемая "разработкой сверху-вниз", утверждает, что модули следует строить, начиная с самого общего, главного и далее прорабатывать до уровня самых мелких модулей.

Последователи такого подхода могут засвидетельствовать возникновение позорно огромных потерь времени в результате ошибок в планировании. На горьком опыте они познали, что попытки корректировать программу после того, как она была написана -- такая практика известна как "наложение заплат" -- подобны попытке запереть двери конюшни после того, как лошадь уже понесла.

Поэтому как контрмеру они предлагают следующее официальное правило программирования сверху-вниз:

Не писать ни строчки текста до тех пор, пока план не проработан до мельчайших деталей.

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

Сцепление

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

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

Когда данные могут быть доступны со стороны многих модулей (например, глобальные переменные), говорят о сильном сцеплении между модулями. Если программисту нужно изменить один из них, велика опасность того, что другие продемонстрируют "побочные эффекты".

Самый надежный способ сцепления данных -- это передача локальных переменных в качестве переметров от одного модуля к другому. В результате вызывающий модуль говорит подчиненному: "Я хочу, чтобы ты использовал данные, которые я загрузил в переменные с именами X и Y, а ответ от тебя я ожидаю в переменной по имени Z. Никто другой больше не использует эти переменные".

Как мы уже говорили, обычные языки, поддерживающие подпрограммы, имеют тщательно проработанные методы передачи аргументов от одного модуля к другому.

Сказание об истории элегантности программ

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

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

В даном разделе мы проследим историю инструментария и технологий, предназначенных для написания более элегантных программ.

Скорость

Несмотря на то, что Форт -- интерпретирующий язык, он исполняет скомпилированный код. Поэтому он работает примерно в десять раз быстрее, чем интерпретирующий Бейсик.

Форт оптимизирован для исполнения слов с помощью техники, известной как "шитый код" [9],[10],[11]. Плата за разбиение на модули, состоящие из очень маленьких кусочков кода, сравнительно невелика.

Он не работает так же быстро, как ассемблерный код, поскольку внутренний интерпретатор (который обрабатывает список адресов, составляющих каждое определение через двоеточие) может отнимать до 50% времени исполнения слов-примитивов, в зависимости от типа процессора.

Но для больших задач Форт очень близко подходит к скорости ассмеблера. Вот три причины:

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

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

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

Форт не гарантирует быстроту исполнения. Он лишь дает программисту творческую среду, в которой можно разрабатывать быстродействующие программы.

Структурированная разработка

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

Все соглашались, что эти издержки можно обычно отнести к неполному анализу программ или плохому замыслу разработчиков. Однако было очевидно, что что-то не так с самим структурированным программированием. Когда проекты появлялись с опозданием, некомплектными или некачественными, разработчики жаловались на то, что все предвидеть невозможно.

Ученые мужи прилагали все больше усилий к проекту. "В следующий раз мы все продумаем лучше".

К этому времени возникла новая философия, описанная в статье, названной "Структурированная разработка" [3]. Один из ее принципов приводится ниже:

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

Разбиение задачи на простые модули должно было облегчить написание, изменение и понимание программ.

Но на какой основе производить разбиение данного конкретного модуля ? Статья "Структурированная разработка" выделяет три фактора при проектирования модулей.

Удобство написания

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

На рисунке 1-4 показано, как этот тип языка позволяет переписать программу "приготовление завтрака".

Рис.1-4. Использование структурированного языка.

ИНСТРУКЦИЯ ИНСТРУКЦИЯ Решение - спешим? ЕСЛИ ДА, ТО ИНСТРУКЦИЯ ИНСТРУКЦИЯ Варка яиц ИНСТРУКЦИЯ ИНАЧЕ ИНСТРУКЦИЯ ИНСТРУКЦИЯ Приготовление овсянки ИНСТРУКЦИЯ ДАЛЬШЕ ИНСТРУКЦИЯ Мытье посуды ИНСТРУКЦИЯ

Языки структурированного программирования имеют управляющие структурные операторы типа ЕСЛИ и ТО для подчеркивания модульности в организации передачи управления. Как Вы можете заметить, отступы в тексте программы важны для ее читабельности, хотя все равно все инструкции внутри модуля написаны полностью вместо замены модуля его именем (например, "приготовление-овсянки"). Законченная программа может занимать десять страниц, с оператором ИНАЧЕ на странице пять.

Управляемость

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

Как ассемблер, так и высокоуровневый язык обеспечивают возможности для переходов и циклов. В ассемблерах мы используем команды типа "jump" ("прыжок"), в некоторых языках высокого уровня пользуемся конструкциями типа "GO TO" ("перейти к"). Когда эти возможности используются в сильной степени, программы начинают становиться похожими на такую же неразбериху, как на рисунке 1-1.

Рис.1-1. Неструктурированный код, использующий инструкции типа "jump" или "GOTO".

ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ПРОВЕРКА УСЛОВИЯ ПЕРЕХОД ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ПЕРЕХОД ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ИНСТРУКЦИЯ ПРОВЕРКА УСЛОВИЯ ПЕРЕХОД ПРОВЕРКА УСЛОВИЯ ПЕРЕХОД

Этот подход, до сих пор широко представленный в таких языках, как Фортран и Бейсик, создает трудности при написании и трудности при внесении изменений. При такой "кашеобразной" манере написания программ невозможно протестировать отдельный участок кода или найти почему выполняется что-то, что выполняться не должно.

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

Упрятывание информации

В работе [4], опубликованной еще в 1972 году, д-р Дэвид Л. Парнас показал, что критерием для разбиения на модули должны быть не шаги в процессе, а куски информации, которые, возможно, будут меняться. Модули должны использоваться для сокрытия такой информации.

Давайте рассмотрим эту важную идею об "упрятывании информации": предположим, Вы пишете Руководство по делопроизводству для своей компании. Вот его фрагмент:

Отдел продаж принимает заказ посылает синюю копию в архив оранжевую копию на склад Джей подшивает оранжевую копию в красный скоросшиватель на своем столе и производит упаковку.

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

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

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

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

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

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

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

Любой хороший программист также применит принцип упрятывания информации при разработке подпрограмм, стремясь к тому, чтобы каждый модуль знал как можно меньше о содержимом других модулей. Сегодняшние языки программирования, такие, как C, Модула-2 и Эдисон, применяют этот подход в архитектуре своих процедур.

Но Парнас проводит свою идею значительно дальше. Он предлагает распространить ее на алгоритмы и структуры данных. Упрятывание информации -- а не структура принятия решений или иерархия вызовов -- вот что должно лежать в основе проектирования !

Упрятывание конструкции структур данных

Мы уже отмечали две особенности Форта, обеспечивающие использование описанной методологии -- автоматические вызовы и автоматическую передачу данных. Третья особенность позволяет описывать структуры данных внутри компонента в терминах предварительно описанных компонентов. Эта особенность -- прямой доступ к памяти.

Предположим, что мы определяем переменную ЯБЛОКИ:

VARIABLE ЯБЛОКИ

Мы можем записать число в эту переменную для указания того, сколько яблок имеется в текущий момент:

20 ЯБЛОКИ !

Мы можем распечатать содержимое переменной:

ЯБЛОКИ ? 20 ok ~~~~~~~

Мы можем увеличить ее содержимое на единицу:

1 ЯБЛОКИ +!

(Новичок может изучить механизм работы этих фраз по .)

Слово ЯБЛОКИ имеет единственную функцию: положить на стек `адрес` в памяти, где хранится количество яблок. О количестве можно думать как о "вещи", в то время как о словах, устанавливающих количество, считывающих или увеличивающих его -- как о "действиях".

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

Мы обсуждали важность проектирования по признаку того, что может измениться. Предположим, мы написали множество кода, использующего переменную ЯБЛОКИ. И теперь, в одиннадцатом часу, обнаруживаем, что необходимо отслеживать два различных типа яблок -- красных и зеленых!

Не стоит опускать руки, лучше вспомнить функцию слова ЯБЛОКИ: давать адрес. Если нам нужно два различных количества, ЯБЛОКИ могут давать два различных адреса, в зависимости от того, о каком типе яблок мы говорим. Так мы можем определить более сложную версию слова ЯБЛОКИ, как показано ниже:

VARIABLE ЦВЕТ ( указатель на текущую переменную) VARIABLE КРАСНЫЕ ( количество красных яблок) VARIABLE ЗЕЛЕНЫЕ ( количество зеленых яблок) : КРАСНЫЙ ( тип яблок - красные) КРАСНЫЕ ЦВЕТ ! ; : ЗЕЛЕНЫЙ ( тип яблок - зеленые) ЗЕЛЕНЫЕ ЦВЕТ ! ; : ЯБЛОКИ ( -- адр текущей яблочной переменной) ЦВЕТ @ ;

Рис.1-10. Смена косвенного указателя.

+------+ | ЦВЕТ | +------+ КРАСНЫЙ | ~~~~~~~ +---------+ | +---------+ | КРАСНЫЕ |

+------+ | ЦВЕТ | +------+ ЗЕЛЕНЫЙ | ~~~~~~~ +---------+ | +---------+ | КРАСНЫЕ | ------>| ЗЕЛЕНЫЕ | +---------+ +---------+

Мы переопределили ЯБЛОКИ. Теперь они дают содержимое переменной по имени ЦВЕТ. ЦВЕТ -- указатель: либо на переменную КРАСНЫЕ, либо на переменную ЗЕЛЕНЫЕ. Последние две переменных и являются действительными хранилищами для количеств.

Если мы сначала говорим КРАСНЫЙ, то можно использовать ЯБЛОКИ по отношению к красным яблокам, если говорим ЗЕЛЕНЫЙ, то -- по отношению к зеленым (рис. 1-10).

Нам не понадобилось изменять синтаксис чего-либо в наработанном коде, использующем ЯБЛОКИ. Мы так же говорим

20 ЯБЛОКИ !

и

1 ЯБЛОКИ +!

Взгляните опять на то, что мы сделали. Мы изменили описание слова ЯБЛОКИ с описания переменной на определение через двоеточие, никак не повлияв на метод его использования. Форт позволяет нам скрыть детали того, как определено слово ЯБЛОКИ, от использующего его кода. То, что представляется "вещью" с точки зрения старых определений, в действительности является "действием" (определением через двоеточие) внутри компонента.

Форт вдохновляет на использование абстрактных типов данных, позволяя определять структуры данных в терминах компонентов нижнего уровня. Только Форт, исключающий вызовы (вида CALL) в процедурах, позволяющий передавать адреса и данные через стек и предоставляющий прямой доступ к памяти с помощью слов @ и ! может предложить такой уровень упрятывания информации.

Форт мало заботится о том, является ли что-либо структурой данных или алгоритмом. Это дает нам, программистам, невероятную свободу в создании тех частей речи, которые нам нужны для описания наших задач.

Я стараюсь думать о каждом слове, возвращающем адрес (например, ЯБЛОКИ) как о "существительном" независимо от способа, которым оно определено. Слово, производящее очевидное действие -- это "глагол".

Такие слова, как КРАСНЫЙ и ЗЕЛЕНЫЙ в нашем примере, могут быть названы только "прилагательными", поскольку они изменяют функцию слова ЯБЛОКИ. Фраза

КРАСНЫЙ ЯБЛОКИ ?

отличается от фразы

ЗЕЛЕНЫЙ ЯБЛОКИ ?

Слова Форта могут служить также наречиями и предлогами. Мало смысла в том, чтобы определить, какой частью речи является конкретное слово, поскольку Форту в любом случае все равно. Нам нужно лишь порадоваться легкости описания задачи в естественных выражениях.

Возможности

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

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

Форт может быть написан для работы под управлением любой операционной системы, такой как RT-11, CP/M или MS-DOS -- или, для тех, кто это предпочитает, Форт может быть написан как самодостаточная операционная система со своими драйверами терминала и дисков.

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

Взгляд назад, вперед и на форт

(*) - игра слов: Форт (FORTH) означает "вперед" (англ.) (здесь и далее примечания переводчика).

В этом разделе мы рассмотрим основные свойства языка Форт и сравним их со свойствами традиционных методологий.

Вот пример текста на Форте:

: ЗАВТРАК СПЕШИМ? IF ОВСЯНКА ELSE ЯЙЦА THEN МЫТЬЕ ;

Он по структуре идентичен процедуре "приготовление-завтрака" на стр.8. (Если Вы -- новичок в Форте, обратитесь к за объяснениями.)

Слова СПЕШИМ?, ОВСЯНКА, ЯЙЦА и МЫТЬЕ также заданы (что наиболее вероятно) как определения через двоеточие.

Здесь Форт демонстрирует все положительные качества, изученные нами: мнемонические обозначения, абстракцию, мощность, структурированные операторы передачи управления, сильную функциональную ограниченность, небольшую степень связности и модульность. Но, кроме модульности, подчеркнем еще то, что, быть может, является наиболее важной заслугой Форта:

Мельчайшим атомом программы на Форте является не модуль или подпрограмма или процедура, а "слово".

Далее, отсутствуют понятия подпрограмм, главных программ, утилит или операторов, вызываемых по отдельности. Все в Форте есть слова.

Перед тем, как мы изучим важность среды, основанной на словах, давайте остановимся на двух новшествах Форта, которые делают это возможным.

Запоминаемость

Первые программы для ЭВМ выглядели как-то вроде:

00110101 11010011 11011001

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

Это оказалось несколько скучноватым.

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

MOV B,A ADD C,A JNC REC1

Переводчик (транслятор) программ был назван `аcсемблером`, а новый язык -- `языком ассемблера`. Каждая инструкция "собирала" ("ассемблировала") соответствующую последовательность битов для себя при сохранении точного соотношения между ассемблерной инструкцией и машинной командой. Но ведь имена программистам запоминать легче. По этой причине новые инструкции были названы `мнемониками`.

Девять фаз цикла программирования

Как мы видели, Форт интегрирует аспекты проектирования с вопросами реализации и поддержки. В результате этого упоминание о "типичном цикле разработки" звучит примерно так же, как и упоминание о "типичном шуме".

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

`Анализ`

Установка требований и ограничений Построение концептуальной модели решения Оценка цены/графика работ/производительности

`Конструирование`

Предварительная разработка Детальная проработка Реализация

`Использование`

Оптимизация Устранение ошибок и отладка Поддержка

В этой книге мы рассматриваем первые шесть стадий цикла, делая акцент на анализе, проектировании и реализации.

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

Но Форт-программисты применяют те же самые фазы при определении каждого слова. В этом случае цикл повторяется в течение минут.

Разработка программы с таким быстрым повторением программного цикла известна как использование "итеративного подхода".

Итеративный подход

Итеративный подход был красноречиво описан Кимом Харрисом [1]. Он начинает с определения научного метода:

... бесконечный цикл открытий и улучшения. Он вначале изучает естественную систему и собирает сведения о ее поведении. Затем наблюдения моделируются для выработки теории об естественной системе. Далее инструменты анализа применяются к модели, что позволяет выдать предсказания о поведении реальной системы. Проводятся эксперименты с тем, чтобы сравнить истинное поведение с предсказанным. Природная система вновь изучается, и модель пересматривается.

`Целью` метода является выработка модели, которая в точности предсказывает все обозримое поведение естественной системы.

Анализ

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

И все же ...