Проектирование и разработка ИС для заказа билетов на самолет

Министерство образования и науки РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Ярославский государственный технический университет»

Кафедра «Информационные системы и технологии»

Проектирование и разработка ИС для заказа билетов на самолет Расчетно-пояснительная записка к курсовому проекту по дисциплине «Проектирование информационных систем»

Содержание Введение Техническое задание

1. Общие сведения

2. Основания для разработки

3. Назначение и цели создания системы

4. Требования к системе

5. Характеристика объектов автоматизации

6. Требования к документированию

7. Стадии и этапы разработки

8. Порядок контроля и приемки системы

Технический проект

1. Функциональная структура

1.1 Описание предметной области

1.2 Функции и организационная структура

1.3 Описание потоков данных и бизнес процессов

2. Системное проектирование ИС

2.1 Разработка концепции, архитектуры построения и платформы реализации ИС

2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем

3. Информационное обеспечение ИС

3.1 Описание логической структуры информационной базы

3.2 Описание физической реализации БД

Заключение

Список литературы информационный заказ билет Введение

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

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

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

ТЗ состоит из трех стадий:

обоснование необходимости разработки информационной системы — постановка задачи, сбор исходных материалов, выбор и обоснование критериев эффективности и качества разработанной системы, обоснование необходимости проведения НИР;

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

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

ТЗ выполняет следующие функции:

Организационная функция — зафиксированное задание для Исполнителя и окончательные требования со стороны Заказчика.

Информационная функция — порядок в процессе Исполнителя и продуманность желаний со стороны Заказчика.

Коммуникационная функция — взаимная договоренность о «предмете проекта», исключающая претензий.

Юридическая функция — ТЗ имеет равную юридическую силу с «Договором».

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

Техническое задание

1. Общие сведения Полное наименование системы и ее условное обозначение

«Автоматизированная информационная система авиакомпании, торгующей билетами на самолет», АИС «Авиакомпания».

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

Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы АИС «Авиакомпания» поставляется в виде исполняемых модулей по завершению всего объема работ, технические средства приобретаются Заказчиком самостоятельно. Оформление результатов работ по созданию системы производится путем подписания акта о принятии системы Заказчиком при отсутствии претензий к Разработчику. Акт составляется в двух экземплярах. Один экземпляр находится у Заказчика, другой — у Разработчика.

2. Основания для разработки Основания для проведения разработки Основанием для разработки технического задания является задание к курсовой работе по курсу «Проектирование информационных систем».

Наименование и условное обозначение темы разработки Наименование темы разработки — «Проектирование и разработка ИС для заказа билетов на самолет»

Условное обозначение темы разработки (шифр темы) — «ИС ЗБС»

3. Назначение и цели создания системы Функциональное назначение системы

АИС «Авиакомпания» предназначена для автоматизации работы предприятия, продающего билеты на самолет.

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

Цели создания системы Система снижает экономические затраты на время за счет заказа билетов на дому.

4. Требования к системе Требования к системе в целом Требования к структуре и функционированию системы Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы АИС «Авиакомпания» включает следующие подсистемы:

— Принятие заказа;

— Хранения данных;

— Формирования отчетности.

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

Подсистема «Подсистема хранения данных» обеспечивает хранение всех данных о пассажирах и информации заказанных билетов. Кроме того содержаться данные о всех ранее заказанных билетах этого клиента.

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

Требования к способам и средствам связи для информационного обмена между компонентами системы:

Информационный обмен осуществляется посредством локальной сети.

Требования к режимам функционирования системы:

Для АИС «Авиакомпания» определен следующий режим функционирования:

— Нормальный режим функционирования;

В нормальном режиме функционирования системы:

— клиентское программное обеспечение и технические средства пользователей и администратора системы обеспечивают возможность функционирования в течение рабочего дня (с 09:00 до 18:00) семь дней в неделю;

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

— исправно работает оборудование, составляющее комплекс технических средств;

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

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

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

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

Требования к численности и квалификации персонала системы Требования к численности персонала (пользователей) АС В системе будут работать 4 сотрудника: 2 сотрудник отвечает за прием и закрытие заявок и заказов, 2 занимается расчетами с заказчиками.

Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков:

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

Показатели назначения Для АСУ указывают:

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

— допустимые пределы модернизации и развития системы;

— вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

АИС «Авиакомпания» должны обеспечивать возможность исторического хранения данных с глубиной не менее 10 лет.

Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительное время.

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

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

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

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

Требования к безопасности

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

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.

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

Требования к защите информации от несанкционированного доступа:

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

а) идентификацию и аутентификацию пользователя;

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

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

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

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

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

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

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

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

— Принятие заказа;

— Хранения данных;

— Формирования отчетности.

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

Подсистема «Подсистема хранения данных» обеспечивает хранение всех данных о пассажирах и информации заказанных билетов. Кроме того содержаться данные о всех ранее заказанных билетах этого клиента.

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

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

К структуре процесса сбора, обработки, передачи данных в системе и представлению данных.

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

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

К контролю, хранению, обновлению и восстановлению данных Система должна поддерживать автоматическое ежедневное резервное копирование.

Требования к программному обеспечению системы Система должна работать в операционных системах Windows XP/Vista/7/8

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

В комплекс технических средств должны входить следующие элементы:

— рабочие станции;

— источник бесперебойного питания;

— среда передачи данных между рабочими станциями (например, витая пара UTP 5e);

— принтер.

Технические средства приобретаются Заказчиком самостоятельно.

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

Процессор Intel Pentium IV 2 ГГц и выше, оперативная память не менее 2Гб, объем жесткого диска не менее 500 Гбайт.

Требования к организационному обеспечению системы.

Для организационного обеспечения приводят требования:

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

Функционирование системы обеспечивает инженер-системотехник, в эксплуатации участвуют 4 сотрудника.

К организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации.

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

К защите от ошибочных действий персонала системы.

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

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

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

6. Требования к документированию Для системы на различных стадиях создания должны быть выпущены следующие документы:

Схема организационной структуры;

Схема функциональной структуры;

Перечень входных сигналов и данных;

Перечень выходных сигналов (документов);

Пояснительная записка к техническому проекту;

Описание автоматизируемых функций;

Описание постановки задач (комплекса задач);

Описание организации информационной базы;

Описание массива информации;

Описание программного обеспечения;

Руководство пользователя.

7. Стадии и этапы разработки Стадии разработки Разработка должна быть проведена в 6 стадий:

1. Разработка технического задания

2. Разработка проектной документации

3.Создание эскизного проекта

4. Рабочее проектирование

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

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

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1) разработка информационной системы;

2) разработка документации.

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

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

Содержание работ по этапам На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1) постановка задачи;

2) определение и уточнение требований к техническим средствам;

3) определение требований к информационной системе;

4) определение стадий, этапов и сроков разработки информационной системы и документации на неё;

5) обоснование и выбор инструментария;

6) согласование и утверждение технического задания.

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

1) определение основных бизнес-процессов (в виде диаграмм IDEF0);

2) определение основных вариантов использования Системы для трех категорий пользователей (Гость, Авторизованный пользователь, Администратор) в виде UML диаграмм вариантов использования;

3) проектирование структуры базы данных в виде (ER диаграммы);

4) проектирование основных компонентов и алгоритмов Системы в виде соответствующих UML диаграмм;

5) проектирование структуры пользовательского интерфейса;

6) согласование и утверждение проектной документации.

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

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

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

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

События:

Таблица 1 — Исходные данные для расчета

Рисунок 1 — Постановка задач Рисунок 2 — Диаграмма Ганта Рисунок 3 — Сетевой график выполнения работ Критический путь сетевого графика будет следующим:

0 1 2 3 4 5 910 111 213

Таблица 2 — Временные параметры событий

Таблица 3 — Расчет полного и свободного резервов времени

8. Порядок контроля и приемки системы Виды, состав, объем и методы испытаний системы и ее составных частей

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

Общие требования к приемке работ по стадиям

Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии.

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

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

Технический проект

1. Функциональная структура

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

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

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

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

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

1.2 Функции и организационная структура Построение структуры предприятия можно разбить на три шага: построение организационной модели, построение функциональной модели и построение информационной модели.

Фирма «Авиакомпания» состоит из следующих отделов:

директор;

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

Кассовый отдел;

отдел доставки.

Организационная структура предприятия отражена на рисунке 4.

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

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

Кассовый отдел осуществляет продажу билетов.

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

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

Проанализировав деятельность авиакомпани, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС «Авиакомпания»:

Продажи и маркетинг.

Оформление билетов.

Отправка билета клиенту.

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

контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);

диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);

диаграммы дерева узлов;

диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (т.е., получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.

Главная бизнес-функция АИС «Авиакомпания» — Деятельность авиакомпании. Входными данными является клиенты. Выходными — проданные билеты и маркетинговые материалы. В качестве управления выступают правила и процедуры. Инструментами выполнения главной бизнес-функции служит бухгалтерская система. IDEF0 для главной бизнес-функции представлена на рисунке 5.

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

Функциональный блок «Продажи и маркетинг» включает отдел продажу билетов, а он в свою очередь выделяет такие аспекты как дата, рейс и наличие билетов. Диаграмма IDEF3 представлена на рисунке 7.

Рисунок 5 — Контекстная диаграмма Рисунок 6 — Диаграмма декомпозиции контекстной диаграммы Рисунок 7 — Диаграмма IDEF3

2 Системное проектирование ИС

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

В настоящее время наиболее распространенными архитектурами являются:

файл-сервер;

клиент-сервер;

многоуровневая архитектура.

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

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

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

масштабируемость;

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

высокая безопасность;

высокая надёжность;

низкие требования к скорости канала (сети) между терминалами и сервером приложений;

низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

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

сложность разработки систем на основе многоуровневой архитектуры, т. к очень сложно «состыковать» различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;

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

высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений;

высокая сложность администрирования.

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

2.2 Техническое обеспечение ИС В комплекс технических средств должны входить следующие элементы:

рабочие станции;

источники бесперебойного питания;

средства для построения ЛВС;

сервер БД;

принтер.

Требования к серверу:

память 8 Гб;

процессор 2.2 ГГц Intel Xeon 5500 минимум;

скорость диска SATA 8 Гбит/с;

сетевой адаптер 10 Гбит/с;

операционная система Windows Server 2008.

Требования к рабочей станции:

процессор 2 Ггц;

память 2 Гб;

жесткий диск не менее 500;

операционная система Windows 7;

сетевой адаптер 100 Мбит/с.

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

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

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

защиту данных от несанкционированного доступа;

сервера и рабочие места должны быть объединены локальной сетью.

3. Информационное обеспечение ИС

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

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

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

исключение некоторых типов избыточности;

устранение некоторых аномалий обновления;

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

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

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

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

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

Рисунок 16 — Логическая структура информационной базы

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

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

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

В конструкторе были созданы следующие таблицы: Рейсы, Маршрут, Билеты, Самолеты, Пилоты и Пассажиры. Физическая модель АИС «Авиакомпания» представлена на рисунке 9.

Описание созданных таблиц базы данных приведены в таблицах 4−9.

Рисунок 9 — Физическая модель Таблица 4 — Описание полей таблицы Рейсы

Таблица 5 — Описание полей таблицы Маршрут

Таблица 6 — Описание полей таблицы Билеты

Таблица 7 — Описание полей таблицы Самолеты

Таблица 8 — Описание полей таблицы Пилоты

Таблица 9 — Описание полей таблицы Пассажиры

Заключение

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

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

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

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

разработана функциональная схема АИС «Авиакомпания»;

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

спроектирована логическая модель системы АИС «Авиакомпания» на основе концептуальной модели;

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

1. ГОСТ 19.201−78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

2. ГОСТ 34.602−89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

3. РД 50−34.698−90 Автоматизированные системы. Требования к содержанию документов

4. В. П. Романов, Н. З. Емельянова, Т. Л. Партыка Проектирование экономических информационных систем. Методологии и современные технологии. — М: Экзамен, 2005. 256 с.;

5. Маклаков С. В. BPWin и ERWin CASE — средства разработки информационных систем / Маклаков С. В. — М: ДИАЛОГ МИФИ, 2001.-256с.;

6. Бойко В. В. Проектирование баз данных информационных систем / Бойко В. В., Савинков В. М. — 2-е изд. — М.: Финансы и статистика, 1989. — 350 с.