Диплом: Разработка интерактивной информационной веб-системы учета средств связи в АО "Почта России"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
87
ПКД
ПКДМаска
ПКДHosts
Строка
Срока
Строка
6
Сотрудники
Наименование
Должность
Телефон
ЭлПочта
ФИО
Активен
Роль
ПользовательСоздан
ID
Строка
Строка
Строка
Строка
Строка
Булево
Перечисление
Булево
Строка
7
Оборудование
Наименование
Тип
Фирма
Модель
SN
ИнвНомер
НаУчете
НаМониторинге
ВРемонте
ID
ДатаПостановкиНаУчет
ДатаОтправкиВРемонт
ДатаПостановкиНаМонито
ринг
IPЛВС
IPRVPN
Строка
Ссылка
Ссылка
Ссылка
Строка
Строка
Булево
Булево
Булево
Строка
Дата
Дата
Дата
Строка
Строка
88
IPLoopback
CPUMhz
RAM
ПортыEthernet100
ПортыEthernet1000
ПортыEthernet10000
ПортыSFPXFP
ПортыEthernet1000Занято
ПортыEthernet100Занято
ПортыEthernet10000Занято
SFPXFPЗанято
Расположение
СЕОбъекта
HostName
Эксплуатируется
Строка
Число
Число
Число
Число
Число
Число
Число
Число
Число
Число
Строка
Булево
Строка
Булево
8
Тип
Наименование
Строка
9
Фирма
Наименование
Строка
10
Модель
Наименование
Строка
11
Стационарная
Телефони
Наименование
Оператор
Тариф
Стоимость
Строка
Строка
Строка
Число
89
2.2.3. Характеристика результатной информации
Выводная информация формируется по средствам динамических списков
на основе отобранных элементов справочника. Даный варинат вывода дает
общирные возможности в построении информационных таблиц, учитывает в
себе связи между различными элементами справочника, позоляет строить
отчетные таблицы на основе обсалютно любых элементов и реквизитов.
Благодаря связности элеметов справочников, такой список можно сформировать
практически в каждой форме. Так же данные списки можно экпортировать в
табличный или тектовый документ (штатная функция платформы 1С
предприятие).
Основываясь на этом нет необходимости отдельно описывать каждый вид
списка отдельно, покольку принцип постраения один, а результат зависит от
выбора пользователя.
2.3 Программное обеспечение задачи.
Управление пользователем информационной системой осуществляется
при помощи набора элементов управления на WEB-форме приложения.
Проектируемая информационной система содержит несколько интерфейсов,
разделённых на подсистемы, так как функциональный набор приложения
разграничен в зависимости от роли пользователя, у ряда пользователей будет
доступно несколько подсистем, у некоторых только одна.
2.3.1. Общие положения (дерево функций и сценарий диалога)
Сценарии диалога приложения различны для 3-х типов интерфейса
приложения:
- Интерфейс разработчика (В качестве основного интерфейса выступает
конфигуратор, в WEB интерфейсе доступны все подсистемы и функции).
- Интерфейс администратора (интерфейс имеет подсистему администратора и
подсистему пользователя).
90
- Интерфейс пользователя (имеет доступ только к WEB интерфейсу, доступна
только подсистема пользователя).
Схема сценария диалога Разработчика представленна на рисунке 6.
Рисунок 6. Схема сценария диалога Разработчика
Диалог Разработчика делится на 2 типа режима, режим конфигуратора и
режим WEB приложения. В режиме конфигуратор происходит непосредственно
процесс разработки: настройка конфигурации, внедрение кода, управление
пользователями и ролями, управления формами, управление справочниками,
подсистемами и другими элементами конфигурации. В режиме WEB интерфейса
ведётся работа в самом приложении. Разработчику доступны все подсистемы и
все интерфейсы, так же разработчику доступные все данные не зависимо от того
в каком подразделении он работает. Так же разработчик может назначить
пользователю дополнительную роль через конфигуратор, например роль
администратора можно присвоить только через конфигуратор, в веб интерфейсе
при создании пользователя эта роль отсевает, делано это в целях безопасности,
91
поскольку в подсистеме Администратора есть функции массового управления
данными.
Схема сценария диалога Администратора представленна на рисунке 7.
Рисунок 7. Схема сценария диалога Администратора
Диалог Администратора строится в WEB приложении, администратору
доступна подсистема пользователя и подсистема администратора, при желании
можно оставить только подсистему администратора. Администратору доступны
сервисные функции, так же администратор может создавать новых
пользователей. Права Администраторов, как и пользователей различаются в
зависимости от иерархии предприятия, тесть Администратор, будучи
92
сотрудником подразделения не сможет создать пользователя с ролью сотрудника
филиала и выше, так он будет иметь доступ только к информации начиная от
своей иерархической позиции и ниже.
Схема сценария диалога Пользователя представленна на рисунке 8.
Рисунок 8. Схема сценария диалога Пользователя
Диалог пользователя обозначен одной подсистемой, относящейся к его
иерархической позиции (сотрудник: аппарата управления, макрорегиона,
филиала, подразделения). Действия пользователя в системе направленны на
получение и добавление информации, пользователю доступны справочники и
реквизиты, при необходимости пользователь тоже сможет создать пользователя,
однако он сильно ограничен в выборе ролей и сможет присвоить только роль
уровня ниже своей. Пользователь не может удалять данные, при попытке
удаления данных, данные будут помечены на удаление, полное удаление данных
сможет осуществить только разработчик или администратор.
2.3.2. Характеристика базы данных
отдельной Файловая использование СУБДодна из специалист систем количество управления базами поддержка данных , рисунок которую
поддерживает расчет платформа. данных Файловая СУБД создании разработана является фирмой «1С» и составляет является
норма частью платформы.
прикладных Файловая рабочих СУБД хранит все рисунок данные в данных одном файле — . средств файловой норму базе данных
рисунок Этот основе формат хранения данных данных создании разработан фирмой «1норму С» норма специально для
прикладных составляет решений1 определяется С:Предприятия 8[11]. определяется Схема специалист взаимодейтсвия
предасталенна на базовый рисунке 9.
93
Рисунок 9. Схема взаимодействия с СУБД.
При создании платформы был необходим эффективный формат для создания на
его основе легкого варианта 1С:Предприятия 8 для персонального
использования и небольших рабочих групп. Формат должен был удовлетворять
определенным требованиям, таким как, эффективность, поддержка UNICODE,
возможность размещения всей информационной базы в одном файле.[2]
Использование этого варианта не должно было требовать установки
дополнительного программного обеспечения у пользователя и каких-либо
действий по администрированию. [12]
Должна была обеспечиваться, например, возможность легкого переноса
информационной базы на ноутбук или быстрого развертывания удаленного
рабочего места на складе. При этом прикладное решение должно было без каких-
либо изменений работать как в этом варианте, так и в варианте с использованием
сервера баз данных. [12]
По результатам исследования продуктов сторонних производителей и их анализа
было принято решение о создании собственного «движка» базы данных,
поддерживающего собственный формат хранения. [12]
Файловая СУБД является частью платформы, поэтому при работе системы
в файловом варианте толстый и тонкий клиенты самостоятельно осуществляют
всю работу с данными.
94
В случае веб-клиента подключение к файловой базе данных выполняется через
веб-сервер, и непосредственную работу с данными выполняет не клиентское
приложение, а модуль расширения веб-сервера, который также содержит в себе
файловую СУБД. Полная схема взаимодейтсвия всех элементов платформы
представленна на рисунке 10.
Рисунок 10. Полная схема взаимодействия с СУБД.
Взаимодействие элементов системы с файловой базой данных осуществляется
по собственному протоколу обмена данными, разработанному фирмой «1С».
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
Разработанная конфигурация включает в себя серверную и клиентскую
часть Серверная часть является приложением для взаимодействия с базой
данных, клиентская – веб-интерфейсом для ввода данных и получения отчетной
информации. Схема представленна на рисунке 11.
95
Рисунок 11. Взаимодействие серверной и клиенстской частей.
2.3.4. Описание программных модулей.
Все модули проекта подчиняются единой логике, различаются лишь связями
справочников и реквизитами, а так же внешним видом форм. Логика работы
моодулей представленна на рисунке 12.
96
Рисунок 12. логика работы модулей
2.4. Контрольный пример реализации проекта и его описание
Работа начинается с окна авторизации
Рисунок 13. Окно авторизации

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран