Доклад

Доклад

"Критический анализ программного обеспечения ЕС ЭВМ и альтернативные пути развития".

Дата: 
01.11.1983
Текстовые представления: 
383-245 Г.С. Цейтин КРИТИЧЕСКИЙ АНАЛИЗ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЕС ЭВМ И АЛЬТЕРНАТИВНЫЕ ПУТИ РАЗВИТИЯ СПРАВКА Данный доклад включён в программу вместе с докладом Л.Д. Райкова в качестве изложения противоположной позиции. Предполагалось, что докладчики заблаговременно обменяются тезисами докладов. Тезисы этого доклада были высланы 1 ноября 1983 г. и, как было позднее подтверждено, получены Л.Д. Райковым. Тезисы доклада Л.Д. Райкова данным докладчиком получены не были, более того, программному комитету было заявлено, что Л.Д. Райков отказывается от доклада накануне дня, на который был назначен доклад. Программный комитет рассмотрел сложившееся положение и принял решение, что данный доклад должен состояться и в том случае, если Л.Д. Райков не выступит, а М.Р. Шура-Бура, представлявший позицию Л.Д.Райкова, подтвердил, что доклада не будет. Одновременно, данному докладчику было предложено ограничиться в основном чисто техническими аспектами критики. За несколько минут до 383-246 предполагавшегося начала доклада, докладчику было сообщено, что доклад Л.Д. Райкова всё же состоится и будет прочитан Г.В. Пеледовым. Перспективы развития программного обеспечения ЕС ЭВМ были изображены Г.В. Пеледовым в таком виде, будто сам НИЦЭВТ уже давно изменил свои планы в сторону исправления ошибок, отмеченных в тезисах данного доклада. Таким образом, в результате недобросовестного поведения представителей НИЦЭВТа в связи с обменом тезисами, они получили возможность представить перед слушателями свою позицию в более выгодном виде. Поскольку, в связи с рекомендацией программного комитета, фактически, произнесённый текст данного доклада не полностью отразил представленные ранее тезисы, эти тезисы прилагаются отдельно после текста доклада. Текст доклада воспроизводится по заранее подготовленному материалу с учётом изменений, произведённых экспромтом перед докладом, а также дискуссии. ТЕКСТ ДОКЛАДА Я не имел возможности предварительно ознакомиться с тезисами Г.В. Пеледова, а из доклада понял, что направление развития программного обеспечения ЕС ЭВМ несколько изменилось и пользователи будут рады получить в своё распоряжение системы с такими характеристиками, о которых говорил Г.В. Пеледов. Вызывает удовлетворение и то, что, как следует из слов Г.В. Пеледова, разработчик, наконец, отказался от точного следования за прототипом. Прежде об этом можно было только догадываться. 383-247 Иногда отмечают, что для некоторых специальных применений (использование зарубежных пакетов, экспорт) необходимо именно точное воспроизведение операционных систем прототипа. Но, во-первых, это совсем особая задача, которую не надо смешивать с созданием системы для широкого применения, и, во-вторых, в докладе Г.В. Пеледова было отмечено, что воспроизводить все операционные системы прототипа НИЦЭВТ всё равно не в состоянии. Может быть, ввиду некоторых изменений направлений развития ЕС ЭВМ, критика их программного обеспечения лишена смысла? Вероятно, всё-таки это не так, потому что многие причины, приведшие к сложившемуся положению, продолжат действовать и, кроме того, условия, в которых работает рядовой пользователь, а не тот, которому разработчик уделяет особое внимание, существенно отличаются от того, на что рассчитывает разработчик. Достаточно сказать, что значительное количество пользователей до сих пор работает на машинах ЕС-1022 и не имеет перспектив в ближайшие годы получить другие машины. Они не смогут воспользоваться теми новыми средствами, о которых говорилось в докладе Г.В. Пеледова. Критическое отношение к программному обеспечению ЕС ЭВМ весьма распространено среди его пользователей и поэтому, хотя бы для восстановления справедливости, необходимо отметить его положительные стороны. Мы их часто не замечаем, поскольку операционные системы вообще принадлежат к числу таких вещей, которые заметны лишь тогда, когда начинают мешать. Из положительных результатов необходимо, прежде всего, отметить то, что сегодня мы имеем массовую серию машин, имеется совместимость разных машин в пределах серии, и благодаря всему этому нам легко обмениваться между собой программами, а также использовать некоторые зарубежные 383-248 прикладные программы. Внедрение массовой серии машин потребовало решения практических задач большого масштаба, которые ранее у нас в стране не решались. Далее, новая операционная система научила нас ориентации, в первую очередь, на данные, а не на пропуск единичной программы, до неё мы не имели понятия файловой системы. Появился широкий спектр внешних устройств, появилась возможность обрабатывать данные относительно независимо от типа носителя, на котором они находятся, появилось представление о свободном выборе конфигурации системы путём сочетания процессора с разными наборами внешних устройств. Очень важным аспектом новой системы был переход от установки на двоичное представление информации, диктуемое сиюминутной машинной эффективностью, к установке на символьное представление, как обеспечивающее большую осмысленность и долговечность данных. На случай изменения в системе, оно используется в ассемблере и макрогенераторе, в языке управления заданиями, для внешних символов в объектном или загрузочном модуле, в утилитах и т.д. Не смотря на то, что эта полезная идея проведена в системе весьма непоследовательно и реализована несистематично и неэффективно, это то средство, без которого мы вообще не смогли бы пользоваться системой. Среди полезных особенностей операционной системы, которых мы не знали прежде, отметим также приспособляемость системы к конкретным особенностям и порядкам определённого вычислительного центра и наличие встроенных средств учёта и протоколирования работы. Э.З. Лебимский, в числе новых для нас понятий, пришедших с этой системой, называет также само понятие программного продукта. Но я согласен с этим лишь частично: наши трансляторы обладали такими чертами и до ЕС ЭВМ. 383-249 Вместе с тем, необходимо остановиться на серьёзных недостатках ОС ЕС, определяемых как недостатками её прототипа (вспомним, что его концепции зародились больше 20 лет назад), так и его несоответствием нашим условиям работы, условиям эксплуатации ЭВМ. Операционную систему нельзя считать полностью неодушевлённой, она отражает все эти условия и предпочтения, заложенные в неё при разработке. Нужно отметить также значительную громоздкость системы, не оправдываемую, на мой взгляд, её функциональными возможностями. Для программного обеспечения фирмы ИБМ, в отличие от других зарубежных фирм, характерен, так сказать, экстенсивный подход к разработке больших систем, ориентация на использование большого количества низкоквалифицированных программистов, что приводит к неоправданному дроблению системы на элементы, раздуванию их объёма, дублированию их функций и общей запутанности её структуры, увеличению затрат на взаимодействие элементов, в частности, на его документирование. Такой подход не характерен для наших программистов и неприемлем в наших условиях. Этот подход распространяется не только на построение системы, но и на её эксплуатацию. Функции различных участников процесса эксплуатации сильно разобщены, для каждого из них составлено отдельное руководство (руководство программиста для такого-то языка, руководство системного программиста, руководство оператора), предполагающее, что никто из них не знает того, что должен знать другой. В зарубежных газетных объявлениях упоминается даже такая особая специальность, как «JCL writer», т.е. составитель заданий для операционной системы на запуск конкретных программ. Вообще, руководства по эксплуатации весьма пространны, 383-250 содержат повторы и рассчитаны на низкий уровень подготовки читателя. Ясно, что в наших условиях мы не можем, подобно ИБМ, ориентироваться на применение большого количества низкоквалифицированных работников, стимулируемых лишь высокой зарплатой. Далее, оказалось, что заимствованная операционная система ориентирована на характеристики оборудования, которые в наших условиях пока не обеспечены. Речь идёт о вполне надёжном его функционировании и о доступности оборудования и материалов в достаточных количествах, сбои процессора и периферийных устройств (в первую очередь дисководов) достаточно обычное явление, а каждый такой сбой приводит к потере значительной части ранее выполненной работы. В некоторых случаях система предусматривает возможность продолжения работы, требует перехода на другой дисковод или НМЛ. Обычно таких устройств, которые можно было бы занять вместо давшего сбой, не оказывается. Но обычный результат сбоя ‒ это гибель одного задания, а нередко и всех заданий с необходимостью перезапуска всей операционной системы. Операционная система предусматривает на случай сбоя специальное средство ‒ контрольные точки и восстановление, но пользование этим средством довольно громоздко и не всегда возможно, его необходимо включать в задачу заранее. Если бы сбои были достаточно редким явлением, можно было бы специально готовить, с учётом этого средства, задачи, требующие многочасового счёта, включать же это в каждую задачу нереально. Аналогичные трудности возникают и при выборке заданий из очереди для исполнения. Задание выбирается без учёта доступности необходимых ему внешних устройств, а когда оно выбрано, система начинает требовать подключения устройств, которые в данный момент неисправны или вообще отсутствуют 383-251 (обычно при генерации системы в неё включают информацию об устройствах, которые предполагается установить в будущем), оператору в этих условиях остаётся лишь отменить несвоевременно выбранное задание с тем, чтобы позднее ввести его в систему повторно. Выдача результатов на печать в этой операционной системе ориентирована на высокое качество бумаги и безупречную работу печатающего устройства. Считается, что в устройство можно заправить фальцованную бумажную ленту, на которой, при необходимости заранее, напечатаны бланки формируемых документов, соблюдается точное положение сгиба бумаги по отношению к печатаемым строкам, есть возможность выводить некоторые короткие сообщения на отдельный лист и т.п. От всего этого на практике приходится отказываться, а операционная система, в случае технической неисправности устройства, может блокировать вывод результатов данного задания, а иногда и большие ресурсы машины. Зато, если неисправность связана с разрывом перфорации на краю бумажной ленты или обрывом бумаги в середине из-за соприкосновения с изношенной красящей ленты, вывод результатов «в никуда» продолжается, и восстановить их уже невозможно. В некоторых случаях операционную систему приходится останавливать из-за неисправности устройства, на которое записывается сбойный протокол системы. Система спасает его любой ценой, начинает выводить его на пультовую пишущую машинку (кстати, часто не выдерживающую такого объёма вывода), и работа системы начинает лимитироваться скоростью работы машинки. Отказаться от протокола невозможно, хотя в наших условиях он, в большинстве случаев, никому не нужен. Аналогичные неприятности возникают, когда погибшее задание «зависает» и система не освобождает захваченный им ресурс 383-252 (внешнее устройство или область памяти). И того, и другого обычно не хватает, держать их занятыми нет возможности и, опять-таки, приходится перезагружать систему. Бичом существующих машин ЕС стала ненадёжная работа дисководов, частые сбои, неполная взаимозаменяемость между однотипными устройствами (запись, сделанная на одном устройстве, ненадёжно читается на другом). Иногда выход дисковода из строя на длительное время ‒ одна из причин этого. Видимо, в том, что были заимствованы количественные параметры дисководов ИБМ (размеры, плотность записи, скорость вращения и т.п.) без возможности воспроизвести тот же уровень технологии, снабжения запчастями и т.п., в наших условиях имело бы смысл, не прекращая усилий, направленных на повышение качества изготовления, учесть уровень, достижимый на сегодня при массовом выпуске дисководов и пакетов дисков, и компенсировать ненадежность оборудования изменением количественных параметров (например, снижением плотности записи), а также такими средствами, как использование кодов, исправляющих ошибки (при небольших дополнительных затратах памяти они во много раз повышают надёжность). Всего этого нельзя было почерпнуть в пресловутом «прототипе». Аналогичные замечания можно отнести и к магнитным лентам, однако, их использование ограничено и поэтому их недостатки меньше отражаются на работе системы в целом. Далее, уже упоминающиеся значительный объём и громоздкость системы ‒ это не только следствие технологии её разработки, но связано и с исходной постановкой задачи. Чуть ли не по каждому вопросу система предлагает пользователю широкий выбор вариантов для достижения примерно одной и той же цели. Для хранения информации на внешних носителях предлагаются форматы F, FS, U, V, VS и другие комбинации (кстати, метод 383-253 хранения информации на магнитных дисках с членением на записи разной длины в пределах одной дорожки, является производным от методов, разработанных для более старого носителя ‒ магнитной ленты). Для работы с последовательными наборами данных предлагаются методы BSAM, QSAM с разными вариантами пересылки и буферизации. Однако же, несмотря на это разнообразие, приходится обеспечивать ещё и метод ЕХСР с непосредственным построением команд для внешнего устройства. Для запроса оперативной памяти предлагаются варианты с регистровым запросом, с запросом на одну область или на много, с указанием того или иного подпула. Для перехода задачи в ожидание некоторого условия, необходимого для продолжения работы, существуют разнотипные средства: WAIT, ENQ, STIMER, для обработки ошибок и аномальных ситуаций ‒ SPIE и STAE. Даже на уровне операционной системы в целом, помимо системы ОС, существует ещё несовместимая с ней система ДОС, предназначенная как будто бы для машин с малым объёмом оперативной памяти. На практике это приводит к тому, что в вычислительном центре, эксплуатирующем ОС, ради пропуска одной программы, написанной на ДОС, приходится останавливать всю работу, и весьма непроизводительно использовать мощную машину. Из всего этого разнообразия лишь небольшая часть отражает реальное разнообразие потребностей. В одних случаях разнообразие отражает отсутствие систематического подхода и последовательные наслоения, возникшие в процессе разработки системы, в других, ‒ неумение найти достаточно общее решение проблемы, что и приводит к тому, что на пользователя перекладывается выбор одной из предлагаемых полумер. Иногда же сама проблема, для решения которой предлагаются альтернативные варианты, является пережитком прежних машин, 383-254 имевших очень малый объём оперативной памяти и других ресурсов, а сейчас вообще не актуальна. Это относится, в первую очередь, к разнообразию форматов записи и вариантов последовательного метода доступа. Для поддержания каждой из альтернатив операционная система имеет свои особые модули. Они отражены в разных управляющих блоках системы, где соответствующую информацию приходится размещать, устанавливать и проверять даже для неиспользуемых альтернатив. Обеспечение разнообразия вариантов, в том числе и действительно необходимых, основывается обычно на построении универсальных управляющих блоков, где заранее представлены все возможности (и оставлен небольшой резерв на будущее развитие), однако, таким образом будущие потребности полностью предвидеть не удаётся. Для управляющих блоков создаются дополнительные вынесенные части, а введение новых функций сопровождается организацией дополнительных проверок и выходов в старых модулях. Следовало бы с самого начала предусмотреть более гибкую структуру управляющих блоков, а варианты функционирования в случаях, где вероятно расширение, изображать не битами, а адресами вынесенных подпрограмм. Сейчас же блок ОСВ, предусматривающий всевозможные типы периферийных устройств, нельзя стандартным образом перестроить на использование вместо периферийного устройства, моделирующей его пользовательской программы. Существенно ограничивает возможности развития системы жёсткий цикл постановки задания на исполнение через входную очередь. Из-за этого любое расширение системы, предусматривающее запуск заданий, должно вмешиваться в этот цикл, и из-за этого каждая новая возможность сопряжена с изменениями в самых основных управляющих блоках и программах 383-255 операционной системы. Сам языковой аппарат, основанный на использовании ключевых и позиционных параметров (и подпараметров) с умолчаниями, без которого пользователь вообще не смог бы воспользоваться системой, не имеет в системе систематической реализации. Естественно было бы ожидать, что система обеспечит единый механизм хотя бы для синтаксического разбора текстов с такой структурой, но его нет, и каждый блок системы производит разбор текста кустарным образом, что сильно удлиняет программы. Например, при анализе операторской команды M 130, VOL=(SL,OLIBG1), производится проверка на группу символов VOL=(SL,). Кроме того, в результате нет полного единства в синтаксисе и в написании ключевых слов между разными компонентами системы. Программа системного ввода требует указывать умолчания ключевых параметров в операторе PROG без знака & для всех ключевых параметров, а ассемблер в макроопределениях ‒ наоборот; сокращение DSN вместо DSNAME допускается на языке управления заданиями, но не для системных утилит. Свободный формат, основанный на ключевых словах, беспорядочным образом чередуется с жёстким форматом 80-байтовых «карт», разделённых на поля. Ещё один пережиток использования устарелых носителей данных и особыми (неодинаковыми в разных случаях) правилами «переноса» на следующую карту. В результате, при обращении к процедуре языка управления заданиями, ключевые параметры можно заменять в произвольном порядке, а […]-предложения ‒ только в порядке их следования в процедуре; в предложении ЕХЕС параметры, относящиеся к разным пунктам процедуры, можно заменять только в порядке следования этих пунктов, хотя запись этих замен использует свободный формат; выдача операторской команды START с очень длинным полем PARM приводит к ошибке языка 383-256 управления заданиями из-за того, что главный планировщик первоначально преобразует эту команду в задание в 80-байтовом формате (откуда это знать оператору?). Эти и подобные курьёзы хорошо знакомы тем, кто повседневно работает в ОС ЕС. Реализация многих часто встречающихся функций операционной системы довольно неэкономна. Это относится даже к таким, часто встречающимся, функциям как WEIT и GETMAIN, для которых основная часть команд SVC-программ посвящена контролю допустимости параметров (аппаратный контроль при переходе в режим супервизора частично отключается), подготовке учётной информации к рассмотрению специфических случаев. Не случайно даже реализация языка ПЛ-1, выполненная тем же разработчиком, избегает пользоваться командой GETMAIN для каждого запроса на память и создаёт собственную систему, а в SVC-программах, равно как и в стандартных рекомендациях по организации входа в реентерабельный модуль, GETMAIN широко используется даже для получения маленьких блоков памяти. Можно, кстати, заметить, что принцип статического выделения ресурсов, имевший целью, видимо, предотвращение системных тупиков, не сработал и в этом отношении. При размещении на дисках временных наборов данных, необходимых для заданий, начальное отведение памяти производится заранее (статически), но во время работы допускается захват дополнительных участков, что при общей нехватке места на дисках, может привести к неразрешимому конфликту между двумя заданиями, каждому из которых нежна дополнительная память. Вот ещё один пример. В системе с MVT возможна такая ситуация: задание не может начаться из-за отсутствия участка оперативной памяти требуемых размеров, который освободится лишь после завершения другого задания, тем не менее, некоторые имена наборов данных уже захвачены им в монопольном режиме, 383-257 из-за чего другое задание с этими именами и с меньшим запросом на память не сможет начаться. Оператор может выдать команду CANCEL для первого задания, но она будет исполнена лишь после того, как оно получит свой (большой) участок памяти. Представляются недостаточными средства защиты программ и данных, предусмотренные оборудованием и операционной системой ЕС. Большая часть средств защиты основана на неосведомлённости пользователя, которому не сообщается, например, структура загрузочного модуля, и от которого рекомендуется прятать программу IMASPZAP, корректирующую загрузочные модули, если же речь идёт о хорошо подготовленном злоумышленнике, то здесь аппаратура обеспечивает лишь один уровень защиты ‒ ключ памяти. Тот, кто сможет получить для своей программы нулевой ключ памяти, сможет любым образом нарушить функционирование системы. Например, вывести её из строя, заодно уничтожив сборный протокол, или, не создавая видимых нарушений, перенести в выдачу своей программы таблицу паролей в преобразованном для неузнаваемости виде, или же, наконец, внести желательные для себя изменения в операционную систему на будущее. Получение же нулевого ключа памяти также не является трудной задачей. В системе с MFT сведения о ключе программы, вызвавшей другую программу, хранятся в блоке PRB незащищенной области памяти и их легко там изменить. В системе с MYT такой возможности до последнего времени, как будто бы, не было (хотя достаточно было произвести незначительное изменение, скажем, в библиотеке процедур, и оператор, не зная того, вместо программы системного вывода запустил бы в привилегированном режиме совсем другую программу. В последних же изданиях системы присутствует команда MODESET, которая позволяет законным образом 383-258 произвести любое изменение режима (и это, возможно, оправдано для некоторых системных программ). В описании блока JSCB содержится «успокаивающая» информация о том, что один из его битов определяет право задания на выдачу макрокоманды MODESET никаких проверок не делает и работает независимо от этого бита. Здесь не просто отсутствие контроля, а лживая информация о его присутствии. Заметим попутно, что другие компоненты операционной системы, например, команда OPEN, затрачивают значительное время на проверку законности запроса. Впрочем, на защищённость наборов данных, в том числе библиотек самой операционной системы, нельзя полагаться и потому, что информация о защите содержится в оглавлении тома, которое можно изменить программно (как набор данных с именем [нечитаемо]). При существующей степени запутанности системы трудно рассчитывать на удовлетворительную организацию защиты. Аналогичное положение имеет место с защитой системы и данных на случай сбоя периферийных устройств или внезапного отключения питания. После перезапуска системы единственным источником информации оказываются записи на диске в системной очереди задания, однако, запись очередного изменения в эту очередь может оказаться незавершённой. Операционная система, для избегания этого, предлагает лишь функцию «обязательного завершения», которая сводится к тому, что до завершения такой записи не могут работать задания пользователей. Для того чтобы выяснить, чего операционной системе больше всего не хватало в наших условиях эксплуатации, достаточно посмотреть на то, что стали делать пользователи, получившие эту систему, не имея времени дожидаться будущих улучшений. Они сами стали разрабатывать то, что им было необходимо. 383-259 Инициатива пользователей проявилась, прежде всего, в создании каталогизированных процедур для запуска утилит с консоли оператора (утилиты воспринимают управляющие предложения из набора данных SYSIN, который нельзя модифицировать при помощи параметров процедур, и здесь потребовались всякие вспомогательные программы). Таких процедур возникло очень много. Разнобой между разными вычислительными центрами здесь огромный. В столь ясном вопросе давно можно было провести какую-то унификацию, но беда в том, что с точки зрения разработчика, всех этих процедур вообще не существует в природе, а команда START предназначена только для запуска системных задач. Другим очевидным недостатком было отсутствие средств диалогового доступа к машине, и повсюду стали разрабатываться самостоятельные системы для этой цели. Некоторые из таких разработок достигли высокого уровня развития, распространились по сотням и тысячам вычислительных центров, а по эксплуатационным качествам и приспособленности к нашим условиям превосходят введённые позднее разработчиком системы ДУВЗ и СРВ. Они тоже никем не признаны официально. Среди направлений самодеятельных разработок можно отметить также различные системы подготовки и оформления документации, средства, улучшающие контроль над распределением ресурсов (например, программа освобождения устройства, занятого «зависшей» задачей) и т.п. Следует заметить, что многие такие средства, требующие модификации операционной системы, создавались в условиях острого недостатка информации о внутренних механизмах операционной системы (с точки зрения разработчика, пользователям этого знать не положено), и приходилось иногда доставать правдами и неправдами исходные тексты программ 383-260 прототипа, а иногда самостоятельно разбирать шестнадцатеричные коды модулей операционной системы. Кое-кто самостоятельно разрабатывал дисассемблеры для восстановления текста по кодам и внесённой человеком дополнительной информации о программе. С формальной точки зрения, авторы всех этих дополнительных средств занимались не своим делом. Возможно, это был действительно не лучший вариант, но механизма, который мог бы побудить разработчика заняться этими неотложными потребностями пользователей, не было. Разработчик руководствовался собственными планами, впрочем, это не только вина разработчика. Все потребности пользователей предусмотреть централизованно невозможно, и пути для развития операционной системы по инициативе и силами пользователей должны быть предусмотрены. Сегодня же, говоря об успешных разработках, выполненных в рамках ОС ЕС, уже невозможно игнорировать роль всех этих самодеятельных инструментов. Эти разработки иногда пренебрежительно оценивают как несерьёзные, кустарные, непромышленные «подделки». В связи с этим встаёт вопрос о том, каковы существенные признаки разработки, которую можно было бы назвать промышленным программным продуктом. Говорить о том, что разработка, широко распространившаяся без внешней формальной поддержки, не удовлетворяет требованию «отчуждаемости», т.е. широкой применимости в отрыве от авторов, несерьёзно. С другой стороны, посадить за работу пятьсот программистов, поделив между ними задачу на мелкие кусочки, это тоже не промышленный подход, а, скорее, средневековая мануфактура. Настоящее совещание проходит под знаком принятых недавно решений, рассматривающих программное обеспечение как изделие производственно-технического назначения, и оставшаяся часть 383-261 моего доклада будет посвящена вопросу о характеристиках промышленного подхода к разработке программного обеспечения и о его желательной структуре. В этом вопросе часто пытаются проводить аналогии с другими видами промышленного производства, в частности, с крупносерийным производством в машиностроении. Многие склонны считать главными признаками «промышленного» подхода шаблон и обезличивание. Вот цитата из документа, разъясняющего директивы по программированию в Министерстве обороны США, которую приводит Дж. Мартин в книге «Разработка приложения без программистов». «Основная мысль, пронизывающая все эти мерs, заключается в том, чтобы превратить политику, практику, процедуры и технологию разработки программного обеспечения из артистической деятельности в подлинно инженерную дисциплину». Действительно, в США подобный формализованный подход к разработке программного обеспечения (в частности, в управленческих задачах, рассматриваемых Дж. Мартином) пустил глубокие корни и выразился в сложных процедурах предварительного составления громоздких спецификаций на требуемый продукт. И вот как оценивает Мартин его результаты: «Такие директивы препятствуют использованию новых методов, при помощи которых более гибкие организации ускорили создание своих приложений не менее, чем в 10 раз. Таким образом, стандарты, с большим трудом внедрённые во многих организациях, словно проволочные заграждения мешают росту производительности труда, на чём настаивают конечные пользователи и что обеспечивается при помощи новых методов. Нелегко отменить эти стандарты, поскольку использовать их обучено и приучено много людей». Сторонники описанного жёсткого подхода не учли, что 383-262 программное обеспечение должно обслуживать потребности конкретных работников в конкретной обстановке, и что эти потребности всё время изменяются так же, как сменяются и сами работники. Видимо, нам нет причин повторять этот неудачный путь, кроме того, массовое использование не предполагает обезличивания. Книга может быть отпечатана многотысячным тиражом, но фамилии автора с неё не стирают. Необходимо осознать специфические особенности разработки программного обеспечения, которое, в конечном счете, представляет собой накопление общественного знания в особой форме, допускающей его функционирование без участия человека. Связь его со знанием приводит к невозможности исключения из процесса его создания человека ‒ носителя этого знания, а также индивидуальных особенностей знания у этого человека, так же, как и знание вообще. Программное обеспечение может создаваться во всех сферах человеческой деятельности, и уже по этой причине будет сопротивляться попыткам жёсткой стандартизации. Противоречие между потребностями унификации и широта применения ‒ неотъемлемая черта программного обеспечения, роднящая его с языком. Говорить всем на одном языке необходимо, но никто не пытался издавать стандарты на язык, хотя стандартизация терминологии в узких областях знания вполне уместна. Феномен программного обеспечения ‒ уникальное явление даже в контексте современной научно-технической революции, и в качестве такового требует осознания с философских, социологических и экономических позиций. Отличительной чертой промышленного производства программного обеспечения, помимо уже упоминавшегося требования широкой применимости, нужно считать широкое использование заранее разработанных модулей и 383-263 инструментальных средств. Ни то, ни другое не исключает индивидуального продукта. Производство программного обеспечения существенно отличается от других видов производства тем, что основным средством производства в нем является человеческий интеллект, и соотношение между материальными и интеллектуальными затратами в нём отличается от такого соотношения в других видах производства. Неучёт этого отличия приводит ко многим ошибкам. Прежде всего, здесь, затраты на тиражирование однажды произведённого продукта ничтожны по сравнению с затратами на первичное изготовление. Что же здесь должно считаться за производство ‒ разработка первого варианта или производство копий? Что является промышленным продуктом ‒ «песня» или «пластинка», кинофильм или фильмокопия? Поддаваться аналогии с разработкой изделия в конструкторском бюро и последующим его выпуском на заводе опасно, получится, что всё производство сведено к копированию магнитных лент и документации, а это к собственно производству программного обеспечения находится примерно в таком же отношении, как упаковка продукции к её изготовлению. Видимо, надо признать, что мы имеем два разных вида продукции, к каждому из которых предъявляются свои требования. Между тем, в предусмотренной стандартами ЕСПД форме технического задания перемешаны требования, например, к программной совместимости (свойство собственно программного обеспечения) и к условиям транспортировки и упаковки (свойство носителя с копией программы). То, что при создании продукта приходится упоминать в ТЗ не относящиеся к делу требования, не способствует повышению авторитета этого документа. Мы не станем всерьёз исследовать климатические условия эксплуатации 383-264 транслятора с АЛРОЛа 68 (в отличие от транслятора с ФОРТРАНа), также, как не станем при периодической проверке качества магнитной ленты с транслятором, исследовать соответствие транслятора текущему мировому уровню достижения в технике трансляции. Ещё одна ошибка, связанная с неучётом необычного соотношения интеллектуальных и материальных затрат, проявляется в вопросе экономии машинных ресурсов. Я как-то читал в журнале статью о том, что в одной очень распространённой подпрограмме можно выбросить одну команду. Работа была выполнена очень тщательно и подкреплена экспериментами и необходимыми подсчётами. Неясно только, покроет ли вся будущая экономия от устранения этой команды затраты на подготовку этой статьи, её публикацию, чтение и последующие изменения в программах и документации. Аналогичной ошибкой порождено обилие альтернатив в операционной системе ОС ЕС. Видимо, когда-то предполагалось, что ради небольшой экономии машинного ресурса, кто-то сможет потратить время на перебор и исследование всех альтернатив и их комбинаций (не считая времени, потраченного на разработку этих альтернатив). Естественно, подобные затраты оправданы, когда предполагается большой объём вычислений по неизменным программам. Но только в этом случае. С этой же особенностью программного продукта связан вопрос, можно ли его продавать, ведь передача этого продукта кому-то другому за плату не может предотвратить его последующего бесконтрольного копирования и распространения. Другое дело, если речь идёт не о самом продукте, а об услугах по его эксплуатации. Вероятно, надо признать, что этот продукт по своей природе не подходит для продажи и вообще для того, чтобы быть предметом собственности 383-265 (производственные отношения не соответствуют особенностям этого средства производства). Возможно, оправдана аналогия со средствами массовой информации, ведь не берут с человека деньги за то, что он прослушал радиопередачу и даже записал её на магнитофон. Ещё одним типичным проявлением недооценки роли интеллектуальных затрат в производстве программного обеспечения является игнорирование свойственных современной технологии его производства, ограничений на объём создаваемого продукта («барьер сложности»). Если речь идёт о другом виде производства, например, строительстве, то никто сейчас не возьмётся, скажем, за строительство здания высотой в 10000 метров, мотивируя свой проект его крайней желательностью с точки зрения каких-либо важных целей, а в производстве программного обеспечения так поступают, берясь за разработку гигантских систем и создавая для этого огромные неуправляемые коллективы, которые, к тому же, невозможно укомплектовать работниками сколь-нибудь высокой квалификации. Нужно чётко осознать, что рекомендуемый в некоторых руководствах метод программирования «сверху вниз» неприменим в системах большого масштаба, и что для решения грандиозной задачи перевода человеческих знаний в машинную форму (хотя бы в минимально необходимом объёме) требуется иная организация систем программного обеспечения. Альтернативный путь состоит в организации системы программного обеспечения по принципу «снизу вверх», с постепенным накоплением средств всё более и более высокого уровня, с созданием новых средств на базе уже созданных. Таким способом мы можем подойти к созданию необходимых нам систем большого масштаба. В этом случае не требуется, чтобы единичное изделие имело вид большой системы, претендующей на 383-266 всеобъемлющий охват задачи и заранее предусматривающей все возможные варианты. Вместо этого целесообразно создать условия для того, чтобы в рамках единой операционной среды многие разработчики могли создавать средства для решения всё новых задач, не связывая себя жёсткими предварительными соглашениями, затрагивающими всех разработчиков сразу. При такой организации систем программного обеспечения всегда остаётся возможность модификации части компонент без сквозной переработки всего сделанного. Можно даже говорить о замене всех компонент нижнего уровня (например, при переходе на другое оборудование с сохранением надстроенных над ними компонент). В связи с этим, интересен опыт разработки и эксплуатации операционных систем типа UNIX, в которых переход на новый тип ЭВМ, без существенных изменений в накопленном запасе программ, стал реальностью. Авторы системы UNIX подчёркивают, что эта система разрабатывалась инициативно, без предварительных спецификаций и технических заданий, но в тесном контакте с пользователями (первыми пользователями были сами авторы). Сегодня эти системы широко распространились, используются в многочисленных прикладных системах, приобрели статус «неофициального стандарта» среди фирм-производителей малых ЭВМ. Знакомство со структурой и принципами UNIX′а, на первый взгляд, разочаровывает, потому что в основу положены только самые элементарные средства и возможности. При более внимательном знакомстве, однако же, обнаруживается, что в этой системе находят своё место и реализацию многие современные средства, которые непросто было бы обеспечить, скажем, в ОС ЕС. Дело в том, что за операционной системой сознательно оставлены лишь наиболее элементарные функции, не препятствующие реализации всего остального на следующих 383-267 уровнях. Из этого ясно, что в организации работ по производству программного обеспечения необходимо обеспечивать, в первую очередь, создание общесистемных средств. Сегодня, к сожалению, положение обратное. Лишь небольшое число организаций занимается этим в плановом порядке, а выделенные на это ресурсы ничтожны, в то время, как большая часть ресурсов (человеческих и материальных) отдаётся ведомственным разработкам, никак не обеспеченным средствами нижнего уровня и уже поэтому малоэффективным. Но нужно не только планировать разработки общего программного обеспечения, но и создавать условия для ведения таких разработок в инициативном порядке, потому что заранее предусмотреть все потребности невозможно. Если новая потребность уже осознана, то искать для неё «законного» исполнителя и включать эту работу в его план было бы слишком долго. Сейчас инициативные работы не предусмотрены даже системой программной документации, и для того, чтобы официально сдать уже выполненную работу, приходится задним числом составлять под неё техническое задание и придумывать в нём основания для выполнения темы. Отметим, наконец, что промышленное производство программного обеспечения предполагает создание условия для повышения производительности труда программистов. Сюда надо отнести, прежде всего, техническую и технологическую вооружённость их труда. Первая предполагает достаточное количество машинных ресурсов для каждого разработчика (а ещё во многих вычислительных центрах к программистам относятся по принципу «вас много ‒ я один»); вторая ‒ богатый запас инструментальных средств, обеспечивающих процесс разработки как отдельных, так и в составе интегрированных технологических комплексов. Необходимы, в частности, развитые 383-268 средства диалогового доступа к машине, средства подготовки и корректировки программ и данных, запуска программ на исполнение и просмотра и анализа их результатов, подготовки корректировки и оформления документации, учёта текущего состояния разработки, различных вариантов модулей и взаимных зависимостей между ними, и т.п. (интересен замысел системы APSE для языка ADA). Важной стороной дела является профессиональный отбор и профессиональная ориентация программистов. Известно, что по индивидуальной производительности труда в программировании люди могут отличаться друг от друга более, чем в 10 раз. По наблюдениям Д. Кнута, подтверждаемым и нашей университетской практикой, хорошие способности в программировании обнаруживаются у 2% людей. Этого было бы достаточно, если бы мы могли отобрать этих людей своевременно. Сейчас же, даже на программистских специальностях в ВУЗах, преобладают случайные люди. Ориентация на высококвалифицированных исполнителей не имеет ничего общего с использованием «суперпрограммистов», которые единолично берутся и за разработку, и за сопровождение, и за эксплуатацию программы. Так что, в конечном счёте, никто кроме них, не может разобраться в происходящем. Остаётся вопрос правильной организации программистского коллектива и правильного соотношения между индивидуальной и коллективной работой. Уже говорилось, что большой коллектив, в котором работа программы каждого будет жёстко зависеть от всех остальных, неэффективен. Мне трудно представить себе работающий над одной цельной разработкой коллектив, в котором непосредственной разработкой программ занято больше, чем 6-8 ведущих программистов (а вместе со всеми, кто обеспечивает вспомогательные работы, включая техническую эксплуатацию ЭВМ, 383-269 это не более нескольких десятков человек). Существующие представления о необходимом объёме и подробности документации (как внутренней, так и для пользователя), тоже, по-видимому, преувеличены. Ясно, что для многократно используемого модуля всё, что относится к его внешним сопряжениям, должно быть документировано с максимальной чёткостью, но необходимость подробных описаний его внутреннего устройства (помимо текста программы) вызывает сомнение. Если потребуется его модификация, то не лучше ли независимо разработать новый модуль по изменившимся требованиям, когда в ЭВМ выходит из строя ТЭЗ, его не разбирают для ремонта, а заменяют. Что касается документации для пользователей, то, вероятно, далеко не всегда нужны такие громоздкие тома с многочисленными повторами, как это стало считаться необходимым, по примеру документации программного обеспечения ЕС ЭВМ. Скорее, в каждом случае вопрос об объёме и стиле документации должен решаться с учётом квалификации пользователей, тиражности продукта и, наконец, его предполагаемой долговечности. Если система разрабатывается для внедрения в одном-двух экземплярах, то не лучше ли вместо того, чтобы сперва разработчикам составлять многотомные инструкции, а пользователям их штудировать, провести обучение пользователей силами разработчиков, а уже потом, на материале опыта эксплуатации, отобразить в инструкциях только самое необходимое. Такими же представляются направления развития производства программного обеспечения. 383-270 ТЕЗИСЫ ДОКЛАДА 1. В части критики программного обеспечения ЕС ЭВМ (ПО ЕС) настоящий доклад основан на личном опыте автора и многих беседах с другими пользователями ЕС ЭВМ и с системными программистами. Эти мнения могут расходиться с официальными документами разработчика ПО ЕС. 2. Настоящая критика не имеет целью перечеркнуть работу, проделанную в ходе создания ЕС ЭВМ и адаптации зарубежного программного обеспечения. В любом случае, благодаря этим работам, мы имеем теперь массовую серию ЭВМ и массовую операционную систему, и многие проблемы, связанные с широким характером производства и применения ЭВМ, были решены впервые в отечественной практике. Ряд положительных уроков можно извлечь и из собственно программного обеспечения ЕС ЭВМ. 3. Заимствование ПО ЕС производилось без учёта различий между нами и клиентурой фирмы-разработчика прототипа в стиле работы, квалификации работников и форм оплаты их труда, различий в языке, наконец, в уровне доступности и надёжности оборудования и материалов. Не учтена была также разница во времени. В 70-е годы пришлось осваивать систему, основные концепции которой зародились в начале 60-х годов, так что в ряде отношений мы сделали шаг назад. 4. Наиболее квалифицированные пользователи ПО ЕС, не найдя в нём средств для обеспечения своих потребностей, вынуждены были самостоятельно начать разработку таких средств, затратив немало усилий, которые из этих средств получили широкое распространение помимо официальных каналов разработки и распространения программного обеспечения и, хотя недостатки 383-271 такой формы очевидны, необходимо отметить, что значительная часть программных разработок, выполненных на базе ПО ЕС, основана на этих «самодеятельных» средствах. Организации, которые по характеру своей работы должны были пользоваться только официальными каналами для получения программного обеспечения, оказались в проигрыше. Сложившаяся система разработки и распространения программного обеспечения никак не поддерживает самодеятельных разработок и даже препятствует им. 5. Отмечается излишняя громоздкость операционной системы, запутанность её структуры, неоправданное обилие альтернатив и раздробленность функций между отдельными компонентами, непредсказуемость реакций, недостаточный уровень защиты. При этом, несмотря на то, что прототип системы был задуман открытым для расширения, фактически все последние усовершенствования системы выполнены в виде громоздких надстроек над существующим аппаратом и поэтому потребляют слишком много ресурсов машины. Аналогичная критика прототипа встречается и в зарубежной литературе. 6. Ряд особенностей прототипа был явно направлен на обеспечение интересов фирмы-разработчика в ущерб клиентам. Искусственно завышенные потребности в оборудовании, усиление зависимости потребителя от производителя, несовместимость с продукцией других фирм. Адаптация не устранила эти черты, более того, наши разработчики сами оказались в зависимости от разработчика прототипа и были вынуждены адаптировать всё новые и новые зарубежные версии вместо того, чтобы ориентироваться на потребности наших пользователей. 7. Распространение ПО ЕС привело к закреплению «монументального» стиля программного обеспечения, при котором создаются громоздкие системы, состоящие из многих тесно 383-271 связанных между собой элементов с узкими функциями и с множеством вариантов, якобы предусматривающих все настоящие и будущие потребности; с томами документации, рассчитанной на малоквалифицированных и безынициативных потребителей; системы, с трудом поддающиеся исправлениям и модификациям. Этот стиль, выдаваемый за единственно возможный стиль промышленной разработки и нашедший отражение также в существующих стандартах ЕСПД, стал препятствием для использования более простых и гибких форм развития программного обеспечения, во много раз сокращающих затраты. 8. Адаптация прототипа не только отвлекла значительные программистские силы, но и в значительной степени прервала отечественные традиции развития архитектуры ЭВМ и программного обеспечения. Значительный объём и громоздкость заимствованного программного продукта создали впечатление, что самостоятельные разработки никогда не смогут достичь его уровня, и внимание переключилось с поиска новых идей на развитие и модификацию заимствованной системы в рамках навязанных этой системой ограничений. 9. Моральные издержки копирования зарубежной разработки очевидны. 10. В целом, опыт создания и освоения ПО ЕС показал, что путь адаптирования зарубежной продукции неэффективен, он не экономит усилия и не решает никаких задач, более того, закрепляет наше отставание. Из зарубежной продукции можно и нужно черпать идеи и опыт, а также, возможно, отдельные программы узкоспециального характера, «гонка» за обновлением версий прототипа в условиях, когда мы уже имеем его аналог, вообще бессмысленна. 11. Сегодня, когда на базе существующего ПО ЕС выполнено большое количество разработок, уже нельзя говорить просто об 383-272 отказе от этой системы и о прекращении её развития, однако, в перспективе нужно ориентироваться не на создание дальнейших надстроек над этой системой, а на разработку новых систем программного обеспечения с самого начала. В любом случае, надо покончить с зависимостью от новых версий, приходящих из-за рубежа. 12. Определяя пути дальнейшего развития программного обеспечения, нельзя слепо копировать формы других отраслей промышленности. Нужно осознать многообразие спектра применения ЭВМ и форм развития программного обеспечения, внутренне присущее программированию противоречие между широтой применений и потребностями унификации, уникальный характер программного обеспечения, как особой формы накоплений общественного знания, сближающий его с явлениями языка и культуры. Необходимо учитывать также особенности программирования, связанные с непривычным для других отраслей промышленности соотношением материальных и интеллектуальных затрат, в частности, между первичной разработкой изделия и его тиражированием. 13. Нельзя игнорировать, присущие современным методам разработки программного обеспечения, технологические ограничения на объём и сложность создаваемого продукта или пытаться «волевыми» методами перескочить через эти ограничения путём затраты огромных ресурсов и создания огромных коллективов. Подход к решению задач большого масштаба возможен только снизу, путём последовательного накопления средств, повышающих уровень программирования. Осознание этого должно привести к резкому изменению соотношения затрат на разработку общего программного обеспечения и на создание специализированных прикладных систем в пользу первых, в частности, в пользу 383-272 технологического обеспечения программных разработок. 14. Структура системы программного обеспечения должна поддерживать работу большого количества пользователей в рамках единой концепции операционной среды, но без необходимости жёстко согласовывать между собой детали своей работы (поучителен опыт разработки и использования операционных систем UNIX). Система в целом должна быть устойчива к местным вариациям операционной среды, к замене части компонент, в том числе к переходу на новое оборудование. Она должна побуждать разработчиков к созданию модулей, пригодных к многократному использованию, в том числе в других разработках. Разработка компонент такой системы должна происходить в условиях тесного контакта разработчиков с пользователями.