Методические указания к лабораторным работам по дисциплине “Системы автоматизации проектирования программного обеспечения” (стр. 4 из 22)

Рисунок 2.1- Отображение компоненты Data Modeler в меню Rational Rose

2.1.1 Создание диаграммы модели данных

После создания схемы (рис.2.1) в ней можно сформировать диаграмму модели данных. Эта диаграмма позволит добавить, изменить или просмотреть таблицы и другие элементы модели данных, поскольку играет ту же роль, что и диаграмма классов в объектной модели. Хотя можно добавлять элементы моделирования данных непосредственно в браузере, диаграмма модели данных позволяет показать в графическом виде, как сами элементы, так и отношения между ними. Для любой схемы можно создать любое необходимое число Создание диаграммы модели данных осуществляется следующим образом:

1. В браузере щелкните правой кнопкой мыши на схеме.

2. Выберите Data Modeler > New > Data Model Diagram.

3. Введите имя новой диаграммы.

4. Дважды щелкните на диаграмме для ее открытия.

Как и другие диаграммы в среде Rose, диаграмма модели данных имеет специализированную панель инструментов для добавления таблиц, отношений и других элементов моделирования. Кнопки этой панели перечислены в таблице 2.2.

Таблица 2.2 – Значки панели инструментов для диаграммы модели данных

Значки	Назначение
	Курсор принимает форму стрелки для выделения элемента Добавляет в диаграмму текстовое поле Добавляет к элементу диаграммы примечание Соединяет примечание с элементом диаграммы Добавляет в диаграмму таблицу Рисует неидентифицируемое отношение между двумя таблицами Рисует идентифицируемое отношение между двумя таблицами Добавляет в диаграмму представление Рисует зависимость между двумя таблицами

Диаграмма Data Model предоставляет следующие возможности:

- создание и редактирование таблиц и их элементов (колонок, ограничений, индексов, триггеров и т. п.);

- создание и редактирование идентифицирующих связей между таблицами;

- создание и редактирование неидентифицирующих связей.

Основные возможности по работе с таблицей доступны, если войти в контекстном меню в пункт “Open Specification”. Появляющееся на экране окно включает следующую информацию (рис. 2.2).

Рисунок 2.2 - Окно спецификации таблицы

При редактировании спецификации таблицы обеспечиваются следующие возможности (табл. 2.3).

Таблица 2.3 - Спецификация таблицы БД

Закладка	Описание
General	Вводится общая информация о таблице.
Columns	Задается описание колонок. Здесь можно добавить или отредактировать свойства колонок, задать тип, длину, обязательность (NULL, NOT NULL), а также пометить, что колонка входит в состав первичного ключа. Типы колонок соответствуют типам конкретной выбранной СУБД.
Key Constraints	Задаются ограничения на колонки таблицы. Здесь можно задать ограничение на уникальность первичного ключа, ограничение на уникальность альтернативных ключей, а также просто определить индекс.
Check Constraints	Задаются выражения – инварианты, которые должны выполнятся для всех строк таблицы.
Triggers	Содержит список триггеров, который можно отредактировать, в том числе добавив новый триггер.
Relationships	При наличии связей между таблицами, закладка содержит полный список связей.

2.1.1.1 Добавление отношений

Отношения в модели данных подобны отношениям в объектной модели. В объектной модели отношение связывает два класса, а в модели данных — две таблицы. В Rose поддерживаются два основных типа отношений: идентифицируемые отношения (identifying relationship) и неидентифицируемые отношения (non-identifying relationship).

В обоих случаях для поддержки отношений в дочернюю таблицу добавляется внешний ключ. При идентифицируемом отношении внешний ключ становится частью первичного ключа в дочерней таблице. В этом случае дочерняя таблица не может содержать запись, не связанную с записью в родительской таблице. Идентифицируемые отношения моделируются составными агрегациями.

Неидентифицируемые отношения тоже создают внешний ключ в дочерней таблице, но он не становится частью первичного ключа в дочерней таблице. При неидентифицируемом отношении мощность (множественность) определяет то, будет ли запись в дочерней таблице существовать без связи с записью в родительской таблице. Если мощность равна 1, должна присутствовать родительская запись. Если мощность равна 0..1, присутствие родительской записи необязательно. Неидентифицируемые отношения моделируются ассоциациями.

Для редактирования свойств связи требуется войти в пункт контекстного меню “Open specification”.

Рисунок 2.3 - Окно спецификации связи

При редактировании спецификации связи обеспечиваются следующие возможности (табл. 2.4).

Таблица 2.4 - Спецификация связи

Закладка	Описание
General	Основные свойства связи. Здесь задаются: имя связи; тип связи; наименования ролей (Parent, Child); кардинальность для каждой роли;
Migrated Key	Содержит список внешних ключей, образующихся в результате создания связи.
RI	Задание условий ссылочной целостности. Ссылочная целостность обеспечивается двумя способами: на основе триггеров; на основе декларативной ссылочной целостности (с использованием ограничений внешних ключей). Оба способа реализуют наиболее популярные алгоритмы, задаваемые для каждой роли (только для операций update и delete, для insert мы не нашли): Restrict; Cascade; Set Null; Set Default.

2.2 Пример концептуальной модели предметной области

На рисунке 2.4 приведен фрагмент модели данных заданной предметной области. Данная модель разработана в среде Rational Rose 2003 с использованием утилиты Rose Data Modeler.

Описание предметной области.

Организация предоставляет услуги по трудоустройству. Организацией ведется банк данных о существующих вакансиях. По каждой вакансии поддерживается следующая информация:

- предприятие, предоставляющее соответствующую вакансию;

- название вакансии (должность);

- требования к соискателю: пол, возраст, образование, знание определенных видов деятельности (выбор из перечня - знание электронного документооборота, определенных прикладных программ и т.п.), коммуникабельность;

- обязанности (выбор из перечня – заключение договоров, распространение агитационного материала, работа с клиентами и т.п.);

- предполагаемая оплата, единицы измерения оплаты - рубли;

- оформление трудовой книжки (да, нет);

- наличие социального пакета (да, нет);

- срок начала открытия вакансии;

- срок закрытия вакансии (вакансия занята).

Рисунок 2.4 – Модель данных предметной области

2.3 Разработка диаграммы вариантов использования

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

Данный тип диаграмм предназначен для создания списка операций, которые выполняет система, поэтому его иногда называют диаграммой функций. Любая система обладает своим множеством вариантов использования и множеством действующих лиц. Каждый вариант использования описывает элемент представляемой системой функциональности. Множество вариантов использования описывает всю функциональность системы на некотором уровне абстракции. Абстракция (abstraction) – сосредоточение на важнейших аспектах приложения и игнорирование всех остальных. Использование абстракции позволяет сохранить свободу принятия решений как можно дольше благодаря тому, что детали не фиксируются раньше времени. Каждое действующее лицо представляет собой один вид объектов, для которых система может выполнять некоторое поведение.

Язык UML предусматривает систему графических обозначений для вариантов использования (рис. 2.5).

Рисунок 2.5 – Графические обозначения диаграммы вариантов использования

Действующее лицо (actor) – это непосредственный внешний пользователь системы. Это объект или множество объектов, непосредственно взаимодействующих с системой. Каждое действующее лицо является обобщением группы объектов, ведущих себя определенным образом по отношению к системе. Действующими лицами могут быть люди, устройства и другие системы – все, что взаимодействует с интересующей нас системой непосредственно.

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

Различные взаимодействия действующих лиц с системой группируются в варианты использования. Вариант использования (use case) – это связный элемент функциональности, представляемый системой при взаимодействии с действующими лицами (рис. 2.6) .

Рисунок 2.6 – Вариант использования

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

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