CC BY
31
в запросе. Например, вывод только одного слоя чертежа или всех указанных объектов, или всех объектов, связанных с данным объектом.
Такой подход (представление) обеспечивает чертежу: независимость представления от программы, в которой он был создан; независимость вывода на внешние устройства; постоянное развитие информации во времени.
А самое главное, такой подход обеспечивает раздельную работу над контентом (содержимым чертежа), структурой чертежа, способами вывода на внешние устройства и запросами к структуре и контенту чертежа. Каждая часть может создаваться и развиваться отдельно. Например, еще до начала черчения может быть уже указана (разработана) структура чертежа.
Кроме этого, чертеж может выводиться и анализироваться с различной степенью абстракции. Даже если имеется уже детализированная сборка, можно заказать для отображения только компоновочные контуры (это определенный уровень в дереве узлов). То есть вместо целого чертежа по запросу можно выводить либо его отдельные фрагменты, либо отдельные детали и узлы, либо все, но с указанной степенью детализации.
Причем если вспомнить, что это все же не чертеж, а именно информационная модель, то вместе с графическим куском, могут выводиться и другие типы данных, относящиеся к настоящему элементу (экономические данные, данные о материалах и т.п.).
С развитием информационных технологий стирается традиционная грань между чертежами и текстом. Есть только информация, которую можно представить разными способами. Основной задачей при этом становится максимальная понимае-мость человеком информации и возможность ее автоматизированной обработки.
Этот подход не противоречит традиционной технологии проектирования и документирования. В узле информационной модели может лежать и традиционный чертеж, и эскиз, и отсканированный чертеж из архива. Данный подход позволяет значительно ускорить процесс конструирования и документирования за счет того, что уже в самом начале определяются полочки, где должна лежать определенная информация, а заполнение этих полочек уже идет по определенному плану по мере готовности той или иной формы представления.
ОБЩЕЕ ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО ЗАДАЧ
КОРАБЛЕСТРОЕНИЯ. КОНЦЕПЦИЯ ПОСТРОЕНИЯ ИНФОРМАЦИОННОЙ МОДЕЛИ
И.А. Конюхов, К.В. Орехов
В начале нынешнего века в отечественном военном кораблестроении существенно возросла потребность в разработке автоматизированных систем проектирования, управления и обучения нового поколения. Подобные системы должны существенно повысить эффективность использования средств, выделяемых на цели обороноспособности страны.
Стратегические задачи современных средств информатизации:
- значительное расширение круга задач Военно-морского флота (ВМФ), подлежащих автоматизации;
- существенное повышение производительности труда разработчиков программного и информационного обеспечения;
- повышение эффективности средств информатизации за счет длительной сохраняемости и повторного использования результатов.
Ключевым вопросом в решении этих задач является создание общего информационного пространства в области кораблестроения, реализованного в виде распределенных хранилищ данных.
Длительная сохраняемость и непрерывное развитие информации могут быть обеспечены только использованием средств на основе международных стандартов на представление и использование информации. В данной статье рассматривается один из таких стандартов - спецификация Common warehouse metamodl (общая метамодель хранилища данных, далее CWM).
Спецификация CWM - это стандарт, который описывает обмен метаданными при использовании технологий хранилищ данных, knowledge management (управление знаниями). Опираясь на базовую метамодель, стандарт добавляет метамо-дели для реляционных, многомерных данных и данных таблиц, а также для преобразования, функций OLAP, data mining и хранилища данных, включая процессы и операции.
В определенной степени появление спецификации CWM можно считать реакцией корпорации "Oracle" на продвигаемый Microsoft стандарт Open information model (открытая информационная модель, далее OIM). Осенью 1999 года Microsoft передал указанную спецификацию на рассмотрение
в консорциум Meta Data Coalition (MDC). Разумеется, "Oracle" не мог допустить лидерства своего соперника в области разработки хранилищ данных и аналитических приложений, и спустя всего несколько недель после памятной инициативы Microsoft, 17 сентября 1999 года, "Oracle", NCR, IBM и ряд других поставщиков программного обеспечения представили в организации Object Management Group (OMG) спецификацию Common warehouse metadata interchange (обмен общими метаданными хранилища данных, далее CWMI).
В сентябре 2000 года MDC вошло в состав OMG, и спецификация CWMI стала называться Common warehouse metamodel, ее версия 1.0 была опубликована в феврале 2001 года. В апреле того же года обнародованы файлы спецификации, в которых были указаны исправления опечаток.
Как было сказано выше, спецификация CWM определяет метамодель, представляющую как логические, так и технические метаданные, которые в большинстве случаев присутствуют в области технологии хранилищ данных и аналитики. Она используется как основа для обмена экземплярами метаданных между гетерогенным программным обеспечением, поставляемым различными производителями. Системы, которые понимают мета-модель CWM, обмениваются данными в форматах, согласующихся с этой моделью.
CWM выражен на языке UML (Unified modeling language, унифицированный язык моделирования). Но хотя UML является нотационным основанием для определения CWM, CWM расширяет базовую метамодель UML с помощью концепций технологий хранилищ данных и логического анализа.
Можно сказать, что CWM расширяет язык UML в том смысле, что каждый метакласс (metaclass) CWM наследуется либо напрямую, либо из метаклассов UML. Например, метакласс "Реляционная таблица (Relational table) CWM" является непосредственным наследником класса UML (UML class), а "Реляционный столбец" (Relational column) - прямой потомок атрибута UML (UML attribute). Таким образом, CWM можно характеризовать как язык определенной области применения, предназначенный для определения моделей хранилищ данных.
Другой стандарт OMG - Meta object facility (средство метаобъекта, далее MOF) - определяет общие интерфейсы и семантику для взаимодействующих метамоделей. MOF - это пример мета-метамодели, или модели метамодели (подмножество UML). Он также определяет набор IDL-преобразований (Interface definition language, язык описания интерфейса, который устанавливает спецификацию интерфейса для обнаружения и управления моделей с помощью программных APIs).
Помимо определения общей семантики для метамоделей, МОБ также служит в качестве модели для иМЬ (то есть в конечном итоге МОБ определяет язык, на котором выражается метамодель ИМЬ). Поскольку CWM наследуется из ИМЬ, МОБ также является моделью и для CWM. Все модели CWM выражаются на ИМЬ и реализуют семантику МОБ.
В таблице приведены резюме этих связей в виде классической четырехуровневой архитектуры моделирования.
Мета-уровень Уровень моделирования Примеры
M3 Meta- Metamodel/Meta- meta-metadata (мета-метамодель/мета-мета-метаданные) MOF Class, Attribute, Association, Package, Operation
M2 Metamodel/Meta-metadata (метамодель/мета-метаданные) UML Class, Attribute CWM Table, Column
Ml Model/Metadata (модель/метаданные) Product: Table PoductType: Column
M0 Data/Object (данные/объект) "Toaster" ("тостер") Television" ("телевизор") "Stereo" ("стереосистема")
Наконец, третий стандарт, который непосредственно задействован в обмене метамоделями, -это XMI. XMI (XML metadata interchange, обмен метаданными XML) - это стандарт OMG, который устанавливает правила преобразования метамоделей MOF в XML. XMI определяет, как использовать XML-теги для представления сериализован-ных моделей, совместимых с MOF. Метамодели MOF транслируются в XML DTD, а модели - в XML-документы, которые согласуются со своими DTD.
Каждая метамодель CWM представляется как XML DTD (в соответствии с правилами XMI), так и определение IDL. В первом случае модели CWM преобразуются в поток (serialize), после чего ими обмениваются как документами XMI. При экспорте метаданных посредством XMI-документа необходимо выполнить XMI-преобразование (MXI-rendering) в форме, которая легальна по отношению к DTD. При импорте данных с помощью XMI-документа следует проверять модель на допустимость по этим DTD.
Во втором случае модели объектов CWM создаются в памяти или хранятся в репозитории. В этой ситуации IDL предпочтительней, поскольку он определяет необходимые интерфейсы, подписи методов и структуру совокупности, которые эта модель должна поддерживать.
Итак, CWM фактически состоит из ряда составных метамоделей (или субметамоделей), ко-
торые организованы в виде следующих 4 слоев: базовый слой (foundation), источники данных (resources), анализ (analysis) и управление хранилищем (management).
Базовый слой состоит из метамоделей, которые поддерживают моделирование таких различных элементов и сервисов, как типы данных, системное преобразование типов, абстрактные ключи и индексы, выражения, бизнес-информация и включения программного обеспечения, основанного на использовании компонентных объектов.
Слой источников данных предоставляет возможность моделировать существующие и новые источники данных, в том числе реляционные базы данных, ориентированные на запись базы данных (record oriented databases), а также XML- и основанные на объектах (object-based) источники данных.
Слой анализа предоставляет средства для моделирования сервисов информационного анализа, которые обычно используются в хранилище данных. Он определяет метамодель для преобразования данных, OLAP, визуализации информа-ции/репортинга (business nomenclature) и data mining.
Слой управления состоит из метамоделей, представляющих стандартные процессы и операции хранилища данных, журнализации (activity tracking) и планирования работ [scheduling] (например, ежедневной загрузки и выгрузки).
Этот набор метамоделей, предоставляемых CWM, достаточен для моделирования всего хранилища данных. Используя инструмент, поддерживающий CWM, можно было бы сгенерировать экземпляр хранилища данных прямо из модели хранилища. Каждый из этих различных инструментов использует те части модели, которыми можно воспользоваться. Например, сервер реляционной базы данных задействует реляционный блок этой модели и будет использовать его для построения его каталога. Аналогично OLAP-сервер будет отыскивать в модели метаданные OLAP и использовать их для определения многомерной схемы. А инструмент извлечения, преобразования и загрузки данных (ETL), скорее всего, обработал бы срез модели хранилища данных, которая охватывает несколько метамоделей CWM, в том числе метамодели OLAP, преобразования, типа данных, преобразования типов, выражений и реляционную метамодель.
Уважаемыв читатели!
Обращаем ваше внимание на почтовые реквизиты редакции международного журнала
«Программные продукты и системы»:
170024, г. Тверь, пр. 50 лет Октября, д. 3а,
ЗАО НИИ «Центрпрограммсистем»,
редакция
Ждем от наших авторов проблемных, насыщенных интересными фактами материалов, соответствующих профилю журнала.
