Аникаев Владислав Анатольевич. Вокруг и около

Вокруг и около организации обработки данных

(очерк по ходу жизни)

"Никто не обнимет необъятного"

(К. Прутков)

1 Введение

"Полезнее пройти путь жизни, чем всю вселенную"

(К. Прутков)

Данная статья не более чем подведение итогов по одному из направлений моей производственной деятельности.

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

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

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

Что ж, как сказал генсек Л. Брежнев: "Цели ясны, задачи определены -- так за работу, товарищи!"

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

2 Описание проблемы

"Пояснительные выражения объясняют темные мысли"

(К. Прутков)

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

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

В чем заключается неоднородность зафиксированной информации? - В том, что запись в файл идет "в навал". Файл структурирован только определенными квантами (сообщениями, кадрами), имеющими:

-- уникальный код начала кадра (код разметки),

-- тип структуры кадра,

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

-- длину информационной части,

-- информационную часть,

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

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

-- задание на проведение измерений,

-- результаты вторичной обработки измеренной информации,

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

-- команды управления,

-- состояние технических средств измерительной системы,

-- команды и сообщения от внешних измерительных систем и пунктов управления.

Объемы зафиксированной информации зависят от времени проведения измерений и от частоты снятия замеров и могут достигать гигобайтных размеров.

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

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

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

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

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

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

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

3 Предыстория

"Что скажут о тебе другие, коли сам о себе ничего сказать не можешь?"

(К. Прутков)

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

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

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

Разрабатывая ядро транслятора, я постепенно вникал в другие части разработки, начиная от препроцессора (макрогенератора) до генерации исполнительного кода и интерпретатора, и даже предлагая улучшения конструкций языка СИАМ.

Изначально система СИАМ была реализована на ЕС ЭВМ в дисковой ОС (ДОС). Позднее, мы ее перевели на ОС. Но основной вариант системы разрабатывался для БЭСМ-6 под руководством В. А. Короткевича, очень умного и целеустремленного специалиста.

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

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

Максимей нашел свою "золотую жилу" в местном университете. Следом за ним потянулась не хилая молодежь, в том числе ушел Короткевич, оставив мне заботы о завершении работ на БЭСМ-6, и некоторые из ушедших под руководством Максимея защитились. Приглашал он и меня под свое крылышко, но тема аспирантуры и защиты мной была закрыта раз и навсегда в 1975-м, когда по окончании МГУ на распределении я отказался от предложенной аспирантуры, выбрав распределение в Гомель.

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

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

Ну а что сталось с нами, осиротевшими "сиамскими братьями и сестрами"? Кажется, в высшем руководстве пришло понимание, что переборщили. И чтобы нас не сильно травмировать, разработку системы СИАМ дали закончить. Хотя уже тогда было очевидно, что использоваться она не будет. А со временем стало понятно, что лучшая модель программы -- сама программа, обвешанная программными имитаторами объектов контроля, оборудования и внешней среды. Завершением всех работ был выпуск программной документации для системы СИАМ на БЭСМ-6 с соблюдением всех требований стандартов. Опыта выпуска документации на Предприятии еще не было, и на нас "потренировались". В основном написание и редактирование достались мне, и наш "шедевр" в виде нескольких книг, пропущенных через машбюро, нормоконтроль и группу размножения попал на выставку в библиотеке Предприятия, где простоял не более одного дня. Видимо, какой-то доброхот, уходя к Максимею, прихватил материальное подтверждение своей преданности. А, может, было и не так: "кто украл -- один грех, у кого украли -- десять".

4 "Ходили мы походами"

"Бросая в воду камешки, смотри на круги, ими образуемые;

иначе такое бросание будет пустою забавою"

(К. Прутков)

Но завершись наши вольные труды, и руководство решило нас приобщить к заботам о хлебе насущном.

К 1980 году появилось множество бюджетных перспективных тем на однотипной вычислительной базе -- МВК Эльбрус-1 с операционной системой общего назначения (ОСПО) и языком программирования Эль-76, который хотя и был по внешним признакам языком высокого уровня (прообразом был Алгол-68), назывался "автокодом" и позволял программировать на самом низком, машинном, уровне, что было определено архитектурой МВК Эльбрус-1. С ОСПО поставлялись и традиционные трансляторы с языков Фортран, Алгол-60 и др., но нами они не были востребованы.

Работы делились на две части:

-- системы реального времени для проведения измерений и управления;

-- системы нереального времени, т. е. системы обработки информации (СОД).

Сначала нам поручили разработать СОД по одной теме, но потом работы стало прибавляться и во второй половине 80-х мы уже отвечали за пять СОД (пятую СОД притащил с собой наш варяг из Твери Борис Кошуков). Моя лаборатория на всем этом изобилии выросла до отдела, в котором трудилось более 90 программистов. Тема Кошукова, хотя и основывалась на одной вычислительной базе и в единой нами же разработанной технологии, делалась на отдаленную перспективу, не вписывалась в сроки других работ и стояла особняком, и под нее был выделен сначала сектор, а потом отдел разделили на два отдела, и часть груза ответственности с моих плеч спала.

Кроме Кошукова по направлениям были следующие ответственные исполнители:

-- Александр Кузнецов;

-- Олег Жикривецкий;

-- Юрий Постол;

-- Николай Дребенцов.

Первые трое были сориентированы на средства морского базирования, а Дребенцов разрабатывал СОД для Подмосковья.

А вот на объединяющей все работы "единой нами же разработанной технологии" остановлюсь подробнее.

Во-первых, разработчики систем реального времени сразу же отказались от ОСПО и по каждой теме были разработаны программы организации вычислительного процесса (ОВП). Всего таких программ было три. Все попытки провести унификацию и отмести "местечковые" амбиции были безрезультатны: у каждого разработчика было свое виденье архитектуры системы и свои аргументы. Так и остались в истории три ОВП для МВК Эльбрус-1: имени Семенцова-старшего, имени Деревянкина, имени Эйсымонта-Тишкова.

И нам, разрабатывая системы нереального времени для разных объектов монтажа, в целях унификации никак нельзя было подстраиваться под различные ОВП, поэтому мы решили не городить огород и доверили свои программы ОСПО, но кроме автокода Эль-76 и системы файлов низкого уровня ОСПО нас ничем не порадовало. И было зазорно каждого разработчика программ обработки заставлять индивидуально решать проблемы организации интерфейсов с оператором и данными. И мы комплексно подошли к решению задач организации обработки: конечные отдаленные сроки позволяли без спешки реализовать поставленные цели в течение трех-четырех лет одновременно с разработкой самих программ обработки, хотя доводка и совершенствование организационной части завершилась только в 1989 году, когда прошли испытания и наши СОД вместе с системами реального времени были сданы в опытную эксплуатацию.

Конечно, наши успехи по унификации СОД на основе единой технологии были на виду и подчас обрастали необоснованными легендами, и люди далекие от реального программирования подчас полагали, что в части обработки данных мы можем всё. Так однажды меня вызвал директор Предприятия В. Н. Моисеенко и предложил съездить в Москву: мол, надо помочь Генеральному директору Объединения разобраться с главными конструкторами в части совместной обработки измеренной информации на их изделиях. У меня и вопросов не было "что и как?" - подумал об очередном заказе на СОД для МВК Эльбрус-1. И приехал в Москву, и был на приеме у Генерального, и опять никаких подозрений не возникло. Но когда попал на большое сборище представителей главных конструкторов, которое было собрано специально для меня, и узнал в чем суть проблемы, то только развел руками и ретировался. Оказывается, была проблема совместной обработки измеренных данных, но не в мою тему: каждое изделие имело свою вычислительную базу и об МВК Эльбрус-1 не было и речи, но амбиции главных конструкторов - "чьи структуры измеренных данных тут "главнее?", не позволяли выйти из тупика. Но, что характерно, обнаружив мою индифферентность к проблеме, собравшиеся вдруг стали меж собой общаться, и я понял, что появилось взаимопонимание и "процесс пошел".

Так как мы дошли до такой жизни?

Во-первых, основная СОД морского базирования разрабатывалась на основе многочисленных алгоритмов от Заказчика и была по большому счету исследовательской, т.е. требовала неоднократного доступа к измеренным и уже обработанным данным. Поэтому сразу в ядро СОД закладывалась БД. Но своей СУБД на МВК Эльбрус-1 не было. Значит, надо было разработать.

Во-вторых, необходимы эффективные средства по загрузке в БД информации из файлов регистрации.

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

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

Для выполнения поставленных задач требовалось создать следующие средства:

-- диалоговый монитор по управлению СОД;

-- транслятор с языка описания структур БД (ЯОБД). Результатом трансляции должны быть созданные структуры БД в виде файлов и описателей структур;

-- СУБД, включая ввод информации в БД через диалоговый монитор. Поддержка диалогового ввода была дополнена системой протоколирования введенной информации в файл, позволяющей даже при незавершенной транзакции повторить ввод из файла. Сначала это было сделано из-за невысокой надежности опытных образцов МВК Эльбрус-1, а затем пригодилось при переносе БД на другие носители и объекты;

-- транслятор и язык формирования заданий на загрузку информации в БД из файлов регистрации по описанию загрузки (ПОФР);

-- транслятор и язык формирования заданий на обработку (язык ГРИФ). Результатом трансляции должен быть исполняемый код задания и его каталогизация в банк программ с именем задания и оперативными данными (параметрами запуска), которые при запуске задания становились доступными оператору для корректировки. Оперативные данные -- это связка пар "имя параметра - значение по умолчанию". Банк программ, конечно же, являлся служебной БД в терминах СУБД и ЯОБД и кроме каталогизированных заданий включал описание пакетов (библиотек) модулей обработки с их входными и выходными данными. Промежуточным результатом трансляции был текст на автокоде Эль-76, что позволило анализировать результат трансляции при отладке транслятора. Вариантом языка ГРИФ было описание пакетов программ (модулей обработки) с входными и выходными данными для их каталогизации в банк программ. Сами программы писались на автокоде как процедуры по определенным правилам для спецификации входных и выходных данных.

Во всех этих средствах просматривалось создание трех трансляторов с трех языков. Тут пригодился еще свежий опыт разработки СИАМа, где устоялся и был опробован "доморощенный" метод трансляции. Чтобы не разрабатывать три различных транслятора независимо, взяв за основу наработанный метод, мы создали систему построения трансляторов MetaL. Исполнителем был Виктор Дзюба, который подошел к работе творчески и даже реализовал идею самораскрутки MetaL'а, когда "вручную" было запрограммировано ядро системы, включающее метод трансляции, а сам транслятор с языка MetaL, на котором описываются языки программирования (в нашем случае ЯОБД, ПОФР и ГРИФ), был описан в терминах входного языка.

Любой транслятор на языке MetaL описывался набором пар "синтаксическая конструкция и номер семантической программы, ее обрабатывающей". Синтаксис описывался в Бэкусовой нормальной форме (БНФ -- не путайте с белорусским народным фронтом), семантические программы писались на Эль-76 и подключались при разборе синтаксической конструкции. Семантические программы отвечали за генерацию результата трансляции (для ЯОБД -- создание файлов БД, для ПОФР -- создание заданий на чтение файлов регистрации и загрузку информации в БД, для ГРИФ -- каталогизация пакетов программ и создание заданий на обработку), а в тех редких случаях, когда метод трансляции не позволял различить контекст использования синтаксической конструкции (метод позволял заглядывать вперед только на один шаг, что достаточно для большого множества контекстно-зависимых языков), то на семантику возлагалась функция определения контекста использования конструкции.

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

А моя приверженность теории и практике языков программирования на том не иссякла. Я еще долго и ревностно отслеживал новости по этой тематике. Писал статьи, выступал с докладами и сообщениями на ежегодных конференциях Предприятия и Объединения и даже написал обзор "Язык АДА и современные тенденции в языках программирования".

Конечно, без такого блестящего программиста, как Костя Бусел, наши успехи выглядели бы скромнее. Разработка СУБД для МВК Эльбрус-1 -- это его детище. Я часто невольно сравнивал Бусела и Дзюбу и даже для себя не мог решить: кто из них сильнее и полезнее в наших работах? Победила, конечно, дружба и взаимопонимание.

Банк данных был представлен тремя уровнями:

-- 1-й уровень - файлы регистрации, которые в общем случае не являются файлами ОСПО;

-- 2-й -- так называемые простые (неизменяемые) файлы, являющиеся результатом работы загрузчиков ПОФР из файлов регистрации и привязанные к дате и времени цикла измерений. Каждый простой файл -- результат сортировки по типу кадра из файла регистрации, состоял из однородных записей и являлся файлом ОСПО;

-- 3-й формируется программами обработки на основе информации простых файлов и ранее сформированных данных и также представлен файлами ОСПО.

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

Кроме того СУБД поддерживала

-- систему индексных файлов, предназначенных для сортировки и быстрого доступа к информации;

-- систему транзакций для внесения согласованных изменений в БД;

-- систему автоматического восстановления по последней копии БД и накопленным изменениям со времени снятия последней копии.

Создание и модификация структур файлов БД выполнялась транслятором ЯОБД.

При реализации СУБД максимально использовались возможности файлов ОСПО, что отчасти упростило реализацию, но это была настоящая БД, причем с поддержкой системы 1-го и 2-го уровней, более того, это была специализированная БД для обработки результатов измерений. Для МВК Эльбрус-1 это была первая и единственная реализация СУБД. И хотя к 90-м всё было закончено и сдано в "утиль", Константин с новыми идеями уже за пределами Предприятия на ПЭВМ (PC) реализовал свое виденье БД и обработки информации. В 90-х его система была популярна у многих программистов в городе и окрестностях, пока ей на смену не пришли Clipper, FoxPro, а затем и Delphi с графическими интерфейсами.

Средства по работе с БД были включены в диалоговый монитор, интерфейс которого использовал примитивы доступа к СУБД, аналогичные программному уровню. Но народное творчество не остановить, и Олег Жикривецкий развил интерфейс до подобия предложениям SQL, причем такой интерфейс стал доступен и в диалоге, и в программах. Наработка была востребована в наших СОД, а Олег впоследствии создал свою концепцию БД, и, насколько я в курсе, до сих пор в Москве поддерживает реализацию своих идей.

Возможно, что разработка транслятора с языка ГРИФ затянулась, и, когда транслятор был готов, то кое-кто из ведущих разработчиков уже успел часть заданий на обработку запрограммировать на Эль-76 и затем уже не смог перестроиться и воспринять предложенные концепции языка. У этих разработчиков не было времени переписывать программы, а у меня не было времени бороться с "оппозицией" и настаивать на своем, важно было, чтобы новые концепции были проверены в каких-либо реализациях, и такая проверка состоялась.

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

Я, в принципе, был в курсе всех подробностей разработанной организации обработки и неоднократно в условиях командировки в отсутствие основных разработчиков выправлял их коды на Эль-76, но алгоритм, который придумал Игорь для упорядочивания узлов обработки по входным и выходным данным, я воспроизвести и сейчас не могу. Игорь говорил, что это просто, но у меня всегда не хватало времени найти решение для мной же предложенной постановки задачи.

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

Подобная организация была использована для разработки типовых заданий (ТЗ) обработки, а базовые элементы, используемые в ТЗ, оформлялись в виде пакетов программ, которые тоже специфицировались на языке ГРИФ. Концепция пакетов была заимствована из языка АДА и, если следовать нынешней терминологии, была близка понятию "класс", поскольку кроме процедур-функций (методов класса, описание которых в нашем случае вместе с входными данными дополнялось спецификацией выходных данных, как значения вычисляемого функцией) могла включать статические (рекурсивные) локальные данные (т. е. были приватные данные, но не было public). Процедурный доступ к локальным данным носил название "инкапсуляция данных". В этой терминологии можно считать, что СУБД -- пакет, в котором инкапсулированы БД.

Описание ТЗ на языке ГРИФ включало следующие разделы:

-- АРГУМ -- описание оперативных данных в виде пар "имя параметра = значение по умолчанию";

-- ГЛОБ -- описание переменных для хранения промежуточных результатов;

-- БД -- описание подсхемы БД, используемой в ТЗ;

-- ВЫБОР -- описание выборок данных по связям и индексам. Определялись имена массивов с входной информацией ТЗ;

-- ВЫВОД -- описание форм выводимых таблиц и графиков;

-- ПАКЕТЫ -- описание имен используемых пакетов;

-- ГРАФ -- описание информационно-функционального графа (основной раздел, давший название языку) обработки потоков данных. Раздел состоит из перечня узлов обработки (вызовов процедур пакетов) и информационных потоков между ними и, как было сказано выше, в этом разделе разрешались циклы и условные операторы. Алгоритм, который придумал Ярошенко, позволял определить корректность данного графа до его исполнения, и определить последовательность и распараллеливание вычислений узлов обработки;

-- ОТЛ -- описание контрольных точек (имен узлов обработки), в которых оператор может проанализировать промежуточные вычисления.

В составе нашей небольшой, но мощной команды, разрабатывающей программы организации обработки, обязательно нужно упомянуть Валентину Никитко, которая будто бы незаметно, но самоотверженно справлялась с заданием любой сложности. Сейчас и не вспомню, был ли у нее свой ответственный участок. Может, транслятор ЯОБД? Или диалоговый монитор? Такое впечатление, что она помогала всем и была везде. И не могу сказать, что она была "на подхвате". Нет, она была везде востребована. Она уставала и подчас блажила, обращалась ко мне: "Найди ошибочку в программе". И куда деваться, я быстро находил, и она опять продолжала свою самоотверженную работу.

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

-- неявное приведение типов. На МВК Эльбрус с его тегированной памятью требовалась определенная дисциплина программирования, особенно при программировании системных задач;

-- использование указателей и неинициализированных или альтернативных данных. Близко к этой проблеме использование объединенных типов (UNION);

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

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

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

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

Но окончены труды, и жаль, что они не нашли продолжения и просто "сгорели" в горниле Истории. Но фраза, оброненная классиком, "Рукописи не горят" заставляет верить, что не всё было напрасно.

В те "застойные" времена наше руководство большое внимание уделяло повышению квалификации программистов. Кого-то удавалось послать на специальные курсы, а в отделах проводились регулярные и обязательные занятия по техническому обучению (хотя, каюсь, ни мне, ни моим сотрудникам такая "обязаловка" не нравилась: актуальные темы занятий быстро исчерпывались и приходилось обращаться к скучной абстракции). А по инициативе главного инженера Анатолия Ивановича Мартьянова и его зама по науке Бориса Александровича Балаша было создано учебное пособие "Введение в программирование или что должен знать каждый программист". Затем главный инженер устраивал экзамены на знание этого минимума и терминологии в нем принятой для каждого молодого специалиста, тем самым поднимая общий профессиональный уровень на Предприятии. Да, были на Предприятии мудрые руководители, которые пеклись не только о делах текущих, но и планировали светлое будущее. Как жаль, что нынче уже ни у кого не появится мысль повторить то, что непререкаемо говорил Б.А. Балаш: "Мы - фирма номер один в Державе". А Мартьянов? Когда я, подчас человек вздорный и любитель попререкаться, на следующий день после каких-то эмоций, пришел к Анатолию Ивановичу с покаянием, то он дружелюбно меня урезонил: "Старик! Это совсем последнее дело помнить зло на своих подчиненных". - Он да еще мой непосредственный руководитель, начальник НИО Эдуард Валентинович Кондаков, военнослужащие, прикомандированные к Предприятию, безусловно были людьми чести и достоинства.

Почему я отвлекся от своего повествования? - Потому, что разработка пособия была поручена мне, в ту пору председателю Совета молодых ученых и специалистов. И после согласования с руководством плана-проспекта пособия я распределил написание глав пособия среди членов Совета, и, когда всё было исполнено, долго и нудно приводил тексты к единому стилю и терминологии.

А чуть позднее, когда состоялась наша система организации обработки, по результатам технической учебы я обязал своих ведущих специалистов написать "выпускные" рефераты, которые с учетом предыдущего опыта я отредактировал. В результате в 1986 году появилось учебное пособие "Основные принципы разработки систем обработки данных на МВК Эльбрус". У меня случайно сохранился экземпляр этого пособия. Я нынче уже позабывал какие-то особенности в нашей СОД, и пришлось к этому пособию обратиться, чтобы систематизировать свое повествование. Пособие кривыми АЦПУ-шными строками было распечатано в рамочках для технической документации. Для форматирования и печати был использован документатор, разработанный в нашем отделе, -- DOCER. Позднее для АЦПУ появились более продвинутые документаторы (КЛЕРК Соколовского?), но наш был первым. То, что у меня сохранился "авторский" экземпляр пособия, я обязан помощнику нашего начальника НИО Николаю Александровичу Ермоленко, заведующему хозяйством и канцелярией. Когда я ему заказал размножить пособие для обучения сотрудников, он принес этот незапланированный экземпляр в твердом красном переплете, явно стараясь сделать мне приятное и поощрить мои труды. Я тогда не придал значения его инициативе и отложил пособие в долгий ящик. А вот ведь пригодилось, и Николая Александровича добрым словом поминаю.

Уже в средине 80-х начались поиски объединения двухуровневой технологии разработки заданий на обработку (модули программировались на Эль-76, а сами задания - на языке ГРИФ) в единую технологию. Так появился проект языка ЮС, в который были заложены апробированные конструкции языка ГРИФ, операторы языка АДА для программирования модулей обработки и рекомендации Юрия Постола, опытного практика по написанию и использованию программ обработки данных, который указал на самое "узкое" место -- выборку информации на обработку по множеству условий.

Сначала проект ЮС отложили до завершения сдаточных работ по разработанным СОД, которые прошли в 1989 году, а потом Перестройка, после которой не осталось камня на камне, завершила все труды. И была "вольному воля" до 2003 года, когда снова пришлось "засучить рукава". Хотя и на "воле" было не так уж вольно.

5 "Сто лет одиночества"

"Смотри в даль -- увидишь даль; смотри в небо -- увидишь небо;

взглянув в маленькое зеркальце, увидишь только себя"

(К. Прутков)

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

На смену МВК "Эльбрус", ОСПО и Автокоду Эль-76 пришли компьютеры с архитектурой INTEL и новые Эльбрусы (90С), операционные системы на ядрах Linux, язык программирования С++, СУБД PostgreSQL. Но у меня уже не было той команды программистов из 80-х, да и новых помощников я так и не дождался.

Хотя командовать и раздавать задачи своим несуществующим помощникам не пришлось, но живого человеческого общения было более чем достаточно. И желание своими руками реализовать свои идеи казалось достижимым. Только не всем нравилась такая самостоятельность: "У всякого портного свой взгляд на искусство" (К. Прутков). И по существу, в одиночку разрабатывая разные программные приложения (в разное время, на разных средствах), мне не удалось составить конкуренцию коллективам разработчиков, которые легко тиражировали свои немудреные наработки, захватывая потенциальный рынок. Так и получилось, что мои идеи оказались любительщиной и романтикой. Как-то мой старший товарищ, алгоритмист и философ по совместительству, Дмитрий Мазурин, меня спросил: "Чем отличается любитель от профессионала?", и сам же ответил: "Профессионал тиражирует свой опыт, навыки, свои проекты, а любитель всё делает в одном экземпляре, но так, что никто этого повторить не может". Вот так! Большой мастер этот "любитель" - это умелец Левша, который подковал блоху, что после этого она перестала прыгать...

И неоднократно были на нас программистов вот такие нападки: "Что вы тут программируете! Поучились бы у моего сына пятиклассника! Он такую программу написал!" - Ну, всё, приехали: еще одной блохе кердык...

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

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

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

Когда в 2003-м по предложению и настоянию моего друга Николая Назарова я вернулся на Предприятие, то при встрече Б. А. Балаш совершенно искренне сказал, что рад моему возвращению. И мне ответно тоже хотелось сказать что-то приятное и достойное: "Да, неважно чем приходится заниматься по жизни: главное, чтобы...", но я застрял на полуфразе подбирая слова, а он быстро нашелся: "... чтобы было интересно!" Я не стал перефразировать: пусть будет так, хотя в тот момент именно мой "хребет" хотел рапортовать о моем открытии: "Главное, чтобы везде было человеческое общение".

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

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

И всё же были исключения.

Лирическое исключение

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

Выше я уже упоминал, что работал главным алгоритмистом-программистом на крупном машиностроительном предприятии в управлении АСУП. Эта работа заняла последние пять с половиной лет из двенадцати. Когда я совершенно случайно был принят на должность заместителя начальника управления АСУП по программированию, то не представлял, что меня ожидает. Но меня, человека "с улицы", встретили доброжелательно. До сих пор я благодарен и поддерживаю дружественные отношения с теми, кто во мне увидел надежду на изменение сложившейся технологии учета производства, с теми, кто меня консультировал, вдохновлял и до конца верил, что я одолею решение самой актуальной задачи: перепись программ ежедневного учета производства ("оперативки") со старушки БЭСМ-6 на ПЭВМ. И, прежде всего, добрым словом помяну Зинаиду Григорьевну Чистову и Николая Александровича Фещенко.

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

Но пока я вникал в новую проблематику, кому-то надо было поддерживать существующие программы "оперативки" на БЭСМ-6, каждый день выдающие на АЦПУ десятки килограмм документации. В ежедневном учете, в непрерывном производстве непреложен основной закон сопровождения программного обеспечения: "Используемая программа должна регулярно модернизироваться". Это где-то, в сложных программных системах, с институтами заказчика, с подразделениями приемки, с госстандартами, испытаниями по каждому изменению и перевыпуском документации могут пройти годы, пока изменение будет внедрено в работающую программу. А в производстве принес тебе цеховик свою неграмотную служебную записку и будь добр исправь ему вчерашнюю отчетность, и исправляли, и никаких испытаний и актов, никаких перевыпусков документации, только программист сделает от руки пометку в своих истрепанных распечатках, - и так почти каждый день. И, конечно, в оперативном учете такие изменения были востребованы. И этот фронт работ прикрыла Ида Александровна Вавилова, которая почти одновременно с моим приемом на работу вернулась из декретного отпуска, и ее незабытые навыки программирования на БЭСМ-6 прикрыли вопросы сопровождения старых программ. И если бы я не изучил эти "старые" программы, то, наверно, до сих пор терзался бы вопросом: "А не могла ли сама Ида переписать оперативный учет?" - Могла, но это был бы не тот результат, которого я достиг и который в самом лучшем виде передал ей же на сопровождение. И хорошо, что я не дал ей такое задание. Я жалел наших девчат, и подспудно чувствовал, что если их перегружу работой, то что-нибудь может сломаться в нашей размеренной жизни.

Когда-то БЭСМ-6 была моей любимой машиной: в университете курсовую и дипломную работы на ней выполнял, и самая главная версия СИАМа на ней была реализована. Но пришли другие времена: на дворе начался 21-й век, а наша старушка, кряхтя и со скрипом, готовая в любой момент совсем развалиться, выполняла огромную работу по ежедневному учету поступления и потребности, изготовления и сборки деталей и узлов по всем цехам и службам огромного производственного объединения, в котором трудилось около 20 тысяч человек, а количество деталей и узлов в БД БЭСМ-6 исчислялось сотнями тысяч. Приход и отгрузка деталей и узлов в цехах вводились через видавшие виды терминалы, что само по себе могло бы и не быть головной болью для руководства АСУП, но телефонные линии, порой не позволявшие дозвониться из цеха в цех (например, дожди прошли), нельзя было назвать надежной и достоверной связью. Поэтому представители цехов постоянно приходили в АСУП для сверки своих накладных, что, в конце концов, от удаленного ввода отказались, а в АСУП стали приносить копии всех накладных по приходу и отгрузке. И здесь я выполнил самую простую часть работы: написал на FoxPro для наших операторов многотерминальный ввод накладных.

В АСУПе еще до меня базовой системой программирования для ПЭВМ был взят FoxPro, и мне знакомому с системой Clipper, которая, как и FoxPro, базировалась на концепции DBASE-III, было не трудно ее освоить. Но еще раньше, по приему на работу, я написал универсальную программу по переносу БД с БЭСМ-6 на ПЭВМ (на FoxPro) и обратно, имея в виду, что отказ от БЭСМ-6 произойдет не сразу. Так и случилось. Наши операторы по-прежнему выходили в ночные и воскресные смены, чтобы к утренней оперативке обеспечить все цеха и службы килограммами бумажных АЦПУ-сводок предыдущего дня. На оперативки обязательно вытаскивали представителя АСУП: доставалось нотаций и матов не только производственникам, но и учетчикам. А было за что: за нее, старушку БЭСМ-6. В конце концов, наши технари нашли на стороне умельцев, сделавших для ПЭВМ полный эмулятор системы команд БЭСМ-6. И купля-продажа состоялась. И хотя по-прежнему медленно выполнялись расчеты, и не отменялись ночные смены, но была снята головная боль от обслуживания отслужившей БЭСМ-6. А для меня появилось время, не торопясь, в параллель с решением текущих задач, заняться главным: переводом программ оперативного учета производства на ПЭВМ, так как даже эмулятор не снимал проблему сопровождения этих программ и включение их вместе с БД в единую с другими подсистемами систему предприятия.

По пути к этой главной цели пришлось разработать и переписать на FoxPro ряд других программ, многие из которых теперь и не вспомнить, но программа подведения результатов инвентаризации цеховых остатков производства была важным этапом в продвижении к главной цели. Специально созданные и независимые комиссии подсчитывали остатки остановленного производства по заготовительным, обработочным, сборочным цехам вплоть до цеха главного конвейера, который стоял в конце производственного процесса и сдавал собранную технику на склад готовой продукции. Все эти остатки вводились в программу инвентаризации и сравнивались с цифрами оперативного учета. Казалось, всё очень просто, но при выяснении, какие детали спрятались в узлах (алгоритм разузловки хотя и рекурсивен, но достаточно прост), появлялся фактор неопределенности, связанный с отступлениями от конструкторской документации и с заменой одних деталей на другие. Попытки навести порядок в этих заменах были, но каждый раз находились противники превращения в систему таких "разовых" замен. А сводки по инвентаризации, которые выдавала моя программа, из-за замен и подмен многим не нравились, но к старой программе на БЭСМ-6 уже боялись обращаться, так как считалась она сутками (а моя несколько часов) и, конечно, тоже не могла обойти существующую проблему замен.

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

И, наконец, когда уже многие не верили, что я перепишу оперативный учет, после определенного подготовительного этапа буквально за две недели сосредоточенной работы я эту проблему решил. И если все предыдущие задачи я решал, не заглядывая в тексты программ, реализованных на БЭСМ-6, то здесь мне пришлось основательно проштудировать исходники, а это был КОБОЛ. И, кстати, я, наверно, зря пренебрег изучением исходников по инвентаризации на БЭСМ-6, наверняка там проблема замен как-то решалась, но к этому вопросу я уже не успел вернуться.

У меня не было цели, что-то поменять, улучшить в самом производстве. Заведомо понятно, что устоявшуюся годами систему из людей и технологий невозможно изменить, и любая попытка встретит противодействие. С советских времен организация и учет производства основывались на так называемом Новочеркасском методе, который изначально был предназначен для непрерывного производства, но постепенно был адаптирован для мелкосерийного производства, что, конечно, нашло отражение в программах учета. Главным недостатком такой системы является требование выполнения заказа: любой ценой вытолкнуть изделие на склад готовой продукции. Любые внеплановые издержки и брак производства, поддержание неприкосновенного и резервного запаса требовали поступления новых материалов и комплектующих, причем сразу по поступлению терялась их принадлежность какому-то заказу, т.е. они становилось "народным" достоянием. Наверно, с развитием организации производства изначально первичные ресурсы и сборочные единицы можно будет приписать к конкретному заказу и ответственному исполнителю, а в лучшем случае объединить подсистему оперативного учета производства с другими подсистемами (например, с бухучетом и зарплатой). Но на этом этапе никто из потребителей информации не должен заметить замены программ.

Язык КОБОЛ мне не был знаком, и реализация его на БЭСМ-6 имела свои особенности, но для меня, "языковеда", изучение этого "древнего" языка было приятным занятием, тем более, что девчата-программисты всегда были рады оказать помощь. По мере изучения языка я, уже постигнув организацию машиностроительного производства, вникал с тихим ужасом в сами программы оперативного учета. Как мне сказали, их спроектировал какой-то НИИ, но отдельные модули писались в разное время разными программистами. Можно было тупо, в лоб, перекомпилировать каждый модуль на FoxPro, но объем работ мне казался неподъемным, а когда я тщательно изучил, что же в этих программах происходит, то вдруг понял, что большинство этих модулей выполняют одни и те же операции, но с минимальными нюансами. Вот тут-то и открылись преимущества одиночного программирования: пришло время систематизации. Итак, мухи отдельно, котлеты отдельно: выделяем системную часть с добавлением интерактивных функций для оператора (на БЭСМ-6 была только пакетная обработка), и все остальное выносим в отдельный модуль под названием "производственные операции" (с параметрами: тип операции и перечень таблиц БД, участвующих в операции). И, как я говорил, на реализацию затрачено было две недели. В какой-то момент, когда я еще выверял свои коды, я предложил часть технической работы по программированию отчетных форм выполнить Виктору Ивановичу с использованием моей системы документирования. Я на него не очень-то рассчитывал как на помощника, хотя он был человеком изрядного ума, кандидатом технических наук и доцентом, оказавшимся у нас по своей слабохарактерности, но тут он меня удивил и действительно помог. Он не только оперативно разработал порученные программы, вникнув в суть проблемы, но и, когда мы сдали систему в эксплуатацию, очень грамотно консультировал цеховиков по непонятным или неточным вычислениям. С тех пор я его зауважал, и до его последних дней мы были в дружеских отношениях. Мой сотовый телефон, иногда неудачно положенный в сумку, отключается, и, когда я его опять включаю, то восстанавливается старинная дата и появляется сообщение: "Вам звонил абонент Виктор Иванович", но сотовый оператор быстро восстанавливает текущую дату и наваждение исчезает. Но спасибо за напоминание. Вечная память!

Моя "оперативка" пошла в работу практически сразу. Может, кому-то показалось, что переписать ее было просто. Может, и так: глаза боялись, а руки делали. Но этой работой я не только закрыл вопрос со старыми программами, но вывел программистов АСУП на новые рубежи: на развитие сетевых технологий и графических интерфейсов. А меня сразу же по окончании этих работ пригласили вернуться на Предприятие (отнюдь не из-за каких-то мнимых успехов, а просто время пришло). Руководство завода (наверно, с подачи З. Г. Чистовой) пыталось уговорить меня остаться (хотя это делалось не очень настойчиво: понятно, что я для них был не основной специалист, не машиностроитель, а что-то вроде бы полезное, но второстепенное, типа уборщицы), но на душе у меня были опустошенность и умиротворение после проделанной работы, и хотелось что-то изменить и измениться.

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

И вот новая программа экспресс-обработки информации. Саму систему реального времени и сбор информации по объектам контроля с управлением техническими средствами блестяще реализовал мой друг и руководитель Николай Павлович Назаров..

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

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

Преобразование сводилось:

-- к покадровому чтению файла регистрации;

-- отбору тех типов кадров, которые интересны для последующей обработки;

-- наложению на прочитанный кадр его структуры, взятой из программ реального времени (т. е. той структуры, в которой кадр регистрировался);

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

Полученный выходной файл вместе с файлами описателей по существу являлся примитивной (вторым уровнем после файла регистрации) БД, для которой были предоставлены следующие средства доступа и обработки:

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

-- таблица - выборка по типу кадра информации для просмотра/печати таблиц (по условию или безусловно);

-- рисунок - выборка по типу кадра информации для просмотра/печати графиков (по условию или безусловно, причем один из целочисленных параметров мог объявляться селектором, например, номером объекта, а также в описании графиков можно было задавать дополнительные условия -- и селекторы, и дополнительные условия могли использоваться оператором при анализе информации в графическом виде);

-- процедура - выборка по типу кадра информации (по условию или безусловно) для передачи в цепочку пошаговой обработки. Этим средством предполагалось покрыть возможности языка ГРИФ (раздел ГРАФ) в тех случаях, когда требовалось оперативно заменить один шаг на другой (например, опробовать разные алгоритмы первичной обработки информации);

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

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

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

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

-- текстовое наименование колонки;

-- идентификатор параметра из файла описания состава кадра;

-- расположение (справа, слева, по центру) и формат значения параметра в колонке;

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

Аналогично описывалась форма "из кадра".

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

-- текстовым наименованием графика;

-- идентификатором параметра абсциссы из файла описания состава кадра;

-- идентификатором параметра ординаты из файла описания состава кадра;

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

В процедурах описание было представлено:

-- текстовым наименование процедуры;

-- идентификаторами выбираемых параметров с номерами их преобразований;

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

И всё же недостатки такого подхода очевидны:

-- любое изменение структуры кадра в файле регистрации требует изменения программы формирования выходного текстового файла, перетрансляции и линковки. Эти изменения касаются только библиотеки преобразования (БИБПР) конкретного параметра кадра в стандартное (в данном случае текстовое) представление. БИБПР присутствует в любой системе обработки, была и на МВК Эльбрус-1 в программе ПОФР, была и в моей программе преобразования БД БЭСМ-6 в БД FoxPro. Не буду утверждать, что нет общего алгоритма чтения любого параметра из кадра и преобразования его к стандартному виду, но этой утопии всегда предпочитали конкретное преобразование "в лоб" каждого параметра кадра (хотя бы из соображений эффективности), тем более, что в работающей системе структура кадра наиболее консервативна, как лежащая в основании системы (хотя дурная инициатива в своем стремлении от хорошего к лучшему считает, что именно она, если не пуп вселенной, то основание системы -- обязательно). Кстати, на Предприятии однажды погнали "высокую" волну о решении проблемы преобразования структуры кадра, описанного на языке Си++ в структуру БД. Но оказалось, что реализуемость таких описаний возможна только на ограниченном множестве кадров (и, конечно, были умышленно забыты "внешние" кадры, которые подчас никакой систематизации не доступны) да и то с жесткими требованиями по оформлению текста описания. Т. е. все свелось к описанию загрузки на подмножестве языка Си++. Так не лучше ли и менее накладно использовать специальные программы типа ПОФР?

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

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

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

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

-- в условия выборки можно было ввести параметры и использовать их как оперативные данные на МВК Эльбрус-1 -- это лишний раз избавило бы от корректировки текстовых форм.

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

Но пришли другие времена, и в следующей системе я модернизировал вышеописанный подход.

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

-- номер кадра;

-- адрес кадра в файле регистрации.

Выборка по номеру кадра теперь делалась по "короткому" индексному файлу, хотя при его отсутствии -- непосредственно по файлу регистрации. В принципе отличия от предыдущего подхода не было, но пропало описание кадра, которое соответствовало текстовому представлению. И меня все-таки одолевали сомнения: одновременно приходилось общаться с двумя файлами, основным и индексным, и хотя казалось, что перебор по "короткому" файлу должен оптимизировать выбор данных, реально я этого не проверял. Конечно, с учетом того, что обработка в основном проходит по одному типу кадра, можно было оптимизацию довести по совершенства, и по каждому типу кадра завести свой индексный файл. Эта идея витала еще в текстовом подходе, где кадры разных типов можно было разложить по разным файлам (так мы и делали на МВК Эльбрус-1), но это усложняло обработку по совокупности кадров. Однако, при работе непосредственно по файлу регистрации при сохранении возможности совместной обработки разных типов кадров, индексы по каждому типу кадра выглядят привлекательно.

Чем удалось заменить описание кадров: как выбрать значения из полей по их именам по обращению к ним из описаний форм вывода (графиков и пр.)? - Увы, на этом этапе в ущерб гибкости реализации пришлось описания полей включить в тексты программы организации обработки, в структуры с условным названием КАДРЫ, где каждый тип кадра описывался совокупностью полей следующего содержания:

-- полное текстовое название поля;

-- имя поля для форм вывода;

-- уникальный номер поля для чтения его значения в БИБПР в машинное представление и для передачи в программу-интерпретатор формы вывода;

-- тип прочитанного значения (целый, вещественный).

Следует заметить, что описываемые поля могли быть и виртуальными, вычисляемыми в БИБПР, которая по каждому типу кадра имела два параметра: указатель на очередной прочитанный кадр и уникальный номер поля из КАДРЫ.

Впоследствии мне хотелось восстановить конструктор графических и табличных форм для новой системы, используя структуры КАДРЫ, и, снимая часть нагрузки с описаний форм вывода, добавить в описание полей базовые единицы измерений (м, радианы и т. д.) и номер их преобразования (в км, град, ...), который в конструкторе можно было бы изменить для формирования документа.

6 "Назад в будущее"

"Кто мешает тебе выдумать порох непромокаемым?"

(К. Прутков)

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

Жалобы на потерю внешнего описания кадров -- это только непродуманность реализации. Нет препятствий вынести структуры КАДРЫ в служебную БД с тем, чтобы использовать их в интерпретаторе форм и конструкторе.

Если говорить только об экспресс-обработке, то принципы организации обработки можно сформулировать так:

-- в основе, конечно, должен лежать файл регистрации;

-- для быстрого доступа к кадрам файла регистрации необходимо создавать индексные файлы (один общий и множество по типам кадров);

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

-- структуры КАДРЫ, связующие описание форм вывода с БИБПР, желательно вынести в служебную БД;

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

Если говорить об обработке для формирования отчетов, специализированной или межцикловой обработке, то без БД и СУБД уже не обойтись. Сохранение результатов обработки и выходных документов в БД для последующего анализа и архивации -- обязательное требование к серьезным системам. Но в отличие от БД на МВК Эльбрус-1 надо оставить на первом уровне только файлы регистрации с индексами (второй уровень, создаваемый ПОФР, проигнорировать. Здесь ПОФР - это построение индексов и БИБПР). И, конечно, для проведения полноценной обработки необходимо развить процедурный подход в направлении формирования типовых заданий с их оперативными данными и пакетами программ. При таком подходе не только определяется дисциплина программирования, но решается сверхзадача накопления программ обработки в фондах разработчика. На мой взгляд, при программировании любых, даже самых скучных задач, необходим творческий подход, чтобы увидеть метапроблему и развитие методов решения подобных задач, вплоть до создания новой парадигмы (хотя бы затем, чтобы мозговые извилины не испрямились).

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

7 "Прощай, оружие!"

"Где начало того конца, которым оканчивается начало?"

(К. Прутков)

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

Оставить комментарий © Copyright Аникаев Владислав Анатольевич (vaniakaev@mail.ru) Размещен: 11/09/2018, изменен: 11/09/2018. 76k. Статистика. Очерк: Мемуары Скачать FB2		Ваша оценка:

Аникаев Владислав Анатольевич : другие произведения.

Вокруг и около