1. Пример диаграммы классов с ограничениями

На рис.3.1 приведена диаграмма классов UML, описывающая модель адреса. Данная диаграмма взята из реального проекта с незначительными упрощениями.

Рисунок3.1 Диш рячмя классом UML для ялрсса

Адрес, в рамках данной модели, может ссылаться на страну, область, насспснный пункт, район и улицу. При этом населенные пункты (города) могут как входить в состав областей, так и принадлежать непосредственно стране (например, в России городами федерального подчинения являются Москва и Санкт-Петербург). Крупные города могут быть разделены на районы, при этом улицы связаны с районами отношением «многие ко многим» - на диаграмме это отношение представлено отдельным классом «Связь городских районов и улиц».

Очевидно, что между этими связями имеются некоторые зависимости — например, адрес не может ссылаться на страну «Россия» и город «Вашингтон». Перечислим ограничения на связи с другими объектами, которым должен удовлетворять адрес:

• Область, если она указана, должна принадлежать гой же стране, что и адрес.

• Если у адреса указана область, то населенный пункт должен принадлежать ей, в противном случае он должен принадлежат ь стране.

• Городской район, если он указан, должен принадлежать населенному пункту адреса.

• Если у адреса указаны улица и район, то они должны быть связанны отношением «Связь городских районов и улиц».

• Если указана улица, то она должна принадлежать населенному пункту адреса.

Опишем перечисленные выше ограничения на языке ОСЬ [103]:

1. context Адрес inv: Адрес.Область-^notErnptyO implies

Адрес.Страна->по1Ешр1уО AND

Адрес.Страна.Обласгь ->includes(AApcc.06.3acTb)

2. context Адрес inv: Адрес.Населенный nyHKr-»notEmpty() implies

(Адрес.Об.ч;к:ть->по1Птр1уО AND

Адрес.Облдсть.Насслснный nyHKT-Hncludes(Адрес.Населенный пункт))

OR

(Лдрсс.Область-HsEmptyOAND

Адрес. Страна. Населенный пункт->includes^pec.Населенный пункт) )

3. context Адрес inv: Адрес.Городской pafioH->notEmpty() implies

Адрес.Населенный nyHKT->notEmptyO AND

Адрсс.Населенный пуикт.Городской pafloH->includes( Адрес.Городской район)

4. contcxt Адрес inv:

Адрес. Городской paiioti->nolF.mply() AND

Адрес.Улица-^notEmptyO implies

Адрес.Городской район.Связь городских районов и улиц.

Exists<p | р.Улица ■ Адрес.Улица)

5. contcxt Адрес inv: Адрес.Улица-^notEmptyO implies

Адрсс.Город—»notEmptyO AND

Ад pec.Город.Улнца-мпс1ис1с$( Адрсс.Улица)

В следующих разделах будет показано, как эти ограничения можно описать в рамках предлагаемого подхода.

2. Альтернативные подходы

Вопросы поддержания целостности и непротиворечивости данных в информационных системах давно и устойчиво интересуют исследователей в области создания ИС [75,102]. Ограничения уникальности по ключу, ограничения ссылочной целостности и запрет на использование неопределенных значений включены в стандарт SQL [52] и поддерживаются всеми современными промышленными СУБД. Однако для описания более сложных ограничений до сих пор нет общепринятого подхода. Большинство исследователей предлагают использовать дня этой пели различные текстовые языки, основанные на логике предикатов [41,72]. Авторы объектно- ориентированного языка моделирования UML [90] ввели в его состав формальный текстовый язык ограничений OCL [ЮЗ]. Существуют исследования, посвященные его применению, в частности, для спецификации ограничений в 6а tan данных [53]. Однако, если разрабатываемая система моделируется с помощью диаграмм, представляется предпочтительным иметь диафаммный язык для описания ограничений, которые являются составной частью разрабатываемой модели.

1. Visual OCL

Я зык Visual OCL [40] был предложен как способ визуализации выражений OCL с помощью диаграмм кооперации UML. Любое OCL-выраженис представляется в виде прямоугольника с указанием типа выражения в верхнем левом углу. Объекты также изображаются в виде прямоугольника, с названием объекта и, при необходимости, списком атрибутов. Условия, которые должны быть выполнены, выписываются под пунктирной чертой.

Операция навигация между объектами различных типов изображается с помощью ассоциаций; если результат ассоциации коллекция, то используются специальные символы, изображенные на рис.3.2.

Визуализацию логических операций предлагается делать с помощью сплошной горизонтальной линии, разделяющей ее операнды.

Па рис.3.4 приведено первое ограничение из рассмотренного в предыдущем разделе примера, записанное с помощью этой нотации.

Visual ОСЬ основан на диаграммах кооперации, но синтаксис этих диаграмм расширяется, что не позволяет специфицировать его как профиль UML. Графическое изображение логических связок между условиями приводит к созданию громоздких и сложных в понимании диаграмм.

2. Constraint Diagrams

Диаграммы ограничений (Constraint Diagrams) (70] и созданные на их основе звездообразные диа1раммы (Spider Diagrams) [64] позволяют специфицировать ограничения на связи между объектами и на состояния связанных объектов. Ограничения описываются с помощью специального графического языка, основанного на диа)раммах Венна для отображения множеств и отношений между ними, а также дополнительно введенных элементах - стрелок, изображающих ассоциации, точек, изображающих элементы множества и т.д.

Рассмотрим основные синтаксические конструкции языка:

Множества и элементы:

ф - множество из одного элемента;

О - множество из одного элемента или пустое множество;

- множество и » любого количества элементов;

• множество и » п элементов;

- пустос множество.

Типы и состояния:

Тип

• множество обьектов заданного мша.

• множество обьсктпи п 1аданиом состоянии.

Ассоциация

Множество р - это множество всех обьектов, связанных ассоциацией с каким-либо элементом множества s.

На рис.ЗЛ приведено первое ограничение из рассмотренного в предыдущем раздею примера, записанное с помощью диаграмм ограничений:

Рисунок 3-5 0|рамич1‘ние 5 (стр. 32), спецмфими^шаииое с помощью диаграмм ограничений

К достоинствам данного подхода можно отнести его простоту, позволяющую, однако, описывать ограничения как на структуру классов, так и на поведение объектов этих классов, к недостаткам - отсутствие поддержки логических операций (кроме операции конъюнкции и импликации), а также свойственную диаграммам Вснна трудность восприятия пересечения более чем трех множеств [70]. Кроме того, в предлагаемой нотации важную роль играют пересечения графических объектов, что существенно отличает ее от графовых нотаций и, в частности, не позволяет использовать диаграммы UML для изображения ограничений.