Создание IEPD NIEM: Часть 1. Моделирование системы обмена информацией NIEM

Проектирование системы обмена XML-информацией между государственными учреждениями США

Национальная модель обмена информацией (National Information Exchange Model – NIEM) быстро становится важнейшим стандартом обмена XML-информацией для госучреждений США и их информационных партнеров. Эта статья, первая в цикле из четырех частей, содержит обзор процесса определения системы обмена информацией NIEM. Затем в ней описывается первый шаг – моделирование системы обмена информацией с использованием языка UML – с некоторым экскурсом в концепцию NIEM-моделирования. Для иллюстрации процесса используется простой пример.

Присцилла Уолмсли, управляющий директор, Datypic

Фото Присциллы УолмслиПрисцилла Уолмсли (Priscilla Walmsley) работает управляющим директором и старшим консультантом компании Datypic. Она специализируется на технологии, архитектуре и реализации XML. В последнее время Присцилла работает с Министерством юстиции США (через Trusted Federal Systems) над системой IEPD LEXS нa базе NIEM. Она – автор книг Definitive XML Schema (Prentice Hall, 2001 г.) и XQuery (O'Reilly Media, 2007 г.). Кроме того, она является соавтором учебника Web Service Contract Design and Versioning for SOA (Prentice Hall, 2008 г.). С Присциллой можно связаться по адресу: pwalmsley@datypic.com.



01.11.2010

9 марта 2010 г. Добавлены ссылки на третью часть этого цикла в разделах "Введение", "Заключение" и "Ресурсы".

9 февраля 2010 г. Добавлены ссылки на вторую часть этого цикла в разделах "Введение", "Заключение" и "Ресурсы".

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

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

  • Oбщая модель данных XML, называемая ядром NIEM, содержит компоненты данных для описания общих объектов, таких как люди, места, действия и организации;
  • Более специализированные модели данных XML, называемые доменами, которые используются для частных случаев (примеры: судопроизводство, иммиграция и преодоление последствий чрезвычайных ситуаций);
  • Mетодология использования и расширения блоков, которые поступают из общих и предметно-ориентированных моделей, для их превращения в полноценную систему обмена информацией, называемая пакетом обмена информацией (information exchange package);
  • Инструменты для разработки, проверки, документирования и распространения пакетов обмена информацией;
  • Руководящая организация, которая занимается обучением и поддержкой, а также осуществляет надзор за развитием NIEM.

Эта статья, первая в цикле из четырех частей, познакомит вас с NIEM и покажет, как составлять документацию пакета обмена информацией NIEM (NIEM Information Exchange Package Documentation – IEPD) с помощью унифицированного языка моделирования (Unified Modeling Language – UML). Рабочие и заключительные UML-модели содержатся в разделе Загрузка.

Как используется NIEM?

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

Чтобы использовать NIEM, необходимо построить IEPD. IEPD извлекает необходимые компоненты из моделей ядра NIEM и доменов и дополняет их для создания системы обмена информацией. IEPD содержит несколько артефактов:

  • XML схемы, определяющие часть модели NIEM для данной системы – так называемая схема подмножества (subset schema);
  • схема, определяющая корневой элемент системы обмена, или схема обмена (exchange schema);
  • схема, определяющая расширения к модели NIEM – схема расширения (extension schema);
  • документация по системе обмена, такая как диаграммы UML, описания и примеры.

Разработка IEPD

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

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

Поскольку главной целью NIEM является обеспечение совместимости данных, прежде чем создавать новую IEPD с нуля, имеет смысл рассмотреть вопрос о повторном использовании существующих. У NIEM есть информационный центр IEPD, который позволяет выполнять поиск существующих IEPD, предоставленных другими организациями. Ссылка на информационный центр IEPD приведена в разделе Ресурсы.

Если вы не нашли IEPD, соответствующую вашим потребностям, ее нужно создать. Разработка новой IEPD NIEM состоит из пяти шагов:

  1. Моделирование системы обмена.
  2. Сопоставление системы обмена с моделью данных NIEM.
  3. Создание подмножества модели NIEM для использования в системе обмена.
  4. Создание системы обмена и расширение схем для описания специальных компонентов.
  5. Сборка IEPD со всеми надлежащими артефактами.

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


Представление о модели NIEM

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

Концепции модели NIEM

Типы – это явления, как материальные, так и нематериальные. Некоторые из основных типов модели NIEM – это PersonType (лицо), ActivityType (действие), ItemType (предмет), LocationType (место) и OrganizationType (организация). Существуют также тысячи других типов с различной степенью детализации. В других парадигмах моделирования типы могут называться классами или объектами.

Свойства – это атрибуты типов. Они сами могут быть сложными типами. Например, PersonName (личное имя) – свойство типа PersonType, но существует также тип PersonNameType со своей собственной структурой, содержащей PersonGivenName (имя), PersonSurName (фамилия) и т.д.

Типы могут выводиться из других типов и наследовать их свойства аналогично обобщениям в объектно-ориентированной модели. Например, ItemType – это общий тип, из которого образуются многие производные типы, в том числе VehicleType (транспортное средство), JewelryType (ювелирные изделия) и RealEstateType (недвижимость).

Ассоциации – это отношения между двумя типами. Могут существовать ассоциации между происшествием и лицом или между лицом и местом. В NIEM ассоциации отделены от типов, к которым они относятся.

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

Дополнения – это группы свойств, которые можно многократно использовать и передавать. Они чаще используются в моделях доменов NIEM, чем в отдельных IEPD.

Метаданные – это информация о содержании сообщения, указывающая, например, когда были собраны данные и насколько они надежны. В модели NIEM есть особые положения, касающиеся отношения данных и метаданных.

Модель NIEM на XML

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

В общем случае типы NIEM реализуются в виде сложных типов XML-схемы, а свойства – это элементы, содержащиеся в этих типах. В листинге 1 показано, как действие представлено сложным типом ActivityType с такими свойствами, как ActivityIdentification и ActivityCategoryText, реализованными в виде дочерних элементов.

Листинг 1. Частичная реализация NIEM ActivityType в XML-схеме
<xsd:complexType name="ActivityType">
 <xsd:complexContent>
  <xsd:extension base="s:ComplexObjectType">
   <xsd:sequence>
    <xsd:element ref="nc:ActivityIdentification" minOccurs="0" 
    maxOccurs="unbounded"/>
    <xsd:element ref="nc:ActivityCategoryText" minOccurs="0" 
    maxOccurs="unbounded"/>
    <!-- ... -->
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Для образования типов NIEM использует расширения XML-схемы. В листинге 2 показано, как из ActivityType образуется более специфический вид деятельности – сложный тип AssessmentType.

Листинг 2. Образование типа NIEM в XML-схеме
<xsd:complexType name="AssessmentType">
 <xsd:complexContent>
  <xsd:extension base="nc:ActivityType">
   <xsd:sequence>
    <xsd:element ref="nc:AssessmentScoreText" minOccurs="0" 
    maxOccurs="unbounded"/>
    <xsd:element ref="nc:AssessmentFee" minOccurs="0" 
    maxOccurs="unbounded"/>
    <xsd:element ref="nc:AssessmentProgram" minOccurs="0" 
    maxOccurs="unbounded"/>
    <!-- ... -->
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Ассоциации представляют собой специальные виды сложных типов, содержащие ссылки на типы, к которым они относятся. В листинге 3 показано, как реализуется ассоциация между лицом и действием – ActivityPersonAssociationType. Все типы ассоциаций представляют собой (прямо или косвенно) расширения ядра NIEM AssociationType.

Листинг 3. Тип ассоциации NIEM в XML-схеме
<xsd:complexType name="ActivityPersonAssociationType">
 <xsd:complexContent>
  <xsd:extension base="nc:AssociationType">
   <xsd:sequence>
    <xsd:element ref="nc:ActivityReference" minOccurs="0" 
    maxOccurs="unbounded"/>
    <xsd:element ref="nc:PersonReference" minOccurs="0" 
    maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Моделирование системы обмена

Для моделирования системы обмена XML NIEM не требуется использования какой-либо конкретной методологии, или типов диаграмм, или даже самого моделирования. Тем не менее, моделирование является важным шагом в разработке IEPD. Процесс моделирования воплощает требования, а конечный результат содержит документацию, которая полезна как для бизнес-, так и технических пользователей. Модель также служит полезным введением в последующие шаги процесса создания IEPD.

Выбор парадигмы моделирования

Использование инструментов UML

Если вы используете UML, то лучше выбирать UML-инструменты с поддержкой XMI, такие как IBM® Rational® Modeler или ArgoUML, потому что на следующем шаге XMI можно будет использовать для автоматического генерирования таблицы соответствий. Для этой статьи я пользовалась UML-редактором с открытым исходным кодом ArgoUML.

UML – в частности, диаграммы классов UML, — будет хорошим выбором, потому что концепции UML легко отображаются на концепции модели NIEM. Конечно, для системы обмена документами можно создать и другие UML-диаграммы, такие как диаграммы сценариев и последовательные диаграммы. Эта статья сфокусирована на диаграмме классов, потому что она важна для процесса разработки IEPD.

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

Типы и свойства

Этой статьи недостаточно, чтобы описать всю работу по UML-моделированию, поэтому основное внимание уделяется сведениям, относящимся к NIEM. Как и следовало ожидать, на диаграмме классов типы NIEM представлены классами. Свойства представлены атрибутами класса.

В своем примере я определила, что есть несколько классов, которыми нужно обмениваться – Theft (кража), MotorVehicle (автомобиль), Bicycle (велосипед), Victim (потерпевший), Witness (свидетель) и TheftLocation (место происшествия). Эти типы вместе с их свойствами изображены на рисунке 1.

Рисунок 1. Исходная UML-модель с типами и их свойствами
Исходная модель UML с типами (Кража, Автомобиль, Велосипед, Потерпевший, Свидетель, Место происшествия) и их свойства

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

Таблица 1. Общие типы данных XML-схемы
Имя типа данных ОписаниеПримеры
stringЛюбая текстовая строкаabc, this is a string
integerЦелое любого размера1, 2
decimalДесятичное число1.2, 5.0
dateДата в формате ГГГГ-ММ-ДД2009-12-25
timeВремя в формате ЧЧ:ММ:СС (24-часовой формат)12:05:04
booleanЗначения типа Да/Нет true, false

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

Обобщения и роли

Модель NIEM использует обобщения, и при необходимости их нужно использовать и при составлении собственной модели. В данном случае MotorVehicle и Bicycle представляют собой отдельные виды имущества, которое может быть украдено. Поэтому я решила добавить более общий класс Property и вывести из него MotorVehicle и Bicycle. Это позволит определить общие свойства, такие как SerialNumber, только однажды и упростить ассоциации, связав класс Property с классом Theft.

Victim и Witness как будто подчиняются тому же правилу. Ведь оба они – просто более конкретные типы лиц. Тем не менее, состояние лица как свидетеля или потерпевшего носит временный характер, так что его лучше представить в виде роли. В данном случае в конкретном происшествии угона одно и то же лицо может быть как потерпевшим, так и свидетелем. Тогда одному и тому же человеку нужно будет отвести две разные роли. Я показываю это в своей модели путем добавления отдельного класса Person и создания ассоциаций с классами Victim и Witness. Я помечаю эти ассоциации как Role Of Person (Роль лица), чтобы указать, что они связаны через роли, а не обычной ассоциацией.

На рисунке 2 приведена модель после добавления обобщений и ролей.

Рисунок 2. UML-модель с добавленными обобщениями и ролями
UML модель с добавленными обобщениями (Имущество, Лицо) и ролями (Потерпевший, Свидетель, Автомобиль, Велосипед)

Отношения

UML предлагает три способа представления отношений: агрегацию, композицию и ассоциацию.

Отношения агрегации и композиции, как правило, отражают отношения типа "имеет", когда один класс является подчиненным по отношению к другому. В нашем примере Person (Лицо) "имеет" PersonName (Личное имя). Класс PersonName бесполезен вне связи с соответствующим лицом. Таким же образом агрегации и композиции рассматриваются и в NIEM. В потенциальной XML-структуре подчиненный класс будет содержаться в другом классе. Например, элемент Person будет содержать элемент PersonName.

Ассоциации же относятся к двум отдельным классам, которые могут быть независимыми. В нашем примере Theft (кража) и TheftLocation (место происшествия) – две разные вещи, и одна может существовать без другой. Для отображения этого в модели можно использовать общие ассоциации UML или, если существуют дополнительные свойства, относящиеся к самой ассоциации, добавить к модели отдельные классы. В любом случае в структуре NIEM XML каждый класс будет представлен разными элементами с отдельным элементом ассоциации, содержащим ссылки на элементы, к которым относится, – в данном случае Theft и TheftLocation.

В своем примере я использую композицию для представления отношения Person-PersonName и простые UML-ассоциации для связи друг с другом остальных классов. На рисунке 3 представлена модель после добавления отношений.

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

Выбор корня

Каждое XML-сообщение должно иметь единственный корень. Как правило, в системе обмена данными XML существует единственная фокальная точка, или цель сообщения. В нашем случае это само заявление об угоне. Добавим в нашу модель класс TheftReport со свойством TheftReportDate. Создадим отношение агрегации между TheftReport и Theft, указывающее на то, что заявление об угоне относится к кражам.

Готовая UML-модель представлена на рисунке 4. Как и следовало ожидать, эта модель пока несовершенна. Обычно в процессе разработки IEPD в модель вносятся итерационные изменения. Например, было бы полезно, где это уместно, изменить структуру или имена, чтобы они лучше соответствовали модели NIEM.

Рисунок 4. Готовая UML-модель
Готовая UML-модель (с классом TheftReport)

Заключение и следующие шаги

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

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


Загрузка

ОписаниеИмяРазмер
Окончательная модель ArgoUML из этой статьиniem1.zip12 KБ
Окончательная модель XMI из этой статьиniem1.xmi.zip4 KБ

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=559954
ArticleTitle=Создание IEPD NIEM: Часть 1. Моделирование системы обмена информацией NIEM
publish-date=11012010