Контрольная работа: Концептуальная модель предметной области

* концептуальную модель на - этапе анализа;

* диаграммы классов уровня спецификации - на этапе проектирования;

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

Диаграмма классов может отражать различные взаимосвязи между

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

* классы;

* интерфейсы;

* кооперации;

* отношения зависимости, обобщения и ассоциации.

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

1. Зависимость представляет собой связь использования. Это связь, которая устанавливает, что одна сущность, например класс Window (Окно), использует информацию и сервис (операцию или услугу), предоставляемые другой сущностью, например классом Event («Событие»), но необязательно наоборот. Зависимость изображается пунктирной линией со стрелкой, направленной на зависимую сущность. Чаще всего зависимость используется для того, чтобы показать, что один класс использует операции другого класса. концептуальный логический атрибут домен

2. Ассоциация - это структурная связь между экземплярами. Она показывает, что объекты одной сущности соединяются с объектами другой. Ассоциация изображается сплошной линией. Допустимо, чтобы оба конца ассоциации соединяли один и тот же класс, иными словами, один объект класса может связываться с другим объектом того же класса. Обычно ассоциация бинарна, т.е. связывает два класса, но бывают и парные ассоциации. Класс, участвующий в ассоциации, выполняет конкретную роль. Роль, которую играет класс, находящийся на конце ассоциации, называется конечным именем (в первой версии UML она называлась именем роли). Ассоциация может иметь параметр множественности. Он представляет собой диапазон целых чисел, указывающий количество связанных объектов (рис. 5.27). Множественность может быть определена как единица (1), ноль или один (0..1), много (0..* или *), один или несколько (1 ..*).

Рис. 3. Способы соединения сущностей

1..*

Человек -

работник

* _

- Компания

работодатель

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

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

Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных.

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

Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических решений.

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

Одной из распространенных моделей концептуальной схемы является модель «сущность - связь». Основными конструкциями данной модели являются сущности и связи.

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

Экземпляр сущности - конкретный объект.

Например:

сущность (объект) - институт экземпляр сущности -СГУТиКД.

Сущность принято определять атрибутами - поименованными характеристиками. Например:

сущность студент

атрибуты: ФИО, Группа,

Пример. Спроектировать БД "Сессия". База данных должна выдавать оперативную информацию об успеваемости студентов на факультетах в семестре. Результатами сессии считать только экзамены.

По сути дела, в БД исходя из формулировки задания, можно выделить лишь одно приложение. Речь идет об успеваемости студентов разных факультетов по тем или иным дисциплинам. Более конкретно речь идет о выдаче справок по результатам сессии каждого студента, учебной группы, курса. (Факультета, а также об автоматизированном составлении ведомости.)

Выберем следующие сущности:

Университет, институт, студент, преподаватель, дисциплина.

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

Зададим каждую сущность набором атрибутов, например:

Университет (название, подчиненность, адрес, телефон, ФИО ректора).

Институт (название, код специальности, группы, декан).

Студент (ФИО, группа, курс, номер семестра).

Преподаватель (ФИО, должность, звание, институт, читаемые дисциплины).

Дисциплина (название, число часов, виды занятий, номер семестра, итоговая аттестация)

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

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

Рассмотрим некоторые ограничения в рассматриваемом примере:

1. Значение атрибута "курс" (сущность - студент) лежит в интервале 1-6.

4. Значение атрибута "семестр" (сущность - студент, дисциплина) в интервале 1-12.

5. Значение атрибута "число часов" (сущность - дисциплина) лежит в интервале 1-300.

6. Одному студенту может быть приписана только одна группа.

7. Один студент может учиться только на одном факультете.

8. Один студент в семестре сдает от 3 до 5 дисциплин.

9. Один студент изучает в семестре от 6 до 12 дисциплин.

10. Одному преподавателю приписывается только один институт.

11. Один студент может пересдавать одну дисциплину не более трех раз.

12. Ключи: название института, название университета, ФИО и группа студента, ФИО и преподавателя, название дисциплины.

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

Для уменьшения нежелательных характеристик БД к схемам отношений применяют процедуры нормализации. Рассмотрим понятие функциональной зависимости. Пусть R (A1, A2,...,Ai,...,An) - схема отношения R. Обозначим через Dom (Aj) множество возможных состояний атрибута Aj. Будем говорить, что атрибуты Ai и AJ отношения К связаны функциональной зависимостью, т.е. f: Dom (Ai) -> Dom (Aj), которую будем понимать как множество упорядоченных пар

{ <а, в> / а€ Dom (Ai), b€ Dom (Aj) },

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

При этом в каждый момент элементу а€ Dom (Ai) соответствует не более

одного элемента b€ Dom (Aj).

Функциональная связь доменов инвариантна по отношению к схеме конкретного отношения. Понятие функциональной зависимости позволяет определить ключ отношения. Пример 1.

Выявим функциональные зависимости в отношении БД "Учеба". R учеба (факультет, группа, дисциплина, вид занятий, преподаватель, квалификация преподавателя)

f: (дисциплина, вид занятий) -> квалификация преподавателя преподаватель -> квалификация преподавателя

группа -> факультет преподаватель -> факультет

Фиксация функциональных зависимостей в схеме отношения ограничивает число возможных состояний схемы.