Проектирование программного продукта «аис «ассистент»» для ГАПОУ СО «нижнетагильского торгово-экономического колледжа»

 

2.1. Постановка задачи

 

У образовательного учреждения ГАПОУ СО «Нижнетагильский торгово-экономический колледж» появилась необходимость создать программный продукт, который будет воплощать в себе единое информационное поле, в котором можно удовлетворить технологические и информационные потребности работников, студентов, преподавателей, абитуриентов и прочих субъектов образовательного учреждения. В связи с этим, образовательное учреждение поставило цель: создать единую, модульную информационную систему, которая будет удовлетворять потребности всех субъектов образовательного учреждения. Модульность необходима для того, чтобы в случае необходимости, была возможность нарастить функционал информационной системы с минимальными затратами и потерями, а также для того, чтобы модули моги общаться между собой.

 

2.2. Требования к программному продукту

 

При постановке задачи были обусловлены следующие требования к программному продукту:

- модульность информационной системы с целью наращения функционала;

- закрытая регистрация в информационной системе, а также разноуровневый доступ к системе;

- использование рассылки электронной почты для предоставления информации до пользователей;

- возможность загружать файлы в информационную систему с разноуровневым доступом к файлам;

- генерация QR-кодов;

- шифрование данных в базе данных как последний оплот защиты информации пользователей;

- простой доступ к информационной системы через веб-платформу;

- открытое API для написания приложений-форков;

- поддержание обновлений информационной системы на всем жизненном цикле.

 

2.3. Перечень нормативных документов

 

Документация на программное обеспечение – печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие, как пользоваться программным продуктом.

Существует четыре основных типа документации на ПО:

- архитектурная/проектная – обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО:

Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она скорее отвечает на вопрос «почему именно так». Например, в проектном документе программист может описать обоснование того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи как можно будет выполнить улучшения в дальнейшем. Ничего из этого не входит в техническую или пользовательскую документацию, но всё это действительно важно для проекта.

- техническая – документация на код, алгоритмы, интерфейсы, API:

При создании программы, одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый текст, описывающий различные аспекты того, что именно делает код. Такая документация часто включается непосредственно в исходный код или предоставляется вместе с ним. Подобная документация имеет сильно выраженный технический характер и в основном используется для определения и описания API, структур данных и алгоритмов.

Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном коде, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML.

Использование генераторов документации и документирующих комментариев многими программистами признаётся удобным средством, по различным причинам. В частности, при таком подходе документация является частью исходного кода, и одни и те же инструменты могут использоваться для сборки программы и одновременной сборки документации к ней. Это также упрощает поддержку документации в актуальном состоянии.

- пользовательская – руководства для конечных пользователей, администраторов системы и другого персонала:

В отличие от технической документации, сфокусированной на коде и том, как он работает, пользовательская документация описывает лишь то, как использовать программу.

В случае если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.

Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно, чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.

Существует три подхода к организации пользовательской документации. Вводное руководство (англ. tutorial), наиболее полезное для новых пользователей, последовательно проводит по ряду шагов, служащих для выполнения каких-либо типичных задач. Тематический подход, при котором каждая глава руководства посвящена какой-то отдельной теме, больше подходит для совершенствующихся пользователей. В последнем, третьем подходе, команды или задачи организованы в виде алфавитного справочника — часто это хорошо воспринимается продвинутыми пользователями, хорошо знающими, что они ищут. Жалобы пользователей обычно относятся к тому, что документация охватывает только один из этих подходов, и поэтому хорошо подходит лишь для одного класса пользователей.

Во многих случаях разработчики программного продукта ограничивают набор пользовательской документации лишь встроенной системой помощи (англ. online help), содержащей справочную информацию о командах или пунктах меню. Работа по обучению новых пользователей и поддержке совершенствующихся пользователей перекладывается на частных издателей, часто оказывающих значительную помощь разработчикам.

- маркетинговая:

Для многих приложений необходимо располагать рядом с ними рекламные материалы, с тем чтобы заинтересовать людей, обратив их внимание на продукт. Такая форма документации имеет целью:

- подогреть интерес к продукту у потенциальных пользователей;

- информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем, что они получат;

- объяснить положение продукта по сравнению с конкурирующими решениями.

Одна из хороших маркетинговых практик – предоставление слогана – простой запоминающейся фразы, иллюстрирующей то, что мы хотим донести до пользователя, а также характеризующей ощущение, которое создаёт продукт.

Часто бывает так, что коробка продукта и другие маркетинговые материалы дают более ясную картину о возможностях и способах использования программы, чем всё остальное.

 

2.4. Диаграммы в нотации UML с описанием

 

Рис. 1 – схема регистрации информационной системы на новом сервере

 

Рис. 2 – схема авторизации пользователя

 

Рис. 3 – проверка предоставляемого токена

 

Программное обеспечение Ассистент служит для связывания аутентификационных данных пользователей системы с модулями программного обеспечения Ассистент. "Голый" Ассистент содержит в себе минимально необходимый пакет библиотек, устанавливает требования к программному исполнению сервера, принципам обращения к базе данных и объявлениям сущностей системы.

Пользователь – такая сущность, которая содержит в себе идентификационные и аутентификационные данные о конкретном пользователе системы. Идентификационные и аутентификационные данные хранятся в разных таблицах. Аутентификационные данные хранятся в виде дайджеста сообщения, «приправленные солью». Сама «соль» представляет из себя дешифруемое сообщение длиной 256 символов.

Ключ симметричного шифрования генерируется системой при первом запуске.

Вторая таблица – идентификационные данные о пользователе. Все данные зашифрованы симметричным ключом. Минимальный набор данных, хранимых в таблице идентификационных данных пользователей:

1. уникальный идентификатор;

2. фамилия;

3. имя;

4. отчество (при наличии);

5. дата рождения;

6. адрес электронной почты;

7. номер мобильного телефона Российской Федерации.

Пользовательская таблица с аутентификационными данными содержит в себе такой набор данных:

1. уникальный идентификатор;

2. дайджест логина;

3. дайджест пароля;

4. зашифрованная «соль»;

5. зашифрованный массив (JSON-данные) уровней доступа.

 

В системе реализована таблица, которая содержит в себе данные о подключенных модулях к информационной системе. Таблица содержит в себе следующие данные:

1. уникальный идентификатор;

2. наименование модуля на русском языке;

3. наименование модуля на латинице;

4. JSON-объект, хранящий в себе пункты для меню;

5. относительный путь модуля с начала домена. Например, запись «ex» гласит о том, что модуль будет доступен по адресу https://example.com/modules/ex

6. булевый тип, свидетельствующий о публичном доступе модуля. Если стоит ложь, то система доступна только администраторам информационной системы;

7. порядковый номер версии модуля.

При старте системы, она будет доступна только для адресного пространства loopback. Изменение этого параметра возможно при изменении конфигурационного файла модуля «First-start».

На рисунке 1 представлен процесс регистрации системы. Регистрация информационной системы: для полноценной работы информационной системы необходимо, чтобы система имела возможность отправлять письма на электронную почту, подключаться к базе данных, регистрировать и делегировать пользователей, добавлять модули информационной системы. По умолчанию, конфигурационные файлы не существуют. Они создаются в процессе регистрации.

Авторизация пользователей происходит по стандартной схеме: пользователь вводит пару логин/пароль, система проверяет эти данные на корректность или существование и продолжает работать по той схеме, которая зависит от авторизации пользователя (см. рисунок 2). Процедура выхода из системы выглядит таким образом: токен очищается из записи пользователя.

Проверка токена на актуальность: когда пользователь авторизовался, ему предоставляется токен. Если токен, с которым идентифицируется пользователь не существует, то токен удаляется у пользователя (см. рисунок 3).

 

2.5. Прототип интерфейса

 

На рисунке 6 представлена главная страница информационной системы. На ней пользователи передвигаются по элементам управления информационной системы.

На рисунке 7 представлена страница входа в информационную систему. На этой странице пользователь совершает вход в информационную систему со своими аутентификационными данными. Если пользователь вводит некорректные данные, то система показывает уведомления, представленные на рисунке ниже.

 

Рис. 4 – Уведомления информационной системы

 

Если пользователь ввел корректные аутентификационные данные, то система генерирует пользовательский уникальный токен, отдает пользователю и переводит его на главную страницу системы, но уже в авторизованном режиме (см. рисунок 8).

В информационной системе реализован личный кабинет пользователя, где ему предоставляется возможность просмотреть свои персональные данные (см. рисунок 9), а также изменить свои аутентификационные данные (см. рисунок 10, рисунок 11).

Когда пользователь захочет изменить свой логин, то ему нужно перейти на форму изменения логина (см. рисунок 10). На этой форме ему нужно ввести логин и продублировать этот логин в соседнем поле. Если пользователь ошибся, то система предупредит, что введённые логины не совпадают. Если же в системе уже имеется пользователь с таким логином, то система не даст пользователю присвоить уже имеющийся логин.

Изменение пароля также входит в базовый функционал системы. Ограничение в пароле – не менее восьми символов (см. рисунок 11).

Также, администраторам системы доступен режим «Администраторской панели» в личном кабинете. В этой панели администраторы могут:

- регистрировать новых пользователей (см. рисунок 13);

- редактировать данные у уже имеющихся пользователей;

- изменять аутентификационные данные у уже имеющихся пользователей;

- удалять уже имеющихся пользователей (см. рисунок 12);

- изменять конфигурацию подключения к серверу баз данных (MySQL) (см. рисунок 14);

- изменять конфигурацию подключения к сервису рассылки электронных писем (SMTP-протокол) (см. рисунок 14).

 

2.6. Вывод

 

В ходе разработки интерфейса были выработаны концепции стилистики модулей информационной системы АИС «Ассистент». При создании интерфейса пользователя использовался Bootstrap Studio. Для компоновки интерфейса пользователя используется фреймворк Boostrap. Цветовая гамма информационной системы перенимает цветовую гамму стандартной цветовой схемы Bootstrap (см. рисунок 5).

Рис. 5 – цветовая гамма Bootstrap

 

Использование фреймворка Bootstrap позволяет упростить разработку пользовательского интерфейса, т.к. Bootstrap берет на себя отрисовывание элементов во всех современных браузерах.