Файл: Автоматизация контроля исполнения документов в приемной комиссии ВУЗ-а.pdf
Добавлен: 28.03.2023
Просмотров: 132
Скачиваний: 2
СОДЕРЖАНИЕ
1. Технико-экономическая характеристика предметной области и предприятия
1.1 Характеристика предприятия и его деятельности
1.2 Организационная структура управления вуза.
1.3 Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов
2. Информационное обеспечение задачи.
2.1 Информационная модель и её описание.
2.2 Используемые классификаторы и системы кодирования
2.3 Характеристика нормативно-справочной, входной и оперативной информации
2.4 Характеристика результатной информации
3. Программное обеспечение задачи
3.1 Общие положения (дерево функций и сценарий диалога)
Все действия по созданию или изменению структуры таблиц базы данных платформа выполнит самостоятельно, на основании состава объектов прикладного решения и их характеристик.
Например, для того, чтобы в справочнике сотрудников появилась возможность хранить сведения о составе семьи сотрудника, разработчику 1С: Предприятия не нужно создавать в базе данных специальную новую таблицу, задавать правила, по которым данные, хранящиеся в этой таблице, будут связаны с данными из основной таблицы, программировать алгоритмы совместного доступа к данным этих таблиц, создавать алгоритмы проверки прав доступа к данным, находящимся в подчиненной таблице и пр.
Все, что требуется сделать разработчику - щелчком мыши добавить к справочнику табличную часть и задать два ее строковых реквизита: Имя и Родство. При сохранении или обновлении конфигурации платформа самостоятельно выполнит реорганизацию структуры базы данных, создаст необходимые таблицы и т.д.
Штатной возможностью 1С:Предприятия 8 является поддержка двух способов доступа к данным — объектного (для чтения и записи) и табличного (для чтения).
В объектной модели разработчик оперирует объектами встроенного языка. В этой модели обращения к объекту, например документу, происходят как к единому целому — он полностью загружается в память, вместе с вложенными таблицами, к которым можно обращаться средствами встроенного языка как к коллекциям записей и т.д.
Рис. 7 Объектная модель баз данных.
При манипулировании данными в объектной модели обеспечивается сохранение целостности объектов, кэширование объектов, вызов соответствующих обработчиков событий и т.д.
В табличной модели все множество объектов того или иного класса представляется как совокупность связанных между собой таблиц, к которым можно обращаться при помощи запросов как к отдельной таблице, так и к нескольким таблицам во взаимосвязи.
Рис. 8 Табличная модель базы данных
В этом случае разработчик получает доступ к данным сразу нескольких объектов, что очень удобно для анализа больших объемов данных, например, при создании отчетов. Однако в силу того, что данные, выбираемые таким способом, содержат не все, а лишь некоторые реквизиты анализируемых объектов, табличный способ доступа не позволяет изменять эти данные.
Под классификатором имеется в виду ключевой элемент таблицы (ключ, regular key) — такое ее поле (простой ключ) или строковое выражение, образованное из значений нескольких полей (составной ключ), по которому можно определить значения других полей для одной или нескольких записей таблицы. На практике для использования ключей создаются индексы — служебная информация, содержащая упорядоченные сведения о ключевых значениях. В реляционной теории и концептуальной модели понятие «ключ» применяется для атрибутов отношения или сущности.
2.3 Характеристика нормативно-справочной, входной и оперативной информации
Это описание состава входных документов и справочников, соответствующих им экранных форм размещения данных и структуры файлов. При этом следует уделять внимание следующим вопросам:
При описании входных документов необходимо привести в приложении формы документов; перечень содержащихся в них первичных показателей; источник получения документа, в каком файле используется информация этого документа, описывается структура документа, число строк, объемные данные, частоту возникновения документа;
Описание экранной формы входного документа должно содержать макет экранной формы в приложении, особенностей организации рабочей и служебной зон макета, состав и содержание подсказок, необходимых пользователю для заполнения макета, перечень справочников, автоматически подключаемых при заполнении этого макета;
Описание структур входных файлов с оперативной информацией должно включать таблицу с описанием наименований полей, идентификатором каждого поля и его шаблона; по каждому файлу должна быть информация о ключевом поле, длине одной записи, числе записей в файле, частоте создания файла, длительности хранения, способе обращения (последовательный, выборочный или смешанный), способе логической и физической организации, объеме файла в байтах;
Описание структур файлов с условно-постоянной информацией содержит те же сведения, что и для файлов с оперативной информацией, но добавляются сведения о частоте актуализации файла и объеме актуализации (в процентах).
Необходимо отметить соответствие проектируемых файлов входным документам или справочникам. Описывается структура записи каждого информационного файла. Если информационная база организована в форме базы данных, то приводится описание и других её элементов (ключей, бизнес-правил, триггеров).
При поступлении абитуриента задача сотрудника приемной комиссии запросить его персональные данные, и это будет являться входной информацией.
Входной информацией абитуриента является:
- Паспортные данные
- Документ об образовании
- Результаты вступительных экзаменов
- Дата подписание договора об оказании образовательных услуг
- Дата оплаты
После предоставления входной информации от абитуриента специалист приемной комиссии заполняет полную таблицу данных входящей информации указанная в таблице 3.
Таблица 3.
№ |
Наименование поля |
Идентификатор |
Тип |
Значность |
1 |
Номер |
Number |
N |
254 |
2 |
Учебный год |
Cod_year/year |
N |
4 |
3 |
Семестр по порядку |
Cod_s1 |
N |
9 |
3 |
Семестр учебного года |
Cod_s2 |
N |
9 |
4 |
Семестр по приказу |
Cod_s3 |
N |
9 |
5 |
Структурное подразделение |
Cod_otd |
C |
254 |
6 |
Программа |
Program |
C |
254 |
7 |
Специальность |
specialty |
C |
254 |
8 |
Форма |
The_from |
C |
3 |
9 |
Срок |
Term |
N |
9 |
10 |
Дата приказа |
Data_of_order |
N |
8 |
11 |
Год поступления |
Admission_years |
N |
8 |
12 |
Ставка |
Rate |
N |
254 |
В нормативно-справочной информации указаны: сотрудник исполнитель приемной комиссии и менеджер-куратор, который занимается поступления клиента. Также шаблоны документов, а именно: договор, заявление на зачисление, согласие на зачисление и согласие на обработку персональных данных указанно в таблице 4.
Таблица 4.
№ |
Наименование поля |
Идентификатор |
Тип |
Значность |
1 |
ФИО сотрудника приемной комиссии |
СOD |
N |
254 |
2 |
ФИО менеджера |
СOD |
N |
254 |
2.4 Характеристика результатной информации
В результате проектирование автоматизации контроля документов в вузе получаются следующие результаты.
Таблица 5.
Таблица 6.
Таблица 7.
Таблица 8.
Таблица 9.
Результатная информация может, быть как в электронном виде, так и в виде бумажного документа. Результатная информация представляет собой сформированные по запросам отчеты, которые содержат в себе информацию о зачисленных студентов.
Отчеты формируются с помощью запросов. Для внутренних пользователей отчетность является важным показателем, как для оперативного зачисления, так и для контроля выполненных задач сотрудниками университета.
3. Программное обеспечение задачи
3.1 Общие положения (дерево функций и сценарий диалога)
В данном пункте следует привести иерархию функций управления и обработки данных, которые призван автоматизировать разрабатываемый программный продукт. При этом можно выделить и детализировать основные функции управления и обработки данных: ввода первичной информации, обработки, ведения справочников, ответов на запросы и др.
Выявление состава функций, их иерархии и выбор языка общения (например, языка типа «меню») позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога, содержание Текстовый (CHAR)каждого кадра и их соподчиненность.
При разработке структуры диалога необходимо предусмотреть возможность работы с экранными формами входных документов, формирование выходных документов, корректировки вводимых данных, просмотра введенной информации, работу с таблицами нормативно-справочной информации, протоколирования действий пользователя, а также помощь на всех этапах работы.
В разработанном приложении взаимодействие пользователя и программы осуществляется в форме простого и удобного диалога, что позволяет обеспечить доступность данного приложения даже для неопытного пользователя.
Диалог – это процесс обмена сообщениями между пользователем и ИС, при котором осуществляется постоянная смена ролей информатора и реципиента (пользователя, принимающего информацию), причем смена ролей достаточно оперативна. В процессе диалога возможно:
- Двустороннее управление на базе языка типа «запрос-ответ»,
- Одностороннее управление со стороны ИС с языком общения типа «меню», «заполнения шаблона», ответа по «подсказке»,
- Одностороннее управление со стороны пользователя с использованием языка директив (команд).
При использовании для общения языка «меню» в диалоговой системе должна присутствовать система планирования и управления диалогом, в функции которой входит:
- управление процессом диалога;
- обеспечение интерфейса пользователя;
- обеспечение выполнения сервисных или справочных функций;
- анализ и обработка ошибочных ситуаций;
- вызов обрабатывающих программ.
При разработке данного проекта система общения с пользователем организована таким образом, что основная часть диалога ведется на языке типа «меню», а заполнение форм входных документов – по «шаблону». Таким образом, происходит одностороннее управление процессом обработки данных со стороны ИС.
3.2 Характеристика базы данных
ER-модель предназначена для логического представления данных. Любой фрагмент предметной области представляется как множество сущностей, между которыми существует множество связей различных типов. ER- модель реализуемого проекта автоматизации представлена на рисунке 9.
Рисунок 9 - ER - модель разрабатываемой ИС
Показанная на рисунке 9. ER-модель основана на информационной модели разрабатываемого проекта и представляет собой модель базы данных предметной области, определяющую взаимосвязь таблиц по внешним ключам.
Описание таблиц реляционной базы данных в таблицах 5-9.
3. 3 Структурная схема пакета (дерево вызова программных модулей)
Разработка программного обеспечения осуществляется, как правило, в два этапа:
- Проектирование логики программ, представляющее определение состава программных модулей, выделение классов модулей и установление связей между ними;
- Разработка кодов программ и их отладка, выполнение которой в сильной степени зависит от используемых средств разработки программного обеспечения.
Были выделены управляющие программные модули, призванные выводить на экран кадры меню и передавать управление другим модулям в зависимости от того, какой пункт меню выбирает пользователь. К числу управляющих модулей относится модуль загрузки основного меню, главного меню, меню служебных операций, меню видов первичных документов, меню видов отчетов, справочников и меню видов операций, выполняемых при работе с этими классами документов.