Дэвид Карлсон

Сообщество разработчиков программ, системных интеграторов, 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-схему!

Диаграмма процесса, изображенная выше, является диаграммой деятельности UML, одной из девяти типов, определенных стандартом. Эта диаграмма была создана в пакете Rational Rose, одном из самых широко используемых инструментов для UML-моделирования. Однако, большинство из наших рассуждений базируется на диаграмме классов UML, которая используется для определения статической информационной структуры XML-словаря конкретной системы в контексте нашего приложения.

Что такое UML?

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

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

Основные элементы диаграммы классов UML следующие.

• Класс (Class) -- в этом примере определяется два класса: класс CatalogItem и класс Organization. Класс представляет совокупность структурных свойств и определяет пространство имен для обозначений этих свойств. Таким образом, оба класса могу содержать атрибут "name", но пространство имен, определяемое их классом делает эти два атрибута различными.
• Атрибут (Attribute) -- каждый класс может опционально определять множество своих атрибутов. Каждый атрибут имеет тип; в этом примере string, double, и float в соотвествии со встроенными типами данных, как определено в спецификации XML Schema. Для тех из вас, кто уже задумывется о проектировании схемы XML, определенными в UML атрибуты не ограничиваются атрибуты в схеме XML; отображение в синтаксис схемы позволяет определить или атрибут XML или дочерний элемент.
• Операция (Operation) -- операция computeTax() внутри CatalogItem частично отражает поведение этого класса. Другими словами, что класс может делать, кроме непосредственно определения структуры своих данных? Выражаясь объектно-ориентированной терминологией, если вы отправите сообщение computeTax объекту CatalogItem, то будет возвращено значение типа float. Эта операция не ожидает каких-либо параметров, но они могут быть определены между круглыми скобками. Мы не будем использовать операции класса в спецификации XML-словаря, но их определение может быть критично для веб-сервисов, особенно для спецификации WSDL сообщений SOAP.
• Ассоциация (Association) -- ассоциация является взаимоотношением двух или более классов в модели. Хотя отношения ассоциации по умолчанию двунаправленное, часто накладываются ограничения на направление навигации. В этом случае на конце ассоциации рисуют стрелку.
• Роль и Мощность (Role & Multiplicity) -- также на конце ассоциации может определяться роль класса; Organization играет роль поставщика для CatalogItem в нашей модели. Дополнительно, "1..*" обозначает мощность, в смысле, что может быть один или более поставщиков для каждого пункта каталога.
• Обобщение (Generalization) -- хотя иллюстрация 2 не содержит наследования класса, эта структура является фундаментальной для объектно-ориентированной модели и включена в следующий расширенный пример.

Теперь, когда вы понимаете простейшие диаграммы классов 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.

Спецификация пакета Address, изображенная на иллюстрации 4, следует подобной логике. На этой диаграмме USAddress и UKAddress являются подтипами Address. В терминах объектно-ориентированного подхода это означает, что оба этих подтипа наследуют три атрибута, определенные в их суперклассе. Атрибут exportCode класса UKAddress инициализируется со значением 1.

Проектирование моделей схем 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.

Три совета на будущее

Чтобы помощь вам при осуществлении ваших будущих проектов, я предлагаю следующий ряд советов:

1. Ваш словарь для электронного бизнеса определяет соглашение или контракт между всеми заинтересованными сторонами. Получите начальные требования всех ключевых соучастников, используя визуальные модели UML для улучшения взаимопонимания.
2. Определите все известные термины, ассоциации и внутренние связи, а для документов их цель, источник и область использования. Не ограничивайте ваши спецификации использованием только выражений DTD или даже расширенного языка W3C XML Schema. Используя UML, вы можете получить полную спецификацию и затем преобразовать ее в любой язык схем XML. Фрагменты документации, добавленные в UML-модель, могут быть автоматически преобразованы в примечания в схеме XML.
3. Создавайте общую UML-модель, чтобы иметь возможность управлять определением схемы XML и другими неXML-компонентами системы. Многие системы используют XML в подмножестве их компонент, но анализ должен быть выполнен целостно.