1.6 Диаграмма вариантов использования

Разработка данной диаграммы преследует следующие цели:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

· Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы см. таблице 1.1.

Рис 1.1 Диаграмма прецедентов

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

Следует предпочитать небольшие и детализованные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта. [3]. Ниже приведена уточненная диаграммы вариантов использования.

Реляционная база данных, спроектированная в соответствии с концептуальной схемой, может обладать рядом серьёзных недостатков, например, содержать информационную избыточность, и (или) в процессе обработки данных могут возникать различные аномалии. Чтобы устранить эти недостатки, т.е. сделать базу данных "хорошей", необходимо привести все отношения базы данных в "сильные" нормальные формы.

В настоящее время известно несколько нормальных форм. Первая нормальная форма (будем обозначать 1НФ), далее - по мере "усиления" - 2НФ, 3НФ, нормальная форма Бойса-Кодда (НФБК) и 4 НФ. Практика показывает, что приведение БД хотя бы к 3НФ позволяет избежать в большинстве случаев почти всех недостатков.

Первая нормальная форма (1НФ).

Отношение со схемой R и множеством функциональных зависимостей F находится в 1НФ, если любой экземпляр схемы R удовлетворяет следующим условиям:

каждый атрибут схемы R имеет уникальное имя;

элементы кортежей с одним и тем же именем должны быть определены на одном и том же домене;

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

каждый элемент кортежа должен иметь единственное значение, повторяющиеся группы значений недопустимы;

в отношении не должно быть повторяющихся кортежей.

Вторая нормальная форма (2 НФ).

Отношение со схемой R и множеством функциональных зависимостей F находится во 2НФ, если оно находится в 1НФ, и каждый неключевой атрибут функционально полно зависит от любого возможного первичного ключа схемы-отношения R.

Однако, схема отношения, находящаяся во 2 НФ, также имеет недостатки. В частности, множество зависимостей, определённое на этой схеме, может содержать транзитивные зависимости, которые могут приводить к нежелательным последствиям (аномалиям удаления).

Третья нормальная форма (3 НФ).

Схема отношений R с множеством функциональных зависимостей F находится в 3НФ, если оно находится во 2 НФ, и каждый неключевой атрибут прямо, а не транзитивно зависит от любого возможного ключа схемы отношения.

Однако, 3НФ также может иметь недостатки, связанные с ключевыми атрибутами. В приведённом примере полученная 3 НФ не вызывает аномалий при обработке данных, так ка в результирующих декомпозиционных подсхемах отсутствуют зависимости ключевых атрибутов от других атрибутов. Если это условие нарушается, то возможны аномалии обработки данных.

Нормальная форма Бойса-Кодда (НФБК).

Нормальная форма Бойса-Кодда более "сильная", чем третья нормальная форма. Схема отношений R с множеством функциональных зависимостей F находится в НФБК, если левая часть каждой зависимости (ХА) F, где А Х, есть первичный или возможный первичный ключ.

Если отношение находится в НФБК, то оно находится и в третьей нормальной форме, но не наоборот.

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

2.3 Нормализация схем отношений

Интегрированное представление пользователей, представленное в виде диаграммы

2.5 Алгоритм синтеза

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

Результатом работы алгоритма является схема автоматизированной системы управления в виде набора декомпозиционных подсхем {R₁, R₂,., Rp}, удовлетворяющих следующим условиям.

Каждая подсхема Ri с БД должна находится хотя бы в ЗНФ относительно множества функциональных зависимостей F и соответственно G.

Синтезируемая информационная система содержит минимальный набор декомпозиционных подсхем Ri, I == 1,., Р. Это условие защищает информационную систему от избыточности.

Для любого экземпляра r (БД), удовлетворяющего F, выполняется соотношение . Это условие гарантирует выполнимость свойства соединения без потерь информации.

Схема автоматизированной системы управления, удовлетворяющая условиям 1,2 и 3, называется полной схемой автоматизированной системы управления.

Рассмотрим шаги алгоритма.

Шаг 1. Строим расширенное множество F функциональных зависимостей, которое имеет следующую структуру зависимостей:

F = { (X_I - > Y_I) | (X_I - >Y_I) F, Y_I = X_I ⁺\ X_I}. Этот шаг делается с целью построения неизбыточного или условно неизбыточного покрытия F, что позволит в некоторой степени удовлетворить условию 3. Полностью обеспечить условие 3 удастся после введения в рассмотрение понятия эквивалентности функциональных зависимостей на шаге 5.

Шаг 2. Строим неизбыточное покрытие F, исключая из F в любой последовательности лишние зависимости.

Очевидно, это покрытие не является каноническим.

Шаг 3. Если среди функциональных зависимостей из F' нет зависимости, включающей все атрибуты из U, то добавляем к F' тривиальную зависимость U-> Ш.

Шаг 4. Преобразуем полученные нетривиальные зависимости к элементарному виду (без лишних атрибутов в левых частях).

Зависимость X_I - >Y_Iявляется элементарной, если не существует таких наборов атрибутов X_J X_I, что (X_j - >Y_I) . Если - существует, то зависимость X_I - >Y_I заменяется зависимостью (X_J - >Y_I).

Шаг 5. Разбиваем множество полученных зависимостей на классы эквивалентности. Это делается для того, чтобы на следующем шаге оставить в каждом классе одного представителя, тем самым минимизировать количество декомпозиционных подсхем в результирующей БД и полностью удовлетворить условию 3.

Зависимости X_I - >Y_I и X_J - >Y_J будем называть эквивалентными, если

, т.е. минимальный ранг имеет зависимость, содержащая все атрибуты из U, а, если ее нет, то - тривиальная зависимость U - > Ш. Всем зависимостям из одного класса эквивалентности назначаем одинаковый ранг. Несравнимым зависимостям ранги назначаем произвольно.

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

Шаг 7. Выполняем транзитивную редукцию зависимостей с большим рангом на зависимости с меньшим рангом. Двигаясь по диаграмме снизу вверх (от зависимостей с большим рангом к зависимостям с меньшим рангом), для каждой текущей зависимости исключаем из правых частей всех зависимостей, расположенных выше текущей, те атрибуты, которые содержатся в правой части текущей зависимости (для тривиальной зависимости атрибуты исключаем из ее левой части).

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

Множество атрибутов:

U = {mNo, mName, mCost, count, oNo, oAddress, oType, oStoreys, oState, eNo, eName, ePost, eState, eSalary, sum, iNo, iName, iPhone}

Множество функциональных зависимостей:

F = {mNo®mName, mNo®mCost, mName®mNo, mName®mCost,

(oNo, mNo) ®count,

oNo®oAddress, oNo®oType, oNo®oStoreys, oNo®eNo, oNo®oState, oNo®oCost

eNo®eName, eNo®ePost, eNo®eState, eSalary

iNo®iName, iNo®iPhone,

(iNo, oNo) ®sum }

Шаг 1. Расширенное множество функциональных зависимостей:

mNo⁺=mNo, mName, mCost =>mNo® (mName, mCost)

mNo⁺=…=>mNo®…

(oNo, mNo) ⁺=oNo, mNo, count=> (oNo, mNo) ?®count

oNo⁺=oNo, oAddress, oType, oStoreys, oState, oCost, eNo =>oNo® (oAddress, oType, oStoreys, eNo,oState, oCost)

oNo⁺=…=>oNo®…

eNo⁺=eNo, eName, ePost, eState, eSalary=>eNo® (eName, ePost, eState, eSalary)

eNo⁺=…=>eNo®…

iNo⁺=iNo, iName, iPhone=>iNo® (iName, iPhone)

iNo⁺=…=>iNo®…

(iNo, oNo) ⁺=iNo, oNo, sum=> (iNo, oNo) ®sum

(mNo, oNo, iNo, eNo) ⁺=mNo, mName, mCost, count, sum, oNo, oAddress, oType, oStoreys, iNo, iName, iPhone, eNo, eName, ePost, eState, eSalary, oState, oCost

=> (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary, oCost)

F = {mNo® (mName, mCost), mNo®…, (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, eNo, oState, oCost), oNo®…, eNo® (eName, ePost, eState, eSalary), eNo®…, iNo® (iName, iPhone), iNo®…, (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary) }

Шаг 2. Неизбыточное покрытие

F' = {mNo® (mName, mCost), (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, oState, oCost, eNo), eNo® (eName, ePost, eState, eSalary), iNo® (iName, iPhone), (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary) }

Шаг 3. Тривиальная зависимость

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

Шаг 4. Элементарный вид зависимостей

Все зависимости элементарные.

Шаг 5. Эквивалентность зависимостей

Эквивалентных зависимостей нет.

Шаг 6. Ранжирование зависимостей

Разбиваем множество полученных зависимостей на классы эквивалентности. Это делается для того, чтобы на следующем шаге оставить в каждом классе одного представителя, тем самым минимизировать количество декомпозиционных подсхем в результирующей БД и полностью удовлетворить условию 3.

Зависимости X_I Y_I и X_J Y_J будем называть эквивалентными, если (X_I Y_I) = (X_J Y_J).

Ранжируем полученные зависимости по следующему правилу rang (X_I Y_I) > rang (X_J Y_J), если (X_I Y_I) (X_J Y_J).

Всем зависимостям из одного класса эквивалентности назначаем одинаковый ранг. Несравнимым зависимостям ранги назначаем произвольно.

Шаг 7. Диаграмма ранжированных зависимостей (2 НФ):

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

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

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

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

Шаг 8. Получаем совокупность декомпозиционных подсхем

После прохождения алгоритма было получено 6 таблиц с соответствующими первичными ключами:

R1 = oNo, oAddress, oType, oStoreys, oState, oCost, eNoс ключом oNo

R2 = eNo, eName, ePost, eState, eSalaryс ключомeNo

R3 = oNo, mNo,countс ключом (oNo, mNo)

R4 = mNo, mName, mCostс ключомmNo

R5 = iNo, iName, iPhoneс ключомiNo

R6 = iNo, oNo, sumс ключом (iNo, oNo)

Rational Rose Data Modeler средство проектирования БД

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей.

Таблица 2.1 Соответствие элементов логической и физической модели

Таким образом, концептуально модуль Data Modeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД.

Перечень основных возможностей Data Modeler включает в себя:

1. Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

2. Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

3. Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

4. Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей.

5. Обеспечивается концептуальное соответствие моделирования данных и объектных моделей, что позволяет более эффективно проектировать программные средства.

Создание логической модели

Основные компоненты диаграммы Data Modeler - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться ото всех остальных экземпляров. Атрибут выражает определенное свойство объекта. На физическом уровне сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.

Работа Data Modeler основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы "сущность - связь" и последующая генерация описания базы данных на SQL.

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