CC BY
5
УДК 004
Зорин Д.Ю. студент 3 курса факультет «Инженерно-экономический»
Абрамова О.Ф. доцент
кафедра «Информатика и технология программирования» научный руководитель: Короткова Н.Н., к.техн.н.
доцент
кафедра «Информатика и технология программирования»
Волжский политехнический институт
(филиал) ВолгГТУ Россия, г. Волжский ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И РАЗРАБОТКА ЭСКИЗНОГО ПРОЕКТА АВТОМАТИЗИРОВАННОЙ ПРОГРАММНОЙ СИСТЕМЫ ДЛЯ АВТОМАТИЗАЦИИ ХОЗДОГОВОРНОЙ ДЕЯТЕЛЬНОСТИ ВОЛЖСКОГО ПОЛИТЕХНИЧЕСКОГО ИНСТИТУТА Аннотация: в статье приводится анализ предметной области, исследование бизнес-процессов научно-исследовательского сектора Волжского политехнического института. Также приводится предложение по дальнейшей реализации соответствующей системы.
Ключевые слова: моделирование бизнес-процессов, хоздоговорная деятельность, эскизный проект, программная система, моделирование UML.
Zorin D.U. student
3 course, engineering-economic faculty Volzhskiy Polytechnical Institute branch of the Volgograd State Technical University
Russia, Volzhsky Abramova O.F.
Associate Professor, Department of computer science and technology
programming Volzhskiy Polytechnical Institute branch of the Volgograd State Technical University
Russia, Volzhsky research supervisor: Korotkova N.N. Candidate of Engineering Sciences Associate Professor, Department of computer science and technology
programming Volzhskiy Polytechnical Institute
branch of the Volgograd State Technical University
Russia, Volzhsky
INVESTIGATION OF THE SUBJECT AREA AND DEVELOPMENT OF THE SKETCH PROJECT OF THE AUTOMATED SOFTWARE SYSTEM FOR AUTOMATION OF THE CONTRACT ACTIVITY OF THE VOLZHSKY POLITECHNICAL INSTITUTE.
Abstract: in the article the analysis of a subject domain, research of business processes of scientific research sector of the Volga Polytechnic Institute is resulted. A proposal for further implementation of the relevant system is also given.
Key words: modeling of business processes, contractual activity, draft design, software system, modeling of UML.
1. Исследование предметной области
Рассмотрим организацию хоздоговорной деятельности волжского политехнического института, а также бизнес-процессы, протекающие в нем.
Для построения моделей, описывающих бизнес-процессы, необходимо сначала выделить структуру предприятия, основные документы участвующие в автоматизируемых бизнес-процессах, а также нормативные документы их регулирующие.
В ходе исследования предметной области, были выделена кадровая структура, представленная в рисунке 1.
Ректор института
Заказчик
НИС
-------------w
4>
Юрист
Юридический отдел
Заведующий кафедрой
Сотрудник кафедры
Кафедра
Рисунок 1. Модель кадровой структуры предприятия. Ректор института является его представителем, а также руководит
всеми его процессами.
Отдел НИС (Научно-исследовательский сектор) - определяет порядок планирования и заключения договоров, организацию и проведения фундаментальных исследований, поисковых и прикладных работ (НИР), также представляет интересы заказчика во время исследовательской деятельности.
Руководитель НИС занимается управлением в рамках деятельности отдела, а также является его представителем.
Сотрудник НИС - абстрактная сущность, объединяющая в своем понятии всех сотрудников НИС. Выполняет учет документации и контроль документации.
Юридический отдел выполняет работу по разработке документов правового характера, а также оказывает помощь всем структурным подразделениям в оформлении документов. Обеспечивает соблюдение правовых норм в рамках деятельности института.
Отдел кафедра абстрактная сущность, объединяющая в себе все кафедры института. В рамках хоздоговорной деятельности, занимается имплементацией договора.
Заведующий кафедрой занимается управлением в рамках деятельности отдела, а также является его представителем.
Сотрудник кафедры - абстрактная сущность, объединяющая в своем понятии всех сотрудников кафедры. Выполняет работы, оговоренные договором. (Справедливо для хоздоговорной деятельности института)
Заказчик - некоторый абстрактный заказчик. Заказчиком может выступать как сам институт, так и некоторое стороннее предприятие. Чаще всего частью института не является, поэтому расположен обособленно от остальных участников хоздоговорной деятельности.
Теперь опишем основные документы входящие в документооборот хоздоговорной деятельности:
• ДОГОВОР на создание (передачу) научно-технической продукции;
• ТЕХНИЧЕСКОЕ ЗАДАНИЕ;
• КАЛЕНДАРНЫЙ ПЛАН;
• ПРОТОКОЛ соглашения о договорной цене на научно-техническую продукцию;
• СМЕТА РАСХОДОВ на выполнение научно-исследовательской работы
• АКТ сдачи-приемки выполненных работ по договору
• ДОГОВОР подряда на выполнение научно-исследовательских, опытно-конструкторских работ
• Служебная записка
• АКТ сдачи-приемки результатов научно-исследовательских работ
• ДОГОВОР б/н на выполнение научно-исследовательских работ,
оказание услуг по договору
• АКТ о приеме научно-исследовательских работ (услуг)
Нормативные документы, регулирующие бизнес-процессы предметной
области:
• Федеральный закон "Об обязательном экземпляре документов" от 29.12.1994 N 77-ФЗ
• Федеральный закон "Об образовании в Российской Федерации" от 29.12.2012 N 273-ФЗ
• ПРИКАЗ Минобрнауки РФ от 21.10.2013 N 1168 "ОБ УТВЕРЖДЕНИИ ФОРМ НАПРАВЛЕНИЯ СВЕДЕНИЙ О НАУЧНО -ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТАХ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ В ЦЕЛЯХ ИХ УЧЕТА В ЕДИНОЙ ГОСУДАРСТВЕННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ УЧЕТА НАУЧНО -ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ И ТРЕБОВАНИЙ К ЗАПОЛНЕНИЮ УКАЗАННЫХ ФОРМ, А ТАКЖЕ ПОРЯДКА ПОДТВЕРЖДЕНИЯ ГЛАВНЫМИ РАСПОРЯДИТЕЛЯМИ БЮДЖЕТНЫХ СРЕДСТВ, ОСУЩЕСТВЛЯЮЩИМИ ФИНАНСОВОЕ ОБЕСПЕЧЕНИЕ НАУЧНО - ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО -КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ И ВЫПОЛНЯЮЩИМИ ФУНКЦИИ ЗАКАЗЧИКА ТАКИХ РАБОТ, СООТВЕТСТВИЯ СВЕДЕНИЙ ОБ УКАЗАННЫХ РАБОТАХ, ВНЕСЕННЫХ В ЕДИНУЮ ГОСУДАРСТВЕННУЮ ИНФОРМАЦИОННУЮ СИСТЕМУ УЧЕТА НАУЧНО - ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ, УСЛОВИЯМ ГОСУДАРСТВЕННЫХ КОНТРАКТОВ НА ВЫПОЛНЕНИЕ НАУЧНО - ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ"
Ф.З. «Об обязательном экземпляре документов» от 29 декабря 1994 г. N9 77-ФЗ (ред. от 05.05.2014)
Ф.З. N 273ФЗ Федеральный закон
ПРИКАЗ Минобрнауки РФ от 21.10.2013 N 1168
Тема проекта
Информация об участниках
Хоздоговорная деятельность
АО
-Акт приема передачи-
Отчетная научно-техническая_ документация
Рисунок 2. Обобщенная модель бизнес-процессов, представленная в
нотации IDEF0
Объединим всю найденную нами информацию, о предметной области в модели нотации ГОЕБО. Соответствующие модели представлены ниже в рисунках 2,3.4
Ф.З. «Об обязательном
Исполнитель
Рисунок 3. Модель бизнес-процессов, в нотации \DEF0. Декомпозиция процесса "Хоздоговорная деятельность ".
НИС
Ф.З. «Об обязательном
экземпляре документов» от 29 декабря 1994 г. N 2 77-ФЗ (ред. от 05.05.2014)
НИС Заказчик
Рисунок 4. Модель бизнес-процессов, в нотации IDEF0. Декомпозиция
процесса "Сформировать пакет документов ". _Таблица 1. Описание бизнес-процессов.
Идентификатор, название бизнес-процесса Описание Входные документы Выходные документы
АО) Вузы заключают 1. Тема проекта 1. Акт приема
Хоздоговорная хозяйственные 2. Информация об передачи
деятельность договоры с участниках 2. Отчетная
заказчиками на документация
выполнение за
счет их средств
фундаментальных,
поисковых и
прикладных
исследований,
опытно-
конструкторских и
технологических
разработок в
интересах
отраслей
народного х-ва,
производственных
(научно-
производственных)
объединений,
предпр.
В1) Сформировать пакет документов. Формируется пакет документов необходимый для начала хоздоговорной деятельности. 1. Тема проекта 2. Информация об участниках 1. Смета затрат. 2. Т.З. 3. Календарный план проекта.
В2) Выполнить этап работ. Исполнитель выполняет очередной этап работ согласно договору. 1. Смета затрат. 2. Т.З. 3. Календарный план проекта. 1. Смета затрат.
В3) Провести учет. Проводится учет полученной в результате выполнения этапа работ документации. Рассчитывается доход по договору. 1. Смета затрат. 1. Акт приема сдачи работ.
С1) Сформировать пакет документов. Оговариваются цель исследования, этапы, стоимость, сроки, исполнители. Заполняется подготовительная документация. 3. Тема проекта 4. Информация об участниках 4. Смета затрат. 5. Т.З. 6. Календарный план проекта.
С2) Заключить договор, утвердить документацию. Сотрудник НИС, совместно с юристом проверяет полученный пакет документов. Затем происходит подписание договоров, и остальных документов. 1. Т.З. 2. Смета затрат 3. Протокол соглашения цены 4. Договора 5. Календарный план проекта. 1. Смета затрат. 2. Т.З. 3. Календарный план проекта.
После исследования модели и пожеланий заказчика, мной были выделены следующие процессы, для их последующей автоматизации:
• Формирование пакета документов;
• Учет документации;
2. Функциональные требования к информационной системе.
Сотрудник кафедры ( Аутентификация
Сотрудник НИС
Рисунок 5. Модель
Описание сценариев: Регистрация
вариантов использования, представленная в нотации UML.
Таблица 2. Описание сценария "Регистрация"
Цель Создать аутентификационные данные студента для их для доступа к функционалу системы
Предусловия Пользователь открыл домашнюю страницу системы и нажал на кнопку "регистрация"
Основной поток событий - Пользователь вводит свои регистрационные данные: почта, пароль, номер кафедры. - Пользователь нажимает кнопку "зарегистрироваться"
Альтернативный поток событий - Пользователь получил сообщение об ошибке т.к. ввел неправильные регистрационные данные. (Пароль должен содержать не меньше 5 символов, и может содержать только буквы латинского алфавита, знаки препинания и нижнее подчеркивание. Почтовый ящик должен соответствовать формату описанному в ЯБС5322. Номер кафедры должен состоять из 4 цифр.) - Пользователь закрыл страницу.
Постусловия Пользователь ожидает подтверждения своей учетной записи
Инициаторы Сотрудник кафедры
Аутентификация
_Таблица 3. Описание сценария "Аутентификация "
Цель Подтвердить личность пользователя для доступа к функционалу системы.
Предусловия Пользователь открыл домашнюю страницу системы и нажал на кнопку "войти"
Основной поток событий - Пользователь вводит свои аутентификационные данные: почта, пароль, номер кафедры. - Пользователь нажимает кнопку "вход". - Производится вход в систему
Альтернативный поток событий 1 - Пользователь получает сообщение о том, что его учетная запись все еще не подтверждена.
Альтернативный поток событий 2 - Пользователь получил сообщение, о том, что ввел неверные данные. (Такого пользователя не существует)
Альтернативный поток событий 3 - Пользователь закрыл страницу.
Постусловия Пользователь попадает на страницу со списком его договоров.
Инициаторы Сотрудник кафедры, Сотрудник НИС
Настройка информации о вузе
_Таблица 4. Описание сценария "Настройка информации о вузе"
Цель Изменить информацию о вузе, которая в последствии будет подставляться в шаблон документов.
Предусловия Сотрудник НИС нажал кнопку в навигационном меню "настроить".
Основной поток событий - Пользователь вводит в текстовые поля информацию о вузе: название вуза, адрес, ФИО директора. - Пользователь нажимает кнопку "сохранить".
Альтернативный поток событий - Пользователь ввел некорректные данные (оставил поля пустыми или данные содержали не допустимые символы. Название и адрес могут содержать: буквы русского и латинского алфавита, кавычки, цифры, знаки препинания. ФИО может содержать только буквы русского алфавита и дефис). - Пользователь закрыл страницу.
Постусловия Данные для заполнения шаблона договоров меняются.
Инициаторы Сотрудник НИС
Работа со списком исполнителей
Рисунок 5. Модель сценария "Работа со списком исполнителей ", представленная в нотации UML. Таблица 4. Описание сценария "Работа со списком исполнителей "
Цель Взаимодействие со списком исполнителей кафедры.
Предусловия Сотрудник кафедры нажал на копку в навигационном меню "Исполнители"
Основной поток событий - Система выводит список исполнителей. - Пользователь просматривает список исполнителей. - Пользователь выбирает одно из действий: добавить, удалить или изменить исполнителя.
Постусловия Список исполнителей меняется в соответствии с манипуляциями пользователя.
Инициаторы Сотрудник кафедры
Таблица 5. Описание сценария "Добавить исполнителя "
Цель Добавить в систему новое представления для исполнителя.
Предусловия Пользователь находится на странице "исполнители"
Основной поток событий - Пользователь вводит в поля информацию о исполнителе: ФИО, Должность - Пользователь нажимает на пиктограмму "плюс" (добавить)
Альтернативный поток событий Пользователь ввел некорректные данные (оставил поля пустыми или данные содержали не допустимые символы. ФИО и должность могут содержать только буквы русского алфавита и дефис).
Постусловия В список добавляется новый исполнитель.
Инициаторы Сотрудник кафедры
Цель Удалить исполнителя из списка исполнителей.
Предусловия Пользователь находится на странице "исполнители". Пользователь нажимает на пиктограмму "крестик"(удалить) на против элемента списка исполнителей.
Основной поток событий - Система выводит сообщение "Вы действительно хотите удалить исполнителя XXX?" - Пользователь нажимает "Да".
Альтернативный поток событий Пользователь нажал 'Нет'.
Постусловия Система удалит исполнителя из списка исполнителей.
Инициаторы Сотрудник кафедры
Таблица 7. Описание сценария "Редактировать исполнителя'
Цель Изменить данные представления исполнителя.
Предусловия Пользователь находится на странице "исполнители". Пользователь нажал на кнопку редактировать напротив элемента списка исполнителей.
Основной поток событий - Система выводит заполненные поля для ввода информации о исполнителе. - Пользователь вводит информацию об исполнителе. - Пользователь нажимает ок
Альтернативный поток событий Пользователь ввел некорректные данные (оставил поля пустыми или данные содержали не допустимые символы. ФИО и должность могут содержать только буквы русского алфавита и дефис).
Постусловия Система изменит информацию об исполнителе.
Инициаторы Сотрудник кафедры
Работа со списком договоров
Сотрудник кафедры
Сотрудник НИС
Рисунок 6. Модель сценария "Работа со списком договоров", представленная в нотации UML.
Цель Взаимодействие со списком исполнителей кафедры.
Предусловия Пользователь нажал на копку в навигационном меню "Договоры"
Основной поток событий - Система выводит список договоров. - Пользователь просматривает список договоров. - В меню на странице договоров пользователь может выбрать один из фильтров. - Сотрудник кафедры выбирает одно из доступных ему действий: добавить, удалить или изменить, отправить на проверку, загрузить шаблоны документов.
Альтернативный поток событий - Система выводит список договоров. В списке отражены: номер договора, тема, остаток, даты начала и окончания, заказчик, исполнитель и статус. - Пользователь просматривает список договоров. - В меню на странице договоров пользователь может выбрать один из фильтров. - Сотрудник НИС может выбрать одно из выбирает одно из доступных ему действий:
Постусловия Список договоров меняется в соответствии с манипуляциями пользователя.
Инициаторы Сотрудник кафедры, сотрудник НИС
Цель
Добавить в систему новое представление для договора._
Предусловия
Пользователь находится на странице "Договоры"_
Основной поток событий
- Система выводит поля для ввода информации.
- Пользователь вводит в поля информацию о договоре: дата составления, тема договора, дата уведомлении состава комитета, дата о уведомлении готовности продукта к испытаниям, время на уведомление об остановке работ, время на обсуждение принятия проекта, другие санкции, право передачи, распределение выручки от передачи разработки, право публикации, другие условия, дата начала действия договора, дата окончания действия договора, ФИО представителя заказчика, название организации заказчика, адрес организации заказчика, договорная цена, к оплате на текущий год, условия надбавки, размер надбавки, условия уменьшения оплаты, размер уменьшения надбавки. Пользователь может не вводить некоторые данные, оставив это на потом. Он обязан ввести тему договора.
- Пользователь выбирает из списка, исполнителей участвующих в проекте и вводит их должности.
- Пользователь нажимает на кнопку "добавить".
Постусловия
В список добавляется новый договор.
Инициаторы
Сотрудник кафедры
Таблица 10. Описание сценария "Удалить договор"
Цель Удалить договор из списка договоров.
Предусловия Пользователь находится на странице "Договоры". Пользователь нажимает на пиктограмму "крестик" (удалить) на против элемента списка договоров. Договор не должен иметь статус "Утвержден".
Основной поток событий - Система выводит сообщение "Вы действительно хотите удалить договор номер №ХХХ?" - Пользователь нажимает "Да".
Альтернативный поток событий Пользователь нажал 'Нет'.
Постусловия Система удалит договор из списка договоров.
Инициаторы Сотрудник кафедры
Цель Изменить данные представления договора.
Предусловия Пользователь находится на странице "договоры". Пользователь нажал на кнопку редактировать напротив элемента списка договоров. Договор не должен иметь статус "Утвержден" или "Завершен".
Основной поток событий - Система выводит заполненные поля для ввода информации о договоре. - Пользователь вводит информацию об договоре. - Пользователь нажимает "ОК".
Постусловия Система изменит информацию об договоре.
Инициаторы Сотрудник кафедры
Таблица 12. Описание сценария "Скачать шаблоны документов'
Цель Сформировать шаблоны документов.
Предусловия Пользователь находится на странице "договоры". Пользователь нажал на кнопку скачать шаблоны документов.
Основной поток событий - Пользователь получает архив с заполненными шаблонами документов.
Инициаторы Сотрудник кафедры
Таблица 13. Описание сценария "Отправить на проверку"
Цель Отправить договор на проверку, чтобы сотрудник НИС мог утвердить его или отправить для исправления.
Предусловия Пользователь находится на странице "договоры". Пользователь нажимает на кнопку "проверить"
Основной поток событий - Статус договора переводится в "проверяется"
Постусловия Сотрудник НИС сможет утвердить его или отклонить.
Инициаторы Сотрудник кафедры
Таблица 14. Описание сценария "Утвердить договор"
Цель Утвердить договор.
Предусловия Пользователь находится на странице "договоры". Договор не утвержден.
Основной поток событий - Сотрудник НИС нажимает на кнопку "Утвердить договор" - Статус договора переводится в "Утвержден"
Альтернативный поток событий - Сотрудник НИС нажимает на кнопку "Отклонить договор" - Статус договора переводится в "Редактируется"
Постусловия Договор больше не доступен для редактирования. Договор теперь доступен на странице "учет".
Инициаторы Сотрудник НИС
Цель Отметить, что действия по договору больше не будут производится, а следовательно, больше нет смысла вести его учет.
Предусловия Пользователь находится на странице "Договоры". Пользователь нажимает кнопку "Закрыть договор". Договор должен быть утвержден.
Основной поток событий - Статус договора переводится в "завершен"
Постусловия Договор больше не доступен для ведения учета или редактирования.
Инициаторы Сотрудник кафедры
Работа со списком пользователей
Рисунок 7. Модель сценария "Работа со списком пользователей ",
представленная в нотации ЦМЬ. Таблица 16. Описание сценария "Работа со списком пользователей"
Цель Взаимодействие со списком исполнителей пользователей.
Предусловия Сотрудник НИС нажал на копку в навигационном меню "Пользователи"
Основной поток событий - Система выводит список пользователей. - Пользователь просматривает список пользователей. - Пользователь выбирает одно из действий: утвердить или удалить пользователя.
Постусловия Список исполнителей меняется в соответствии с манипуляциями пользователя.
Инициаторы Сотрудник НИС
Таблица 17. Описание сценария "Работа со списком пользователей "
Цель Взаимодействие со списком исполнителей пользователей.
Предусловия Сотрудник НИС находится на странице "Пользователи". Пользователь нажимает на кнопку "утвердить", напротив пользователя с статусом "не утвержден".
Основной поток событий - Статус выбранного пользователя меняется на "утвержден".
Постусловия Теперь пользователь может войти в систему.
Инициаторы Сотрудник НИС
Таблица 18. Описание сценария "Удалить пользователя"
Цель Удалить исполнителя из списка исполнителей.
Предусловия Пользователь находится на странице "пользователи". Сотрудник НИС нажимает на пиктограмму "крестик" (удалить) на против элемента списка исполнителей.
Основной поток событий - Система выводит сообщение "Вы действительно хотите удалить пользователя XXX?" - Пользователь нажимает "Да".
Альтернативный поток событий Пользователь нажал 'Нет'.
Постусловия Система удалит пользователя из системы.
Инициаторы Сотрудник НИС
Ведение учета
Рисунок 8. Модель сценария "Провестиучет", представленная в
нотации UML.
Цель Взаимодействие со списком исполнителей пользователей.
Предусловия Сотрудник НИС нажал на копку в навигационном меню "Учет"
Основной поток событий - Система выводит список договоров, с полями для заполнения данных необходимых для учета: сумма пополнения, дата пополнения, процент налога, зарплаты, дополнительные расходы. - В меню на странице договоров пользователь может выбрать один из фильтров. - Пользователь заполняет список данных необходимых для учета. - Нажимает кнопку рассчитать, чтобы получить значения: доход, расход, остаток.
Альтернативный поток событий 1 Пользователь получил сообщение об ошибке, т.к. ввел не корректные данные (все введенные данные должны быть числами)
Альтернативный поток событий 2 Пользователь нажал кнопку назад, чтобы вернуть предыдущее значение учета.
Постусловия Список меняется в соответствии с манипуляциями пользователя.
Инициаторы Сотрудник НИС
Эскизный проект системы.
1.1. Статическая структура системы.
-cathedra: string -pass: string
+RegistrationData(cathedra:string, mail:string, pass:string) + getJso n():string
Рисунок 9. Диаграмма классов программной системе в нотации UML.
Так как разработка данной ПС основывается на объектно-ориентированном подходе, большинство диаграмм будут представлены в нотации UML.
На рисунке 9 представлена диаграмма классов. Классы: ButtonView, TextView, GroupView, ListView, FormTextView и ListView, отвечают за отображение графического интерфейса, и логику его обработки. Их объединяет интерфейс IView, реализуя паттерн composer. Есть классы описывающие контейнеры - узлы дерева (GroupView, ListView) остальные классы View, представляют собой листья дерева. Полученная древовидная структура обходится рекурсивно, в следствии чего вызываются методы генерации html кода.
UserManager, отвечает за реализацию логики работы с пользователями. UserManager работает с базой данных, а также совершает
валидацию данных. Для передачи данных пользовательских данных между клиентом и сервером, созданы классы AuthorizationData, UserData, RegistrationData.
AuthorizationData - картеж данных, содержащий в себе данные необходимые для аутентификации и авторизации пользователя.
UserData - данные которые сервер возвращает авторизированному пользователю. В нем содержится общая информация о пользователе.
RegistrationData - картеж данных, содержащий в себе данные необходимые для регистрации нового пользователя.
PhPStamp - библиотека для формирования отчетов в формате .docx.
Остальные классы описывают логику ведения учета документов. Класс Contract - содержит в себе сведения о договоре.
Класс ContractManager - отвечает за работу с базой данных и обработку договорных данных.
Book - содержит данные для проведения учета.
Bookkeeper - класс обрабатывающий учетные данные, также работает с базой данных.
1.2. Описание деятельности системы.
На рисунке 10 представлено графическое описание процесса работы с договорами. Пользователь открывает журнал договоров, далее он выбирает какие действия он собирается произвести над договорами. Пользователь может создать договор. Создавая договор, он заполняет форму для ввода данных договора. Уже созданные договоры можно редактировать и удалять. При редактировании договора, появляется заполненная форма с данными договора, которые пользователь модифицирует. Также пользователь может собирать с помощью фильтров.
работа с договорами
Обновление
т
Список обновлен Выбран фильтор
просмотр списка договоров
— Нажата "удалить"-
уадление договора
—Нажата "создать"—
создание договора
редактирование договора
гО
Рисунок 10. Диаграмма состояний в нотации UML. Процесс "учет ".
-о
Рисунок 11. Диаграмма состояний в нотации ЦЫЬ. Процесс "учет " На рисунке 11 представлено графическое описание процесса учета. Сотрудник НИС открывает страницу учета. На странице выводится заполняемая таблица с значениями для учета. Учет можно отменить. Если учет был отменен, его можно вернуть действием "повторить".
1.3. Состав и формат хранимых данных.
пользователе»
«»♦«Дрв
:
суР0гхвт_к_осхг%50ввтвда
фйо.игпсимяпм
олоси1ог^ ?сагп
¿ата_£оста«лет*я
пополнение
ЩГ*.ПСЛ0ДН(И1»
процеиг.мыога
АОЛйЛНИ *1Л»ЙМ .рвекшы
1»ма_де»-й*ора
уведем тв
вое *м_*я_с ооб.об.остви овив _рвЬ
ятлроа »'в
друпйе.анмиим
право.л* ргдои
аыручна.ат_перед»«*_0аслред
прав аими
другие _ уишам •
двтв.-ч»» аса_£е Ас»* а
дл^а вши. <•«»•« д«ж гшиа
да'в 1СК(а*памма
нжлвндлрмый план
дата_соов«.»«имя
да-а_состаалеии»
сог лои*?мие_о_црме
мхпа* р .со» то* та
дргв_ составлен*«
договори ав_«е«а
в аплт* па,'«кумли
»слов иа_дю _м адбаамя
»слов на_ у ме я аше«м а.оллаты
на_саоааля_»**иаи аг»т»_опя|1га
Рисунок Х15. Концептуальная схема базы данных. Все данные, хранимые системой, будут сохранятся на сервере. Часть данных будет организована с помощь баз данных. Управление и доступ к
базам данных будет осуществляется посредством СУБД MySQL. На рисунке X3 представлена концептуальная схема баз данных (Рисунок x15).
Для передачи данных между сервером и клиентом, будет использован формат данных json, описанный в стандарте RFC 8259. С помощью данного формата будут передаваться авторотационные, регистрационные данные, данные о договоре и пользователе.
Данные для настроек данных о вузе, будут содержаться на сервере, и храниться в xml формате. Пример этого файла:
<?xml version-'1.0"?>
<configs>
<organizationName> Волжский политехнический институт </organizationName> <organizationAddress> ул. Энгельса, 42а </organizationAddress > <director> Фетисов А.В. </director> </configs> Описание тегов:
• Тег configs - корневой тег, хранящий в себе данные настроек. o Тег organizationName - хранит наименование вуза. o Тег organizationAddress - юридический адрес вуза. o Тег director - ФИО ректора вуза.
Использованные источники:
1. ГОСТ 2.119-2013 Единая система конструкторской документации (ЕСКД). Эскизный проект - М.: Стандартинформ, 2015. - С. 9
2. Карпухина, И.А. Критерий оценки сложности программ. / Короткова Н.Н. // Международный студенческий вестник. - 2016. - № 3-1. - С. 114-115
3. Кащенко, Я.В. Исследование предметной области и анализ осуществимости разработки программной системы для учета учебных и научных достижений студента вуза. / Абрамова О.Ф., Рыбанов А.А. // Форум молодых ученых. - 2017. - №6. - С. 892-903
4. Мартин, Ф. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. - 3-е издание - М.: Символ-Плюс, 2018. - С. 192
