Исследование предметной области и разработка эскизного проекта автоматизированной программной системы для автоматизации хоздоговорной деятельности Волжского политехнического института
Автор: Зорин Д.Ю., Абрамова О.Ф.
Журнал: Форум молодых ученых @forum-nauka
Статья в выпуске: 5-1 (21), 2018 года.
Бесплатный доступ
В статье приводится анализ предметной области, исследование бизнес-процессов научно-исследовательского сектора Волжского политехнического института. Также приводится предложение по дальнейшей реализации соответствующей системы.
Моделирование бизнес-процессов, хоздоговорная деятельность, эскизный проект, программная система, моделирование uml
Короткий адрес: https://sciup.org/140282364
IDR: 140282364
Текст научной статьи Исследование предметной области и разработка эскизного проекта автоматизированной программной системы для автоматизации хоздоговорной деятельности Волжского политехнического института
-
1. Исследование предметной области
Рассмотрим организацию хоздоговорной деятельности волжского политехнического института, а также бизнес-процессы, протекающие в нем.
Для построения моделей, описывающих бизнес-процессы, необходимо сначала выделить структуру предприятия, основные документы участвующие в автоматизируемых бизнес-процессах, а также нормативные документы их регулирующие.
В ходе исследования предметной области, были выделена кадровая структура, представленная в рисунке 1.

Рисунок 1. Модель кадровой структуры предприятия.
Ректор института является его представителем, а также руководит всеми его процессами.
Отдел НИС (Научно-исследовательский сектор) – определяет порядок планирования и заключения договоров, организацию и проведения фундаментальных исследований, поисковых и прикладных работ (НИР), также представляет интересы заказчика во время исследовательской деятельности.
Руководитель НИС занимается управлением в рамках деятельности отдела, а также является его представителем.
Сотрудник НИС – абстрактная сущность, объединяющая в своем понятии всех сотрудников НИС. Выполняет учет документации и контроль документации.
Юридический отдел выполняет работу по разработке документов правового характера, а также оказывает помощь всем структурным подразделениям в оформлении документов. Обеспечивает соблюдение правовых норм в рамках деятельности института.
Отдел кафедра абстрактная сущность, объединяющая в себе все кафедры института. В рамках хоздоговорной деятельности, занимается имплементацией договора.
Заведующий кафедрой занимается управлением в рамках деятельности отдела, а также является его представителем.
Сотрудник кафедры – абстрактная сущность, объединяющая в своем понятии всех сотрудников кафедры. Выполняет работы, оговоренные договором. (Справедливо для хоздоговорной деятельности института)
Заказчик – некоторый абстрактный заказчик. Заказчиком может выступать как сам институт, так и некоторое стороннее предприятие. Чаще всего частью института не является, поэтому расположен обособленно от остальных участников хоздоговорной деятельности.
Теперь опишем основные документы входящие в документооборот хоздоговорной деятельности:
-
• ДОГОВОР на создание (передачу) научно-технической продукции;
-
• ТЕХНИЧЕСКОЕ ЗАДАНИЕ;
-
• КАЛЕНДАРНЫЙ ПЛАН;
-
• ПРОТОКОЛ соглашения о договорной цене на научно-техническую продукцию;
-
• СМЕТА РАСХОДОВ на выполнение научно-исследовательской работы
-
• АКТ сдачи-приемки выполненных работ по договору
-
• ДОГОВОР подряда на выполнение научно-исследовательских, опытно-конструкторских работ
-
• Служебная записка
-
• АКТ сдачи-приемки результатов научно-исследовательских работ
-
• ДОГОВОР б/н на выполнение научно-исследовательских работ, оказание услуг по договору
-
• АКТ о приеме научно-исследовательских работ (услуг)
Нормативные документы, регулирующие бизнес-процессы предметной области:
-
• Федеральный закон "Об обязательном экземпляре документов" от 29.12.1994 N 77-ФЗ
-
• Федеральный закон "Об образовании в Российской Федерации" от 29.12.2012 N 273-ФЗ
-
• ПРИКАЗ Минобрнауки РФ от 21.10.2013 N 1168 "ОБ УТВЕРЖДЕНИИ ФОРМ НАПРАВЛЕНИЯ СВЕДЕНИЙ О
НАУЧНО - ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО -КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТАХ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ В ЦЕЛЯХ ИХ УЧЕТА В ЕДИНОЙ ГОСУДАРСТВЕННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ УЧЕТА НАУЧНО - ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ И ТРЕБОВАНИЙ К ЗАПОЛНЕНИЮ УКАЗАННЫХ ФОРМ, А ТАКЖЕ ПОРЯДКА ПОДТВЕРЖДЕНИЯ ГЛАВНЫМИ РАСПОРЯДИТЕЛЯМИ БЮДЖЕТНЫХ СРЕДСТВ, ОСУЩЕСТВЛЯЮЩИМИ ФИНАНСОВОЕ ОБЕСПЕЧЕНИЕ НАУЧНО -
ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ И ВЫПОЛНЯЮЩИМИ ФУНКЦИИ ЗАКАЗЧИКА ТАКИХ РАБОТ, СООТВЕТСТВИЯ СВЕДЕНИЙ ОБ УКАЗАННЫХ РАБОТАХ, ВНЕСЕННЫХ В ЕДИНУЮ ГОСУДАРСТВЕННУЮ ИНФОРМАЦИОННУЮ СИСТЕМУ УЧЕТА НАУЧНО -ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО - КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ, УСЛОВИЯМ ГОСУДАРСТВЕННЫХ КОНТРАКТОВ НА ВЫПОЛНЕНИЕ НАУЧНО - ИССЛЕДОВАТЕЛЬСКИХ, ОПЫТНО -КОНСТРУКТОРСКИХ И ТЕХНОЛОГИЧЕСКИХ РАБОТ ГРАЖДАНСКОГО НАЗНАЧЕНИЯ"
Ф.З. «Об обязательном экземпляре документов» от29декабря 1994 г. № 77-ФЗ (ред. от 05.05.2014)
Ф.З. N 273ФЗ Федеральный закон
ПРИКАЗ Минобрнауки РФ от 21.10.2013 N 1168
Тема проекта
Хоздоговорная деятельность
Акт приема передачи
Информация об участниках
A0
Отчетная научно-техническая документация
Рисунок 2. Обобщенная модель бизнес-процессов, представленная в нотации
IDEF0
Объединим всю найденную нами информацию, о предметной области в модели нотации IDEF0. Соответствующие модели представлены ниже в рисунках 2,3.4
Ф.З. «Об обязательном

Исполнитель НИС
Рисунок 3. Модель бизнес-процессов, в нотации IDEF0. Декомпозиция процесса “Хоздоговорная деятельность”.
Ф.З. «Об обязательном экземпляре документов» от 29 декабря 1994 г. № 77-

Рисунок 4. Модель бизнес-процессов, в нотации IDEF0. Декомпозиция процесса “Сформировать пакет документов”.
Таблица 1. Описание бизнес-процессов.
Идентификатор, название бизнес-процесса |
Описание |
Входные документы |
Выходные документы |
A0) Хоздоговорная деятельность |
Вузы заключают хозяйственные договоры с заказчиками на выполнение за счет их средств фундаментальных, поисковых и прикладных исследований, опытноконструкторских и технологических разработок в интересах отраслей народного х-ва, производственных (научнопроизводственных) объединений, предпр. |
|
|
B1) Сформировать пакет документов. |
Формируется пакет документов необходимый для начала хоздоговорной деятельности. |
|
|
B2) Выполнить этап работ. |
Исполнитель выполняет очередной этап работ согласно договору. |
|
1. Смета затрат. |
B3) Провести учет. |
Проводится учет полученной в результате выполнения этапа работ документации. Рассчитывается доход по договору. |
1. Смета затрат. |
1. Акт приема сдачи работ. |
С1) Сформировать пакет документов. |
Оговариваются цель исследования, этапы, стоимость, сроки, исполнители. Заполняется подготовительная документация. |
|
|
С2) Заключить договор, утвердить документацию. |
Сотрудник НИС, совместно с юристом проверяет полученный пакет документов. Затем происходит подписание договоров, и остальных документов. |
|
|
После исследования модели и пожеланий заказчика, мной были выделены следующие процессы, для их последующей автоматизации:
-
• Формирование пакета документов;
-
• Учет документации;
-
2. Функциональные требования к информационной системе.

Рисунок 5. Модель вариантов использования, представленная в нотации
UML.
Описание сценариев:
Регистрация
Таблица 2. Описание сценария “Регистрация”
Цель |
Создать аутентификационные данные студента для их для доступа к функционалу системы |
Предусловия |
Пользователь открыл домашнюю страницу системы |
и нажал на кнопку “регистрация” |
|
Основной поток событий |
“зарегистрироваться” |
Альтернативный поток событий |
|
Постусловия |
Пользователь ожидает подтверждения своей учетной записи |
Инициаторы |
Сотрудник кафедры |
Аутентификация
Таблица 3. Описание сценария “Аутентификация”
Цель |
Подтвердить личность пользователя для доступа к функционалу системы. |
Предусловия |
Пользователь открыл домашнюю страницу системы и нажал на кнопку “войти” |
Основной поток событий |
|
Альтернативный поток событий 1 |
- Пользователь получает сообщение о том, что его учетная запись все еще не подтверждена. |
Альтернативный поток событий 2 |
- Пользователь получил сообщение, о том, что ввел неверные данные. (Такого пользователя не существует) |
Альтернативный поток событий 3 |
- Пользователь закрыл страницу. |
Постусловия |
Пользователь попадает на страницу со списком его договоров. |
Инициаторы |
Сотрудник кафедры, Сотрудник НИС |
Настройка информации о вузе
Таблица 4. Описание сценария “Настройка информации о вузе”
Цель |
Изменить информацию о вузе, которая в последствии будет подставляться в шаблон документов. |
Предусловия |
Сотрудник НИС нажал кнопку в навигационном меню “настроить”. |
Основной поток событий |
|
Альтернативный поток событий |
- Пользователь ввел некорректные данные (оставил поля пустыми или данные содержали не допустимые символы. Название и адрес могут содержать: буквы русского и латинского алфавита, кавычки, цифры, знаки препинания. ФИО может содержать только |
буквы русского алфавита и дефис). - Пользователь закрыл страницу. |
|
Постусловия |
Данные для заполнения шаблона договоров меняются. |
Инициаторы |
Сотрудник НИС |
Работа со списком исполнителей

Рисунок 5. Модель сценария “Работа со списком исполнителей”, представленная в нотации UML.
Таблица 4. Описание сценария “Работа со списком исполнителей”
Цель |
Взаимодействие со списком исполнителей кафедры. |
Предусловия |
Сотрудник кафедры нажал на копку в навигационном меню “Исполнители” |
Основной поток событий |
- Система выводит список исполнителей. |
|
|
Постусловия |
Список исполнителей меняется в соответствии с манипуляциями пользователя. |
Инициаторы |
Сотрудник кафедры |
Таблица 5. Описание сценария “Добавить исполнителя”
Цель |
Добавить в систему новое представления для исполнителя. |
Предусловия |
Пользователь находится на странице “исполнители” |
Основной поток событий |
|
Альтернативный поток событий |
Пользователь ввел некорректные данные (оставил поля пустыми или данные содержали не допустимые символы. ФИО и должность могут содержать только буквы русского алфавита и дефис). |
Постусловия |
В список добавляется новый исполнитель. |
Инициаторы |
Сотрудник кафедры |
Таблица 6. Описание сценария “Удалить исполнителя”
Цель |
Удалить исполнителя из списка исполнителей. |
Предусловия |
Пользователь находится на странице “исполнители”. |
Пользователь нажимает на пиктограмму “крестик”(удалить) на против элемента списка исполнителей. |
|
Основной поток событий |
- Система выводит сообщение “Вы действительно хотите удалить исполнителя XXX?” - Пользователь нажимает “Да”. |
Альтернативный поток событий |
Пользователь нажал ‘Нет’. |
Постусловия |
Система удалит исполнителя из списка исполнителей. |
Инициаторы |
Сотрудник кафедры |
Таблица 7. Описание сценария “Редактировать исполнителя”
Цель |
Изменить данные представления исполнителя. |
Предусловия |
Пользователь находится на странице “исполнители”. Пользователь нажал на кнопку редактировать напротив элемента списка исполнителей. |
Основной поток событий |
|
Альтернативный поток событий |
Пользователь ввел некорректные данные (оставил поля пустыми или данные содержали не допустимые символы. ФИО и должность могут содержать только буквы русского алфавита и дефис). |
Постусловия |
Система изменит информацию об исполнителе. |
Инициаторы |
Сотрудник кафедры |
Работа со списком договоров

Рисунок 6. Модель сценария “Работа со списком договоров”, представленная в нотации UML.
Таблица 8. Описание сценария “Работа со списком договоров”
Цель |
Взаимодействие со списком исполнителей кафедры. |
Предусловия |
Пользователь нажал на копку в навигационном меню “Договоры” |
Основной поток событий |
документов. |
Альтернативный поток событий |
|
Постусловия |
Список договоров меняется в соответствии с манипуляциями пользователя. |
Инициаторы |
Сотрудник кафедры, сотрудник НИС |
Таблица 9. Описание сценария “Добавить договор”
Цель |
Добавить в систему новое представление для договора. |
Предусловия |
Пользователь находится на странице “Договоры” |
Основной поток событий |
|
год, условия надбавки, размер надбавки, условия уменьшения оплаты, размер уменьшения надбавки. Пользователь может не вводить некоторые данные, оставив это на потом. Он обязан ввести тему договора.
|
|
Постусловия |
В список добавляется новый договор. |
Инициаторы |
Сотрудник кафедры |
Таблица 10. Описание сценария “Удалить договор”
Цель |
Удалить договор из списка договоров. |
Предусловия |
Пользователь находится на странице “Договоры”. Пользователь нажимает на пиктограмму “крестик” (удалить) на против элемента списка договоров. Договор не должен иметь статус “Утвержден”. |
Основной поток событий |
- Система выводит сообщение “Вы действительно хотите удалить договор номер №XXX?” - Пользователь нажимает “Да”. |
Альтернативный поток событий |
Пользователь нажал ‘Нет’. |
Постусловия |
Система удалит договор из списка договоров. |
Инициаторы |
Сотрудник кафедры |
Таблица 11. Описание сценария “Редактировать договор”
Цель |
Изменить данные представления договора. |
Предусловия |
Пользователь находится на странице “договоры”. Пользователь нажал на кнопку редактировать напротив элемента списка договоров. Договор не должен иметь статус “Утвержден” или “Завершен”. |
Основной поток событий |
|
Постусловия |
Система изменит информацию об договоре. |
Инициаторы |
Сотрудник кафедры |
Таблица 12. Описание сценария “Скачать шаблоны документов”
Цель |
Сформировать шаблоны документов. |
Предусловия |
Пользователь находится на странице “договоры”. Пользователь нажал на кнопку скачать шаблоны документов. |
Основной поток событий |
- Пользователь получает архив с заполненными шаблонами документов. |
Инициаторы |
Сотрудник кафедры |
Таблица 13. Описание сценария “Отправить на проверку”
Цель |
Отправить договор на проверку, чтобы сотрудник НИС мог утвердить его или отправить для исправления. |
Предусловия |
Пользователь находится на странице “договоры”. Пользователь нажимает на кнопку “проверить” |
Основной поток событий |
- Статус договора переводится в “проверяется” |
Постусловия |
Сотрудник НИС сможет утвердить его или отклонить. |
Инициаторы |
Сотрудник кафедры |
Таблица 14. Описание сценария “Утвердить договор”
Цель |
Утвердить договор. |
Предусловия |
Пользователь находится на странице “договоры”. Договор не утвержден. |
Основной поток событий |
|
Альтернативный поток событий |
|
Постусловия |
Договор больше не доступен для редактирования. Договор теперь доступен на странице “учет”. |
Инициаторы |
Сотрудник НИС |
Таблица 15. Описание сценария “Закрыть договор”
Цель |
Отметить, что действия по договору больше не будут производится, а следовательно, больше нет смысла вести его учет. |
Предусловия |
Пользователь находится на странице “Договоры”. Пользователь нажимает кнопку “Закрыть договор”. Договор должен быть утвержден. |
Основной поток событий |
- Статус договора переводится в “завершен” |
Постусловия |
Договор больше не доступен для ведения учета или редактирования. |
Инициаторы |
Сотрудник кафедры |
Работа со списком пользователей

Рисунок 7. Модель сценария “Работа со списком пользователей”, представленная в нотации UML.
Таблица 16. Описание сценария “Работа со списком пользователей”
Цель |
Взаимодействие со списком исполнителей пользователей. |
Предусловия |
Сотрудник НИС нажал на копку в навигационном меню “Пользователи” |
Основной поток событий |
|
Постусловия |
Список исполнителей меняется в соответствии с манипуляциями пользователя. |
Инициаторы |
Сотрудник НИС |
Таблица 17. Описание сценария “Работа со списком пользователей”
Цель |
Взаимодействие со списком исполнителей |
пользователей. |
|
Предусловия |
Сотрудник НИС находится на странице “Пользователи”. Пользователь нажимает на кнопку “утвердить”, напротив пользователя с статусом “не утвержден”. |
Основной поток событий |
- Статус выбранного пользователя меняется на “утвержден”. |
Постусловия |
Теперь пользователь может войти в систему. |
Инициаторы |
Сотрудник НИС |
Таблица 18. Описание сценария “Удалить пользователя”
Цель |
Удалить исполнителя из списка исполнителей. |
Предусловия |
Пользователь находится на странице “пользователи”. Сотрудник НИС нажимает на пиктограмму “крестик” (удалить) на против элемента списка исполнителей. |
Основной поток событий |
- Система выводит сообщение “Вы действительно хотите удалить пользователя XXX?” - Пользователь нажимает “Да”. |
Альтернативный поток событий |
Пользователь нажал ‘Нет’. |
Постусловия |
Система удалит пользователя из системы. |
Инициаторы |
Сотрудник НИС |
Ведение учета

Рисунок 8. Модель сценария “Провести учет”, представленная в нотации
UML.
Таблица 19. Описание сценария “Провести учет”
Цель |
Взаимодействие со списком исполнителей пользователей. |
Предусловия |
Сотрудник НИС нажал на копку в навигационном меню “Учет” |
Основной поток событий |
необходимых для учета.
|
значения: доход, расход, остаток. |
|
Альтернативный поток событий 1 |
Пользователь получил сообщение об ошибке, т.к. ввел не корректные данные (все введенные данные должны быть числами) |
Альтернативный поток событий 2 |
Пользователь нажал кнопку назад, чтобы вернуть предыдущее значение учета. |
Постусловия |
Список меняется в соответствии с манипуляциями пользователя. |
Инициаторы |
Сотрудник НИС |
-
1. Эскизный проект системы.
-
1.1. Статическая структура системы.
Executor
Contract
contractManager
Сторонняя библиотека для формирования документов PhP
-fio: string
-
- post: string
-
- role: string
+Contract(fio:string, post:string, role:string)
+Contract(fio:string, post:string)
+getFio():string
+getPost():string
+getRole():date
ButtonView
PHPStamp
WordDocument
Templator
-
- id: string
-
-them: string
-startDate: date
-endDate: date
-cathedra: string
-executors: Executor[*]
+Contract(id: i nt, them: string, startDate: string, customer:string, executors: Executor[*], cathedra: string)
+getThem():string
+getId():string
+getStartDate():date
+getEndDate():date
+getCathedra():string +getCustomer():string
+addContract(contract:Contract)
+getContracts(filters: string[*]):Contract +deleteContract(contract:Contract)
Bookkeeper
-getLastBook(contract:Contract):Book
-getBooks(contract:Contract):Book[*]
-getBooks(contract:Contract):Book[*]
-getBooks(filters:string[*]):Book[*]
-calculate(books:Book[*]):float
filterString -ассоциативный
массив
filterString -ассоциативный массив
+id:sting
+name:sting
+drawView()
+getId()
+setListner(event:string, listner)
+removeListner(event:string, listner)
+setValue()
+setName(name:string)
+getValue()
FormTextFieldView
id:sting name:sting +drawView() +getId():string +setValue(text:string) +setName(name:string) +getValue():string
CheckBoxView
id:sting
name:sting
+setName(name:string)
+getValue():bool
+setValue(value:bool)
+getId()
+drawView()
Book
TextView
-views: IView
-size: int
+TextView(value:string)
+drawView()
+setValue(value:string) +getValue():string
drawView()
<<Интерфейс>>
IView
listView
GroupView
-views: IView[*]
-border: int
-color: int
-children: IView[*]
+drawView()
+addChild(child: IView)
-views: IView[*]
+addElements(elements:IListElement)
+deleteElement(id: int)
+getElement(id:int):IListElement
+clear()
+drawView()
-balancePrev:float
-addmissionDate:date -addmission:float
-taxPercent:float -accrualPercent:float -pay:float
-otherExpenses:float -expenses:float
+getAddmissionDate():date +getBalance():float
+getBalancePrev():float +getAdmissionDate():date +getTaxPercent():float +getTax():float
+getAccrualPercent():float +getAccrual():float
+getPay():float
+getOtherExpenses:float
-getExpenses():float
+setAddmissionDate(value:date) +setBalancePrev(value:float) +setAdmissionDate(value:date) +setAccrualPercent(value:float) +setTaxPercent(value:float) +setPay(value:float)
+setOtherExpenses(value:float) +calculate()
-
-
UserManager
+createUser(regData:RegisrtarionData)
+login(authData:AuthorizationData):bool
+logout():bool
+getUser():UserData
+isAuthorized(): bool
AuthorizetionData
-
- mail: string
-
- pass: string
+RegistrationData(mail:string, pass:string)
+getJson():string
UserData
-cathedra: string
-mail: string
+UserData(cathedra:string, mail:string)
+getCathedra():string
+getMail():string
RegistrationData
-cathedra: string
-
- mail: string
-
- pass: string
+RegistrationData(cathedra:string, mail:string, pass:string)
+getJson():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. Диаграмма состояний в нотации UML. Процесс “учет”

На рисунке 11 представлено графическое описание процесса учета. Сотрудник НИС открывает страницу учета. На странице выводится заполняемая таблица с значениями для учета. Учет можно отменить. Если учет был отменен, его можно вернуть действием “повторить”.
-
1.3. Состав и формат хранимых данных.

Рисунок X15. Концептуальная схема базы данных.
Все данные, хранимые системой, будут сохранятся на сервере. Часть данных будет организована с помощь баз данных. Управление и доступ к базам данных будет осуществляется посредством СУБД MySQL. На рисунке X3 представлена концептуальная схема баз данных (Рисунок x15).
Для передачи данных между сервером и клиентом, будет использован формат данных json, описанный в стандарте RFC 8259. С помощью данного формата будут передаваться авторотационные, регистрационные данные, данные о договоре и пользователе.
Данные для настроек данных о вузе, будут содержаться на сервере, и храниться в xml формате. Пример этого файла:
Волжский политехнический институт
Фетисов A.В.
Описание тегов:
-
• Тег configs – корневой тег, хранящий в себе данные настроек. o Тег organizationName – хранит наименование вуза.
o Тег organizationAddress – юридический адрес вуза.
o Тег director – ФИО ректора вуза.
Список литературы Исследование предметной области и разработка эскизного проекта автоматизированной программной системы для автоматизации хоздоговорной деятельности Волжского политехнического института
- ГОСТ 2.119-2013 Единая система конструкторской документации (ЕСКД). Эскизный проект - М.: Стандартинформ, 2015. - С. 9
- Карпухина, И.А. Критерий оценки сложности программ. / Короткова Н.Н. // Международный студенческий вестник. - 2016. - № 3-1. - С. 114-115
- Кащенко, Я.В. Исследование предметной области и анализ осуществимости разработки программной системы для учета учебных и научных достижений студента вуза. / Абрамова О.Ф., Рыбанов А.А. // Форум молодых ученых. - 2017. - №6. - С. 892-903
- Мартин, Ф. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. - 3-е издание - М.: Символ-Плюс, 2018. - С. 192