Основы проектирования информационных систем
Жизненный цикл информационной системы
Как и любой программный продукт, информационная система обладает собственным жизненным циклом, который включает в себя следующие основные этапы:
1. планирование разработки базы данных;
2. определение требований к системе;
3. сбор и анализ требований пользователей;
4. проектирование базы данных:
· концептуальное проектирование базы данных;
· логическое проектирование базы данных;
· физическое проектирование базы данных;
5. разработка приложений:
· проектирование транзакций;
· проектирование пользовательского интерфейса;
6. реализация;
7. загрузка данных;
8. тестирование;
9. эксплуатация и сопровождение:
· анализ функционирования и поддержка исходного варианта информационной системы;
· адаптация, модернизация и поддержка переработанных вариантов.
Этап 1. Планирование разработки базы данных. Содержание данного этапа — разработка стратегического плана, в процессе которого осуществляется предварительное планирование конкретной информационной системы. Планирование разработки информационной системы состоит в определении трех основных компонентов: объема работ, ресурсов и стоимости проекта. Важной частью разработки стратегического плана является проверка осуществимости проекта.
Этап 2. Определение общих требований к информационной системе. На данном этапе необходимо определить диапазон действия приложения базы данных, состав его пользователей и области применения. Определение требований включает выбор целей БД, выяснение информационных потребностей различных отделов и руководителей фирмы и требований к оборудованию и программному обеспечению.
Этап 3. Сбор и анализ требований пользователей. На данном этапе необходимо создать для себя модель движения важных материальных объектов и уяснить процесс документооборота.
Собранная информация о каждой важной области применения приложения и пользовательской группе должна включать следующие компоненты: исходную и генерируемую документацию, подробные сведения о выполняемых транзакциях, а также список требований с указанием их приоритетов.
Информация должна быть максимально детализирована. Например, по каждому документу необходимо установить периодичность его использования, определить данные, необходимые для его формирования (анализируя существующую и планируемую документацию, выясняют, как получается каждый элемент данных, кем получается, где в дальнейшем используется, кем контролируется).
Этап 4. Проектирование базы данных. Полный цикл разработки базы данных включает концептуальное, логическое и физическое ее проектирование.
Первая фаза процесса проектирования базы данных - концептуальное проектирование – заключается в создании концептуальной модели данных. Проектирование сложных баз данных осуществляется использованием, так называемого, нисходящего подхода. Этот подход начинается с разработки структуры данных, которая содержит несколько высокоуровневых объектов и связей, затем работа продолжается в виде серии нисходящих уточнений, в результате которых в структуре данных появляются объекты более низких уровней с соответствующими связями.
Наиболее распространенная технология концептуального моделирования данных, реализующая нисходящий подход, - модель "сущность — связь" (Entity-Relationship model — ER-модель) была предложенной американским ученым в области информатики Питером Ченом.
Эту технологию мы использовали на наших лабораторных занятиях.
ER-модель относится к семантическим моделям. Семантическое моделирование данных связано со смысловым содержанием данных и может осуществляться независимо от их представления в компьютере.
В построении общей концептуальной модели данных выделяют ряд этапов.
· Выделение предметных областей информационной системы, соответствующих относительно независимым данным.
· Выявление объектов, относящихся к каждой предметной области проектируемой информационной системы, и описание свойств, составляющих структуру каждого объекта.
· Выделение ключевых свойств объектов.
· Спецификация связей между объектами. Удаление избыточных связей.
· Объединение предметных областей.
Созданная концептуальная модель данных является источником информации для фазы логического проектирования базы данных.
Цель второй фазы проектирования базы данных – логического проектирования – состоит в создании логической модели данных. Эта фаза проектирования опирается на определенную модель организации данных (реляционная, сетевая, иерархическая), которая определяется типом предполагаемой для реализации информационной системы СУБД.
Концептуальное и логическое проектирование — это итеративные процессы, которые включают в себя ряд уточнений, продолжающиеся до тех пор, пока не будет получен наилучший результат.
Целью физического проектирования является создание описания базы данных, предназначенное для реализации с использованием конкретной СУБД.
Этап 5. Разработка приложений. Параллельно с проектированием системы базы данных выполняется разработка приложений. Главные составляющие данного процесса — это проектирование транзакций и пользовательского интерфейса.
Проектирование транзакций заключается в определении:
· входных данных, которые используются транзакцией;
· последовательности действий, составляющих транзакцию;
· выходных данных, формируемых транзакцией;
· степени важности и интенсивности использования транзакции.
· Интерфейс должен быть удобным и обеспечивать все функциональные возможности, предусмотренные техническим заданием.
Этап 6. Реализация. На данном этапе осуществляется физическая реализация базы данных и разработанных приложений, позволяющих пользователю формулировать требуемые запросы к БД и манипулировать данными в БД. База данных описывается на языке определения данных выбранной СУБД. В результате компиляции его команд и их выполнения создаются схемы и пустые файлы базы данных.
Прикладные программы, меню, формы ввода данных, отчеты и другие компоненты информационной системы реализуются с помощью языков программирования высокого уровня.
Этап 7. Загрузка данных. На этом этапе созданные в соответствии со схемой базы данных пустые файлы, предназначенные для хранения информации, должны быть заполнены данными.
Этап 8. Тестирование. Для оценки законченности и корректности выполнения приложения базы данных могут использоваться различные стратегии тестирования.
При плановом подходе к тестированию программный продукт проверяется последовательно модуль за модулем. Если она состоит из центрального модуля, который производит обращения к периферийным модулям, то возможны различные стратегии тестирования:
· восходящее тестирование,
· нисходящее тестирование,
· тестирование потоков,
· интенсивное тестирование.
Восходящее тестирование применяется обычно для небольших программ. Сначала тестируются отдельные периферийные модули информационной системы, а затем центральный модуль, который при таком подходе взаимодействует с уже отлаженными периферийными модулями.
Для больших программ применяют нисходящее тестирование, когда одновременно с тестированием периферийных модулей (или даже до их тестирования) производится тестирование центрального модуля. Причем при таком варианте тестирования центральный модуль взаимодействует либо с уже отлаженными периферийными модулями, либо, если соответствующие модули еще не отлажены, с так называемыми заглушками – имитаторами периферийных модулей.
В задачу имитаторов входит моделирование работы соответствующих модулей с целью поддержать функционирование центрального модуля. Обычно заглушки выдают сообщение о факте своего участия в работе и простейший результат. Например, заглушка для модуля вычисления определенного интеграла может возвращать константу или случайную величину в требуемом диапазоне.
Тестирование потоков осуществляется при тестировании работающих в реальном масштабе времени систем, которые обычно состоят из большого количества взаимодействующих процессов, управляемых с помощью прерываний. Стратегия тестирования потоков направлена на слежение за отдельными процессами.
Стратегия интенсивного тестирования часто включает серию тестов с постепенно возрастающей нагрузкой и продолжается до тех пор, пока система не выйдет из строя.
Типы тестов, которые используют для проверки работы программ:
· Основной тест – тест, проверяющий основные функциональные возможности программы.
Применение основного теста – главный момент тестирования, но помимо него программа должна быть подвергнута и другим тестам.
· Тест граничных значений, или "стрессовый тест" – проверяет работу программы для граничных значений параметров. Часто для граничных значений параметров работа программы носит особый характер, который тем самым требует и особого контроля.
Если в качестве примера рассмотреть тестирование подпрограммы сортировки массива, то в рамках стрессового теста нужно исследовать следующие ситуации:
- сортируемый массив пуст;
- сортируемый массив содержит только один элемент;
- все элементы в сортируемом массиве одинаковы;
- массив уже отсортирован.
· Аварийный тест – проверяет реакцию программы на возникновение разного рода аварийных ситуаций, в частности вызванных неправильными исходными данными, то есть проверяются те блоки программы, которые предназначены для диагностики и обработки таких ситуаций.
Поэтому в реальных программах, спроектированных с достаточной надежностью, блоки, которые должны работать только в особых аварийных ситуациях, могут занимать до 90% общего объема программы. Эти блоки иногда называют блоками защиты от дурака. Такие системы устойчиво функционируют даже при самых неподходящих действиях работающих с ними людей.
Этап 9. Эксплуатация и сопровождение. Основные действия, связанные с этим этапом сводятся к наблюдению за созданной системой и поддержке ее нормального функционирования по окончании развертывания. Поддержка БД предполагает разрешение проблем, возникающих в процессе эксплуатации БД и связанных как с ошибками реализации БД, так и с изменениями в самой предметной области, созданием дополнительных программных компонент или модернизацией самой БД.
