§ 41. Программное обеспечение

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

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

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

Некоторые разработчики систем обработки изображений предусматривают даже подробный командный язык обработки изображений. Такой язык дает логическую основу, в рамках которой представляются меню имеющихся в наличии программ и исполняются отдельные программы. Его преимущество в том, что пользователю легче освоиться с системой, а также то, что уменьшается, число набираемых на клавиатуре символов, необходимых для прогона программы. В то же время новый командный язык также должен быть переносимым, для достижения чего требуется гораздо больше усилий, чем в случае обычных программ обработки изображений. В ФТЛ мы установили, что язык системных команд, являющийся частью операционной системы VMS на нашем компьютере VAX-11/780, более чем достаточен для наших задач, а потому для нашей системы обработки изображений специальный командный язык не разрабатывался. Одной из областей применения, где особенно эффективен набор простых команд, является интерактивное улучшение визуального качества (препарирование) изображений. Для этой цели мы предусматриваем интерактивную программу, реагирующую на простой набор команд — но эта программа является только частью обшей системы обработки изображений.

Следующий вопрос, который необходимо рассмотреть при разработке программного обеспечения, — выбор языка программирования. Такой язык должен быть широко доступен, а различия между его версиями для разных компьютеров должны быть минимальны. Несколько лет назад мы выбрали для работы Фортран, так как он казался лучшим из имевшихся в то время языков. Оригинальной версией, с которой мы работали, был Фортран 1966 ANSI (Американского национального института стандартов). Но, когда появились компиляторы для больших и мини-компьютеров, она была заменена версией Фортран-4. Заметим, что Фортран-4 является продуктом фирмы DEC и не отвечает стандартам ANSI. Сейчас мы используем Фортран-4, но, когда станут более доступны компиляторы для миникомпьютеров, мы внесем в него небольшие изменения, чтобы привести в соответствие с Фортраном-77 ANSI. Фортран — далеко не идеальный язык, но у него есть свои преимущества. Это наиболее широко используемый в научных целях язык, для которою имеются хорошо проверенные компиляторы. К тому же именно на Фортране написано много пакетов прикладных программ (например, программы обращения матриц и БПФ). Большая часть программного обеспечения

по обработке изображений связана с операциями ввода-вывода. Это — слабое место Фортрана (и других языков), в связи с чем возникают особые осложнения при обработке изображений. Наш выход из положения таков: осуществлять все операции ввода-вывода (кроме ввода текста в формате Фортрана) посредством малого числа системнозависимых подпрограмм. Последние содержат любые вызовы, которые зависят от версии компилятора Фортрана и аппаратной конфигурации. Остальное программное обеспечение разрабатывается как системнонезависимое. Перенос программного обеспечения на другой компьютер требует изменений только в системнозависимых подпрограммах. Аналогичный подход принят в большинстве других систем обработки изображений. Еще одна трудность, возникшая с Фортраном (и другими языками), заключается в том, что отдельные разработчики предусматривают в своих компиляторах дополнительные нестандартные возможности. При использовании таких компиляторов очень трудно добиться переносимости. Таких трудностей можно избежать, если пользоваться только стандартными возможностями компилятора, но для этого нужно четко представлять себе, что в компиляторе является стандартным, а что нет. Такое понимание приходит с опытом, достигаемым сравнением разных компиляторов. Последний недостаток Фортрана — его неудачная общая структура. Это особенно касается путаницы с типами выражения GOTO в зависимости от использования. Хотя в Фортране-77 сделана попытка преодолеть эту трудность, более современные языки, такие, как Паскаль и приходящий ему на смену язык Ада, гораздо лучше именно в этом отношении. Тем не менее Фортран остается наиболее широко используемым языком, и пройдет некоторое время, прежде чем его сменит какой-то новый язык. Поскольку ранее выбор был сделан в пользу Фортрана и значительная часть программного обеспечения написана именно на нем, перейти к более новому языку типа Ада не так просто. Полная переписка всего существующего программного обеспечения потребовала бы значительных и, видимо, неоправданных усилий. Единственный практически приемлемый выход — писать на вновь выбранном языке дополнительное программное обеспечение, с тем чтобы переход на новый язык осуществлялся постепенно. При этом необходимо, чтобы программы, написанные на одном языке, могли вызывать подпрограммы, написанные на другом. К сожалению, в настоящее время это предусматривается лишь на небольшом числе компьютеров, поставляемых с соответствующими компиляторами. Тем не менее ситуация исправляется. Мы принимаем этот подход и часть новых программ записываем на Паскале.

Следующий вопрос, возникающий при разработке программного

обеспечения — выбор режима обработки. Режим может быть либо диалоговым, либо пакетным. Мы пришли к выводу, что использование командных файлов (это пакетный режим) весьма эффективно при прогоне больших или повторяющихся процедур. Каждая новая процедура устанавливается копированием и редактированием стандартного командного файла или аналогичного предыдущего командного файла. Это упрощает соблюдение расписания заданий и уменьшает вероятность появления ошибки при вводе с клавиатуры, что в свою очередь уменьшает количество необходимого для функционирования системы обслуживающего персонала. Например, мы установили командные файлы так, чтобы они прогонялись в течение нескольких суток. Эти файлы обеспечивают считывание изображений в НМЛ, обработку их и последующий вывод результата на цветную пленку, делая паузу при необходимости вставить новую ленту или пленку. В случае прерывания (например, из-за отключения сетевого напряжения) командный файл запускается с того места, где произошло прерывание (после проверки регистрационного файла, созданного командным файлом). Крайне желательно иметь возможность прогонять программы как в пакетном режиме, используя командные файлы, так и в диалоговом режиме с видеотерминалом. Это вносит некоторое усложнение. Каждый параметр, считываемый программой, должен быть предельно тщательно проверен на отсутствие ошибок. В пакетном режиме в случае ошибки программа должна остановиться и выдать соответствующее сообщение. При прогоне же программ в диалоговом режиме желательно, чтобы все ошибки вызывали запрос повторного ввода данных. Мы устранили это противоречие, обеспечив остановку программ при возникновении ошибки как в пакетном, так и в диалоговом режиме. Заметим, что диалоговые программы, работающие в реальном времени (см. § 44), требуют обратной связи с пользователем и обычно не выполняются в пакетном режиме.

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

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

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

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

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

Рассмотрим теперь вопрос об использовании ЗУПВ. Наш компьютер модели VAX снабжен ОЗУ большой емкости и обычно предоставляет каждой программе в распоряжение до 4 Мбайт виртуальной памяти. Использование этой виртуальной памяти обеспечивает высокую эффективность работы программ (см. программы интерполяции между контурами, обсуждаемые в § 47). Такие программы, как правило, можно прогонять и на мини-компьютере, уменьшая соответствующим образом размерность массивов, но это весьма неэффективно. Таким образом, некоторые программы переносимы только для больших компьютеров, а в противном случае требуют изменения размерности массивов. Однако заметим, что даже в случае больших компьютеров виртуальная память не может заменить специальных алгоритмов

прямого доступа к данным НМД. Классический пример этого — большие двумерные преобразования (см. § 48). В случае оптимизованной схемы управления НМД и ОЗУ они занимают несколько минут, тогда как использование виртуальной памяти приводит к тому, что на страничный обмен (постоянную пересылку блоков данных из ОЗУ в НМД и обратно) будут уходить часы.

Обсудим теперь некоторые дополнительные трудности, специфические для прогона программ обработки изображений на компьютере. На нашем мини-компьютере модели большинство программ ограничивается рабочей скоростью устройств ввода-вывода. Это особенно относится к устройству цветной записи модели Colorwrite фирмы Optronics, которое записывает изображение на пленку с максимальной скоростью 4 строка/с. Скорость работы с этим устройством была значительно повышена буферизацией выводимых массивов строк изображения, которая устранила необходимость ожидания после каждого запроса новой строки. Благодаря этому каждая новая строка считывается с НМД, пока предыдущая выводится из буфера. Операционные системы мини-компьютеров, как правило, хуже, чем операционные системы больших компьютеров. Они часто допускают ошибки и неожиданные сбои, что делает реализацию нужных задач более затруднительной, чем ожидалось. Например, при отладке нашего программного обеспечения для прогона на мини-компьютере модели под управлением операционной системы мы столкнулись с несколькими ошибками в компиляторе Фортрана, с трудностью определения длин записей, считываемых с НМЛ, а также с другими трудностями, касающимися максимального размера корневого оверлейного сегмента для больших программ.