Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
16
Добавлен:
13.03.2015
Размер:
618.5 Кб
Скачать

Лекция№4 Жизненный цикл базы данных.

Проблемы организации информационного фонда. Жизненный цикл приложения базы данных

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

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

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

Жизненный цикл приложения баз данных

Этапы жизненного цикла приложения базы данных показаны на рисунке 4.

Рассмотрим основные действия, выполняемые на каждом этапе жизненно­го цикла базы данных.

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

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

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

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

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

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

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

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

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

  • с помощью наблюдений за деятельностью предприятия;

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

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

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

Требование - некоторая функция, которая должна быть включена в создаваемую систему.

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

Определение набора требуемых функциональных возможностей приложения базы данных является критически важным действием. Поэтому для того чтобы тре­бования были более четко сформулированы, существует ряд методов составления спецификаций тре­бований, к числу которых относятся, например, технология структурного анализа и проектирования (SAD), диаграммы потоков данных (DFD) и графики "вход-процесс-выход" (HIPO), дополненные соответствующей документацией. Для получения гарантий того, что составленный набор требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного проектирования и создания программ. Аббревиатура CASE, соответствует двум направлениям использования CASE-систем. Первое из них — подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Далее CASE-системы этого направления будем называть системами CASE для концептуального проектирования. Второе направление было рассмотрено выше, его название Computer Aided Software Engineering переводится, как автоматизированное проектирование программного обеспечения, соответствующие CASE-системы называют инструментальными CASE или инструментальными средами разработки ПО (одно из близких к этому названий — RAD).

Среди систем CASE для концептуального проектирования различают системы функционального, информационного или поведенческого проектирования. Наиболее известной методикой функционального проектирования сложных систем является методика SADT (Structured Analysis and Design Technique) впоследствии ставшая основой международного стандарта IDEFO.

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

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

Средства CASE по своему функциональному назначению принадлежат к одной из следующих групп:

1) средства программирования;

2) средства управления программным проектом;

3) средства верификации (анализа) программ;

4) средства документирования.

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

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

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

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

  • разработка предварительного варианта проекта, структура которого позво­ляет удовлетворить все основные требования, предъявляемые к производи­тельности системы — например, ко времени реакции системы.

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

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

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

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

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

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

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

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

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

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

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

Этот этап выполняется только в том случае, если новая база данных заменяет старую.

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

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

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

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

  • Тестирование потоковэто стратегия тестирования систем, работающих в ре­альном масштабе времени, которые обычно состоят из большого количества взаимо­действующих процессов, управляемых с помощью прерываний. Эти системы доволь­но трудно тестируются, поскольку взаимодействие процессов системы зависит от времени. Стратегия тестирования потоков направлена на слежение за отдельными процессами. При этом "поток" обработки каждого внешнего события "проходит" че­рез различные системные процессы. Данная стратегия включает идентификацию и выполнение каждого возможного "потока" обработки в системе.

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

Это последний этап жизненного цикла, он включает выполнение таких дей­ствий, как:

  • контроль производительности системы. Если производительность падает ниже приемлемого уровня, то может потребоваться дополнительная на­стройка или реорганизация базы данных;

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

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

Основная литература: 1[147-177]

1. Из каких этапов состоит жизненный цикл приложений баз данных?

2. Что подразумевается под планирование разработки базы данных и какие дополнительные работы необходимо при этом провести?

3. Каким образом можно произвести сбор необходимой информации?

4. Что такое требование пользователя?

5. Какие цели преследуются при проектировании баз данных?

6. Какие подходы применяются при проектировании баз данных?

7. Что вы понимаете под прототипом?

8. Для чего необходимо тестирование и какие стратегии тестирования вы знаете?

9. Какие действия выполняются на последнем этапе жизненного цикла приложений баз данных?

Соседние файлы в папке Новые лекции