Моделирование Элементов данных для Бизнес объектов.
Основой введения электронного бизнеса являются обмен электронными сообщениями, на основании которых осуществляются принятие решения по проведению операций при торговых сделках. В качестве базовой структуры сообщения используется опыт при создании сообщений стандарта UN/EDIFACT. В итоге моделирования необходимо получить описания структуры сообщения в виде структуры XML/DTD или XML-схемы.
На рис 3. изображена трехступенчатая схема реализации модели сообщения.
Рис 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:
____________________________________________________________________________ <?xml version="1.0"> <!-BGM : Beginning of Message --> <!ELEMENT MessageId (#PCDATA) > <!ATTLIST MessageId UN-EDIFACT:Segment CDATA #FIXED "BGM" UN-EDIFACT:Attributes CDATA #FIXED "1001 MessageTypeCode 1060 RevisionNo 1225 MessageFunction 4343 ResponseType" MessageTypeCode CDATA #FIXED "CustomsDeclaration" RevisionNo CDATA #IMPLIED MessageFunction (%Confirmation; "Original" ResponseType (%Response;) "Accepted" Constraints CDATA #FIXED "an..35" > ____________________________________________________________________________
Подходя комплексно к моделированию всего сообщения, используются как информация из базовых сегментов, таких как NAD, RFF, DOC и пр., так и учитывается их семантика и месторасположение.
При создании Бизнес модели используются следующие принципы:
- Бизнес модель разделена на следующие секции: реквизиты сообщения, стороны, таможенные отметки, упаковка, товары, документы, коды;
- основные сегментные группы или сегменты корневого уровня должны соответствовать секции БМ.
- термины данных БМ могут порождаться из других элементов данных EDIFACT или из значения кодов для определенных элементов данных;
- подсекции бизнес модели должны быть основаны в соответствии с надобностями, понимания бизнес операций. Это не обязательные предлагаемые структуры составных элементов данных или группы сегментов;
- Использование термина данных в БМ на уровне кодов данных сслылается на свю "концепцию кода"
- имена БМ должны быть специфицированы достаточным для понимания;
- в БМ использовать смысловую семантику, так например таг, описывающий перевозимые товары может именоваться GoodItems
- дублирование имен недопустимо.
