Файл: Автоматизация продажи авиабилетов "JP Airlines".pdf

Рис.2.4. Декомпозиция родительской функции

Следующим аспектом функциональной модели является отображение потоков данных с помощью диаграмм DFD (Data Flow Diagramming). Эти диаграммы в функциональной модели могут дополнять то, что уже показано в IDEF0 диаграммах. Они описывают потоки данных между отдельными работами системы. Под потоками данных в данном случае понимается как материальные так и информационные потоки. Материальные потоки - это, например, сырье, материалы, заготовки, продукты производства, оборудование, транспортные средства и др. Информационные потоки - это информация о заказ, данные о состоянии рынка, о наличии сырья, запасных частей, запасы на складах, выполненные работы, узкие места в производстве,

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

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

Основные элементы диаграммы потоков данных DFD такие:

• работы (функции обработки информации);
• потоки данных (дуги входных и выходных величин)
• хранилища данных;
• внешние сущности.

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

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

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

---

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

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

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

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

Внешние сущности изображают объекты, являющиеся источниками входных и выходных величин системы. Их изображают прямоугольником с тенью, подчеркивает нахождения объекта будто вне плоскости диаграммы. Внешние сущности в диаграмме соединяют дугами подобно тому как и другие объекты (Работы и хранилища), они могут также соединяться дугами между собой. Обозначают внешние сущности буквой Е (External Reference).

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

Рис. 2.5. Родительская диаграмма DFD

Иллюстрация родительского процесса Оформление бронирования и продажи авиабилетов представлена на рис.2.5.

---

Рис.2.6. Детализация родительского процесса

Иллюстрация детализации родительского процесса на три подпроцесса (подсистемы) представлена на рис.2.6.

Описание всех объектов модели на втором уровне представлены в таблице 2.2.

Таблица 2.2 - Описание объектов подсистем предметной области модели DFD

Элемент нотации	Имя объекта	Краткое описание объекта
Поток данных	Заявка клиента	Даннные клиента и заявка на бронирование и продажу билета
Внешняя сущность	Клиент	Оставляет заявку на бронирование авиабилета
	Менеджер	Осуществляет оформление заявки клиента
Хранилище данных	Реестр заявок	Содержит информацию о заявках клиентов
	Реестр клиентов	Содержит информацию о клиентах авиакомпании
	Реестр рейсов	Содержит информацию о рейсах авиакомпании
	Реестр билетов	Содержит информацию о проданных билетах

Детализация 3-4 уровней модели DFD представлены на рисунках 2.7-2.8.

Рис.2.7. Декомпозиция подпроцесса А1

Рис.2.8. Декомпозиция подпроцесса А12

3.Разработка структуры ИС

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

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

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

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

---

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

3.1. Требования, свойства, ограничения ИС.

Информационная система, должна соответствовать следующим очевидным требованиям: информационная среда должна быть надежной, гибкой, легко модифицируемой, расширяемой, простой в управлении и сопровождении.[3 с.55].

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

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

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

Производительность – возможность максимальной обработки информации в единицу времени.

Оперативность – возможность работы в режиме “on-line” для осуществления мобильного доступа к информационным ресурсам и достоверного отражения текущего состояния организации.

Защита данных – способность восстановления данных при физическом разрушении аппаратуры баз данных.

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

Безопасность включает в себя несколько аспектов:

- защита данных от потерь. Реализуется на организационном, аппаратном и системном уровнях.

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

- предотвращение несанкционированного доступа. Решается комплексно организационными мероприятиями, операционной системой и прикладными системами, т.е. среда должна иметь развитые средства администрирования [5 с.93].

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

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

---

Кроме этого, подразумевает возможность не только трансформации данных, но и подключение компьютеров, узоров и внешних ИС (информационных систем). [6 с.87].

3.2 Основные модули ИС

Физическая модель разработанного приложения в виде диаграммы компонентов, представленная на рисунке 3.1. Она показывает разбиение программной системы на структурные единицы и зависимости между представленными компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п. Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом, иллюстрируются отношения клиент-источник между двумя компонентами. Зависимость показывает, что один компонент предоставляет сервис, необходимый другому компоненту [13].

Рис.3.1. Диаграмма компонентов

Диаграмма развертывания системы представлена на рисунке 3.2.

Рис.3.2. Диаграмма развертывания

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

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

Рис.3.3 Диаграмма классов

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

Таблица 3.1 – Описание разрабатываемых классов

Имя класса	Функциональное назначение
AdminForm	Класс реализует главную форму администратора системы
UsersForm	Класс реализует форму пользователя системы
AuthorizationForm	Класс реализует форму авторизации в системе
ChangePasswordForm	Класс реализует форму для смены пароля
ClientTableForm	Класс реализует форму для отображения приобретенных пользователем билетов
ChangeColorStyle	Класс реализует форму для изменения цветовой гаммы системы
PaymentForm	Класс реализует форму для бронирования билета
FlightSearchForm	Класс реализует форму для поиска информации о билетах
RegistrationForm	Класс реализует форму для регистрации нового пользователя

---