Объектно-ориентированная модель
Объектно-ориентированная база данных состоит из объектов, каждый из которых должен принадлежать к определенному классу, то есть каждый объект – экземпляр класса. Структура и поведение объектов в объектной среде полностью определяется его классом. Класс, в свою очередь, является коллекцией объектов, при этом структура и поведение объектов одного класса одинаковы. Заметим, что понятия "объект" и "класс" совпадают с теми же понятиями объектно-ориентированного программирования.
Создание объектной модели начинается с классификации – выявлении объектов с аналогичными свойствами и поведением и объединении их в классы. Однако, некоторые их свойства и методы различны. В этом случае производят генерализацию и специализацию.
Генерализация выявляет классы объектов с аналогичными свойствами и образует на основе этих свойств абстрактный суперкласс. Например, в базе данных, содержащей описание геометрических фигур, можно начать проектирование с выделения классов: треугольников, прямоугольников, окружностей, – а затем образовать из них абстрактный суперкласс Фигуры, состоящий из свойств, общих для всех фигур. Специализация – процесс обратный генерализации. При использовании этих процессов создается иерархия классов. Иерархии указывают цепочку наследования.
Важным процессом в объектно-ориентированной базе является агрегация. С помощью агрегации классы объектов могут связываться друг с другом, образуя класс агрегатов. Например, банковская база может содержать информацию о клиентах, счетах, филиалах, а также связи между ними. В объектно-ориентированной базе всю эту информацию можно инкапсулировать в одном агрегированном классе объектов.
|
|
|
Резюмируя все вышеизложенное, можно сказать следующее:
- объектно-ориентированная база данных – это попытка применить идеологию объектно-ориентированного программирования к технологии баз данных;
- объектно-ориентированная база данных состоит из объектов, причем каждый объект принадлежит к определенному классу;
- поведение объекта полностью определяется его принадлежностью к определенному классу;
- процесс проектирования объектно-ориентированной базы основан на выявлении классов объектов и построении их иерархии.
Раздел 10. Проектирование реляционных баз данных с использованием универсального языка моделирования UML.
Тема 10.1. Основные понятия диаграмм классов UML
Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать программные системы.
|
|
|
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML удобнее всего начать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка.
Несмотря на свои достоинства, UML - это всего лишь язык; он является одной из составляющих процесса разработки программного обеспечения, и не более того. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру.
В UML выделяют девять типов диаграмм:
- диаграммы классов;
- диаграммы объектов;
|
|
|
- диаграммы прецедентов;
- диаграммы последовательностей;
- диаграммы кооперации;
- диаграммы состояний;
- диаграммы действий;
- диаграммы компонентов;
- диаграммы развертывания.
На диаграмме классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования. Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов.
На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими "фотографиями" экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.
На диаграмме прецедентов представлены прецеденты и актеры (участники системы, выполняющие определённые функции), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.
|
|
|
Диаграммы последовательностей и кооперации являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации ‑ структурную организацию обменивающихся сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга.
На диаграммах состояний представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем.
Диаграмма деятельности ‑ это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.
На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.
На диаграмме развертывания представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания относятся к статическому виду архитектуры системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов.
Тема 10.2. Ограничения и язык OCL
Как уже отмечалось, в диаграммах классов могут указываться ограничения целостности, которые должны поддерживаться в проектируемой БД. В UML допускаются два способа определения ограничений: на естественном языке и на языке OCL. Пример: диаграмма классов Студент и Университет с ограничением, выраженным на естественном языке.
В данном случае накладывается ограничение на состояние объектов классов Студент и Университет, входящих в один экземпляр ассоциации. Объект класса Студент может входить в экземпляр связи с объектом класса Университет только при условии, что размер стипендии данного студента находится в диапазоне, допустимом в данном университете.
Более точный и лаконичный способ формулировки ограничений обеспечивает язык OCL (Object Constraints Language). Язык OCL предназначен, главным образом, для определения ограничений целостности данных, соответствующих модели, которая представлена в терминах диаграммы классов UML. OCL может применяться для определения ограничений, описывающих пред- и постусловия операций классов, и ограничений, представляющих собой инварианты классов.
Примеры ограничений.
Рассмотрим БД, состоящую из таблиц
Отдел(Номер_отдела, Название)
Служащий(Номер_отдела, Должность, Возраст)
1) Пусть в таблице Служащий значения атрибута Возраст должны быть больше 18 и меньше 70 лет. Тогда это ограничение описывается на языке OCL следующим образом:
context Служащий inv:
self.возраст > 18 and self.возраст < 70
Условие инварианта накладывает требуемое ограничение на значения атрибута Возраст, определенного в классе Служащий. В условном выражении инварианта ключевое слово self обозначает текущий объект класса-контекста инварианта. При проверке данного условия будут перебираться существующие объекты класса Служащий, и для каждого объекта будет проверяться, что значения атрибута Возраст находятся в пределах заданного диапазона.
2) Пусть в каждом отделе должен быть ровно один начальник.
context Отдел inv:
self.служащий 
select (должность = "начальник отдела") size () = 1
Тема 10.3. Пример разработки структуры и функционала БД
В качестве примера рассмотрим базу данных "Библиотека". Основные классы (сущности) для построения диаграммы классов:
Читатель(Номер_билета, Фамилия, Имя, Отчество, Адрес, Телефон)
Каталог(Шифр_книги, Название, Авторы, Издательство, Год)
Книга(Инвентарный_номер, Шифр_книги)
Выдача_книг(Номер_записи, Инвентарный_номер, Номер_билета, Дата_выдачи, Дата_возврата, Отметка_о_возврате)
Основные процессы для построения диаграммы действий:
- регистрация читателя (добавление записи в таблицу Читатель);
- поиск книг (выполнение поискового запроса);
- выдача книг (добавление записи в таблицу Выдача_книг);
- возврат книг (изменение записи в таблице Выдача_книг);
- выдача предупреждений о нарушениях срока возврата книг (выполнение поискового запроса);
- списание книг (удаление записей из таблиц Книга, Каталог);
- статистический анализ деятельности библиотеки (выполнение статистического запроса).
Дата добавления: 2018-04-15; просмотров: 269; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!