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

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

(Окончание. Начало в № 3 - 2006)

Информационные модели объектов - термин новый, но чтобы понять его мы провели уже все необходимые рассуждения. Это просто текст на Express, описывающий классы с их свойствами и методами. Иногда говорят об информационной модели предметной области, подчеркивая, что описывается не один объект, а множество. Например, информационная модель управления людскими ресурсами предприятия. Ведь в ней кроме класса Человек со всеми его потомками, должен быть класс Организация. Этот класс необходим, чтобы мы могли описать все места работы и учебы сотрудника. Здесь уже пора оговориться, что в языке Express классы называются сущностями (в английской транскрипции - entity), но это не принципиально. Поскольку понятие "класс" традиционно для объектно-ориентированного подхода, то для начального понимания мы пользовались им, а теперь будем использовать два этих слова как синонимы.

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

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

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

Теперь становится понятно, почему корни CALS-стандартов уходят в обеспечение логистики. Вспомните, что изначально эта аббревиатура раскрывалась как система автоматизированной логистической поддержки (Computer Aided Logistic Support). А теперь трактуется как непрерывная поддержка жизненного цикла (Continuous Acquisition and Life Cycle). Оба раскрытия понятия CALS подразумевают, что объект живет долго и его жизненный цикл надо обслуживать. Применять стандарт STEP для описания объекта целесообразно тогда, когда объект имеет много свойств и много методов, т.е. сложную структуру и сложное поведение на протяжении длительного жизненного цикла. Именно для работы с такими объектами-долгожителями нужно использовать стандартные информационные модели. Во-первых, потому что без информационной модели не разобраться с сущностью и поведением объекта. А, во-вторых, потому что эта сущность должна взаимно однозначно пониматься всеми организациями, обслуживающими жизненный цикл объекта: проектировщиками, производителями, эксплуатантами, поставщиками узлов и комплектующих и т.д.

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

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

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

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

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

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

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

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

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

Искушенный в информационных технологиях читатель мог бы уже несколькими абзацами выше состроить кислую мину и заявить: "А что же здесь нового? Еще одна популярная интерпретация объектно-ориентированного подхода к построению информационных систем? Объектно-ориентированные базы данных, библиотеки методов доступа - все это хорошо известно человечеству на протяжении последних 20 лет. Express - не самый удачный объектно-ориентированный язык, способный всего лишь описывать (декларировать) данные. IDEF - устаревшая нотация 70-х годов прошлого века. И уж если вести речь о построении моделей предметных областей в рамках объектно-ориентированного подхода, то как можно обходить стороной UML-нотации"?

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

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