2

Аннотация

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

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

При проектировании базы данных использовалось CASE-средство как ERwin 4.0. Также использовалась система управления реляционными базами данных Microsoft Access 2003. Среда Delphi 7.0 была выбрана в качестве средства для разработки СУБД

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

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

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

Annotation

This degree work is devoted to a theme "The development of the information system under the account of account materials and conduction statistics of a press". The system will be a real boon to companies that use both own and rented vehicles: it will allow you to automate the vehicles tracking process. The data base is freely distributed. The Case tool Erwin 4.0, Microsoft Access 2003, Delphi 7.0 were used at designing of database. This program has the clear interface adapted for simple and easy process of a press in company.

The following results have been reached during performance of system: the principal model of database, the logic normalized model of database were designed, the physical model of database was constricted, the technical tools were chosen, the basic program modules of system were realized, the ecological and ergonomic requirements were analyzed at designing the interface.

The information system has been developed on the basis of the received materials. This system is directed on automation the vehicles tracking process.

Оглавление

• Аннотация 2
• Annotation 3
• Введение 6
• Постановка задачи 9
• Глава 1. Основы проектирования программных продуктов 12
• 1.1. Характеристика программных продуктов 12
• 1.2. Жизненный цикл программного обеспечения (ЖЦ ПО) 15
• 1.3. Модели жизненного цикла ПО 18
• 1.4. Структурный подход к проектированию ПП 20
• Глава 2. Основные принципы проектирования базы данных 24
• 2.1. Понятие базы данных и системы управления базами данных 24
• 2.2. Основные свойства базы данных 24
• 2.3. Трехуровневая архитектура базы данных 26
• 2.4. Жизненный цикл базы данных 28
• 2.4.1. Планирование разработки базы данных 29
• 2.4.2. Определение требований к системе 30
• 2.4.3. Сбор и анализ требований пользователей 30
• 2.4.4. Проектирование базы данных 30
• 2.4.5. Разработка приложений 31
• 2.4.6. Реализация 31
• 2.4.7. Загрузка данных 32
• 2.4.8. Тестирование 32
• 2.4.9. Эксплуатация и сопровождение 33
• 2.5. Модели представления данных 33
• 2.5.1. Иерархическая модель данных 34
• 2.5.2. Сетевая модель данных 34
• 2.4.3. Реляционная модель данных 34
• 2.6. Проектирование базы данных 41
• 2.6.1. Нормализация как особенность проектирования базы данных 41
• 2.6.2. Концептуальное проектирование базы данных 44
• 2.6.3. Логическое проектирование базы данных 46
• 2.6.4. Физическое проектирование базы данных 48
• 2.6.5. Этапы проектирования базы данных 49
• Глава 3. Проектирование пользовательского интерфейса 51
• 3.1. Требования к пользовательскому интерфейсу 51
• 3.1.1. Методы оценки пользовательского интерфейса 53
• 3.1.2. Цели и критерии оценки пользовательского интерфейса 53
• 3.1.3. Этапы проектирования интерфейса 55
• 3.2. Принципы проектирования эргономичного пользовательского интерфейса 56
• 3.2.1. Размещение информации на экране 57
• 3.2.2. Непротиворечивость и стандартизация 58
• 3.2.3. Тексты и диалоги 58
• 3.2.4. Средства управления графического интерфейса пользователя 59
• 3.2.5. Меню 59
• 3.2.6. Формы 60
• 3.2.7. Организация системы навигации и системы отображения состояний 61
• 3.2.8. Проектирование сообщений 61
• 3.2.9. Предотвращение, обнаружение и исправление ошибок 62
• Глава 4. Построение концептуальной модели базы данных 63
• 4.1. Исследование предметной области применения и выявление требований конечных пользователей и решаемых задач 63
• 4.1.1. Определение объектов базы данных и связей между объектами 63
• 4.1.2. Инфологическая модель данных "сущность-связь" 66
• 4.2. Проектирование логической модели базы данных 68
• 4.3. Проектирование физической модели базы данных 69
• Глава 5. Реализация проекта 76
• 5.1. Набор компонентов, используемых для создания приложений 76
• 5.2. Работа с режимами программы Diplom 77
• Глава 6. Выбор инструментальных средств 102
• 6.1. Выбор аппаратных средств 102
• 6.2. ERwin - современное средство проектирования баз данных 102
• 6.3. Microsoft Access 2003 105
• 6.4. Язык SQL как стандартный язык баз данных 108
• 6.4.1. Функциональные возможности языка SQL 109
• 6.4.2. Достоинства SQL 110
• 6.5. Среда Delphi как средство для разработки СУБД 110
• 6.5.1. Высокопроизводительный компилятор в машинный код 112
• 6.5.2. Библиотека визуальных компонент 113
• 6.5.3. Технологии доступа к данным 114
• 6.5.4. Элементы управления Windows XP 115
• 6.5.5. Генератор отчетов Rave Reports 5.0 116
• Глава 7. Обоснование реализуемости системы по результатам анализа предельно допустимой длины слова с помощью системы MathCad 2001i 117
• 7.1. Постановка задачи 117
• Глава 8. Расчет затрат на создание программного обеспечения и оценка технико-экономической эффективности разработанного программного обеспечения 122
• Введение 122
• 8.1. Расчет затрат на разработку системы учета компьютерного вагонов на подъездном пути на предприятии 122
• 8.2. Расчет затрат на основную заработную плату разработчикам 123
• 8.3. Расчет дополнительной заработной платы разработчиков программы 124
• 8.4. Расчет отчислений на социальное страхование и обеспечение 125
• 8.5. Расчет затрат на амортизацию ЭВМ, используемых при разработке системы учета компьютерного оборудования на предприятии 126
• 8.6. Расчет затрат на электроэнергию, используемую ЭВМ в процессе разработки программы 127
• 8.7. Расчет накладных расходов 128
• 8.8. Расчет затрат на эксплуатацию системы учета компьютерного оборудования на предприятии 129
• 8.9. Расчет отпускной цены разрабатываемой системы учета компьютерного оборудования на предприятии 132
• 8.10. Расчет окупаемости капитальных вложений 132
• Заключение 134
• Глава 9. Экологическая часть 136
• 9.1. Требования к условиям эксплуатации вычислительной техники (ВТ) 137
• 9.1.1. Требования к помещениям для эксплуатации ВТ 137
• 9.1.2. Требования к освещению помещений и рабочих мест пользователей ВТ 138
• 9.1.3. Требования к шуму и вибрации в помещениях для эксплуатации ВТ 140
• 9.1.4. Требования к микроклимату, содержанию аэроионов и вредных химических веществ в воздухе помещений эксплуатации ВТ 141
• 9.1.5. Требования к уровням электромагнитных полей в помещениях для эксплуатации ВТ 143
• 9.2. Требования к организации и оборудованию рабочих мест пользователей и мест эксплуатации ВТ 144
• 9.3. Общие рекомендации к организации труда и отдыха при работе с ВТ 147
• Заключение 150
• Список литературы 152
• Приложение 1 154
• Введение
• За последние годы в мире произошли значительные перемены, которые не могли не затронуть области информатики и вычислительной техники. Еще несколько лет назад работа с базами данных и электронными таблицами была уделом профессиональных программистов. Сами системы не были предназначены для широкого пользования. С появлением огромного числа банков, акционерных обществ и частных компаний ситуация резко изменилась.
• В настоящее время обработка и хранение информации не является чисто умозрительной задачей. Потеря информации или ее несвоевременное получение могут обернуться потерей денег. Именно этими обстоятельствами можно объяснить столь бурный рост компьютерной техники и стремительное развитие электронных таблиц и систем управления базами данных (СУБД). Для оперативного, гибкого и эффективного управления предприятиями, фирмами и организациями различных форм собственности широко внедряются системы автоматизированного управления, ядром которых являются базы данных (БД). При большом объеме информации и сложности производимых с ней операций проблема эффективности средств организации хранения, доступа и обработки данных приобретает особое значение.
• Данная дипломная работа посвящена теме "Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия".
• Система учета подвижного состава предназначена для предприятий, использующих как собственный, так и арендованный подвижной состав, и позволяет автоматизировать процесс его учета. Помимо того, что система существенно облегчает и ускоряет определение местонахождения подвижного состава, она также позволяет анализировать затраты на стоимость его обслуживания.
• База данных, разрабатываемая в данной дипломной работе, является свободно распространяемой, без каких-либо жестких ограничений. Это требование является желательным, поскольку не всегда руководители предприятий готовы пойти на уступки и оплачивать покупку того или иного программного обеспечения.
• Разработанная база данных позволит автоматизировать обработку информации и оперативно реагировать на обстановки, что особенно важно в таком динамичном сегменте рынка как грузоперевозки. Кроме того, она сократит долю ручного труда при ведении учета и позволит автоматизировать процесс составления документов.
• Для удобства учета программу можно разместить на внутреннем сервере компании, что позволит нескольким сотрудникам одновременно вводить информацию в одну БД. Это обеспечит равномерное распределение нагрузки на работников.
• При проектировании базы данных использовалось такое мощное CASE-средство как ERwin 4.0, поскольку от того, насколько хорошо спроектирована база данных, зависит удобство ее дальнейшего использования и администрирования. Также использовалась система управления реляционными базами данных Microsoft Access 2003, которая предоставляет пользователям функциональные возможности, позволяющие осуществлять доступ к важным данным, и производить их глубокий анализ, а также является серьезной средой разработки приложений.
• Среда Delphi 7.0 была выбрана в качестве средства для разработки СУБД, поскольку она отвечает следующим критериям: высокая скорость разработки приложений; возможность быстрого внесения изменений в программу; возможность редактирования и просмотра БД, используя средства разработки.
• Программа обладает интуитивно понятным интерфейсом, полностью адаптированным к простому и необременительному процессу печати в компании.
• Постановка задачи
• Темой дипломной работы является "Разработка информационно-справочной системы по учету вагонов на подъездном пути предприятия" и пользовательского интерфейса к ней. Вопрос автоматизации процесса учета вагонов до сих пор остается открытым и актуальности терять не собирается. Данная информационная система (ИС) позволит специалистам оперативно получать и анализировать данные о наличии, состоянии и точном местонахождении вагонов.
• Информационная система должна представлять собой базу данных, позволяющую вести учет вагонов на подъездном пути предприятия и обеспечивать расчет затрат на обслуживание вагонов и интерфейс к ней.
• ИС должна обеспечивать выполнение всех этих действий, а также должна обладать удобным и простым для восприятия интерфейсом и справочной системой.
• Исходными данными БД являются:
• 1. вагон:

инвентарный номер;

год изготовления;

грузоподъемность;

износ;

род вагона;

район движения;

2. операции с вагоном:

станция отправитель;

станция получатель;

фронт получения/отправления;

груз;

вес груза;

операция;

3. вид работ:

вид работ;

единица измерения;

цена за единицу измерения

База данных должна отвечать следующим требованиям:

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

внедрение данной БД должно значительно сократить время на заполнение ведомостей и позволить вести легкий и удобный учет вагонов

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

в БД должна быть предусмотрена печать отчетов.

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

Задачи, решаемые с помощью системы:

Загрузка в систему информации о вагонах, обработка информации;

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

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

Ввод, хранение, поиск и вывод информации о вагонах на подъездных путях;

Расчет стоимости обслуживания вагонов;

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

Система учета вагонов - это новый уровень учета, который существенно увеличивает производительность персонала и обеспечивает экономию времени. Основные преимущества системы:

Автоматизированная обработка получаемой информации.

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

Быстрый поиск информации. Поиск необходимой информации о вагоне занимает секунды.

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

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

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

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

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

Глава 1. Основы проектирования программных продуктов

1.1. Характеристика программных продуктов

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

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

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

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

Программный продукт - комплекс взаимосвязанных программ для решения определенной проблемы (задачи) массового спроса, подготовленный к реализации как любой вид промышленной продукции.[1]

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

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

Сопровождение программного продукта - поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.

Основными характеристиками программ являются:

алгоритмическая сложность (логика алгоритмов обработки информации);

состав и глубина проработки реализованных функций обработки;

полнота и системность функций обработки;

объем файлов программ;

требования к операционной системе и техническим средствам обработки со стороны программного средства;

объем дисковой памяти;

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

тип процессора;

версия операционной системы;

наличие вычислительной сети и др.

Показатели качества программных продуктов отражают следующие аспекты:

насколько хорошо (просто, надежно, эффективно) можно использовать программный продукт;

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

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

Характеристики качества программных продуктов:

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

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

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

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

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

Коммуникативность программных продуктов основана на максимально возможной их интеграции с другими программами, обеспечении обмена данными в общих форматах представления (экспорт/импорт баз данных, внедрение или связывание объектов обработки и др.).[1]

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

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

1.2. Жизненный цикл программного обеспечения (ЖЦ ПО)

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Стадия создания ПО - часть процесса создания ПО, ограничивающееся временными рамками и заканчивающееся выпуском конкретного программного продукта. Разработка ПО включает следующие стадии:

1. формирование требований (анализ)

2. проектирование

3. реализация (кодирование)

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

5. внедрение

6. сопровождение

7. снятие с эксплуатации

Стадия анализа предназначена для изучения требований к создаваемому программному продукту, а именно:

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

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

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

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

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

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

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

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

Снятие программного продукта с продажи и отказ от сопровождения происходят, как правило, в случае неэффективности работы программного продукта, наличия в нем неустранимых ошибок, отсутствия спроса.[1]

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства программные продукты.

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

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

1.3. Модели жизненного цикла ПО

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

В настоящее время известны и используются следующие модели жизненного цикла:

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

Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

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

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

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

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

1.4 Структурный подход к проектированию ПП

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

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

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

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

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

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

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

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

принцип непротиворечивости заключается в обоснованности и согласованности элементов;

принцип структурирования данных заключается в том, что данные должны быть структурированы и иерархически организованы.[1]

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). Данное средство было использовано в дипломной работе для проектирования специализированной базы данных, на основе которой разрабатывалась система учета подвижного состава на подъездном пути. С помощью ER-диаграмм определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных, что соответствует выбранной модели базы данных, проектируемой в данной дипломной работе.[1]

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

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

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

Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.[1]

Глава 2. Основные принципы проектирования базы данных

2.1 Понятие базы данных и системы управления базами данных

База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области, или иначе БД - это совокупность взаимосвязанных данных при такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений в определенной предметной области.[3]

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

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

2.2 Основные свойства базы данных

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

Проектируемая БД должна обладать определенными свойствами. Ниже перечислены основные свойства базы данных.

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

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

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

Эффективность. Свойство эффективности обычно понимается как:

минимальное время реакции на запрос пользователя;

минимальные потребности в памяти;

сочетание этих параметров.

Предельные размеры и эксплуатационные ограничения. Предельные размеры, а также другие ограничения, накладываемые эксплуатацией данной БД, могут существенно повлиять на проектное решение.[3]

2.3. Трехуровневая архитектура базы данных

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

администраторы данных и баз данных;

разработчики баз данных;

прикладные программисты;

конечные пользователи.

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

Физическое проектирование и физическая реализация базы данных, обеспечение безопасности и целостности данных, обеспечение максимальной производительности приложений - это область действия компетенций Администратора базы данных (АБД). Как видно по сравнению с АД, обязанности АБД более связаны с решением технических проблем.

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

При проектировании больших БД все разработчики распадаются на две группы:

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

разработчики физической базы данных.

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

разработка концептуальной модели БД;

разработка логической модели БД.

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

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

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

Чтобы различать представления данных конечными пользователями, программистами и АБД создаются разные уровни моделей данных. Их общая структура представлена на рисунке 2.1.

2

Рис.2.1. Уровни моделей данных

Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни.[3]

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

2.4. Жизненный цикл базы данных

Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦ БД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. Жизненный цикл системы базы данных определяет и жизненный цикл всей информационной системы организации, поскольку база данных является фундаментальным компонентом информационной системы.

ЖЦ БД включает в себя следующие основные этапы:

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

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

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

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

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

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

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

· разработка приложений;

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

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

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

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

2.4.1. Планирование разработки базы данных

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

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

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

2.4.3. Сбор и анализ требований пользователей

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

2.4.4. Проектирование базы данных

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

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

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

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

В создании БД как модели предметной области выделяют:

· объектную (предметную) систему, предъявляющую фрагмент реального мира;

· информационную систему, описывающую некоторую объектную систему;

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

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

2.4.5. Разработка приложений

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

2.4.6. Реализация

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

2.4.7. Загрузка данных

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

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

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

2.4.8. Тестирование

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

2.4.9. Эксплуатация и сопровождение

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

2.5. Модели представления данных

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

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

Существуют три основные МД и их комбинации, на которых основываются современные БД: реляционная модель данных (РМД), сетевая модель данных (СМД), иерархическая модель данных (ИМД).[3]

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

Используют взаимосвязи "один к одному", "один ко многим" и "многие ко многим". "Один к одному" - это взаимно однозначное соответствие, которое устанавливается между одним объектом и одним атрибутом. "Один ко многим" - это соответствие между одним объектом и многими атрибутами. "Многие ко многим" - это соответствие между многими объектами и многими атрибутами.

Рассмотрим эти модели данных более подробно.

2.5.1. Иерархическая модель данных

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

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

2.5.2. Сетевая модель данных

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