В настоящее время организацией CEFACT (the United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport - Центр по упрощению процедур и практики в управлении, торговле и на транспорте) при ООН реализуется проект ebXML - "Создание единого глобального электронного рынка", который поддерживается Организацией продвижения стандартов структурированной информации (the Organization for the Advancement of Structured Information Standards ) – OASIS. Акроним ebXML - XML for electronic bisiness т.е. XML для электронного бизнеса.

      Концепция проекта

При разработке проекта ebXML использовались следующие основные принципы:

Рабочая группа создания глобального электронного рынка - ebXML работает в следующих направлениях, которые выделены как самостоятельные проекты:

На рис.1 представлено взаимодействие основных компонентов ebXML при осуществлении бизнес-транзакций.

Некая Компания Х (Interprise Systems) ведет электронный обмен с другой Компанией Y через Центр электронного бизнеса - Репоситорий (Repository). Электронный бизнес осуществляется путем обмена между компаниями электронными бизнесс-документами.

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

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

На рис.2 представлен один из вариантов обмена Электронными документами для компаний X и Y.

Основой введения электронного бизнеса являются обмен электронными сообщениями, на основании которых осуществляются принятие решения по проведению операций при торговых сделках. В качестве базовой структуры сообщения используется опыт при создании сообщений стандарта UN/EDIFACT. В итоге моделирования необходимо получить описания структуры сообщения в виде структуры XML/DTD или XML-схемы.

На рис 3. изображена трехступенчатая схема реализации модели сообщения.

Шаг 1 - ручное преобразование в Бизнес модель (БМ) на основе использования Руководства по разработки сообщений EDIFACT. При этом преобразовании имеется в виду перенос синтаксиса элементов EDIFACT всех спецификаций и выделение функциональной спецификации на содержание информации и ее структуры.

Шаг 2 - преобразование БМ в UML Модель сообщений. Преобразование поддерживается программным комплексом моделирования UML, используются такой аппарат как класс диаграмм, класс списка атрибутов и т.д.

Шаг 3 - создание соответствия Бизнес модели XML/DTD и XML-схемы. Данное преобразование осуществляется специально разработанным программным обеспечением.

Шаг 4 - (необязательный) Возможность запомнить образ UML Модели сообщения и создание домена транспортной модели для использования накопленного опыта при разработке других типов сообщения.

Точное отражение EDIFACT структуры включает имена сегментов, составных и отдельных элементов данных.

Сообщение UN/EDIFACT можно разобрать на следующие самостоятельные единицы, вложенные друг в друга:

Осуществление ручного переноса (шаг 1) структуры сегмента сообщения в термины описания XML/DTD требует хорошего понимания структуры сообщения и знания стандарта UN/EDIFACT. Ниже приведен пример преобразования в DTD начального сегмента сообщения – BGM.

Структура сегмента BGM в соответствии со спецификацией :

#гр.эл. #спр описание элемента данных обяз/необ формат даннных M/C данных ____________________________________________________________________________ 010 C002 DOCUMENT/MESSAGE NAME C 1001 Document/message name, coded C an..3 1131 Code list qualifier C an..3 3055 Code list responsible agency, coded C an..3 1000 Document/message name C an..35 020 C106 DOCUMENT/MESSAGE IDENTIFICATION C 1004 Document/message number C an..35 1056 Version C an..9 1060 Revision number C an..6 030 1225 MESSAGE FUNCTION, CODED C an..3 040 4343 RESPONSE TYPE, CODED C an..3 ____________________________________________________________________________

Таблица 1

Преобразовывая сегмент сообщения BGM, опуская неиспользуемые клалификаторы, мы получим следующий вид DTD:

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

При создании Бизнес модели используются следующие принципы:

Бизнес модель разделена на следующие секции: реквизиты сообщения, стороны, таможенные отметки, упаковка, товары, документы, коды;

основные сегментные группы или сегменты корневого уровня должны соответствовать секции БМ.

термины данных БМ могут порождаться из других элементов данных EDIFACT или из значения кодов для определенных элементов данных;

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

Использование термина данных в БМ на уровне кодов данных сслылается на свю “концепцию кода”

имена БМ должны быть специфицированы достаточным для понимания;

в БМ использовать смысловую семантику, так например таг, описывающий перевозимые товары может именоваться GoodItems

дублирование имен недопустимо.

     Преобразование Бизнес Модель в Модель сообщений

UML Модель сообщений специфицирована как тип сообщения и состоит из: классов сообщений, атрибутов и соответствий (ассоциаций). Эти термы формально определены в UML и представляют класс сообщений, который является подкласс формального класса UML. Эти термы используют различные формы обычного UML класса, т.к. сообщение может состоять из атрибутов форм одного или более классов.

Правило 1. Классы сообщений должны быть структурно иерархически взаимосвязаны. Корневой класс всегда должен быть определен. Создавая корневой класс предпочтительно ему дать имя БМ сообщения, например при моделировании EDIFACT сообщения CusDec (таможенная декларация), классу предпочтительно дать имя CustomDeclaration. Ниже изображен формальный UML класс - CustomDeclaration

Секции и подсекции в БМ могут быть разделены на категории по:

Ниже приведен пример создания корневой секции сообщения CusDec. В таблице приняты следующие сокращения:

Секция А – Message Information (информация о сообщении)

Аналогичным образом строятся остальные секции БМ.

Правило 2. Создать класс сообщений для каждой необязательной секции. Имя класса сообщений должно быть эквивалентно имени секции.

Секция категорий списка ролей будет формироваться не из класса сообщений, но имя роли будет позже использоваться при создании соответствий (ассоциаций).

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

Правило 3 (необязательное). Секция может быть перенесена, при соблюдении следующих условий:

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

Правило 4. Создание единственной ассоциации (соответствия).

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

“Соответствие” в сообщение имеет только одно направление – от родительского класса к дочернему. Возможно представления множественных соответствий. Множественные соответствия записываются как Min..Max Например по одной таможенной декларации возможно провести от одного до … (десяти) контейнеров. В этом случае соответствия представится как 0..9. Множественность должна описываться в конце дочерней секции.

Правило 5. Создание множественного соответствия.

Множественные соответствия создаются для класса сообщений, включающие подсекции категории списка ролей.

Каждое множественное соответствие дает свое имя роли. Имя роли определяется как имя терма данных в подсекции категории списка ролей. Каждое имя роли будет заменено дочерним именем класса, сгенерированным в XML/DTD или схемы XML. Использование нотации UML “+” показывает, что имя роли имеет атрибут “public”. На рисунке ниже изображено альтернативное изображение UML модели.

Данная техника моделирования может быть использована в основной модели при моделировании ролей. Однако она не может быть использована при моделировании самого сообщения, т.к. наследование увеличивает комплексный уровень генерации описаний тагов XML.

Данные термов в секции могут быть категоризированны как: необязательный терм данных, имя роли и значение кода (см таблицу 2). Возращаясь к примеру в таблице 2 значение терма (терм кодов) A1-3 (Customs procedure ) в справочнике кодов 8323 имеет значение 1- export и 2- import, значение CU для роли A1-7 (Consignor reference number ) по справочнику кодов 1153 , а значение для данных A1-2 (Document issue date ) является датой принятия документа (например 12/12/2000).

Правило 5. Создание атрибутов для термов данных и кодов значений.

Атрибут создается для каждого необязательного терма данных и располагается в классе сообщения, соответствующего атрибуту секции. Секция, состоящая из кодов значений, должна быть преобразована в один атрибут, который всегда имеет значение соответствующее списку кодов. Ниже приведен пример для секции A3 “Идентификация EDIFACT сообщения”

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

Тип данных используется в создании XML схемы и может иметь допустимые значения соответствующие определению схемы XML.

Множественность – используется в создании XML/DTD или схемы XML. Допускаются следующие два значения:

Допустимые значения используют определение одного или более допустимых значений кодов атрибутов. Например:

Эти значения всегда используются при создании XML/DTD или схемы XML.

Бизнес правила могут быть определены для более сложных зависимостей в БМ. Хотя бизнес правила не используются при создании XML/DTD или XML схемы.

Комментарии о терме данных в БМ могут быть скопированы как комментарии атрибутов. Оны будут использованы для документирования.

Стандартные ссылки представляют уникальный идентификатор какточеку определения стандартного атрибута т.е. номер тага элемента данных UN/EDIFACT. Они могут быть использованы для документирования, а также и при создании XML/DTD и схемы XML как альтернативных атрибут имени.

Ниже на рис. 4 приведена диаграма классов UML бизнес модели сообщения CusDec:

При автоматической генерации из БМ в XML/DTD или XML схема используется формальный алгоритм преобразования. Правила преобразования UML модели в XML/DTD или схеме XML осуществляюстя в соответсвии следующими правилами:

При создании XML/DTD или схемы XML БМ специфицируется последовательно по секциям, начиная с корневой, и далее с подсекции и термов данных и должны быть сохранены в модели сообщения. Соответствия и атрибуты должны быть смоделированы в некоторой последовательности. Это возможно только для атрибутов, исключая соответствия. Ниже приведен пример XML/DTD, полученный в результате моделирования секции сообщения Customs.

      Заключение