Самарский портал "Технологии, компьютеры"

Всем лучшим в себе я обязан книгам.
Максим Горький

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

Эту серию я хочу начать с главного. Традиционные устройства: соху, автомобиль, станок – инженер мог увидеть целиком, разобрать на детали, исследовать каждую из них и вообще понять, как же это устройство работает. Причём понять с любой степенью детализации. Также специалист мог усовершенствовать отдельные компоненты одного изделия и применить эти компоненты на другом. То есть изделие было для него, как сейчас принято выражаться, транспарентным. Если же специалист не мог во всём этом разобраться, это просто-напросто говорило о его некомпетентности. Устройство не обязательно было механическим: электронную систему, состоящую из аналоговых элементов, тоже можно было разъять на компоненты и проверить каждый из них на соответствие паспортным характеристикам, например, АЧХ. Простейшие логические схемы, например, упомянутое в первой части «шитое» ПЗУ, тоже поддавались привычному анализу.

Всё изменилось с появлением компьютеров (раньше у нас их называли ЭВМ, но это уже детали). До сих пор приходится сталкиваться с вопросами людей, впервые садящихся за компьютер: «А где к нему инструкция?». Объяснения про то, что инструкция к компьютеру в обычном понимании (не будем же мы всерьёз говорить о том, как распаковать и подключить устройство) отсутствует, и следует изучать информационные технологии как таковые, и сейчас вызывает недоверие, а уж в начале распространения компьютеров многие были убеждены, что их просто обманывают. По моим ощущениям, для большинства современных пользователей понимание наличия в системе физических, логических и сетевых дисков, создания там системы папок и осмысленное помещение туда файлов – непосильная задача.

Что уж говорить о руководителях предприятий, которым на голову свалились все эти АСУПы и ВЦ! Здесь, на мой взгляд, надо было просто отринуть весь свой предыдущий опыт транспарентности традиционных машин и перейти к представлению чёрных ящиков, принципиально не пытаясь понять их физического устройства. Но самостоятельно сделать это нереально, а электронщики, ставшие руководителями ВЦ и умеющие только поддерживать «железо» в рабочем состоянии, явно не могли здесь ничем помочь.

Как я уже писал, к концу 1985 года наше бюро гидрооборудования вовсю проектировало на СМ-ках гидроблоки, и тут выяснилась одна неожиданная для меня вещь. При появлении новых гидроаппаратов, вносить их в программу мог только программист, а на мою просьбу дать возможность делать это конструктору, последовал категорический отказ. Оказалось, что весь перечень элементов находится в каком-то «исходном тексте», который надо уметь компилировать и собирать, чего пользователю доверить никак нельзя. А для того, чтобы дать доступ к данным пользователю, надо полностью переделывать программу и использовать СУБД. Так в руках у меня оказалась толстенная книга М. Мейера «Теория реляционных баз данных». Там не было ничего о языках или конкретных реализациях, а просто рассказывалась, как устроена эта область «объективной реальности, данной нам в ощущениях».

После прочтения книги и её последующего осмысления, ощущение было такое, что протёрли стекло, и я вдруг чётко увидел то, о чём раньше лишь смутно догадывался. К примеру, во всех библиотеках существует иерархическая десятичная классификация – УДК. Замечательный подход, всё написанное удалось систематизировать. Но вот проблема: для того, чтобы эффективно пользоваться этими каталогами, их надо зазубрить. Потому что если нужно найти популярные книжки по физике для детей, то в какую ветку надо нырять? Искать сначала детскую литературу, научно-популярную литературу или физику? Ведь в иерархии эти три уровня можно расположить в любом порядке. Но стоит нам построить базу и к полю «предмет» добавить поля «степень научности» (на одном полюсе – монографии, на другом – максимально популярное изложение) и «возраст читателя», как эта проблема тут же решается. Одновременно становится понятным, что формальное преобразование иерархического библиотечного каталога (УДК) в «электронный вид» (не люблю этот термин, но приходится употреблять) при наличии у информационных технологий мощных реляционных возможностей – дело абсолютно неблагодарное и бессмысленное.

Ещё интереснее построение не плоской таблицы, а настоящей многомерной базы. Например, для адекватного отображения библиотеки нам следует построить таблицу «Книги» с атрибутами (название, издательство, год издания и др.), «Авторы» (не буду перечислять поля, описывающие личность) и «Книги-Авторы». Потому что хотя чаще всего автор у книги один, но бывают ведь, что авторы объединяются для создания книги. Правда, бывает, что группа авторов берёт псевдоним (Козьма Прутков, Гривадий Горпожакс) – но не будем здесь усложнять задачу. Так вот, при наличии трёх связанных таблиц, читатель всегда сможет найти все книги, которые написал интересующий его писатель один или в соавторстве, а также все книги, написанные определённой группой авторов.

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

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

Моя идея была проста и для нынешнего времени очевидна: сформировать единую базу данных по всем изделиям с возможностью получать из неё любые мыслимые отчёты. И это не гипербола: дело в том, что построенная не под конкретную задачу, а «вообще», приведённая к нормальным формам (по Кодду) база действительно даёт такую возможность. Если же для нового отчёта не хватает реквизитов (полей), до их всегда можно просто добавить, не затрагивая при этом уже имеющейся структуры. Основой системы можно считать таблицу изделий, содержащую все необходимые их реквизиты (обозначение, наименование, вид поставки, материал и пр.) и таблицу составов изделий. При этом таблица состава изделия имела три основных поля: Что (входит), Куда (входит), Количество. Дополнительные поля Формат, Зона, Позиция и Примечание нужны были для связи со сборочным чертежом, и большинство задач обходилось без них. Самым интересным в этой структуре была симметричность полей Что и Куда: это позволяло нам строить как традиционные иерархии, так и обратные. Традиционные мы называли «дерево вниз», обратные «дерево вверх». То есть, если бумажные спецификации давали нам представление о выпускаемой номенклатуре изделий как о не связанных друг с другом иерархиях, то теперь мы видели своеобразную сетку, из каждого узла которой можно было построить по дереву в каждую сторону. Несложные инструменты позволяли понять, насколько разные модели окончательных изделий связаны между собой (какие подмножества они образуют), анализировать уровень унификации.

Далее, в первую очередь для проведения унификации, нам понадобилось классифицировать изделия (в первую очередь – детали). Оказалось, что классификатор ЕСКД существует, и он довольно логично устроен. Следом возник вопрос: если теперь мы видим производимую продукция не как набор не связанных друг с другом иерархий, а как сложную сеть, то конструкторские обозначения перестали выглядеть логичными, ведь классическое обозначение строится по иерархической схеме: ФИРМА. АВТОМОБИЛЬ. 000. 000. 000 (ВАЗ. 21093. 000. 000. 000). А если какая-то деталь изначально проектировалась для «восьмёрки», потом использовалась во всех последующих моделях, то почему она должна жить под «восьмым» обозначением? А если конструктора «восьмёрки» (сопровождение производства) захотят изменить что-то в этой детали? А если «восьмёрка» будет снята с производства? Оказалось, что не мы первые озаботились этой проблемой, и всё это уже продумано, только не существовало программного инструмента для реализации. ГОСТ 2.201-80 устанавливает единую обезличенную классификационную систему обозначения изделий основного и вспомогательного производства и их конструкторских документов всех отраслей промышленности. Обозначение изделия имеет вид: АБВГ.XXXXXX.ХХХ-XX.XX, где

• АБВГ – четырёхзначный буквенный код организации-разработчика изделия;
• XXXXXX – шестизначный числовой код классификационной характеристики согласно классификатору ЕСКД;
• ХХХ – трёхзначный числовой регистрационный номер;
• XX.XX – двух- или четырёхзначный номер исполнения (только при групповом исполнении).

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

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

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

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