Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
5. Основы проектирования.doc
Скачиваний:
4
Добавлен:
25.11.2018
Размер:
208.38 Кб
Скачать

5. Основы проектирования информационных систем

5.1. Жизненный цикл информационной системы

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

  1. планирование разработки базы данных;

  2. определение требований к системе;

  3. сбор и анализ требований пользователей;

  4. проектирование базы данных:

  • концептуальное проектирование базы данных;

  • логическое проектирование базы данных;

  • физическое проектирование базы данных;

  • разработка приложений:

    • проектирование транзакций;

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

  • реализация;

  • загрузка данных;

  • тестирование;

  • эксплуатация и сопровождение:

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

    • адаптация, модернизация и поддержка переработанных вариантов.

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

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

    Этап 3. Сбор и анализ требований пользователей. На данном этапе необходимо создать для себя модель движения важных материальных объектов и уяснить процесс документооборота.

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

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

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

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

    Наиболее распространенная технология концептуального моделирования данных, реализующая нисходящий подход, - модель "сущность — связь" (Entity-Relationship model — ER-модель) была предложенной американским ученым в области информатики Питером Ченом.

    Эту технологию мы использовали на наших лабораторных занятиях.

    ER-модель относится к семантическим моделям. Семантическое моделирование данных связано со смысловым содержанием данных и может осуществляться независимо от их представления в компьютере.

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

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

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

    • Выделение ключевых свойств объектов.

    • Спецификация связей между объектами. Удаление избыточных связей.

    • Объединение предметных областей.

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

    Цель второй фазы проектирования базы данных – логического проектирования – состоит в создании логической модели данных. Эта фаза проектирования опирается на определенную модель организации данных (реляционная, сетевая, иерархическая), которая определяется типом предполагаемой для реализации информационной системы СУБД.

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

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

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

    Проектирование транзакций заключается в определении:

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

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

    • выходных данных, формируемых транзакцией;

    • степени важности и интенсивности использования транзакции.

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

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

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

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

    Этап 8. Тестирование. Для оценки законченности и корректности выполнения приложения базы данных могут использоваться различные стратегии тестирования.

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

    • восходящее тестирование,

    • нисходящее тестирование,

    • тестирование потоков,

    • интенсивное тестирование.

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

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

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

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

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

    Типы тестов, которые используют для проверки работы программ:

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

    Применение основного теста – главный момент тестирования, но помимо него программа должна быть подвергнута и другим тестам.

    • Тест граничных значений, или "стрессовый тест" – проверяет работу программы для граничных значений параметров. Часто для граничных значений параметров работа программы носит особый характер, который тем самым требует и особого контроля.

    Если в качестве примера рассмотреть тестирование подпрограммы сортировки массива, то в рамках стрессового теста нужно исследовать следующие ситуации:

    • сортируемый массив пуст;

    • сортируемый массив содержит только один элемент;

    • все элементы в сортируемом массиве одинаковы;

    • массив уже отсортирован.

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

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

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