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

ОАНО «Волжский университет им. В.Н. Татищева»

Факультет «Информатика и телекоммуникации»

Кафедра «Информатика и системы управления»

КУРСОВАЯ РАБОТА

по дисциплине «Технологии программирования»

на тему: «Разработка автоматизированной системы для организации услуг туристического агентства»

Выполнил: студент Иванов С.В.

Проверил: ст. преподаватель Маркова Т.И.

Тольятти 2010

Цель курсовой работы - осуществить моделирование информационной системы на ранней стадии — фазе формирования концепции, включая формирование идей, постановку целей, изучение мотиваций и требований заказчика, анализ исходных данных, определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов. Для моделирования бизнес-процессов заданной предметной области применить CASE-средство Visual UML или Rational Rose.

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

Методы решения: моделирование стандартами UML.

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

моделирование программирование информационный материальный

1 Анализ работы туристического агентства

1.1 Характеристика существующей организации обработки информации аналогичных задач

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

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

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

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

— увеличивается скорость обработки данных;

— повышается надежность хранения информации;

— удобное представление;

— быстрый доступ;

— появляется больше возможностей по обработке данных.

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

1.2 Информационные данные, обеспечивающие вариантность решения задачи

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

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

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

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

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

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

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

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

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

2 Назначение разработки

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

3 Требования к программе или к программному изделию

3.1 Требования к функциональным характеристикам

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

- Регистрация видов туристических отдыхов;

— выбор клиентом тура;

— поиск тура в базе данных;

— проверка наличия тура;

— регистрация клиентов;

— подписание контракта на тур;

— прием платежей;

— входные данные: заказ, выходные — выполнение заказа.

3.2 Требования к надежности

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

- отсутствие ошибок;

— устойчивость к возможным ошибкам;

— резервное копирование информации на сменные носители;

— перезапускаемость при сбое;

— автосохранение вводимой информации;

— контроль входной и выходной информации;

— время восстановления после отказа составляет 5 минут с откатом к последнему сохранению данных.

3.3 Условия эксплуатации

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

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

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

— чистка оборудования;

— температура воздуха в помещении +20 …+25°С

— проветривание помещения;

— уборка помещения.

3.4 Требования к составу и параметрам технических средств

Рекомендуемые системные требования:

- Процессор Intel PentiumIV с частотой 2700 МГц;

— материнская плата Gigabyte GF 9800;

— оперативная память DIMM 256 Mb SDRAM PC-133;

— видеокарта 4 Mb AGP Riva TNT2 M64;

— жесткий диск 80 Gb HDS728080PLAT20;

— монитор;

— клавиатура;

— мышь;

— Принтер;

— сетевой адаптер.

3.5 Требования к информационной и программной совместимости

Операционная система Windows 2000/ME/XP/VISTA, программное обеспечение, выполняющее функции вычисления налогов, складского учета, создания баз данных и т. п.

Среда разработки программного приложения Delphi 7.0;

4 Требования к программной документации

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

- пояснительная записка;

— руководство пользователя;

— инструкция.

5 Технико-экономические показатели

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

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

— установление требований — 2 дня;

— спецификация требований — неделя;

— проектирование архитектуры — неделя;

— детализированное проектирование — 2 недели;

— реализация — 2 недели;

— интеграция — 2 дня;

— сопровождение — 1 месяцев.

7 Порядок контроля и приемки

Испытания на надежность будут полигонные, зависимые:

- экспериментальные;

— контрольные;

— в нормальных условиях;

— в критических условиях;

— модулей и компонент.

3 . Разработка модели использования. Диаграмма вариантов использования (диаграмма прецедентов)

Субъект (actor) — это некто или нечто (человек, машина и т. д.) взаимодействующее с системой. Субъект взаимодействует с прецедентом, ожидая получить некий полезный результат.

Типичным графическим изображением субъекта является «штриховой человечек». В общем случае субъект может быть показан в виде прямоугольного символа класса. Подобно обычному классу субъект может обладать атрибутами и операциями (связанными с событиями, сообщения о которых он отправляет и получает). На рисунке 1 показаны три субъекта: Klient (Клиент), TO (Туроператор) и Мanager (Менеджер).

Рисунок 1 — Субъекты системы «Туристическое агентство»

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

Рисунок 2 — Прецеденты системы «Турагентство»

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

Рисунок 3 — Диаграмма прецедентов для системы «Автосервис»

В таблице 1 представлены актеры и соответствующие им прецеденты.

Таблица 1 — Оборот актеров и прецедентов

В таблице 2 представлено описание этих прецедентов, в таблице 3 — описательная спецификация прецедента Registracia_na_obslugivanie (регистрация на обслуживание).

Таблица 2 — Распределение требований по субъектам и прецедентам

Таблица 3 — Описательная спецификация прецедента Registracia_na_obslugivanie (регистрация на обслуживание)

4. Построение концептуальной модели предметной области (диаграмма классов)

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

Класс (class) — это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.

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

Диаграмма классов для системы «Турагентство» представлена на рисунке 4.

Рисунок 4. Диаграмма классов для системы «Автосервис»

Таблица 4 — Описание классов для системы «Автосервис »

Таблица 5 — Описание отношений между классами в системе «Автосервис»

5. Описание поведения системы

5.1 Диаграммы последовательностей системы (системные события и операции)

Диаграмма последовательности действий (sequence diagrams) отображает взаимодействие объектов, упорядоченное по времени. На ней показаны объекты и классы, используемые в сценарии, и последовательность сообщений, которыми обмениваются объекты, для выполнения сценария. Диаграммы последовательности действий обычно соответствуют реализациям прецедентов в логическом представлении системы.

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

Рисунок 5 — Диаграмма последовательности для прецедента «Прием заказа»

5.2 Диаграммы кооперации

Диаграмма взаимодействий (кооперации, collaboration diagram) — это альтернативный способ отображения сценариев. Такой тип диаграммы показывает взаимодействие объектов, организованное вокруг них, и их связи друг с другом.

На рисунке 6 приведена диаграмма кооперации, описывающая процесс оформления заказа.

Рисунок 6 — Диаграмма кооперации для прецедента «Прием заказа»

5.3 Диаграмма видов деятельности

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

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

Диаграмма видов деятельности для прецедента «Прием заказа» представлена на рисунке 7.

Рисунок 7 — Диаграмма видов деятельности для прецедента «Прием заказа».

Таблица 6 — Установление действий в основном и альтернативном потоках

6. Обоснование проектных решений по программному решению задачи

6.1 Компоновка программных компонентов (Диаграмма компонентов)

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

Рисунок 8. Нотация языка UML для компонента

Рисунок 9. Диаграмма компонентов для системы «Автосервис»

6.2 Обоснование выбора средств моделирования и языка программирования

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

UML был разработан компанией Rational Software Corporation. В1997 году OMG утвердила UML стандартным языком моделирования. UML поддерживает объектно-ориентированный подход к созданию ПО. Конструкцию языка позволяет моделировать статику (структуру) и динамику (поведение) системы. Система представляется в виде взаимодействующих объектов (программных модулей), которые реагируют на внешние события.

Все модели делятся на 3 группы:

— Модель состояний (state model), которая представляет статический взгляд на систему — это модель требований к данным. Модель состояния представляет структуры данных и отношения на них. Основной метод визуализации модели состоянии состоит в использовании диаграммы классов.

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

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

Для создания программы используются средства Delphi, использующего объектно-ориентированный подход (ООП).

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

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

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

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

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

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

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

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

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

Программирование в Delphi является:

— Объектно-ориентированным (осуществляется над объектами и с помощью объектов).

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

7. Разработка интерфейса пользователя

7.1 Общая схема интерфейса пользователя. Стандарт интерфейса пользователя проекта

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

Рисунок 10 — Вид главного окна приложения

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

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

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

— кнопка «Добавить» на вкладке «Заказчики» позволяет вносить информацию о заказчиках в базу посредством открывающейся формы (рисунок 11);

Рисунок 11 — Форма «Заказчики»

- кнопка «Изменить» позволяет модифицировать выбранные данные, так же посредством открывающейся формы;

— кнопка «Удалить» позволяет удалять данные из базы;

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

— кнопка «Поиск заказчика по реквизитам» позволяет делать то же самое, только поиск ведется по реквизитам заказчика;

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

— кнопка «Добавить» на вкладке «Заказы» позволяет вносить информацию о заказах в базу посредством открывающейся формы, представленной на рисунке 12;

Рисунок 12 — Форма «Заказы»

Поиск заказов на вкладке «Заказы» ведется по деталям, по имени заказчика и по дате заказа, посредством выбора необходимых данных из выпадающих списков и нажатия соответствующих кнопок.

Вкладка «Склад» имеет те же кнопки, что и предыдущие вкладки. Они так же позволяют добавлять (кнопка «Добавить»), изменять (кнопка «Изменить») данные посредством открывающейся формы (рисунок 13), а так же удалять их (кнопка «Удалить»), а так же искать по выбранной информации.

Рисунок 13 — Форма «Склад»

На вкладке «Типы деталей» можно вносить добавлять и удалять детали. Добавление так же происходит посредством открывающейся формы «Типы деталей», представленной на рисунке 14.

Рисунок 14 — Форма «Типы деталей»

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

Рисунок 15 — Форма «Поставки»

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

Рисунок 16 — Форма «Поставщики»

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

8. Тестирование разработанного программного продукта

Тестирование по методу «черного ящика» применимо к исполняемым программным продуктам, а не к документам или модели. Другое название метода: функциональное тестирование, тестирование по входу/выходу.

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

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

На рисунке 13 показана диаграмма тестирования по методу «черного ящика»: 0 — нет, 1 — да Рисунок 13 — Тестирование по методу «черного ящика»

9. Результаты исследований

9.1 Анализ экономической эффективности. Оценка качества и надёжности

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

9.2 Характеристика разработанного ПП

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

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

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

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

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

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

— эффективным, так как не потребляет большого количества системных ресурсов;

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

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

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

1 Норенков И. П. Основы автоматизированного проектирования: Учеб. Для вузов. — М.: Изд-во МГТУ им. Н. Э. Баумана, 2000. — 360 с. ил. (сер. Информатика в техническом университете)

2 Липаев В. В., Филинов Е. Н. Мобильность программ и данных в открытых информационных системах. М.: Научная книга, 1997.

3 Системы автоматизированного проектирования: Учеб. Пособие для вузов / Под ред. И. П. Норенкова. М.: Высш. Шк., 1986.

4 Мацяшек, Лешек А. анализ требований и проектирование систем. Разработка информационных систем с ипользованием UML.: Пер. с англ. — М.: Издательский дом «Вильямс», 2002. 432 с.- Парал. тит. англ.

5 Вендор А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. — М.: Финансы и статистика, 2000. — 352 с.: ил.