Дипломная работа: Автоматизация приема регистрируемых почтовых отправлений УФПС "Татарстан Почтасы"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
69
определить где, когда и кем выполняется каждая функция, какие данные,
информационные или функциональные взаимосвязи для этого нужны и откуда эти
данные поступают. Цель этапа информационного моделирования состоит в том,
чтобы идентифицировать концептуальные сущности, или объекты, которые
составляют подсистему для анализа. Объекты информационной модели
представляются через их имена и имена их атрибутов. Здесь устанавливаются связи
между информационными объектами и функциональные зависимости. Кроме
структурной направленности информационное моделирование связанно с
особенностями реализации связей в различных компьютерных технологиях, в
зависимости от количества связываемых предметов.
Для успешной реализации проекта объект проектирования должен быть
прежде всего адекватно описан, должны быть построены полные и
непротиворечивые функциональные и информационные модели ИС. Накопленный
к настоящему времени опыт проектирования ИС показывает, что это логически
сложная, трудоемкая и длительная по времени работа, требующая высокой
квалификации участвующих в ней специалистов.
Однако до недавнего времени проектирование ИС выполнялось в основном
на интуитивном уровне с применением неформализованных методов, основанных
на искусстве, практическом опыте, экспертных оценках и дорогостоящих
экспериментальных проверках качества функционирования ИС. Кроме того, в
процессе создания и функционирования ИС информационные потребности
пользователей могут изменяться или уточняться, что еще более усложняет
разработку и сопровождение таких систем. Информационная модель комплекса
задач служит для отображения взаимосвязи входных, промежуточных, а также
результатных информационных потоков, функций предметной области и файлов с
условно-постоянной информацией.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
При решении поставленных задач используется ряд входных документов:
1) Данные о контейнерах.
70
2) Данные о посылках.
3) Данные об отделениях.
4) Данные о сотрудниках отделений.
5) Данные о населенных пунктах.
6) Данные о районах.
7) Данные о регионах.
2.2.3. Характеристика результатной информации
В данном разделе описан документ, получаемый в результате выполнения
всех запросов данной задачи и произошедших событий. Результативным
документом (в электронной форме) является документ о принятой посылке.
Выходной документ «Посылка» содержит следующие данные:
- Штрих-код посылки (13 цифр);
- ФИО (для физлица) или название (для юрлица) отправителя;
- Индекс отправителя;
- Адрес отправителя;
- Населенный пункт отправителя;
- ФИО (для физлица) или название (для юрлица) получателя;
- Индекс получателя;
- Адрес получателя;
- Населенный пункт получателя.
В процессе описания структуры записи файлов для описания типа полей
записи используются сокращенные обозначения, приведенные в таблице 13.
Таблица 13 - Перечень обозначений типов полей записи базы данных
Наименование типа поля записи
Полное название
Краткое обозначение
Символьный тип
nChar, VarChar
С
Числовой тип
Int, TinyInt, BigInt,
SmallInt
I
Логический тип
Boolean
B
71
Данный выходной документ формируется всякий раз когда принимается
посылка. Документ в электронном виде доставляется до получателя (разработчика)
при помощи, разрабатываемой в данном научном исследовании программы.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
В данном проекте автоматизируется рутинная работа почтовых операторов
УФПС «Татарстан почтасы» по приему регистрируемых почтовых отправлений.
Разрабатываемая система мониторинга представляет из себя набор
функциональных форм, работающих непосредственно с общей для всей системы
базой данных. В стандартный набор входят следующие формы: 1) добавление в
базу посылки; 2) добавление в базу контейнера; 3) проверка контейнера. Сценарий
диалога представлен на рисунке 13.
72
Рисунок 13 - Сценарий диалога работы программы
Сценарии диалога – описывает начальное окно, множество состояний
диалога, а также действия, которые выполняются в каждом состоянии. Выявление
состава функций, их иерархии и выбор языка общения (например, языка типа
«меню») позволяет разработать структуру сценария диалога, дающего возможность
определить состав кадров диалога, содержание каждого кадра и их
соподчиненность.
Программа согласно заложенной в неё логике обрабатывает письма,
проверяя их содержимое и согласовывая доступ. В программе есть возможность
просмотреть историю обработанных писем и при возможности отменить созданные
заявки.
Любой функционал программы можно разделить на основной, с помощью
Оформление новой посылки
Распределение по
контейнерам
Извлечение посылок из
контейнера
Новое согласование
Новое согласование
Вывод сообщения о
целостности контейнера
Вывод сообщения о
нецелостности контейнера
Проверка целостности
контейнера
73
которой достигается основная цель алгоритма программы и дополнительный
(Служебный) это то, что можно настроить изменить, прояснить. Дерево функций
как раз наглядно демонстрирует разделение данных функций. Дерево функций
изображено на рисунке 14.
Рисунок 14 - Дерево функций
При разработке структуры диалога предусмотрена возможность работы с
экранными формами входных документов, формирование выходных документов,
корректировки вводимых данных, просмотра введенной информации, работу с
таблицами нормативно-справочной информации, протоколирования действий
пользователя, а также помощь на всех этапах работы.
Описание диалога, реализованного с использованием контекстно-зависимого
меню, не требует нестандартного подхода. Необходимо лишь однозначно
определить все уровни, на которых пользователь принимает решение относительно
следующего действия, а также обосновать решение об использовании именно этой
технологии (описать дополнительные функции, контекстные подсказки и т.д.). Для
спроектированной структуры диалога пользователя с ИС разработаны макеты
экранных форм.
Источник: https://baza.diplomsite.ru/previewfile/1481