Проектування XML-словників за допомогою UML

Зміст



Спільнота розробників програм, системних інтеграторів, XML-аналітиків, авторів та розробників B2B-словників відразу ж відреагувало на публікацію Специфікації W3C XML Schema. Деякі раділи більше багатою структурі та семантиці, яка може бути виражена за допомогою нових схем у порівнянні з DTD, інші ж навпаки говорили про надмірну їх складності. І багато зійшлися на тому, що результуючі схеми складні для широкої аудиторії користувачів і бізнес-партнерів.


З усіх різних підходів до XML Schema, мені зручніше розглядати її просто як синтаксис для реалізації моделей бізнес-словників. Найчастіше при створенні нових словників або спільне використання з користувачами вже визначених інші форми представлення моделей більш ефективні, ніж W3C XML Schema. Зокрема, я вважаю за краще використовувати уніфікована мова моделювання UML, як широко застосовуваного стандарту для специфікацій систем та проектування. Публікацією цього циклу статей я хотів би донести до читачів деякі свої міркування про те, як ці два стандарти доповнюють один одного і спільно працюють. Для того, щоб зробити виклад більш зрозумілим, я збудував його на основі простого прикладу.


Хоча в цій статті йде мова про специфікацію W3C XML Schema, аналогічні міркування вірні і для інших мов схем XML. Насправді, я вже застосовував подібні технології при створенні і реинжиниринге DTD і схем SOX також, як і при використанні RELAX, TREX, і RELAX NG. Загалом, коли я використовую термін "схема", я маю на увазі не якийсь конкретний мову, а сімейство мов схем XML.


Роль моделей в XML-додатках


Великі корпоративні системи часто складні для розуміння. У таких випадках часом необхідно розбити вихідну проблему на безліч допоміжних подмоделей, що представляють різні точки зору. У кожній з цих подмоделей цілеспрямовано ігноріруютя деякі аспекти системи, які не відносяться до їх сфери застосування. Така декомпозиція є фундаментальним способом впоратися зі складністю реального світу, опускаючи непотрібні деталі, що заважають нам сконцентруватися на самій задачі. До того ж командам, які працюють з системою на різних етапах, потрібні моделі з різним ступенем абстрагування.


У контексті системної інтеграції рівня B2B, всі бізнес-партнери повинні домовитися про спільну інформаційної моделі, в рамках якої був би визначений словник для комунікації, орієнтований на конкретні завдання. Моделі включають як структуру даних для XML-документів, які беруть участь у документооброте, так і процеси, що моделюють розширені діалоги, що вимагаються для виконання складних бізнес-транзакцій.


Історично, в системному аналізі та проектуванні існували різні технології, інструменти та методики для управління та підтримки подмоделей системних структур і поводжень. У відсутність формальних методів та інструментів для того, щоб забезпечити взаємодію розробників будующей системи, створювалися моделі за допомогою PowerPoint, Visio або навіть за допомогою паперу та олівця. Якщо ж немає явно записаних моделей, то системні архітектори вдаються до використання інтуїтивних подмоделей, що дозволяють охопити ціле і частини основної моделі. Схема XML також є моделлю словника, записаної в синтаксисі мови цієї специфікації.


Високо-рівневий підхід до розробки XML-словників показаний на малюнку 1. Вона включає в себе три точки розгалуження, які обумовлюють кінцеве визначення словника, незалежно від того, яка мова схем використовувався. Data-і text-орієнтовані програми повинні відповідати різним вимогам. Наприклад, data-орієнтовані словники можуть бути оптимізовані під побудову послідовності об'єктів або під результати запитів до баз даних, і їх внутрішні зв'язки повинні точно відповідати типам даних. Документи, які відповідають таким data-орієнтованим словникам, можуть бути ніколи не прочитаними людьми, хіба тільки розробниками, тестуючими додатки.


Навпаки, інформація, записана за допомогою text-орієнтованих словників, часто безпосередньо використовується людьми. При цьому доводиться ред XML-документи, як за допомогою так і без допомоги візуальних засобів редагування. Структура таких документів повинна бути проста, щоб їх могли зрозуміти люди, які пишуть таблиці стилів для трансформації та представлення вмісту документів. XML-додаток, ідеально відповідне для роботи з даними, іноді може викликати у користувача абсолютно непотрібну головний біль. Не забувайте про потреби ваших користувачів, коли будете створювати XML-схему!

Рис. 1: Діаграма діяльності UML для процесу розробки схеми


Діаграма процесу, зображена вище, є діаграмою діяльності UML, однією з дев'яти типів, визначених стандартом. Ця діаграма була створена в пакеті Rational Rose, одному з найбільш широко використовуваних інструментів для UML-моделювання. Проте, більшість з наших міркувань базується на діаграмі класів UML, яка використовується для визначення статичної інформаційної структури XML-словника конкретної системи в контексті нашого застосування.


Що таке UML?


Уніфікована мова моделювання (Unified Modeling Language, UML) визначає стандартний мова та графічну систему позначень для створення моделей бізнес і технічних систем. Всупереч широкораспространенной думку, UML є інструментом не тільки для програмістів. UML визначає типи моделей, які покривають проміжок від функціональних вимог і бізнес-моделей до проектування структур класів і діаграм компонент. Такі моделі, і процес розробки, що використовує їх, покращують і спрощують комунікацію між багатьма різними групами виконавців.


Діаграма класів UML може бути побудована для візуального представлення елементів, взаємин і внутрішніх зв'язків XML-словника. Після невеликого навчання, використання діаграм класів дозволяє використовувати складні словники спільно з нетехнічними групами виконавців. Дуже просте підмножина словника для каталогу продуктів показано у вигляді діаграми класів на малюнку 2.

Рис. 2: Проста діаграма класів UML


Основні елементи діаграми класів UML наступні.



Концептуальні моделі XML-словників


Тепер, коли ви розумієте найпростіші діаграми класів UML, давайте застосуємо їх для проектування більш великих XML-словників. Ми будемо працювати зі словником для мови замовлень, який визначався в розділі 2.1 документа XML Schema Part 0: Primer і далі використовується у всій специфікації W3C. У нашій моделі додатково визначені міжнародні адреси і підтримка декількох схем, як описано в розділі 4.1 специфікації W3C. Якщо ви новачок у XML Schema, я раджу вам переглянути Primer після читання цієї статті і потім порівняти наш UML-процес проектування в цих трьох статтях з аналогічним словником для мови замовлень у специфікації схеми.


Словник для мови замовлень визначається в двох модулях, відповідних основного типу PurchaseOrder і окремому модулю Address. У UML такі модулі називаються пакетами. Специфікація першого пакету показана на діаграмі класів UML на малюнку 3. Клас PurchaseOrder має два атрибути та три асоціації, які визначають його структуру. Деякі з цих атрибутів включають потужність, певну символами [0 .. 1], маючи на увазі, що значення цих атрибутів опціонально та приймає значення або 0, або 1.


Клас Address грає роль як shipTo, так і billTo в асоціації з PurchaseOrder. (Зауваження: може статися, що shipTo і billTo є дочірніми елементами в схемі.) Потужність 1 позначає, що для кожного PurchaseOrder повинен існувати рівно 1 адресу. Зауважимо, що в класі Item quantity має тип QuantityType. Це тип визначений як інший клас в UML-моделі. На тій же діаграмі QuantityType визначено як підклас класу positiveInteger, який оголошується як приходить з пакету XSD_Datatypes в цій UML-моделі. Таким чином, quantity є спеціальним типом позитивних цілих чисел.


І QuantityType, і SKU є певними користувачем типами даних, і обидва включають атрибути, що обмежує їх область використання. Атрибути pattern і maxExclusive є заданими значеннями і використовуються на наступних етапах процесу проектування для управління створенням XML Schema. Нарешті, ім'я класу Address показується курсивом; це означає, що це абстрактний клас, і що він не призначений для безпосереднього використання. Як далі буде видно, Address крім того визначається в інших діаграмах класів UML.

Рис. 3: Концептуальна модель словника замовлень покупок


Специфікація пакету Address, зображена на унке 4, слід подібній логіці. На цій діаграмі USAddress і UKAddress є підтипами Address. У термінах об'єктно-орієнтованого підходу це означає, що обидва цих підтипу успадковують три атрибути, визначені в їх суперкласі. Атрибут exportCode класу UKAddress ініціалізується зі значенням 1.

Рис. 4: Компонент схеми Modularized Address


Проектування моделей схем XML


Тепер, коли ми створили концептуальну модель змісту нашого XML-словника і отримали схвалення від усіх бізнес і технічних груп виконавців, що далі? Як було відмічено в попередньому розділі, на етапі відображення нашої моделі в XML schema є ряд варіантів.


Чи відображаються UML-атрибути і кінці асоціацій в XML-атрибути або елементи? Як узагальнення класів і типів даних UML відображається в визначення схеми? Як на це відображення вплине зміна цільового мови схеми з W3C XML Schema на RELAX NG? Як щодо DTD?


Якщо ви повернетеся трохи назад до процесу розробки схеми, зображеному на унке 1, наступне завдання проектування залежить від того, чи буде наш словник data-або text-орієнтованим. Так як словник для мови замовлень є data-орієнтованим, більшість залишилися рішень проектування має відношення результатами впровадження: угоди розробників по використанню XML-атрибутів або дочірніх елементів, відповідність типів даних з іншими точками входу і виходу даних, якими повинні обмінюватися при використанні цього словника, і предполагемие майбутні вимоги для розширення цього словника або комбінування його з іншими просторами імен XML.


Якщо це було б text-орієнтованим додатком, то контент-менеджери й автори мали б додатковий підхід при виборі способу розробки. Наприклад, більшість авторів вважають за краще уникати в XML-документах надмірного використання контейнерних елементів, для групування пов'язаних елементів, в той час як це є нормальним підходом у data-орієнтованих додатках. Також, порядок елементів у документі найчастіше більш важливий для людей, ніж для додатків, що здійснюють аналіз даних.


Основною ідеєю цієї статті був огляд концептульной моделі словника, побудова якої є першим логічним етапом у процесі розробки. Наступна стаття цього циклу представляє список способів розробки та альтернативних підходів для відображення UML у W3C XML Schema. Модель UML, представлена в цій статті, буде доопрацьована для того, щоб відобразити способи розробки, виконані авторами W3C "s XML Schema Primer, звідки взято цей приклад. Для наших цілей, ці автори є співрозробник системних вимог.


У третій статті бидет введений UML-профіль для схем XML schemas, що дозволить додати всі способи детальної розробки до визначення моделі і потім використовувати їх для автоматичного породження завершеною схеми. Результатом буде UML-модель, яка використовується для породження W3C XML Schema. Отримана схема може бути використана для успішної перевірки на коректність прикладів XML-документів, взятих з специфікації Schema Primer. Попутно, я введу веб-інструментарій, використовуваний для породження схем з UML і реінжінеріінга схем в UML.


Три поради на майбутнє


Щоб допомогу вам при здійсненні ваших майбутніх проектів, я пропоную наступний ряд порад:



Моделі – це невід'ємні частини аналізу і проектування, навіть якщо вони існують лише в голові розробника. Використовуючи UML для створення концептуальної моделі планованого словника, ми можемо окреслити суттєві моменти і взаємозв'язку, не потрапивши в пастку синтаксичних проблем вибраної мови схем. Фактично, групи розробників галузевих стандартів можуть використовувати UML для первинного визначення їх словників, а остаточний вибір мови (або мов) схем залишити тим, хто вже безпосередньо буде займатися їх реалізацією.


Я також хочу підкреслити, що підхід до розробки схеми, що базується на моделях і описаний в цьому циклі статей, набагато ближче до ітераційної методології розробки, а не до каскадної. Перша схема, створена із застосуванням правил відображення, використовуваних за замовчуванням, з моделі словника замовлення покупок, може бути і не ідеальна, але вона точно схоплює семантику модельованої області. У третій частині цього циклу статей описується, як модель може бути спеціалізована з урахуванням особливостей проектування, унікальних для XML-схем. Цей підхід відповідає сучасній методології швидкого програмування та моделювання, де моделі виконують дуже прагматичну роль у процесі розробки. (Див. XMLmodeling.com, веб-портал, який я створив, щоб об'єднати дані конкретних досліджень і ресурси з моделювання).


Для того, щоб досягти цих досить високих цілей, важливо, що ми маємо повні і гнучкі специфікації відображення між UML і схемами XML. Наведені нижче приклади не представляють завершеної картини, але є спробою ввести вас в лабіринт термінології UML і W3C XML Schema Definition Language (надалі я буду його називати XSD).


Відображення UML-моделей в схеми XML


Саме це є ключовим моментом використання UML при розробці XML-схем. Основною метою, що визначає специфікацію такого відображення, є забезпечення його достатньою гнучкістю, щоб покрити більшість вимог до розробки схем, але при цьому зберегти "м'який" перехід від концептуальної моделі словника до його детального опрацювання і подальшої реалізації.


Споріднена мета – створити умови для автоматичної генерації коректної XML-схеми з будь-якої діаграми класів UML, навіть якщо той, хто моделює не знайомий з синтаксисом XML-схем. Наявність такої можливості допускає швидкий процес розробки і підтримує багаторазове використання моделей словників для різних мов реалізації або оточень, оскільки сама модель не надто прив'язана безпосередньо до XML.


Відзначте, будь ласка, що приклади схем у цій статті не повністю можна порівняти з відповідним прикладом у XML Schema Primer. Тим не менш, наступні фрагменти схем є коректними інтерпретаціями концептуальної моделі. Третя стаття цього циклу продовжить процес удосконалення аж до логічного завершення, коли результуюча схема зможе підтвердити приклад з XSD Primer.


Концептуальна модель для нашого словника замовлень показана на рисунку 5, вона відтворена з першої статті з дуже невеликими змінами. Ми разоб'ем цю діаграму на головні структури і відобразимо кожну її частину на мову W3C XML Schema. Я зазначу кілька випадків, де можливі інші альтернативи, і також вкажу, де результуюча схема відрізняється від прикладу з XSD Primer.

Рис. 5: Концептуальна модель словника замовлень покупок


Клас і атрибут


Клас у UML визначає складну структуру даних (і відповідна поведінка), яка за замовчуванням відображається в complexType в XSD. На першому етапі клас Purchase Order і його UML атрибути створюють наступне визначення XML Schema:



<xs:complexType name=”PurchaseOrder”>
< xs:all>
< xs:element name=”orderDate” type=”xs:date”
minOccurs=”0″ maxOccurs=”1″/>
< xs:element name=”comment” type=”xs:string”
minOccurs=”0″ maxOccurs=”1″/>
< /xs:all>
< /xs:complexType>


Атрибути в UML-класі не мають визначеного порядком, тому для створення невпорядкованою групи використовується елемент XSD <xs:all>. Крім того, клас UML створює різні простори імен для імен своїх атрибутів (наприклад два класи можуть містити атрибути, що мають однакові імена), так що вони створюються у схемі як локальні визначення елементів. Для більш широкого ознайомлення з цією темою дивіться A New Kind of Namespace. Обидва атрибуту в нашій моделі UML не обов'язкові, що показано на Малюнку 1 як [0 .. 1]. Ці значення відображаються в атрибути minOccurs і maxOccurs в XSD. UML-атрибути визначалися за допомогою найпростіших типів даних із специфікації XSD, так що вони записуються прямо в результуючу схему з використанням відповідного префікса простору імен. Якщо ж у моделі UML використовуються інші типи даних, то для використання цих типів в схемі може бути створена бібліотека типів XSD. Наприклад, я створив бібліотеку типів XSD для найпростіших типів мови Java і для найпростіших класів Java таких, як Date, String, Boolean, і т.д.


Корисно помітити, що елемент верхнього рівня автоматично створюється у схемі для кожного complexType. За замовчуванням ім'я для цього елемента таке ж як і ім'я класу, – це можливо в W3C XML Shema, оскільки використовуються різні простори імен усередині однієї схеми для complexType і для елементів верхнього рівня. Для PurchaseOrder елемент верхнього рівня схеми складається наступним чином:


<xs:element name=”PurchaseOrder” type=”PurchaseOrder”/>


Якщо ви звернетеся до прикладу в XSD Primer, ви побачите, що orderDate моделюється як XML-атрибут, а не як дочірній елемент PurchaseOrder. Крім того там використовується группирующих елемент <sequence> замість <all>. І, по-третє, елемент верхнього рівня визначався в Primer за допомогою малої першої літери, тобто purchaseOrder (його часто називають форматом "lower camel case"). Тут я адресую вас до третьої статті, де використовується UML profile / * профілі * / для розширення відображень на схеми XML.


Асоціація


Тип PurchaseOrder в нашій моделі визначався не лише за допомогою атрибутів UML, але також своїми асоціаціями з іншими класами в моделі. На рисунку 1 показані три асоціації, в яких бере участь PurchaseOrder. У кожної асоціації є роль і потужність, які точно визначають ставлення з цільовим класом. Ці асоціації додаються до групи complexType в XSD разом з елементами, створеними з атрибутів UML.



<xs:complexType name=”PurchaseOrder”>
<xs:all>
<xs:element name=”orderDate” type=”xs:date”
minOccurs=”0″ maxOccurs=”1″/>
<xs:element name=”comment” type=”xs:string”
minOccurs=”0″ maxOccurs=”1″/>
<xs:element name=”shipTo”>
<xs:complexType>
<xs:sequence>
<xs:element ref=”Address”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=”billTo”>
<xs:complexType>
<xs:sequence>
<xs:element ref=”Address”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name=”items” minOccurs=”0″ maxOccurs=”1″>
<xs:complexType>
<xs:sequence>
<xs:element ref=”Item”
minOccurs=”0″ maxOccurs=”unbounded”/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
< /xs:complexType>


Оскільки UML-атрибути для orderDate і comment мають найпростіші типи даних, схема включає їх у себе в якості змісту елемента. Однак, за замовчуванням при відображенні для асоціацій у XSD створюються покривають елементи згідно з ім'ям ролі в UML. Крім того ці елементи містять вимоги до асоційованого класу, до якого схема звертається за допомогою елементу верхнього рівня, створеного для кожного complexType.


Якщо ви хочете створити W3C XML Schema, використовуючи модель змісту <all>, то покриває елемент буде необхідний завжди, коли асоційований клас має більше одного випадку. Причина в тому, що <all> може бути використаний тільки, коли внутрішні елементи мають потужність або [0 .. 1], або [1 .. 1]. Так, коли створюється покриває елемент для асоціації з Item, елемент, який називається item, може мати або нуль, або одну реалізацію, яка, у свою чергу, містить нуль, або більше елементів Item всередині себе.


Різниця між схемою, створеної за допомогою правил за замовчуванням з UML, і схемою, включеної до XSD Primer в тому, що ролі shipTo і billTo в Primer містять пряму вказівку на адресу, без звернення до елементів асоційованого класу. Іншими словами, дочірні елементи для імені, вулиці, міста і т.д. містяться прямо в shipTo і billTo. Цей альтернативний підхід ми ще раз додатково висвітлимо в третій статті.


Тип даних, визначений користувачем


За замовчуванням при відображенні в XSD має генеруватися визначення complexType для SKU і QuantityType, але ми хочемо, щоб це відбувалося, як визначення користувачем простих типів даних в XML-схемі. Цього достатньо просто домогтися, додавши UML-стереотип, який показаний як <<XSDsimpleType>> на рисунку 1, у кожний з цих двох класів. Ця можливість включення стереотипів є невід'ємною частиною стандарту UML і використовується для формального визначення додаткових характеристик моделі, які, як правило, унікальні для кожної конкретної області, в нашому випадку, унікальні для проектування XML-схеми.


Використовуючи стереотип, генератор схеми знає, як створити наступне визначення для SKU:



<xs:simpleType name=”SKU”>
<xs:annotation>
<xs:documentation>Stock Keeping Unit, a code
for identifying products</xs:documentation>
</xs:annotation>
<xs:restriction base=”xs:string”>
<xs:pattern value=”d{3}-[A-Z]{2}”/>
</xs:restriction>
< /xs:simpleType>


Крім того, UML-модель може включати документацію для кожного елемента моделі. Така документація приводиться у визначенні схеми XML, як показано в цьому прикладі. Узагальнене ставлення UML показує, які існуючі прості типи даних повинні бути використані в якості основи для визначається нового типу. Зрештою, атрибут pattern в SKU, відображений у формат XSD, змушений прийняти як значення рядок SKU.


Другий модуль у визначенні схеми purchase order представляє повторно використовуваний набір формальних визначень для адрес (це показано на малюнку 6). Ці визначення запозичені з розділу 4.1. в XSD Primer. У нашій моделі успользуются два додаткових конструктора схеми, на додаток до використаних при складанні схеми на малюнку 5.

Рис. 6: Компонента схеми Modularized Address


Узагальнення


Узагальнення – це Фундаментальне і поширене поняття в об'єктно-орієнтованому аналізі і проектуванні. Спеціалізовані підкласи успадковують атрибути та асоціації від всіх батьківських класів. Це легко представляється у W3C XML Schema, хоча вимагає більш витончених механізмів при використанні інших мов XML-схем.


На Малюнку 2 клас Address, позначений курсивом, що використовується в UML для позначення абстрактного класу, призначається тільки для визначення інших спеціалізованих класів. Дотримуючись тими ж правилами, використовується за умовчанням для PurchaseOrder, визначення complexType для Address і USAddress створюються наступним чином:



<xs:element name="Address" type="Address" abstract="true"/>
< xs:complexType name=”Address” abstract=”true”>
<xs:all>
<xs:element name=”name” type=”xs:string”/>
<xs:element name=”street” type=”xs:string”/>
<xs:element name=”city” type=”xs:string”/>
</xs:all>
< /xs:complexType>


<xs:element name=”USAddress” type=”USAddress”
substitutionGroup=”Address”/>
< xs:complexType name=”USAddress”>
<xs:complexContent>
<xs:extension base=”Address”>
<xs:all>
<xs:element name=”state” type=”USState”/>
<xs:element name=”zip” type=”xs:positiveInteger”/>
</xs:all>
</xs:extension>
</xs:complexContent>
< /xs:complexType>


Тут три відмінності від минулих прикладів. По-перше, елемент верхнього рівня та визначення complexType для Address включають XSD-атрибут abstract = "true". По-друге, елемент USAddress включає в себе substitutionGroup = "Address"; це означає, що кожного разу, коли елемент Address запитується в якості елемента змісту, USAddress може бути замінений. Таким чином, ми можемо використовувати USAdress (або, аналогічно, UKAdress), як зміст shipTo і billTo в PurchaseOrder.


По-третє, визначення complexType для USAddress поширюється з основного complexType для Address. У цьому і полягає дуже серйозне відмінність між тим, як ці структури успадкування інтерпретуються в UML і, як це відбувається в XSD. У UML порядок атрибутів і асоціацій всередині класу не має значення, а в підкласі характерні особливості, успадковані з батьківських класів, вільно перемішуються з локально визначеними атрибутами та асоціаціями. У XSD успадковані елементи трактуються як група, так що три елементи, успадковані з Address представляють із себе невпорядковану групу в USAddress, і слідують один за іншим поруч з іншого невпорядкованою групою з двох елементів, визначеної в USAddress. Ви не можете визначити пятіелементную групу, коли один або більше елемент успадкований.


Перераховується тип даних


Елемент state USAddress приписує визначення простого типу для USState. Це визначення проводиться з UML-перерахування. На Малюнку 2 USState показаний разом зі стереотипом <<enumeration>>, що сповіщає генератора схеми про необхідність створити XSD-перерахування для кожного атрибуту, визначеного для даного класу. Перераховується тип в XSD, це всього лише спеціалізований вид визначень simpleTipe, так що він повинен ще вказувати суперклас в UML, щоб використовуватися як базовий тип в XSD. Виходить наступна схема:



<xs:simpleType name=”USState”>
<xs:restriction base=”xs:string”>
<xs:enumeration value=”AK”/>
<xs:enumeration value=”AL”/>
<xs:enumeration value=”AR”/>
<xs:enumeration value=”PA”/>
</xs:restriction>
< /xs:simpleType>


Висновок


Правила відображення за замовчуванням, описані в цій статті, можуть бути використані для створення повної XML-схеми з будь-якої діаграми класів UML. Це, може бути, що раніше існувала модель застосунку, яка зараз повинна використовуватися в рамках архітектури веб-сервісів XML, або це може бути модель нового XML-словника, обумовлена в якості стандарту для обміну даними рівня B2B. У будь-якому випадку, схема, отриману за допомогою цих правил, забезпечує зручний спосіб отримання першого наближення, яке вже може бути негайно використана в первинному розгортанні програми, хоча і може зажадати деякого доопрацювання для відповідності іншим архітектурним і проектним вимогам.


Перша стаття цього циклу присвячена процесу розробки схеми, в ній підкреслювалося відмінність між створенням для data-орієнтованого і для text-орієнтованого пріложенія.Правіл відображення за замовчуванням часто достатньо для data-орієнтованих додатків. Фактично, ці правила відповідають специфікації OMG XML Metadata Interchange (XML) 2.0 для використання XML як формат обміну моделями. Цей підхід ще добре реалізований разом з новою ініціативою OMG за Model Driven Architecture (MDA).


Text-орієнтовані схеми, і будь-яка інша, яка може бути ким-небудь придумана і використана для утримання для веб-порталів, часто повинні бути вдосконалені, щоб спростити структуру XML-документів. Наприклад, багато проектувальників схем усувають покривають елементи, відповідні ролі ассоцииации (але це також попереджає використання групує елемента XSD <all>). Ця доробка, а також багато інших, можуть бути визначені в моделі словника шляхом приміщення нового параметра за замовчуванням для одного пакету UML, який потім застосовується до всіх містяться в ньому класів.


У цій статті ми розглянули два приклади стереотипів UML, які були створені, щоб відзначити спеціалізоване використання класу UML. Більш узагальнено, ці стереотипи й асоційовані з ними значення властивостей є частиною UML-профілю для XML-схем, який я спочатку розробляв у рамках моєї книги про моделювання додатків XML. Третя стаття цього циклу являє додаткові приклади використання інших стереотипів для уточнення результуючої схеми. Також я запропоную вашій увазі опис інструментів, які були нами розроблені. Ці інструменти являють повний UML-профіль для пректирования схеми та перетворення будь-якої моделі класу UML або в W3C XML Schema, або в граматику OASIS RELAX NG.


Поради на майбутнє


Для того, щоб полегшити вам застосування викладених ідей на практиці при виконанні власних проектів, я пропоную такі корисні поради.



Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*