- •3.6 Заключение 59
- •Глава 1. Определение и виды информационных систем
- •Виды ис
- •Функциональность информационных систем, ориентированных на данные
- •Глава 2. Технология real-it
- •Моделирование схемы данных
- •Описание ограничений целостности
- •Описание экземпляров
- •Создание представлений
- •Расширение uml для моделирования представлений
- •Создание экранов
- •Генерация
- •База данных
- •Программный интерфейс базы данных
- •Экранные формы
- •Заключение
- •Глава 3. Язык описания расширенных ограничений ссылочной целостности
- •Пример диаграммы классов с ограничениями
- •Альтернативные подходы
- •Контекстные ограничения
- •Нотация
- •Семантика
- •Базовая модель Определение 1
- •Модель с отрицаниями Определение 7
- •Модель с ограничениями на отдельные объекты Определение 11
- •3.6 Заключение
- •Глава 4. Разработка пользовательского интерфейса
- •Модельно-ориентированные подходы к разработке пользовательского интерфейса
- •Визуальное моделирование при разработке web-приложений
- •Моделирование интерфейса в real-гг
- •Порядок использования модели интерфейса
- •Диаграммы классов uml
- •Шаблоны экранных форм
- •Разработка отдельных типов экранных форм
- •4.3.1 Список
- •Определение набора столбцов
- •Моделирование фильтров
- •Карточка
- •Форма - отношение
- •Заключение
- •Глава 5. Поддержка итеративной разработки
- •Альтернативные подходы
- •Поддержка «ручных» изменений кода
- •Возможные решения
- •Анализ возможных решений
- •Предлагаемое решение
- •Программный интерфейс базы данных
- •Изменение расположения и размеров элементов управления
- •Изменение поведении элементов интерфейса
- •Изменение визуального представления (замена и добавление элементов управления)
- •Составление сложной формы из нескольких сгенерированных
- •Сохранение содержимого базы данных при обновлении ее схемы
- •Заключение
- •Глава 6. Реализация
- •База данных
- •Архитектура приложения
- •Оптимизация выборки данных
- •Учет зависимостей между полями
- •Отложенная инициализация закладок
- •Передача дополнительной информации между формами
- •Генераторы
- •Заключение
- •Глава 7. Направления дальнейших исследований
- •Моделирование расширенных ограничений ссылочной целостности
- •Моделирование пользовательского интерфейса
- •Распределение прав доступа в терминах модели системы
- •Разработка семейств информационных систем
- •Использование модели бизнес-процессов для реализации системы
- •0. Для профессионалов: Пер. С англ. — сПб: Питер, 2000. — 864 с.
Контекстные ограничения
Каждое из представленных в примере ограничений можно привести к следующему виду: выделяются два объекта (экземпляры классов), связанные ассоциацией6, а также другие связанные с ними объекты и ассоциации (их мы будем называть контекстом ассоциации). При этом ассоциация допустима
* Здесь и далее под ассоциацией мы будем понимать как собственно ассоциацию между классами, так и соответствующую ей связь между экземплярами этих классов.
только в том случае, если такой контекст можно построить, т.е. существуют объекты, связанные определенными в контексте ассоциациями.
Например, для первого ограничения такой ассоциацией будет ассоциация между адресом и областью, а контекстом — ассоциации между адресом и страной, а также страной и областью. Ассоциация между адресом и областью допустима, если контекст можно построить, т.е. сели существует страна, связанная одновременно с адресом и областью укачанными ассоциациями. Мы будем называть такие ограничения контекстными ограничениями ссылочной целостности, поскольку, как и традиционные ограничения ссылочной целостности, они позволяют запретить недопустимые ссылки, но при определении допустимости используется контекст.
Очевидно, что ограничения 1, 2, 3 и 5 являются кошскстными. В ограничении 4 ассоциации между адресом и районом и между адресом и улицей являются равноправными — можно переписать это ограничение, сделав его контекстным для любой из них. Вопрос о том, какую именно ассоциацию, входящую в ограничение, считать ограниченной этим ограничением, решается, обычно, исходя из соображений удобства и дальнейшего использования описанных ограничений. Если, например, они используются для проверки вводимых пользователем данных, то удобнее ограничивать ту ассоциацию, информацию о которой пользователь должен ввести последней.
На приведенных ниже диаграммах (рис.3.6-3.11) изображены ограниченные ассоциации вместе с их контекстами. При этом ограничиваемые ассоциации имеют стереотип «Limited».
Рисунок
3.6 Дищрнмма кооперации для oi
раничении I
Рисунок
3.7 Нервам диаграмма кооперации для oi
раннчеиия 2
Рисунок
3.8 Вторая диаграмма кооперации ял
я окраничения 2
Рисунок
3.9 Диаграмма кооперации для ограничения
3
Рисунок
3.10 Первая диаграмма кооперации для
ограничений 4 и 5
Рисунок
3.11 Вторая лиаграччя кооперации для
ограничений 4 н 5
Нотация
Каждая диаграмма ограничений представляет собой |раф. вершинам которою соответствуют классы в модели классов, на которую накладываются ограничения. При этом одному классу может соответствовать произвольное количество вершин. Ребрам графа соответствуют ассоциации между классами. При этом одно из ребер выделяется — оно соответствует ограничиваемой ассоциации. Как уже было сказано выше, предлагаемая нотация вкладывается в нотацию диаграмм кооперации UML. При этом используются два типа элементов диаграмм кооперации — объекты и связи, сообщения не используются. Для связей вводится стереотип «Limited» для обозначения
ограничиваемых ассоциаций. При этом считается, что диаграмма кооперации является диаграммой ограничений в том и только том случае, если на ней присутствует хотя бы одна связь со стереотипом «Limited» (в предлагаемой версии нотации такая связь на диаграмме может быть только одна). У всех объектов на диаграмме ограничений должны быть указаны их классы, а у связей
ассоциации.