Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. - Базы данных. Учебник для высших учебных заведений (6-е изд.) - 2009

6. Метод сущность-связь

193

ПРЕПОДАВАТЕЛЬ			ДОЛЖНОСТЬ	СТАЖ
ФИО	Стаж	Должн ...	Должн	Стаж
ВЕДЕТ				ЗАНЯТИЕ
ФИО	Группа	Предм	Групрас^Предм

Рис. 6.24. Схема базы данных

Замечания.

•В нашем примере отношение ЗАНЯТИЕ, кроме ключевых атрибутов (Группа. Предм). других атрибутов не имеет. Поэтому оно не несет дополнительной информации, кроме содержащейся в отношении ВЕДЕТ. Действительно, это отношение включает в себя атрибуты Группа. Предм. Поэтому отношение ЗАНЯТИЕ нужно исключить из формируемой схемы БД (на рис. 6.24 оно перечеркнуто). Если бы имелись другие атрибуты, например атрибут Семестр, в котором некоторая группа изучает конкретную дисциплину, то получили бы отношение ЗАНЯТИЕ (Группа. Предм. Семестр), которое вошло бы в БД.

•На последнем этапе проектирования предварительные отношения анализируются на предмет избыточного дублирования информации. При

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

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

Контрольные вопросы и задания

1.Перечислите основные понятия метода сущность-связь.

2.Охарактеризуйте понятие ключа сущности.

7 Зак. 541

194	Часть 2. Проектирование и использование БД

3.Что представляют собой диаграммы ER-экземпляров и диаграммы ER-типа.

4.Что определяет степень связи между сущностями?

5.Каким может быть класс принадлежности?

6.Приведите пример диаграммы ER-экземпляров со степенью связи между сущностями 1:1 и обязательным классом принадлежности двух сущностей.

7.Как на диаграммах ER-типа обозначаются степень связи, обязательное и необязательное участие в связи экземпляров сущности?

8.Приведите пример диаграммы ER-экземпляров для связи типа 1:М варианта Н-О.

9.Назовите этапы проектирования базы данных.

10.Как осуществляется формирование отношений для связи 1:1?

11.Сформулируйте правило 3 формирования отношений, если степень связи 1:1 и класс принадлежности обеих сущностей является необязательным.

12.Сформулируйте правило формирования отношения для случая степени связи между сущностями 1:М (М:1) и обязательного класса принадлежности М-связной сущности.

13.Укажите правила формирования отношений для связи М:М.

14.Покажите, что полученные в прикладном примере из раздела отношения находятся в нормальной форме Бойса - Кодда.

Литература

1.Дейтп К. Дж. Введение в системы баз данных / Пер. с англ. — б-е изд. К.: Диалектика, 1998.

2.Джексон Г. Проектирование реляционных баз данных для использования с МИКРОЭВМ/ Пер. с англ. М.: Мир, 1991.

3.Кузнецов С. Д. Введение в СУБД: часть 4 / / Системы Управления Базами Данных, №4, 1995. С. 114 -122.

4.Основы современных компьютерных технологий: Учебник / Под ред. проф. Хомоненко А. Д. Авторы: Брякалов Г. А., Войцеховский С. В., Воробьев Е. и др. - СПб.: КОРОНА принт, 2005. - 672 с.

5. Хансен Г., Хансен Д. Базы данных: разработка и управление / Пер. с англ. М.: ЗАО «Издательство БИНОМ», 1999.

195

7. Средства автоматизации проектирования

В разделе дается общая характеристика CASE-средств создания и сопровождения информационных систем. Рассматриваются модели жизненного цикла программных систем, описываются модели структурного и объектно-ориентированного проектирования. Дается классификация CASE-средств и приводится характеристика наиболее популярных систем.

7.1. Основные определения

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

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

Термин CASE (Computer Aided Software Engineering) дословно переводится как разработка программного обеспечения с помощью компьютера. В настоящее время этот термин получил более широкий смысл, означающий автоматизацию разработки информационных систем.

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

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

196	Часть 2. Проектирование и использование БД
CASE-технология	обычно определяется как методология проектирования

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

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

Основная цель CASE-систем и средств состоит в том, чтобы отделить проектирование программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и пр.), а также автоматизировать весь процесс создания программных систем, или инжиниринг (от англ. engineering - разработка).

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

Повторная разработка сводится к построению исходной модели программной системы путем исследования ее программных кодов. Имея модель, можно ее усовершенствовать, а затем вновь перейти к разработке. Так часто и поступают при проектировании. Одним из наиболее известных принципов такого типа является принцип «возвратного проектирования» - Round Trip Engineering (RTE).

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

Перспективная CASE-система

Динамика изменения позиций структурных и объектно-ориентированных систем позволяет предположить, что перспективная CASE-система будет объектно-ориентированной. Рассмотрим требования к идеальной перспективной CASE-системе.

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

Для решения задач анализа и моделирования целесообразно иметь интегрированную среду разработчика, которая должна обеспечивать возможности:

• динамического моделирования событий в системе;

7. Средства автоматизации проектирования

197

•динамической и согласованной коррекции всей совокупности диаграмм;

•добавления пояснительных надписей к диаграммам моделей и в документацию;

•автоматической генерации документации;

•создания различных представлений и скрытия неиспользуемых слоев системы;

•поддержки различных нотаций (это требование ослабевает в связи с переходом к единому языку моделирования).

Осуществление процесса проектирования предполагает наличие возможностей:

•определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнесправил);

•поддержки процесса проектирования с помощью библиотек, оснащенных средствами хранения, поиска и выбора элементов проектирования (объектов и правил);

•создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т. п.);

•создания различных распределенных клиент-серверных приложений. Средства разработки в составе CASE-системы должны обеспечивать пост-

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

CASE-системы ближайшего будущего должны позволять создавать скелетные заготовки под классы, атрибуты и методы, готовые приложения на объек- тно-ориентированных языках программирования типа С++ или Smalltalk, либо программы на языках клиент-серверных продуктов (PowerBuilder, Forte, VisualAge, VisualWorks и т. д.). К поддерживаемым языкам, по-видимому, скоро добавится язык Java.

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

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

198	Часть 2. Проектирование и использование БД

7.2. Модели жизненного цикла

Модель жизненного цикла (ЖЦ) цикла программного обеспечения информационной системы (ПО И С) при автоматизированном проектировании И С играет достаточно важную роль. Это обусловлено тем, что каждая из CASE-систем ориентирована на (поддерживает) определенную модель Ж Ц П О ИС.

Жизненный цикл ПО ИС представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся при завершении его эксплуатации.

Основным нормативным документом, регламентирующим Ж Ц ПО, является международный стандарт I S O / I E C 12207 (International Organization of Standardization - Международная организация по стандартизации/International Electrotechnical Commission - международная комиссия по электротехнике). В нем определяется структура ЖЦ, содержащая процессы, действия и задачи, которые должны быть выполнены при создании ПО.

Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее распространение получили следующие модели ЖЦ ПО: каскадная, с промежуточным контролем и спиральная.

Модели каскадная и с промежуточным контролем включают следующие этапы жизненного цикла ПО: анализ, проектирование, реализация, внедрение и сопровождение.

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

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

Спиральная модель жизненного цикла (рис. 7.1) позволяет устранить недостатки предыдущих моделей. Основной упор в ней делается на начальные этапы: анализ и проектирование. На них реализуемость технических решений проверяется с помощью создания прототипов.

	7. Средства автоматизации проектирования	199
		Определение
		требований
	ПроектироЕ
	Реапизащ	т
	тестирова	Внедрение
		версий

Интеграция

Рис. 7.1. Спиральная модель жизненного цикла

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

7.3. Модели структурного проектирования

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

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

Наиболее распространенными моделями и диаграммами графического представления являются следующие:

•диаграммы сущность-связь или ER-диаграммы - Entity-Relationship Diagrams (ERD) служат для наглядного представления схем баз данных (раздел 6);

•диаграммы потоков данных - Data Flow Diagrams (DFD) служат для иерархического описания модели системы;

•метод структурного анализа и проектирования - Structured Analysis and Design Technique (SADT), служащий для построения функциональной модели объекта;

•схемы описания иерархии вход-обработка-выход - Hierarchy plus Input- Processing-Output (HIPO) служат для описания реализуемых программой функций и циркулирующих внутри нее потоков данных;

200	Часть 2. Проектирование и использование БД

•диаграммы Варнъе-Орра служат для описания иерархической структуры системы с выделением элементарных составных частей, выделением процессов и указанием потоков данных для каждого процесса.

Названные модели позволяют получить описание информационной системы, а их состав зависит от требуемой полноты ее описания. Широко используемые диаграммы сущность-связь описаны в разделе 6. Рассмотрим коротко также важные и часто используемые в CASE-средствах диаграммы и модели DFD и SADT.

Диаграммы потоков данных

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

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

Основными компонентами диаграмм потоков данных являются:

•внешние суш;ности - источники или потребители информации, порождающие или принимающие информационные потоки (потоки данных);

•системы/подсистемы., преобразующие получаемую информацию и порождающие новые потоки;

•процессы, представляющие преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом;

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

•потоки данных, определяющие информацию, передаваемую через некоторое соединение от источника к приемнику.

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

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

7. Средства автоматизации проектирования

201

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

Примеры фрагментов диаграммы потоков данных с изображением перечисленных компонентов приведены на рис. 7.2.

Рис. 7.2. Фрагменты диаграммы потоков данных

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

Методология функционального моделирования

Методология функционального моделирования SADT служит для построения функциональной модели объекта какой-либо предметной области. Последняя отображает функциональную структуру объекта - выполняемые им действия и связи между ними.

Функциональная модель информационной системы состоит из имеющих ссылки друг к другу диаграмм, фрагментов текстов и глоссария. На диаграммах представляются функции ИС и взаимосвязи (интерфейсы) между ними в виде блоков и дуг. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация указывается сверху, обрабатываемая информация - елевой стороны блока, выводимая информация - с правой стороны, выполняющий операцию механизм (человек, программа или устройство), представляется дугой снизу блока (см. рис. 7.3).

202	Часть 2. Проектирование и использование БД
	Управление
Входы	Функция	->- Выходы

Механизм

Рис. 7.3. Функциональный блок и дуги интерфейса

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

0

А - О

Рис. 7.4. Декомпозиция диаграмм

В общем случае функциональная модель И С представляет собой серию диаграмм с документацией, декомпозирующих сложный объект на составные компоненты в виде блоков. Блоки на диаграмме нумеруются. Для указания положения диаграммы или блока в иерархии диаграмм используются номера диаграмм. Например, обозначение А32 указывает на диаграмму, детализирующую блок 2 на диаграмме A3. В свою очередь, диаграмма АОЗ детализирует блок 3 на диаграмме АО.

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