Моделирование XML-словарей с помощью UML, часть I

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

• Класс (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 не содержит наследования класса, эта структура является фундаментальной для объектно-ориентированной модели и включена в следующий расширенный пример.