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

Silverrun представляет собой открытую систему, используемую совместно с продуктами других различных фирм. Она имеет интерфейсы с СУБД, в число которых входят следующие: DB2, Informix, Ingress, Oracle, Progress, SQLBase, SQLServer. Система Silverrun имеет интерфейсы с системами про-

граммирования для языков четвертого поколения (4GL), включая системы

PowerBuilder, Progress, SQLWindows, Uniface.

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

Она позволяет независимо строить модели двух видов: функциональные и информационные. Функциональные модели в виде диаграмм потоков данных DFD ориентированы на пользователей-заказчиков для обоснования требований и постановки задач. Информационные модели в виде диаграмм сущ- ность-связь служат для генерации схем баз данных.

Система Silverrun состоит из трех основных подсистем: модуля построения диаграмм потоков данных и двух модулей построения диаграмм типа сущность-связь: модуля концептуальных моделей ERX (Entity Relationship eXpert) и модуля реляционных моделей RDM (Relational Data Modeler).

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

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

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

В целом система Silverrun по своим возможностям близка к системам S- Designor и ERwin. Система поддерживает коллективную разработку в разнородной среде и может функционировать на платформах Windows, OS/2, Macintosh и Solaris.

Система Designer/2000

CASE-система Designer/2000 фирмы ORACLE является встроенной и используется в СУБД Oracle. Основу CASE-технологии, реализованной в продуктах фирмы ORACLE, составляют:

•методология структурного нисходящего проектирования;

•поддержка всех этапов жизненного цикла прикладной системы;

•ориентация на технологию «клиент-сервер»;

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

•возможность одновременной работы с репозиторием многих пользователей;

•автоматизация последовательного перехода между этапами разработки;

•автоматизация проектирования и создания приложения (создание докумен-

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

жения и синтез программ.

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

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

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

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

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

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

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

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

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

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

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

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

Генератор серверной части по спецификациям БД автоматически строит тексты программ на языке SQL (операторы определения схем БД, триггеров, хранимых процедур и т. д.). Генераторы клиентских частей по полученным спецификациям автоматически синтезируют тексты программных модулей (экранные формы, отчеты, процедуры и прочее). Для каждого типа модулей имеется свой генератор.

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

7.7. Объектно-ориентированные системы

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

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

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

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

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

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

Конкретный вариант системы определяется языком, на котором выполняется генерация кодов программ (С++, Smalltalk, PowerBuilder, Ada, SqlWindows и ObjectPro), Основным вариантом системы является Rational Rose/C++, позволяющий генерировать программные коды на С++, подготавливать проектную документацию в виде диаграмм и спецификаций.

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

Основными компонентами системы являются следующие:

•репозиторий, представляющий объектно-ориентированную БД;

•графический интерфейс пользователя;

•средства просмотра проекта, обеспечивающие перемещение по элементам проекта, в том числе по иерархиям классов и подсистем, переключе-

ние между видами диаграмм;

• средства контроля проекта, позволяющие находить и устранять ошибки;

•средства сбора статистики;

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

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

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

внескольких проектах.

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

•спецификации классов, объектов, атрибутов и операций;

• заготовки текстов программ;

• модель программной системы.

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

7.8. Рекомендации по применению CASE-систем

Анализ характеристик и возможностей большинства современных CASEсистем позволяет сделать следующие выводы.

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

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

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

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

5.Современные CASE-системы ориентированы на квалифицированного пользователя, поскольку для их использования требуется знание теории проектирования баз данных. Так, например, для разработки структуры БД с помощью системы S-Designor информацию о проектируемой информационной системе нужно представить в виде ER-модели.

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

Применение нескольких CASE-систем часто позволяет объединить достоинства используемых систем и существенно сократить сроки решения задач исследования или разработки. Для примера приведем схему возможного совместного использования CASE-систем ERWin, BPWin и Rational Rose.

Как показано на рис. 7.9, различные CASE-системы могут взаимодействовать друг с другом напрямую (ERWin и BPWin), либо с помощью дополнительных модулей (Model Mart - средство коллективной разработки, ERWin Translation Wizard - модуль импорта в ERWin моделей, созданных в Rational Rose).

Рис. 7.9. Схема взаимодействия ERWin, BPWin и Rational Rose

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

1.Дайте определение CASE-средствам и CASE-технологии.

2.Дайте определение понятия модели жизненного цикла ПО и назовите основные варианты моделей.

3.Перечислите требования к перспективной CASE-системе.

4.Охарактеризуйте спиральную модель жизненного цикла ПО.

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

6.Приведите пример диаграммы потоков данных.

7.Охарактеризуйте методологию функционального моделирования, приведите пример декомпозиции диаграмм.

8.Что представляет собой унифицированный язык моделирования UM L?

9.Назовите типы диаграмм унифицированного языка моделирования. 10. Для чего служат диаграммы прецедентов использования и диаграммы

классов?

11. Приведите пример диаграммы следования.

12. Назовите признаки классификации CASE-средств.

13.На какие группы делятся CASE-системы по их функциональной ориентации?

14.Приведите пример независимой CASE-системы структурного типа и дайте ей характеристику.

15.Охарактеризуйте CASE-систему Designer/2000.

16.К какому типу CASE-систем относится Rational Rose?

17.Назовите основные компоненты системы Rational Rose.

Литература

1.Бабкин А., Новиков Ф. Унифицированный язык моделирования UML. Software Engineering Center St. Petersburg, 1999 (www2.sec.fi/russia/OLD/public/ reports).

2.ВендровА. M. CASE-технологии. Современные методы и средства проектирования информационных систем. М.: Финансы и статистика, 1998.

3.Горин С. В., Тандоев А. Ю. CASE средство S-Designor 4.2 для разработки структуры базы данных / / Системы Управления Базами Данных, № 1, 1996. С. 79-

86.

4.Горчинская О. Ю. DESIGNER/2000 - новое поколение CASE-продуктов фирмы ORACLE / / Системы Управления Базами Данных, № 3, 1995. С. 9-25.

5.Диго С. М. Базы данных: проектирование и использование. Учебник. - М.: Финансы и статистика, 2005.

6.Каляное Г. Н. CASE. Структурный системный анализ (автоматизация и применение). М.: Лори, 1996.

7.Коннолли Т., Бегг К. Базы данных. Проектирование. Реализация и сопровождение. Теория и практика. М.: Вильяме, 2003.

8.Кумсков М. Унифицированный язык моделирования (UML) и его поддержка в Rational Rose 98i - CASE-средстве визуального моделирования (www.interface.ru/public).

9.Международные стандарты, поддерживающие жизненный цикл программных средств. М.: МП «Экономика», 1996.

10.Мюллер Роберт Дж. Базы данных и UML. Проектирование. - М.: Лори, 2002.'

11.Новоженов Ю. В., Звонкий М. 3., Тимонин Н.Н. Объектно-ориентированные

CASE-средства / / Системы Управления Базами Данных, № 5-6, 1996.

С. 119-125.

12.Новоженов Ю. В. Объектно-ориентированные технологии разработки сложных программных систем. М., 1996.

13.Панащук С. А. Разработка информационных систем с использованием CASE-

системы SILVERRUN / / Системы Управления Базами Данных, № 3, 1995.

С. 41-47.

14.Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. М.: Мир, 1999.

221

8.Использование баз данных

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

8.1. Настройка и администрирование

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

•выбор способа размещения файлов на диске;

•определение требуемого объема дисковой памяти;

•распределение информации на диске;

•резервное копирование.

Рассмотрим коротко решение этих задач.

Выбор способа размещения файлов на диске

Большинство СУБД позволяют администратору системы выбрать один из двух способов размещения файлов БД на дисках: на «чистьис» дисках или в файловой системе ОС. В первом случае управление данными, хранящимися на отдельных носителях, производится низкоуровневыми средствами самих СУБД. Некоторые СУБД, например Ingres и Interbase, требуют обязательного использования файловой системы (в среде ОС UNIX). Рассмотрим достоинства и недостатки обоих вариантов размещения файлов на диске.

Достоинством хранения информации на «чистых» дисках является то, что внешняя память используется более эффективно и, как правило, увеличивается производительность обмена с дисками. Экономия внешней памяти от 10 до 20% достигается на основе устранения необходимости организации самой файловой системы. Так, в ОС UNIX служебная информация файловой системы составляет примерно 10% от емкости дисков. Примерно столько же памяти резервируется для последующего возможного расширения файлов. Производительность (обычно порядка 10%) повышается на

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

основе удаления дополнительного слоя программного обеспечения при обращении к дискам.

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

Определение требуемого объема дисковой памяти

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

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

Распределение информации на дисках

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

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