Преобразование Бизнес Модель в Модель сообщений
UML Модель сообщений специфицирована как тип сообщения и состоит из: классов сообщений, атрибутов и соответствий (ассоциаций). Эти термы формально определены в UML и представляют класс сообщений, который является подкласс формального класса UML. Эти термы используют различные формы обычного UML класса, т.к. сообщение может состоять из атрибутов форм одного или более классов.
Правило 1. Классы сообщений должны быть структурно иерархически взаимосвязаны. Корневой класс всегда должен быть определен. Создавая корневой класс предпочтительно ему дать имя БМ сообщения, например при моделировании EDIFACT сообщения CusDec (таможенная декларация), классу предпочтительно дать имя CustomDeclaration. Ниже изображен формальный UML класс - CustomDeclaration
Секции и подсекции в БМ могут быть разделены на категории по:
- простым секциям, т.е секция которая не категоризируется по списку ролей и списку значений;
- списку ролей - т.е секции содержат данные, являющимися именами ролей;
- списку значений - т.е секции содержат данные термов специальных кодов значений.
Ниже приведен пример создания корневой секции сообщения CusDec. В таблице приняты следующие сокращения:
O = Optional / Необязательный DE = элемент данных справочника UN/EDIFACT
R = Requred / Обязательный CL = значение из списка кодов справочника
D = Dependent / Зависимый
Секция А - Message Information (информация о сообщении)
| Наименование терма, ссылка на Элемент данных | O/R/D | Значение клалификатора, примечание | Элемент данных клалификатор |
| А 1 идентификация документа |   | ||
| A1-1 Document type coded | R | "914" = Customs declaration | CL 1001 - 335 |
| A1-2 Document issue date | R | CL 2005 - 137 | |
| A1-3 Customs procedure | R | 1 - export, 2 -import | CL 8323 |
| A1-4 Customs Declaration number | R | CL 3035 - CM | |
| A1-5 Carrier booking number | D | Primary key, if not CU | CL 1153 - BN |
| A1-6 Invoice reference number | D | CL 1101- 935 | |
| A1-7 Consignor reference number | D | Primary key, If not BN | CL 1153 - CU |
| A1-8 Reference to previous message | D | CL 1153 - ACW | |
| A1-9 Message sender | O | For return purposes | CL 3035 - MS |
| A1-10 Message receiver | O | For on-distribution | CL 3035 - MR |
| A2 функции сообщения | DE 1225 | ||
| A2-1 Original | D | CL 1225 - 9 | |
| A2-2 Replace | D | CL 1225 - 5 | |
| A2-3 Cancellation | D | CL 1225 - 1 | |
| A3 идентификация Edifact | |||
| A3-1 Message type | O | Fixed "CUSDEC" | DE 0065 |
| A3-2 Message type version | O | Fixed " D" | DE 0052 |
| A3-3 Message type release | O | Fixed "98A" | DE 0054 |
| A3-4 Controlling agency | O | Fixed "UN" | DE 0051 |
| A3-5 MIG identity | O | Fixed "SE0023" | DE 0057 |
| A3-6 Message reference number | O | DE 0062 |
Таблица 2
Аналогичным образом строятся остальные секции БМ.
Правило 2. Создать класс сообщений для каждой необязательной секции. Имя класса сообщений должно быть эквивалентно имени секции.
Секция категорий списка ролей будет формироваться не из класса сообщений, но имя роли будет позже использоваться при создании соответствий (ассоциаций).
Секция категорий списка значений должна формироваться не из класса сообщений, но позже она будет использоваться для создания атрибутов. При моделировании проще выбрать класс, если класс сообщений будет иметь один атрибут.
Правило 3 (необязательное). Секция может быть перенесена, при соблюдении следующих условий:
- максимальное кол-во соответствий = 1 (не повторяющихся), и
- существует только одна родительская ассоциация.
Перенос между секциями мог бы осуществляться в виде иерархических уровней, или дочерняя секция переносилась бы с ее родительской секцией.
Правило 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. Допускаются следующие два значения:
0..1 - для необязательных (optional) атрибутов
1..1 - для обязательных (mandatory) атрибутов
Допустимые значения используют определение одного или более допустимых значений кодов атрибутов. Например:
- Таможенный режим TypeDeclaration - 1 "export" , 2 "import"
- Вид перевозки EquipmentType - CN - контейнер, PL - паллеты;
Эти значения всегда используются при создании XML/DTD или схемы XML.
Бизнес правила могут быть определены для более сложных зависимостей в БМ. Хотя бизнес правила не используются при создании XML/DTD или XML схемы.
Комментарии о терме данных в БМ могут быть скопированы как комментарии атрибутов. Оны будут использованы для документирования.
Стандартные ссылки представляют уникальный идентификатор какточеку определения стандартного атрибута т.е. номер тага элемента данных UN/EDIFACT. Они могут быть использованы для документирования, а также и при создании XML/DTD и схемы XML как альтернативных атрибут имени.
Ниже на рис. 4 приведена диаграма классов UML бизнес модели сообщения CusDec:
Рис. 4
При автоматической генерации из БМ в XML/DTD или XML схема используется формальный алгоритм преобразования. Правила преобразования UML модели в XML/DTD или схеме XML осуществляюстя в соответсвии следующими правилами:
| Модель сообщения | XML/DTD | XML Sсhema |
| Имя класса корневого сообщения | Имя корневого элемента | Имя типа корневого элемента |
| Имя роли | Имя элемента | Имя типа элемента |
| Множественное соответствие | ?, *, +, (empty) | Соответствие min и max |
| Имя атрибута | Имя элемента | Имя типа элемента |
| Тип данных атрибута | - | Тип данных или макс. длинна |
| Атрибут множественности | ?, (empty) | Соответствие min и max |
| Значение атрибутов | допустимый список значений | Допустимый список значений |
<?xml version="1.0"> <!- section B 4 Customs --> <!ELEMENT Customs (CustomsIdentification, CustomsDetails) > <!ELEMENT CustomsIdentification (CustomsID ; код таможни CustomsRegion?, ; регион деятельности таможни CustomsType?, ; тип таможни CustomsPostName, ; наименование тамж.
Поста Address?)> ; адрес поста <!ELEMENT CustomsID (#PCDATA)> <!ELEMENT CustomsRegion (#PCDATA)> <!ELEMENT CustomsIype (#PCDATA)> ; "destination", "departure","border" <!ELEMENT CustomsPostName (#PCDATA)> <!ELEMENT CustomsDetalies (DataTimeRegistration, ; дата и время оформления TypeExamination?, ; вид досмотра SealExamination?, ; номер печати после досмотра InspectorName, ; ФИО инспектора SealNumber, ; номер личной печати TextDetalies?) > ; примечание <!ELEMENT DataTimeRegistration (Date, ; дата оформления Time?) ; время оформления <!ELEMENT TypeExamination (#PCDATA)> <!ELEMENT SealExamination (#PCDATA)> <!ELEMENT InspectorName (#PCDATA)> <!ELEMENT SealNumber (#PCDATA)> <!ELEMENT TextDetalies (#PCDATA) > <!ELEMENT Address (Province?, ; регион City, ; город Street?, ; улица HomeNumber?, ; номер дома OfficeNumber?, ; номер офиса Zip?)> ; почтовый индекс <!ELEMENT Date (#PCDATA) > <!ELEMENT Time (#PCDATA) > <!ELEMENT Province (#PCDATA) > <!ELEMENT City (#PCDATA) > <!ELEMENT Street (#PCDATA) > <!ELEMENT HomeNumber (#PCDATA) > <!ELEMENT OfficeNumber (#PCDATA) > <!ELEMENT Zip (#PCDATA) >
