2.3.1 Навигационная структура веб-интерфейса
Интернет-портал системы реализован в виде одностраничного приложения (англ. Single Page Application). Одностраничное приложение - это веб-приложение, использующее единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML, CSS, JavaScript посредством асинхронного обмена данными с сервером.
Условно интерфейс системы разделен на следующие блоки:
- страница входа в систему;
- страница списка заявок на сертификацию ПО;
Рисунок 8 – ER-диаграмма физической модели базы данных
- страница списка пользователей;
- страница списка видов испытаний и закрепленных экспертов;
- страница формирования отчетов;
- страница личного кабинета пользователя;
- модальные экранные формы редактирования данных.
Навигационная структура веб-интерфейса системы приведена на рисунке 9. Стрелками показаны возможные направления переходов между компонентами интерфейса.
| Форма входа в систему |
| Основная страница |
| Страница «Заявки на сертификац- -ию ПО» |
| Страница «Виды испытаний» |
| Страница «Пользователи» |
| Страница «Отчеты» |
| Страница «Личный кабинет» |
| Форма ввода параметров отчета |
| Форма формирован- -ия и редактирова- -ния заявки |
| Форма редактирования видов испытаний |
| Форма редактирования пользователя |
Рисунок 9 – Навигационная структура веб-интерфейса
2.3.2 Структура разметки интерфейса
Визуально интернет-портал системы оформлен в виде экранной формы-контейнера, включающей в себя следующие секции:
- область заголовка;
- панель переключения вкладок страниц;
- область данных страницы.
Структура разметки интерфейса основной экранной формы интернет-портала приведена на рисунке 10.
Область заголовка включает в себя элемент – название информационной системы.
Панель переключения вкладок страниц содержит в себе кнопки вкладок:
- заявки на сертификацию ПО;
| Область заголовка |
| Панель переключения вкладок |
| Область данных |
Рисунок 10 – Структура разметки основной экранной формы
- виды испытаний;
- пользователи;
- отчеты;
- личный кабинет.
Содержимое области данных зависит от выбранной вкладки.
Все области данных имеют однотипное шаблонное оформление и могут включать в себя следующие секции:
- верхняя панель инструментов;
- секция основного содержимого страницы;
- панель инструментов «подвала»;
- панель фильтрации данных.
Структура разметки областей данных приведена на рисунке 11.
Страницы вкладок «Заявки на сертификацию ПО», «Виды испытаний», «Пользователи» включают в себя следующие секции:
- панель фильтрации;
- верхняя панель инструментов;
- секция основного содержимого;
- панель инструментов «подвала».
Страницы вкладок «Отчеты» и «Личный кабинет» состоят из единственной секции - основного содержимого.
| Область заголовка |
| Панель переключения вкладок |
| Панель фильтрации |
| Верхняя панель инструментов |
| Панель инструментов «подвала» |
| Секция основного содержимого страницы |
Рисунок 11 – Структура разметки областей данных
Разработка сайта
2.4.1 Программная архитектура сайта
Программная архитектура интернет-сайта построена в соответствии с паттерном MVC (Model-View-Controller). Данная архитектура реализует принцип, при котором модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента. Модификация одного из компонентов оказывает минимальное влияние на остальные. Иллюстрация архитектуры MVC приведена на рисунке 12.
Рисунок 12 – Иллюстрация архитектуры MVC
Модель предоставляет:
- данные;
- методы работы данными;
- ограничения, накладываемые на данные;
- контроль целостности данных.
Модель не содержит информации, как данные можно визуализировать.
В разработанном программном продукте используется активная модель MVC. В данном случае модель - это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика приложения.
Представление отвечает за отображение информации (визуализацию). В качестве представления выступает форма (окно) с пользовательскими элементами ввода-вывода данных.
Контроллер обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.
Перечень реализованных моделей соответствует списку сущностей логической модели базы данных.
Перечень реализованных контроллеров соответствует списку экранных форм интернет-сайта, т.к. каждой экранной форме ставится в соответствие один контроллер.
Перечень представлений определяется структурой экранных форм. Для каждой экранной формы реализовано как минимум одно представление. Сложные экранные формы, содержащие несколько секций, состоят из главного представления и нескольких частичных (partial-view).
2.4.2 Реализация базы данных
База данных реализована в СУБД Microsoft SQL Server Express 2014. Структура базы данных реализована в соответствии с ранее разработанной физической моделью. Создание объектов базы данных выполнено с помощью автоматически сгенерированного SQL-скрипта, сформированного с помощью инструмента ERWin DataModeler на основе физической модели.
Ниже приведены некоторые примеры скриптов, описывающие физическую структуру таблиц.
Таблица для хранения сущности «Заявка на сертификацию ПО» с первичным ключом создана с помощью следующего SQL-скрипта:
CREATE TABLE [dbo].[CertOrder](
[CertOrderId] [int] IDENTITY(1,1) NOT NULL,
[CertOrderDate] [datetime] NOT NULL,
[Author_UserId] [int] NULL,
[OrderState_OrderStateId] [int] NOT NULL,
[AdministratorComment] [nvarchar](4000) NULL,
[ProgramName] [nvarchar](255) NULL,
[ProgramType_ProgramTypeId] [int] NOT NULL,
[UserOrgName] [nvarchar](255) NOT NULL,
[UserOrgAddress] [nvarchar](255) NOT NULL,
[UserOrgPhone] [nvarchar](255) NOT NULL,
[UserOrgInn] [nvarchar](255) NULL,
[UserOrgKpp] [nvarchar](255) NULL,
PRIMARY KEY CLUSTERED
(
[CertOrderId] ASC
)
Все остальные таблицы для хранения сущностей создавались по аналогии, каждая со своими атрибутами в соответствии с разработанной физической моделью базы данных.
Ограничение целостности данных по внешним ключам реализовано на уровне приложения.
Для ограничения ссылочной целостности данных, в базе данных созданы внешние ключи. Шаблоны скриптов для создания внешних ключей таблицы CertOrder приведены ниже:
ALTER TABLE [dbo].[CertOrder] WITH CHECK ADD FOREIGN KEY([Author_UserId])
REFERENCES [dbo].[User] ([UserId])
ALTER TABLE [dbo].[CertOrder] WITH CHECK ADD FOREIGN KEY([ProgramType_ProgramTypeId])
REFERENCES [dbo].[ProgramType] ([ProgramTypeID])
ALTER TABLE [dbo].[CertOrder] WITH CHECK ADD FOREIGN KEY([OrderState_OrderStateId])
REFERENCES [dbo].[OrderState] ([OrderStateId])
Все остальные таблицы для хранения сущностей создавались по аналогии, каждая со своими атрибутами в соответствии с разработанной физической моделью базы данных.
Состав и структура всех таблиц соответствует структуре разработанной ранее физической модели базы данных.
2.4.3 Реализация моделей данных
В соответствии с подходами, принятыми в архитектуре MVC, работа с данными сущностей и реализация бизнес-процессов реализована в классах моделей. Каждая модель реализована в виде класса, наследуемого от Object.
Большинство моделей, представляющих сущности данных, имеет следующие методы:
- CreateNew(): инициализация нового экземпляра сущности;
- SelectById(): получение существующего экземпляра сущности из базы данных;
- SelectAll(): получение всех существующих экземпляров сущности из базы данных;
- SelectByFilter(): получение списка существующих экземпляров сущности из базы данных по заданному критерию фильтрации;
- SaveToDb(): сохранение экземпляра сущности в базе данных;
- DeleteFromDb(): удаление экземпляра сущности из базы данных;
- CheckCanDelete(): проверка возможности удаления экземпляра сущности из базы данных на уровне контроля целостности данных и правил бизнес-логики приложения.
Кроме перечисленных методов, классы моделей имеют собственные методы и свойства, обеспечивающие реализацию бизнес-логики приложения.
2.4.4 Реализация представлений веб-форм
Перечень реализованных представлений определен структурой экранных форм. Для каждой экранной формы реализовано как минимум одно представление. Сложные экранные формы, содержащие несколько секций, состоят из нескольких вложенных представлений, сформированных по следующим правилам:
- основное представление формы содержит только ключевые структурные элементы: заголовок, вкладки, кнопки и др.;
- именование объектов внутри основного представления начинается с префикса имени страницы данного представления;
- основное представление включает в себя ссылки на дочерние частичные представления (partial view);
- именование объектов внутри дочерних представлений начинается с префикса, состоящего из: имени страницы родительского представления + «_» + имя страницы текущего частичного представления.
Для реализации структурных элементов разметки форм, элементов ввода-вывода данных и управляющих элементов, в разработанном интернет-сайте использован JavaScript-фреймворк Sencha ExtJS. В качестве объектно-ориентированной надстройки над JavaScript-фреймворком использованы библиотеки Ext.NET.
Для реализации структурных элементов разметки веб-форм использованы следующие элементы управления Ext.NET:
- Viewport: контейнер, обеспечивающий использование всего пространства страницы веб-браузера с автоматическим масштабированием;
- FormPanel: контейнер, обеспечивающий размещение элементов ввода-вывода данных и передачи их значений на сервер;
- Window: контейнер диалогового окна.
- TabPanel: контейнер переключаемых вкладок.
Ввод-вывод данных в представлениях веб-форм реализован с автоматической привязкой к полям модели. Каждый элемент, содержащий данные, обязательно имеет привязку к соответствующему свойству модели.
Для реализации элементов ввода-вывода данных на веб-формах использованы следующие элементы управления Ext.NET:
- TextFieldFor: текстовое поле;
- ComboBoxFor: поле выпадающего списка;
- CheckBoxFor: поле флажка;
- RadioGroupFor: группа флажков;
- DateFieldFor: поле выбора даты.
Для реализации управляющих элементов на веб-формах, использованы следующие элементы Ext.NET:
- HyperlinkButton: гиперссылка;
- Button: кнопка.
Взаимодействие веб-страниц и сервера построено полностью с помощью асинхронных запросов (технология AJAX). Представление веб-формы взаимодействует с контроллером. Для выполнения асинхронных запросов к серверу используется механизм DirectMethods, реализованный в библиотеке Ext.NET. Например, для создания окна для формирования заявки на сертификацию ПО с клиентской стороны используется метод TabCertOrders_Create() с реализованным в нем асинхронным запросом к серверу с клиентской стороны:
function TabCertOrders_Create() {
Ext.net.Mask.show();
Ext.net.DirectMethod.request(
{
url: "/CertOrderForm/CreateNew",
params:{
onCloseClientScript: "TabCertOrders_Refresh();"
},
success: function (result) { Ext.net.Mask.hide(); },
failure: function (errorMessage) {Ext.net.Mask.hide(); Ext.Msg.alert('Ошибка', errorMessage); }
});
}
В данном примере производится обращение к методу CreateNew контроллера CertOrderForm. Данный метод имеет следующую реализацию в модуле контроллера на серверной стороне:
public ActionResult CreateNew(String onCloseClientScript = null)
{
Logging.LogAccess("CertOrderForm", "CreateNew");
//инициализация новой модели заявки
CertOrder model = new CertOrder();
model.InitNewObject();
//установка параметров частичного представления формы, возвращаемого на клиент
Ext.Net.MVC.PartialViewResult result = new Ext.Net.MVC.PartialViewResult()
{
ViewName = "CertOrderForm",
WrapByScriptTag = false,
Model = model,
RenderMode = RenderMode.Auto
};
if (String.IsNullOrWhiteSpace(onCloseClientScript) || onCloseClientScript == "null")
onCloseClientScript = "{}";
result.ViewBag.OnCloseClientScript = onCloseClientScript;
return result;
}
Приведенный выше метод контроллера осуществляет создание сущности CertOrder и осуществляет возврат результата операции на клиентскую сторону.
2.4.5 Реализация печатных форм и отчетов отчетов
В информационной системе реализован ряд печатных форм и отчетов, перечень которых приведен в таблице ниже. Источником данных для всех печатных форм и отчетов является сущность CertOrder и связанные с ней сущности справочников.
Таблица 8 – Перечень печатных форм и отчетов
| Наименование печатной формы | Входные параметры | Имя файла макета |
| Сертификат | Номер заявки на сертификацию ПО | PrintFormCert.frx |
| Форма уведомления об отказе в сертификации ПО | Номер заявки на сертификацию ПО | PrintFormCertDecline.frx |
| Договор на проведение сертификации ПО | Номер заявки на сертификацию ПО | PrintFormCertOrder.frx |
| Отчет «Заявки в работе» | Начало периода; Конец периода; Формат | ReportCertOrdersClosed.frx |
| Отчет «Закрытые заявки» | Начало периода; Конец периода; Формат | ReportCertOrdersInWork.frx |
| Отчет «Статистика обработки заявок» | Начало периода; Конец периода; Формат | ReportCertOrdersStats.frx |
| Модуль отчета (свой для каждого отчета) |
| БД |
| PDF, RTF, XLSX |
| Модуль подготовки отчетности ReportingCommon.cs |
| Макет отчета.frx |
| Файлы XML, XSD |
| Модуль экспорта отчетов ReportingExport.cs |
| Контроллер формы отчета |
| Представление формы отчета |
| SQL |
| HTTP |
| Запрос от пользователя |
| Модель |
| Параметры отчета |
Рисунок 13 – Схема формирования отчетов
С учетом специфики архитектуры интернет-сайта, реализация каждого отчета включает в себя следующие компоненты:
- контроллер формы параметров отчета: обеспечивает отображение формы ввода входных данных, необходимых для запроса отчета;
- модель данных формы параметров отчета: обеспечивает хранение и передачу на сервер входных данных, необходимых для запроса отчета, введенных пользователем;
- представление формы отчета: обеспечивает отображение элементов ввода входных данных, необходимых для запроса отчета;
- макет отчета: обеспечивает описание дизайна структуры формируемого файла отчета;
- модуль отчета: реализовывает логику выборки данных из СУБД, подстановку данных в макет и выгрузку отчета клиенту в запрошенном формате.
Формирование отчетов реализовано с помощью библиотек FastReport.NET. Макеты отчетов хранятся в виде XML-документов с расширением. FRX, расположенных в каталоге Reports. Схема формирования отчетов приведена на рисунке 13.
Формирование отчетов реализовано следующим образом. Из контроллера веб-формы отчета производится вызов соответствующего статического метода класса модуля отчета, который формируют набор данных в формате XML, и производят сохранение набора данных и XSD-схемы в каталог Reports.
Модуль подготовки отчетности осуществляет загрузку соответствующего макета отчета из каталога Reports, и осуществляет подстановку в шаблон отчета ранее подготовленных данных в формате XML и XSD-схемы.
Модуль экспорта отчета осуществляет выгрузку подготовленного отчета в затребованном формате (PDF, Word, Excel), и передачу бинарного потока данных на сторону клиента.
2.4.6 Реализация разграничения прав доступа
Разграничение прав доступа пользователей к объектам информационной системы реализовано с помощью ролевой политики безопасности. Матрица доступа к функциям системы приведена ниже в таблице 9.
Привилегии не назначаются пользователям непосредственно, и приобретаются ими только через членство в соответствующих группах. Управление индивидуальными правами пользователя, по сути, сводится к включению его в группы.
Таблица 9 – Матрица доступа
| Заказчик | Администратор | Эксперт | Руководитель | Системный администратор | |
| Создание заявок на сертификацию ПО | + | + | + | ||
| Просмотр заявок на сертификацию ПО созданных другими пользователями | + | + | + | + | |
| Удаление заявок на сертификацию ПО | + | + | |||
| Изменение статуса заявок на сертификацию ПО | + | + | |||
| Редактирование этапов тестирования ПО | + | + | + | ||
| Назначение экспертов на этапы тестирования ПО | + | + | + | ||
| Редактирование результатов испытаний | + | + | + |
Продолжение таблицы 9
| Редактирование справочника видов испытаний | + | + | |||
| Формирование отчетов | + | + | + | + | |
| Печать договора на выполнение сертификации ПО | + | + | + | + | + |
| Печать приложения к договору об отказе в сертификации | + | + | + | + | + |
| Печать сертификата | + | + | + | + | + |
| Редактирование списка пользователей | + |
Эксплуатационная часть
Тестирование
Тестирование является этапом приемки системы в эксплуатацию. Тестирование выполняется после завершения программной реализации и настройки системы. Целью проведения тестирования является подтверждение выполненной реализации требуемой функциональности системы.
Основные тесты:
- тесты справочников;
- тесты экранных форм;
- тесты отчетности.
Ниже приведена рекомендуемая методика тестирования системы. Тестирование следует выполнять строго в указанном порядке.
В процессе тестирования, результат каждого теста фиксируется. Считается, что тест прошел успешно, если полученный результат совпадает с ожидаемым результатом.
Таблица 10 – Методика тестирования системы
| Выполняемое действие | Требуемый результат |
| 1 В интернет-браузере перейти по адресу веб-портала системы | Открыта страница входа в систему |
| 2 Произвести вход в систему под учетной записью, входящей в группу администраторов | Открыта главная страница |
| 3 Перейти на вкладку «Пользователи» | Отображен табличный список пользователей системы |
| 4 Создать новую учетную запись пользователя. Включить её в группу «Администратор» | В списке пользователей отображается созданная учетная запись |
Продолжение таблицы 10
| 5 Создать новую учетную запись пользователя. Включить её в группу «Заказчик» | В списке пользователей отображается созданная учетная запись |
| 6 Создать новую учетную запись пользователя. Включить её в группу «Руководитель» | В списке пользователей отображается созданная учетная запись |
| 7 Создать несколько новых учетных записей пользователя. Включить их в группу «Эксперт» | В списке пользователей отображаются созданные учетые записи |
| 8 Перейти на вкладку «Виды испытаний» | Отображен список видов испытаний |
| 9 Произвести первоначальное заполнение справочника «Виды испытаний». За каждым видом испытаний закрепить эксперта | Добавленные виды испытаний отображаются в списке. Список доступных экспертов формируется в соответствии с ранее заполненным на шаге 7 справочником пользователей |
| 10 Закрыть все окна интернет-браузера. Выполнить повторный вход в систему под учетной записью, созданную на шаге 5, входящей в группу Заказчик. Произвести заполнение данных на странице «Личный кабинет» | Вход под учетной записью выполнен. Данные заполнены |
| 11 Произвести создание новой заявки на сертификацию ПО на вкладке Заявки на сертификацию ПО | На форме заявки в разделе «Реквизиты заказчика» поля автоматически предзаполнены данными, указанными в личном кабинете пользователя - заказчика |
| 12 Произвести заполнение программы испытаний в заявке на сертификацию ПО | Программа испытаний заполнена и отображается в разделе Программа испытаний |
Продолжение таблицы 10
| 13 Прикрепить к заявке на сертификацию один или несколько документов | Документы прикреплены к заявке и отображаются в списке документов а разделе заявки Приложения |
| 14 Сохранить заявку | Созданная заявка отображается в списке на главной странице, в группе «Новые» |
| 15 Произвести выход из системы. Войти в систему с учетной записью администратора созданной на шаге 4. Открыть созданную на шаге 11 заявку на сертификацию ПО. Изменить статус заявки на «Принята в работу» | Статус заявки изменен |
| 15 Сохранить заявку | Заявка отображается в списке на главной странице, в группе «Принята в работу» |
| 16 Выйти из системы. Произвести вход в систему с учетной записью пользователя, входящего в группу «Эксперт», созданной на шаге 7 | Вход выполнен. Открыта главная страница |
| 17 Открыть заявку на сертификацию ПО, находящуюся в статусе «Принята в работе» (шаг 15). Открыть шаг тестирования, назначенный на шаге 12 текущему пользователю-эксперту. Указать результат испытания «Пройдено». Сохранить шаг тестирования | Шаг тестирования сохранен |
Продолжение таблицы 10
| 18 Повторить пункты «Указать результат испытания «Пройдено» и «Сохранить шаг тестирования» шага 17 для каждого вида испытаний текущей заявки | Шаги тестирования сохранены |
| 19 Сохранить заявку | В списке заявок на главной странице отображается статистика испытаний: количество пройденных и не пройденных тестов соответствует заполнению результатов шагов программы испытаний шагов 17 и 18 |
| 20 Произвести заполнение результатов остальных шагов программы испытаний под учетными записями пользователей, назначенных в качестве соответствующих экспертов на шаге 7. Сохранить заявку | В списке заявок на главной странице отображается статистика испытаний: количество пройденных и не пройденных тестов соответствует заполнению результатов шагов программы испытаний |
| 21 Выполнить вход в систему под учетной записью администратора | Вход выполнен. Открыта главная страница |
| 22 Изменить статус заявки на «Сертификация пройдена» | Статус заявки изменен на «Сертификация пройдена» |
| 23 Произвести формирование печатной формы Договора на проведение сертификации ПО | Выгружен документ в формате PDF. Документ содержит всю информацию, указанную в заявке на сертификацию ПО |
Продолжение таблицы 10
| 24 Произвести формирование печатной формы документа «Сертификат соответствия» | Выгружен документ в формате PDF. Документ содержит всю информацию, указанную в заявке на сертификацию ПО |
| 25 Изменить статус заявки на «Сертификация не пройдена». Сохранить заявку и снова её открыть. Произвести формирование печатной формы «Уведомление об отказе в сертификации» | Выгружен документ в формате PDF. Документ содержит всю информацию, указанную в заявке на сертификацию ПО. |
| 26 Входя в систему под разными учетными записями пользователей, создать несколько заявок на сертификацию ПО (выполнить последовательно шаги 11-14). Под учетной записью администратора установить для созданных заявок различный статус (либо выполнить шаг 22, либо 25) | Заявки отображаются в списке на главной странице, в группе «Принята в работу». Статусы заявок изменены на «Сертификация пройдена» и «Сертификация не пройдена» в соответствии с действиями администратора |
| 27 Сформировать отчет «Заявки в работе» | Отчет сформирован и содержит список заявок на сертификацию ПО, находящихся в статусе «Принята в работу» |
| 28 Сформировать отчет «Закрытые заявки» | Отчет сформирован и содержит список заявок на сертификацию ПО, находящихся в статусах «Сертификация пройдена», «Сертификация не пройдена», «Отклонена» |
Окончание таблицы 10
| 29 Сформировать отчет «Статистика обработки заявок» | Отчет сформирован и содержит графическую иллюстрацию распределения заявок на сертификацию ПО в разрезе различных показателей, в соответствии со статусом и другими атрибутами созданных на предыдущих шагах заявок |
На основании результатов, полученных в ходе тестирования по приведенной методике, сделаны следующие выводы:
- функционал разработанного продукта соответствует требованиям, предъявленным в техническом задании;
- разработанный программный продукт не содержит критических ошибок;
- разработанный программный продукт пригоден к эксплуатации.