Файл: Разработка регламента выполнения процесса « Реализация билетов через розничные кассы».pdf
Добавлен: 04.04.2023
Просмотров: 153
Скачиваний: 2
СОДЕРЖАНИЕ
1.1. Выбор комплекса задач автоматизации
1.2. Характеристика существующих бизнес-процессов
1.3. Характеристика документооборота, возникающего при решении задачи
1.4. Обоснование проектных решений по информационному обеспечению
2.1. Информационная модель и её описание
2.2. Характеристика нормативно-справочной, входной и оперативной информации
В СУБД Paradox 7, как и в других инструментах разработки Borland (Visual dBase, Delphi и C++), используются система Borland Database Engine (BDE) и базовые программные средства промежуточного уровня производства самой компании. BDE с помощью SQL Links связывается с интерфейсом InterBase API и тем самым реализует в Paradox функциональность модели клиент-сервер.
Приложения, перемещенные в среду клиент-сервер, перенимают все преимущества и отличительные черты реляционных СУБД. InterBase поддерживает декларируемую целостность ссылок, внешние связи, хранимые процедуры, триггеры, крупные двоичные объекты, обновляемые окна просмотра и расширенный набор функций SQL. Приложения могут осуществлять одновременный доступ к нескольким устройствам; кроме этого, полностью поддерживаются возможности начала/принятия/отказа от транзакций. InterBase Server поддерживает протокол двухфазной фиксации транзакций (two-phase commit), в том числе и в случае одновременной работы с несколькими базами данных. Наличие специальных библиотек позволяет разрабатывать приложения-клиенты с использованием Embedded SQL и Dynamic SQL.
Недостатками Paradox являются: устаревший пользовательский интерфейс InterBase, который приводит к рассогласованию внешнего вида различных компонентов пакета; недостаточность документации по взаимодействию и преобразованиям между различными компонентами Paradox 7 и InterBase.
В сравнении с MS Access Paradox имеет значительно более слабую собственную среду программирования, проигрывает в мощности языка программирования и интегрированности с другими продуктами. Кроме того, в отличие от MS Access развитие среды Paradox практически прекращено.
Visual FoxPro – это среда, позволяющая разработчикам создавать приложения по обработке информации. Язык Visual FoxPro принадлежит к так называемой xBASE – группе, ведущей свою историю от первых версий dBASE. Помимо Visual FoxPro, в эту группу входят Clipper, FoxBase и некоторые другие продукты.
Основной задачей приложений по обработке информации является поддержка одной или нескольких таблиц с данными, хранящимися на жестком диске компьютера. В мире xBASE таблицы часто называют DBF – файлами, так как они по большей части имеют расширение DBF(DataBaseFile). Таблицы представляют собой один или несколько столбцов для хранения однотипной информации. Обычно столбцы называют полями.
Visual FoxPro использует активный словарь данных, то есть таблицы описаны и управляются из единого места – контейнера баз данных, или просто базы данных. Это таблица таблиц, содержащая не только информацию о таблицах, но и об индексах, отношениях между таблицами, представления и даже процедурах и функциях, перемещаемых вместе с базой данных.Visual FoxPro относится к реляционным СУБД, так как таблицы могут быть связаны между собой посредством индексов, выполняющих функции синхронизации положения указателя записей. Важным инструментом использования таблиц Visual FoxPro является индекс – файл с расширением CDX, имя которого совпадает с именем таблицы. Каждому ключевому выражению присваивается имя, по которому его можно активизировать, чтобы заставить Visual FoxPro рассматривать записи в определённом порядке. Visual FoxPro использует интерпретатор языка. Программы, написанные на большинстве языков программирования, требует компиляции или преобразования в машинный код, прежде чем их можно будет запускать на исполнение. В отличие от этого, Visual FoxPro позволяет исполнять отдельные команды, набираемые в командном окне, и анализировать результаты их выполнения.
Возможность обработки формы или объекта во время исполнения программы вместо новой генерации и компиляции приводит к огромной разнице программирования на предыдущих версиях FoxPro и Visual FoxPro. Форма может быть модифицирована непосредственно во время работы Вашего приложения посредством обращения к её свойствам.
Недостатки: отдельные файлы таблиц довольно часто могут терять индексы, физически портиться, кроме того, при изменении каскада таблиц нельзя прерывать это изменение иначе может нарушиться ссылочность данных; программисту приходится изучать еще и язык СУБД, помимо встроенного языка; при переносе программ необходимо на клиентской машине установить сам Visual FoxPro, чтобы он мог прописать свои библиотеки и драйвера для работы с dbf-файлами; хотя FoxPro взаимодействует с другими продуктами Microsoft, подчас реализация этого взаимодействия запаздывает.
В результате сравнительного анализа СУБД было выявлено, что оптимальным будет выбор сделанный в пользу Microsoft Access, поскольку он обладает рядом преимуществ по сравнению с другими СУБД, а именно: удобство использования и одновременно мощность продукта — в сочетании с возможностью построения комплексных решений на базе современных технологий; совместим с большинством приложений работающих из под Windows; не требует установки драйверов доступа к данным в этом формате, так как они поставляются с операционными системами Windows.
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Информационная модель и её описание
Информационная модель задачи автоматизации учета продаж билетов показана на рис.2.
Разрабатываемая автоматизированная система работает со справочниками мест, операций, клиентов. На каждый справочник предусмотрена экранная форма для заполнения и корректировки. На основании справочных данных формируются данные отчетов.
На основании данных, хранящихся в справочниках и журналах, формируется отчетная информация.
Рис.6. Информационная модель задачи
2.2. Характеристика нормативно-справочной, входной и оперативной информации
Для получения отчета по доходам за определенный период времени необходимо обеспечить вывод этой информации на печатающее устройство.
Для получения посадочной ведомости необходимо обеспечить диалог с пользователем для вывода посадочной ведомости для определенного рейса. Номер рейса вводиться с клавиатуры в ответ на сообщение-запрос на экране в процессе решения задачи.
Для получения ответа на запрос пользователя о ближайшем рейсе по заданному маршруту необходимо обеспечить диалог с пользователем для ввода времени ввода запроса и маршрута. Такая входная информация вводится с клавиатуры в ответ на сообщение-запрос на экране в процессе решения задачи.
Для добавления записей в базу данных нужно обеспечить диалог с пользователем (кассиром), в котором он будет вводить все данные о клиенте, удалять и изменять их. Такая входная информация вводится с клавиатуры в ответ на сообщение-запрос на экране в процессе решения задачи
2.3. Характеристика результатной информации
Выходной информацией для пользователя являются следующие документы:
- Посадочная ведомость;
- Отчет за период с группировкой по маршрутам.
Посадочная ведомость и отчет за период с группировкой по маршрутам должны выводиться на экран и печать, остальные только на экран в виде результата на запрос пользователя. Формы выходных документов приведены в формах 1 и 2.
Форма 1. Форма выходного документа задачи с результатом составления посадочной ведомости
Номер рейса
Бортовой номер
Марка самолета
Вид самолета
ФИО клиента
Номер билета
Полный номер паспорта
Место прописки клиента
Вес багажа
Форма 2. Форма выходного документа задачи с результатом вывода отчета по доходам аэрофлота за определенный период с группировкой по маршрутам.
Название рейса
Количество проданных билетов
Выручка по рейсам
2.4. Общие положения (дерево функций и сценарий диалога)
Главные функции можно разделить на три класса:
- функции, связанные с составлением первичных документов;
- функции, предназначенные для обработки и получения отчетов;
- функции по ведению справочников.
Выявление состава функций, их иерархии и выбор языка общения (язык типа «меню») позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность.
Дерево функций программного обеспечения можно представить в виде схемы (рис. 3).
Рис.3. Функции системы
При разработке структуры диалога была предусмотрена возможность работы с входными документами, формирования выходных документов, корректировки вводимых данных, просмотра введенной информации, ведение файлов нормативно-справочной информации.
Основные функции разрабатываемой информационной системы включают в себя работу со справочниками, операциями ввода документов, работу с журналами, откуда реализован режим выборок. Сценарий диалога в информационной системе учета продаж представлен на рис.4.
Рис.4. Сценарий диалога программы
2.5. Характеристика базы данных
С учетом построенной инфологической модели и зная ограничения, налагаемые на хранимые данные используемой системой управления базами данных, строится датологическая модель базы данных.
Датологическая модель строится в терминах базы данных. Так как в нашем случае используется СУБД ACCESS, то мы строим реляционную модель базы данных в реализации MS ACCESS.
Она позволяет организовывать описание объектов в виде таблиц. При этом можно задавать ограничения на типы хранимых данных в столбце, первичные ключи для задания связи нескольких таблиц. Наконец можно задавать ограничения целостности с помощью триггеров и процедур.
Кроме того таблицы поддерживают ограничения на непустое значение поля и уникальное поле. Возможно так же задание индексации полей для последующего ускорения поиска данных в таблицах.
Построенная датологическая модель БД, с учетом особенностей MS ACCESS, выглядит следующим образом:
Таблица 2
Таблица «Карточка клиента»
Имя поля |
Тип данных |
Описание |
№ паспорта |
текстовый |
Идентификатор |
Фамилия |
Текстовый |
Фамилия пассажира |
Имя |
Текстовый |
Имя пассажира |
Отчество |
текстовый |
Отчество пассажира |
Дата рожденья |
Дата/время |
Дата рожденья |
Контактный телефон |
текстовый |
Контактный телефон клиента |
Таблица 3
Таблица «Места»
Имя поля |
Тип данных |
Описание |
самолет |
числовой |
Номер рейса |
Кол. Мест 1-го кл. |
числовой |
|
Стоимость мест 1кл |
денежный |
Стоимость билета на места 1 класса |
Кол-во мест 2-го кл |
числовой |
|
Стоимость мест 2-го кл |
денежный |
Стоимость билета на места 2 класса |
Кол-во мест 3кл |
числовой |
|
Стоимость мест 3кл. |
денежный |
Стоимость билета на места 3 класса |
Таблица 4
Таблица «Операции»
Имя поля |
Тип данных |
Описание |
самолет |
числовой |
Номер рейса |
Клиент |
текстовый |
|
класс |
текстовый |
|
операция |
текстовый |
|
Номер кассы |
Числовой |
|
К возврату |
денежный |
Таблица 5
Таблица «Расписание»
Имя поля |
Тип данных |
Описание |
№ п/п |
Счетчик |
|
самолет |
Счетчик |
|
Аэропорт отправления |
Дата\время |
|
Время отправления |
Текстовый |
|
Аэропорт прибытия |
Числовой |
|
Время прибытия |
Числовой |
Таблица 6
Таблица «Отправления»
Имя поля |
Тип данных |
Описание |
№ п/п |
числовой |
|
Самолет |
числовой |
|
Дата |
Дата /время |
Связь между таблицами выглядит следующим образом:
Рис.5. Связь между таблицами
2.6. Структурная схема пакета (дерево вызова программных модулей)
Система состоит из модулей, обеспечивающих работу системы, а именно:
- Модуль «авторизация»
- Модуль «Меню»
- Модуль «Справочники»
- Модуль «Ввод данных
- Модуль «Печать»
- Модуль «Настройки»
Структурная схема пакета представлена на рисунке 6.