ЭТО СТРАННОЕ СЛОВО - CALS

ММП им. В.В. Чернышева: Сергей Викторович Андреев,
заместитель директора производства по планированию
Илья Валерьевич Сафонов,
начальник информационно-вычислительного центра

Столь неблагозвучная для российского уха аббревиатура ворвалась в нашу жизнь в середине 90-х годов ХХ века и прочно осела в профессиональном обиходе. Но что удивительно: вполне профессиональный технический термин CALS использовался скорее как иероглиф для обозначения той отрасли информационной индустрии, на которой конкретный докладчик или автор статьи желал сконцентрировать внимание аудитории. Достаточно бегло пролистать материалы конференций тех лет, чтобы увидеть как после ряда вводных фраз о CALS-технологиях докладчик переходил к изложению проблем внедрения САПР в конструкторском бюро или разворачивания ERP-системы на машиностроительном предприятии. Масла в огонь подливал тот факт, что сама аббревиатура претерпевала трансформацию в своем раскрытии. Изначально понятие CALS трактовалось как Computer Aided Logistic Support, т.е. компьютерная поддержка поставок или автоматизированная система логистической поддержки, затем - Continuous Acquisition and Life Cycle Support, т.е. непрерывная информационная поддержка жизненного цикла изделия или продукта, а венчался весь этот ряд остро модным, почти рекламным слоганом - Commerce at Light Speed - бизнес со скоростью света. При этом CALS иногда называют технологиями, иногда стандартом, иногда подходом, а иногда концепцией. Мне даже довелось слышать мнение, что CALS - это стратегия развития национальной промышленности.

Забегая вперед, скажу, что я бы определил CALS как концепцию совместного использования данных. В нашей стране сейчас понятие CALS постепенно вытесняется понятием ИПИ-технологий (на языке оригинала, скорее - "АЙПИ-технологий"), а информационная индустрия уже являет миру достаточно широкий спектр новых подходов к совместному использованию данных. Таких подходов требуют и активно их адсорбируют, пожалуй, все сферы общественного производства. Но первыми, почувствовавшими "на собственной шкуре" важность проблемы, были инженеры-логистики 70-80-х годов прошлого столетия. И результатом их поисков решения проблемы явился набор приемов, методов и стандартов совместного использования данных, объединенных в понятие CALS. Это понятие, вернее то, что под ним скрывается, скорее всего, будет играть серьезную роль в развитии наукоемких отраслей промышленности в XXI веке.

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

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

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

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

Компания Б более молодая, и ее система управления формировалась в то время, когда в России уже прочно утвердились такие понятия как медицинское и пенсионное страхование, индивидуальный номер налогоплательщика и т.д. Запись о сотруднике компании Б имела вид: ФИО, Должность, ИНН, Номер пенсионной страховки и т.д.

При этом в компании А объект "сотрудник" идентифицировался по ФИО и паспортным данным, а в компании Б - по ИНН.
И та, и другая система отлаженно функционировали, и менеджеры кадровых служб давно к ним привыкли. Перед руководством объединенной фирмы встал вопрос объединения систем управления кадрами, и решение этой задачи вылилось в существенные затраты. Сначала пришлось пройти через отчаянные споры менеджеров о том, как следует управлять объектом "сотрудник" и какие атрибуты при этом важны. После согласования концептуальных вопросов настал черед программистов писать и согласовывать ТЗ, что также затянулось надолго. Сам процесс программирования не отнял много времени, так как ТЗ было четко структурировано и удалось привлечь дополнительных разработчиков на реализацию разовых работ по трудовым контрактам. Далее данные из старых систем были перекачаны в новую, но с частичной их потерей, так как на этапе концептуального согласования были допущены некоторые терминологические неточности, и оказалось, что разные люди по-разному понимают понятие "адрес". Это вылилось в прямые затраты, связанные со сверкой новой базы данных и ручных картотек, и в косвенные, возникшие по причине общей неразберихи в работе кадровой системы. Новая система, по настоянию программистов, была разработана на новых информационных технологиях и потребовала замены части парка персональных компьютеров. Эти, в общем-то еще вполне исправные компьютеры, были вдруг признаны морально устаревшими. Потом еще в течение полугода систему с затухающей периодичностью потрясали программные сбои, что также приводило к неразберихе и косвенным затратам. Через полгода люди вздохнули с облегчением, а через год преодоленные трудности стали забываться.

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

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

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

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

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

Все эти стандарты оформлены документом ISO 10303, называемым так же STEP. Поэтому к информационной системе, отвечающей этому стандарту, мы можем применять понятия STEP-база и STEP-данные. Однако STEP - это еще не весь CALS. И для того, чтобы окончательно прояснить смысл понятия CALS, мы должны поглубже заглянуть в природу объектов, подлежащих описанию на языке Express.

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

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

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

Через полтора года после объединения компаний А и Б, когда все страсти вокруг кадровой политики улеглись, на фирме сложилась следующая ситуация.

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

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

Первое. Описывается класс объектов Человек. Каждый объект этого класса имеет следующие обязательные свойства: имя; дата рождения и т.д.

Второе. Класс объектов Человек имеет подклассы Сотрудник и Чужой. В этом случае класс Человек называется родительским классом, а Чужой и Сотрудник - классами-потомками. Каждый потомок наследует все свойства своего родителя и, кроме того, имеет собственные свойства. В частности, класс Сотрудник обладает свойствами: образование; должность и т.д.

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

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

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

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

Вот каким образом стала выглядеть структура данных информационной системы, обслуживающей Службу кадров и Протокольный отдел: КЛАСС Человек. Он включает Имя и т.д. КЛАСС Сотрудник СУПЕРКЛАСС Человек. Он включает Образование и т.д. КЛАСС Персона_из_Досье СУПЕРКЛАСС Человек. Гастрономические вкусы. Опасные связи и т.д.
Программисты компании создали один дополнительный класс Персона_из_Досье и дописали программный код, позволяющий пользователю создавать, редактировать и просматривать объекты класса с экрана компьютера. Вся остальная система осталась без изменений.

Через некоторое время фирма открыла представительство в Германии, и в корпоративной Базе данных появилась запись: КЛАСС Сотрудник_из_Германии СУПЕРКЛАСС Сотрудник, включающий Счет в банке, № Кредитной карточки и т.д.
Поскольку такая запись о сотруднике из Германии была продиктована немецким законодательством, то на очередном отраслевом совещании класс Сотрудник_из_Германии был признан стандартным. Фирмы, имеющие представительства в Германии, внесли соответствующие изменения в свои базы данных, а программное обеспечение работы с объектами класса приобрели у компании А.

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

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

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

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

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

Подметив общность в поведении злаков, человек выработал методы их возделывания и сбора урожая. Анализ общности в поведении животных позволил человеку заняться сначала охотой, а затем - животноводством. Промышленная революция XIX века выработала эффективные методы обработки сырья и построения сложных механизмов. Информационное общество конца XX - начала XXI века ищет единые методы обработки информации.

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

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

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

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

(Продолжение следует)