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

В первой части этого цикла статей я подчеркнул, что модели — это неотъемлемые части анализа и проектирования, даже если они существуют лишь в голове разработчика. Используя 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.

Концептуальная модель для нашего словаря заказов показана на рисунке 1, она воспроизведена из первой статьи с очень небольшими изменениями. Мы разобъем эту диаграмму на главные структуры и отобразим каждую ее часть на язык W3C XML Schema. Я отмечу несколько случаев, где возможны другие альтернативы, и также укажу, где результирующая схема отличается от примера из XSD Primer.

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

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

Класс в 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. Этот альтернативный подход мы еще раз дополнительно осветим в третьей статье.