2.3 Структура веб-интерфейса системы
2.3.1 Навигационная структура веб-интерфейса
Интернет-портал системы реализован в виде одностраничного приложения (англ. Single Page Application). Одностраничное приложение - это веб-приложение, использующее единственный HTML-документ как оболочку для всех веб-страниц и организующий взаимодействие с пользователем через динамически подгружаемые HTML, CSS, JavaScript посредством асинхронного обмена данными с сервером.
Условно интерфейс системы разделен на следующие блоки:
- страница входа в систему;
- страница списка заявок на сертификацию ПО;
Рисунок 8 – ER-диаграмма физической модели базы данных
- страница списка пользователей;
- страница списка видов испытаний и закрепленных экспертов;
- страница формирования отчетов;
- страница личного кабинета пользователя;
- модальные экранные формы редактирования данных.
Навигационная структура веб-интерфейса системы приведена на рисунке 9. Стрелками показаны возможные направления переходов между компонентами интерфейса.
Рисунок 9 – Навигационная структура веб-интерфейса
2.3.2 Структура разметки интерфейса
Визуально интернет-портал системы оформлен в виде экранной формы-контейнера, включающей в себя следующие секции:
- область заголовка;
- панель переключения вкладок страниц;
- область данных страницы.
Структура разметки интерфейса основной экранной формы интернет-портала приведена на рисунке 10.
Область заголовка включает в себя элемент – название информационной системы.
Панель переключения вкладок страниц содержит в себе кнопки вкладок:
- заявки на сертификацию ПО;
Рисунок 10 – Структура разметки основной экранной формы
- виды испытаний;
- пользователи;
- отчеты;
- личный кабинет.
Содержимое области данных зависит от выбранной вкладки.
Все области данных имеют однотипное шаблонное оформление и могут включать в себя следующие секции:
- верхняя панель инструментов;
- секция основного содержимого страницы;
- панель инструментов «подвала»;
- панель фильтрации данных.
Структура разметки областей данных приведена на рисунке 11.
Страницы вкладок «Заявки на сертификацию ПО», «Виды испытаний», «Пользователи» включают в себя следующие секции:
- панель фильтрации;
- верхняя панель инструментов;
- секция основного содержимого;
- панель инструментов «подвала».
Страницы вкладок «Отчеты» и «Личный кабинет» состоят из единственной секции - основного содержимого.
Рисунок 11 – Структура разметки областей данных
2.4 Разработка сайта
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 |
Рисунок 13 – Схема формирования отчетов
С учетом специфики архитектуры интернет-сайта, реализация каждого отчета включает в себя следующие компоненты:
- контроллер формы параметров отчета: обеспечивает отображение формы ввода входных данных, необходимых для запроса отчета;
- модель данных формы параметров отчета: обеспечивает хранение и передачу на сервер входных данных, необходимых для запроса отчета, введенных пользователем;
- представление формы отчета: обеспечивает отображение элементов ввода входных данных, необходимых для запроса отчета;
- макет отчета: обеспечивает описание дизайна структуры формируемого файла отчета;
- модуль отчета: реализовывает логику выборки данных из СУБД, подстановку данных в макет и выгрузку отчета клиенту в запрошенном формате.
Формирование отчетов реализовано с помощью библиотек FastReport .NET. Макеты отчетов хранятся в виде XML-документов с расширением. FRX, расположенных в каталоге Reports. Схема формирования отчетов приведена на рисунке 13.
Формирование отчетов реализовано следующим образом. Из контроллера веб-формы отчета производится вызов соответствующего статического метода класса модуля отчета, который формируют набор данных в формате XML, и производят сохранение набора данных и XSD-схемы в каталог Reports.
Модуль подготовки отчетности осуществляет загрузку соответствующего макета отчета из каталога Reports, и осуществляет подстановку в шаблон отчета ранее подготовленных данных в формате XML и XSD-схемы.
Модуль экспорта отчета осуществляет выгрузку подготовленного отчета в затребованном формате (PDF, Word, Excel), и передачу бинарного потока данных на сторону клиента.
2.4.6 Реализация разграничения прав доступа
Разграничение прав доступа пользователей к объектам информационной системы реализовано с помощью ролевой политики безопасности. Матрица доступа к функциям системы приведена ниже в таблице 9.
Привилегии не назначаются пользователям непосредственно, и приобретаются ими только через членство в соответствующих группах. Управление индивидуальными правами пользователя, по сути, сводится к включению его в группы.
Таблица 9 – Матрица доступа
|
Заказчик |
Администратор |
Эксперт |
Руководитель |
Системный администратор |
1 |
2 |
3 |
4 |
5 |
6 |
Создание заявок на сертификацию ПО |
+ |
+ |
|
|
+ |
Просмотр заявок на сертификацию ПО созданных другими пользователями |
|
+ |
+ |
+ |
+ |
Удаление заявок на сертификацию ПО |
|
+ |
|
|
+ |
Изменение статуса заявок на сертификацию ПО |
|
+ |
|
|
+ |
Редактирование этапов тестирования ПО |
+ |
+ |
|
|
+ |
Назначение экспертов на этапы тестирования ПО |
+ |
+ |
|
|
+ |
Редактирование результатов испытаний |
|
+ |
+ |
|
+ |
Продолжение таблицы 9
1 |
2 |
3 |
4 |
5 |
6 |
Редактирование справочника видов испытаний |
|
+ |
|
|
+ |
Формирование отчетов |
|
+ |
+ |
+ |
+ |
Печать договора на выполнение сертификации ПО |
+ |
+ |
+ |
+ |
+ |
Печать приложения к договору об отказе в сертификации |
+ |
+ |
+ |
+ |
+ |
Печать сертификата |
+ |
+ |
+ |
+ |
+ |
Редактирование списка пользователей |
|
|
|
|
+ |