Лабораторная работа № 4

Тема: «Построение концептуальной модели предметной области. Разработка диаграммы вариантов использования в среде Rational Rose»

Цель работы:

1. Освоить методику построения диаграмм вариантов использования;

2. Познакомиться с Case-средством Rational Rose и получить навыки работы в данной среде;

3. Разработать диаграмму вариантов использования согласно заданию.

1 Задание на самоподготовку

- изучить лекционный материал по данной теме;

- знать методику построения диаграмм вариантов использования.

2 Краткие теоретические сведения

Концептуальную модель предметной области можно представить в виде ER-диаграммы, т.е. отношения “сущность-связь”.Для этого необходимо разработать модель данных.

Моделирование данных является важнейшим процессом при проектировании программного обеспечения (ПО). По этой причине, разработчики CASE-средств в своих продуктах вынуждены уделять моделированию данных повышенное внимание. Являясь признанным лидером в области объектных методологий, фирма Rational Software Corporation, тем не менее, до недавнего времени такого средства не имела. Основной причиной этого, по-видимому, является ориентация на язык Unified Modeling Language (UML), как универсальный инструмент моделирования. UML полностью покрывает потребности моделирования данных. Сложившаяся на протяжении десятилетий технология моделирования данных, традиции, система понятий и колоссальный опыт разработчиков не могли далее игнорироваться. Немаловажную роль здесь сыграла и необходимость формального контроля моделей данных, что является абсолютно необходимым при проектировании мало-мальски больших схем баз данных и что UML не обеспечивает в достаточной степени. И, наконец, последней причиной, побудившей специалистов Rational Software Corporation к созданию собственного средства моделирования данных, является требование построения эффективных физических моделей, прежде всего для конкретных СУБД - лидеров рынка.

В начале 2000 года фирма Rational Software Corpоration анонсировала появление собственного средства моделирования данных – Data Modeler, и в настоящее время оно доступно специалистам, например, использующим в своей работе Rational Rose 2000.

Целью данной лабораторной работы является знакомство с основными возможностями этого нового средства.

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

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

Логическая модель	Физическая модель
Class (Класс)	Table (Таблица)
Operation (Операция)	Constraint (Ограничение)
Attribute (Атрибут)	Column (Колонка)
Package (Пакет)	Scheme (Схема)
Component (Компонент)	Database (База данных)
Association (Ассоциация)	Relationship (Связь)
Нет	Trigger (Тригер)
Нет	Index (Индекс)

2.1 Rose Data Modeler

После установки Rational Rose в специальной редакции (Rational Rose Professional Data Modeler Edition) в разделе главного меню Tools появляется новый раздел Data Modeler (рис. 1).

В разделе Data Modeler имеются два пункта: “Add Schema” и “Reverse Engeneer…”. Пункт “Add Schema” используется для создания новых схем БД, а пункт “Reverse Engeneer” - для построения модели на основе существующей схемы БД.

Рисунок 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 – Вариант использования

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

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

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

На рисунке 2.7 приведен пример документирования варианта использования.

Рисунок 2.7 – Окно документирования варианта использования

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

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

- отношение ассоциации;

- отношение зависимости;

- отношение обобщения.

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

Рисунок 2.8 – Пример реализации отношения ассоциации

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

Кратность (multiplicity) ассоциации указывается рядом с обозначением компонента диаграммы, который является участником данной ассоциации. Кратность характеризует общее количество конкретных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации. Применительно к диаграммам вариантов использования кратность имеет специальное обозначение в форме одной или нескольких цифр и, возможно, специального символа "*" (звездочка).

Зависимость – семантическое отношение между двумя сущностями, при которой изменение одной из сущностей, независимой, может повлиять на семантику второй сущности, зависимой.

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

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

Рисунок 2.8 - Пример графического изображения отношения зависимости (расширения) между вариантами использования

Обобщение – отношение, при котором объект специализированного элемента может быть подставлен и использован вместо объекта обобщенного элемента. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 2.9).

Рисунок 2.9 - Пример графического изображения отношения обобщения между действующими лицами