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

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

203

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

ния значимости:
• случайные	связи,	означающие, что связь между функциями мала или от-
сутствует;
•логические	связи,	означающие, что данные и функции относятся к одно-

му классу или набору элементов, но функциональных отношений между ними нет;

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

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

так как используют одни и те же входные данные и/или порождают одни

ите же выходные данные;

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

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

7.4. Объектно-ориентированные модели

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

Общая характеристика

UML

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

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

гих непрограммных систем. В снову создания UML положены три наиболее распространенные модели:

•Booch, получившая название по фамилии автора Гради Буча (Grady Booch);

• О М Т (Object Modeling Technique - метод моделирования объектов);

•OOSE (Object-Oriented Software Engineering - объектно-ориентирован- ное проектирование программного обеспечения).

На заключительной стадии разработки, унификации и принятия UML в качестве стандарта большой вклад внес консорциум OMG (Object Management Group - группа управления объектом). UML можно определить также как промышленный объектно-ориентированный стандарт моделирования. Он включает в себя в унифицированном виде лучшие методы визуального (графического) моделирования. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о поддержке UML, среди них можно выделить: Rational Rose, Select Enterprise, Platinum и Visual Modeler.

ТИПЫ диаграмм UML

Создаваемый с помощью UML проект информационной системы может включать в себя следующие 8 видов диаграмм (diagrams):

•прецедентов использования (use case),

•классов (class),

•состояний (statechart),

•активности (activity),

•следования (sequence),

•сотрудничества (collaboration),

•компонентов (component),

•размещения (deployment).

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

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

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

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

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

205

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

•описывает видимую пользователем функцию,

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

Прецедент изображается как овал, связанный с типичными пользователя-

ми, называемыми «актерами» (actors). Актером является любая сущность, взаимодействующая с системой извне, например человек, оборудование, другая система. Прецедент описывает, что система предоставляет актеру - определяет набор транзакций, выполняемый актером при диалоге с информационной системой. На диаграмме изображается один актер, но пользователей, выступающих в роли актера, может быть много. Диаграмма прецедентов использования имеет высокий уровень абстракции и позволяет определить функциональные требования к И С.

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

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

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

206	Часть 2. Проектирование и использование БД
Диаграммы активности	представляют частный случай диаграмм состоя-

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

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

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

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

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

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

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

7. Средства автоматизации проектирования	207
(как при компиляции).
Диаграммы размещения используются для задания конфигурации	ком-

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

Примеры диаграмм UML

Чтобы получить более наглядное представление, приведем ряд диаграмм UML. Рассмотрим пример, в котором описана объектная модель, построенная в Rational Rose 98. В качестве предметной области используем описание работы библиотеки, которая получает запросы от клиентов на различные издания и регистрирует информацию об их возвращении в фонды библиотеки.

Пример диаграммы ?грецедентов использования приведен на рис. 7.5. На диаграмме приведен ряд выделенных при анализе реализуемых информационной системой функций: администрирование пользователей (Administrative Client); учет книг (Administrative Books); составление отчетов (Report) и поиск издания (Find Book).

Рис. 7.5. Диаграмма прецедентов использования

Пример диаграммы следования приведен на рис. 7.6. Приведенная диаграмма описывает поведение объектов во времени. Она показывает объекты и последовательность сообщений, посылаемых объектами.

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

Книга Журнал

Администратор Добавить книгу Удалить книгу

Зарегистрировать книгу

Т1

Рис. 7.6. Диаграмма следования

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

7.5. Классификация CASE-средств

При классификации CASE-средств используют следующие признаки:

•ориентацию на этапы жизненного цикла;

•функциональную полноту;

•тип используемой модели;

•степень независимости от СУБД;

•допустимые платформы.

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

По ориентации на этапы жизненного цикла выделяют следующие основные типы CASE-средств:

•средства анализа, предназначенные для построения и анализа моделей предметной области, например: Design/IDEF (Meta Software) и BPwin (Logic Works);

7. Средства автоматизации	проектирования	209
• средства анализа	и проектирования,	обеспечивающие создание проект-

ных спецификаций, например: Vantage Team Builder (Cayenne), Silverrun (Silverrun Technologies), PRO-IV (McDonnell Douglas) и CASE.Аналитик ( Mакро П poджект );

• средства проектирования баз данных, обеспечивающие моделирование данных и разработку схем баз данных для основных СУБД, например: ERwin (Logic Works), S-Designor (SPD), DataBase Designer (ORACLE);

• средства разработки приложений, например: Uniface (Compuware), J AM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Centura) и Delphi (Borland).

По функциональной полноте CASE-системы и средства можно условно разделить на следующие типы:

•системы, предназначенные для решения частных задач на одном или нескольких этапах жизненного цикла, например, ERwin (Logic Works), S-Designor (SPD), CASE.Аналитик (МакроПроджект) и Silverrun (Silverrun Technologies);

•интегрированные системы, поддерживающие весь жизненный цикл И С и связанные с общим репозиторием, например система Vantage Team Builder (Cayenne) и система Designer/2000 с системой разработки приложений Developer/2000 (ORACLE).

По типу используемых моделей CASE-системы условно можно разделить на три основные разновидности: структурные, объектно-ориентированные и комбинированные.

Исторически первые структурные CASE-системы основаны на методах структурного и модульного программирования, структурного анализа и синтеза, например, система Vantage Team Builder (Cayenne).

Объектно-ориентированные методы и CASE-системы получили массовое использование с начала 90-х годов. Они позволяют сократить сроки разработки, а также повысить надежность и эффективность функционирования ИС. Примерами объектно-ориентированных CASE-систем являются Rational Rose (Rational Software) и Object Team (Cayenne).

Комбинированные инструментальные средства поддерживают одновременно структурные и объектно-ориентированные методы, например: Designer/ 2000 (ORACLE).

По степени независимости от СУБД CASE-системы можно разделить на две группы:

•независимые системы;

•встроенные в СУБД.

Независимые CASE-системы поставляются в виде автономных систем, не входящих в состав конкретной СУБД. Обычно они поддерживают несколько форматов баз данных через интерфейс ODBC. К числу независимых CASE-

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

систем относятся S-Designor (SDP, Powersoft), ERwin (LogicWorks) и Silverrun (Computer Systems Advisers Inc.).

Встроенные CASE-системы обычно поддерживают главным образом формат баз данных СУБД, в состав которой они входят. При этом возможна поддержка и других форматов баз данных. Примером встроенной системы является Designer/2000, входящая в состав СУБД ORACLE.

Рассмотрим наиболее популярные CASE-системы.

7.6. Системы структурного типа

При рассмотрении представителей CASE-систем структурного типа можно выделить две основные группы: независимые и встроенные системы.

Независимые системы

К независимым CASE-системам структурного типа можно отнести популярные продукты S-Designor (фирмы SDP, приобретенной Powersoft), пакет ERwin (LogicWorks) и Silverrun (Computer Systems Advisers Inc.).

S-Designor представляет собой графический инструмент, позволяющий в определенной степени автоматизировать процесс проектирования реляционных БД. Начиная с версии S-Designor 6.0, продукт выпускается под названием PowerDesigner 6.0.

При разработке структуры БД с помощью S-Designor формируется концептуальная модель данных (КМД), которая впоследствии преобразуется в физическую модель данных (ФМД).

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

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

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

	7. Средства автоматизации проектирования		211
			Руководит
	ОТДЕЛ	Состоит	СОТРУДНИК
	Номер отдела		Идентификатор
	Название отдела		Фамилия
	Расположение отдела		Имя

Рис. 7.7. Пример концептуальной модели

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

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

Если в концептуальной модели данных между сущностями имеется связь вида М:М, то при построении физической модели автоматически создается дополнительная таблица. Ее назначение - нормализация отношения. Колонками таблицы являются идентификаторы участвующих в связи сущностей. Первичный ключ новой таблицы объединяет колонки первичных ключей двух исходных связанных таблиц. Пример перехода от концептуальной модели данных к физической модели данных для связей вида М:М приведен на рис. 7.8. Символьная конструкция вида <рк> обозначает, что эта колонка (поле) таб-

лицы является ключевой.
Концептуальная модель данных	Физическая модель данных

Рис. 7.8. Пример перехода к физической модели

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

Рассматриваемая система позволяет создавать базы данных путем подключения к работающему серверу СУБД через интерфейс ODBC или готовить текстовые файлы (пакеты) SQL-операторов по созданию структуры БД. Файлы SQL-операторов после этого обрабатываются некоторой СУБД, в результате чего создаются нужные БД.

S-Designor имеет интерфейсы со многими СУБД, включая Oracle, Ingress, Informix, Sybase, SQL Server, Access и Paradox.

Система S-Designor работает в среде Windows и обеспечивает возможность использования других инструментальных средств разработки программ, таких как PowerBuilder, TeamWindows и Progress. Для инструментальной системы PowerBuilder пакет S-Designor позволяет выполнить автоматическую генерацию приложения.

С помощью средств моделирования структур БД системы S-Designor можно осуществлять прямой (к функциональной модели) и обратный (к концептуальной модели) переходы. «Обратное проектирование» информационной модели может понадобиться при решении задач анализа и расширения функций существующих АИС.

Создание таблиц БД сопровождается синтезом средств обеспечения поддержки ссылочной целостности данных в соответствии с типом конкретной СУБД.

Наряду с синтезируемыми программными объектами, система S-Designor поддерживает генерацию отчетов о концептуальной и физической моделях данных. Отчеты можно готовить в виде ASCII-текстов или в формате RTF для текстовых процессоров, например MS Word.

Система S-Designor поддерживает групповую разработку. Модели данных проектируемой информационной системы могут разбиваться на подмодели, с каждой из которых может работать отдельный разработчик. Подмодели данных для удобства хранятся в базах данных. Для хранения моделей может использоваться любая SQL-СУБД. В системе S-Designor имеются средства администрирования групповой работы с парольной защитой.

ERwin представляет собой систему концептуального моделирования баз данных. Система ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Sybase, MS SQL Server и др.) и реинжиниринг баз данных. Для ряда систем быстрой разработки приложений (PowerBuilder, SQL Windows, Delphi, Visual Basic) обеспечивается генерация форм и прототипов приложений.

По функциональным возможностям ERwin близок к S-Designor. В ERwin связь с СУБД организуется напрямую, в отличие от S-Designor, в которой связь с СУБД осуществляется через ODBC-интерфейс с использованием внешних файлов. Отсюда следует, что ERwin менее универсальна и поддерживает меньшее число СУБД.