Для описанных выше прецедентов было добавлено расширенное описание каждого из них, включающее название, актора, краткое описание, триггер, основной поток и альтернативные потоки. Итоговая диаграмма прецедентов с расширенными описаниями представлена в функциональной спецификации в разделе концептуального проекта [см. Приложение А].
Диаграмма активностей позволяет рассмотреть процесс работы с системой в динамике. Так, на примере прецедента добавления нового поставщика в систему можно увидеть весь ход взаимодействия администратора с системой. Для начала администратор должен нажать кнопку «Список поставщиков/Добавить», что повлечет переход на форму заполнения данных поставщика (электронная почта и пароль). Введя запрашиваемые данные, он нажимает кнопку «Сохранить», после чего данные проверяются на корректность. Если они не корректны, то администратору придется их поправить. В случае валидности данных они сохраняются в системе, и администратор переходит на страницу поставщика.
Подобным образом можно описать ход взаимодействия пользователя и системы у прецедентов редактирования сотрудника, добавления фильтра, редактирования фильтра, редактирования настроек профиля поставщика, редактирования подачи заявок поставщика и некоторых других.
Активности, не требующие ввода данных, могут проходить несколько проще. Так, если администратор захочет удалить поставщика, то сначала ему необходимо будет нажать кнопку «Список поставщиков/Удалить», затем системой будет удалена запись о поставщике и будет произведен переход на окно списка поставщиков.
Аналогично диаграмме активности удаления поставщика могут быть разработаны диаграммы удаления фильтра, отзыва заявки, а также все диаграммы просмотра каких-либо данных или списков.
Особняком стоят диаграммы активностей для скачивания извещений и подачи заявок. Согласно требованиям, необходимо обеспечить скачивание нескольких извещений с электронных торговых площадок периодически с фиксированной задержкой. В данном случае актором является только сама система, поэтому диаграмма этой активности будет содержать одну «плавательную дорожку». Аналогично будет построена диаграмма подачи заявок на участие, а также диаграммы для учета извещений и учета поданных заявок.
Итоговый вариант всей диаграммы активности представлен в функциональной спецификации в разделе концептуального моделирования [см. Приложение А].
В качестве дополнения диаграммы активностей может выступать диаграмма последовательностей. Каждой активности, зафиксированной ранее, можно поставить в соответствие последовательность. Так, для активности добавления поставщика в систему соответствующая последовательность будет иметь схожий вид. Администратор нажимает кнопку «Список поставщиков/Добавить», после чего система в течение некоторого времени формирует и возвращает страницу для заполнения данных. Администратор заполняет данные и отправляет их, после чего система либо возвращает страницу с введенными данными и сообщением об ошибке, либо возвращает страницу добавленного поставщика. В процессе взаимодействия явно видны объекты (например, страницы), передаваемые одной стороной другой.
Полная диаграмма последовательностей представлена в функциональной спецификации в разделе концептуального моделирования [см. Приложение А].
Таким образом, описанные диаграммы прецедентов, активностей и последовательностей формируют концептуальную модель разрабатываемой программной системы. Другой, не менее важной составляющей проекта, является логическая модель системы, включающая диаграмму бизнес-классов, а также описание архитектурных паттернов.
2.2 Разработка логической модели
Диаграмма бизнес-классов может играть роль статической модели программной системы, описывающей данные и сущности, а также связи между ними. На основании требований и концептуальной модели можно выделить сущности разрабатываемой системы, а также выявить типы связей между ними.
Наиболее важной сущностью является поставщик (User), так как в него должно быть инкапсулировано множество данных для подачи заявок. Помимо логина и пароля (хэша пароля), задаваемых администратором, важно также хранить контактный телефон, имя, фамилию и отчество ответственного за закупки от имени поставщика лица, а также набор документации, включающий файлы для первых и вторых частей заявок, а также некоторые дополнительные файлы (документы о принадлежности к субъектам малого предпринимательства, к социально ориентированным некоммерческим организациям и т.д.). Помимо этого, важно также хранить информацию и настройках пользователя, включающих разрешение на оповещения по электронной почте и автоматическую подачу заявок на участие. Для реализации инкапсуляции доступ ко всей этой информации должен производиться через соответствующие методы. В дополнение, пользователю также можно добавить некоторую справочную информацию (например, дата и время добавления в систему).
Другой важной сущностью будет являться фильтр (Topic). Фильтр должен иметь строковое поле для наименования и строковое поле для выражения. Помимо этого, возможно также добавить справочную информацию о дате создания фильтра.
Так как ранее было выяснено, что пользователь может иметь несколько фильтров, то становится очевидным необходимость наличия типа связи «многие-ко-многим» между пользователем и фильтром. Вспомогательная сущность, именуемая как права на фильтр (TopicRights) поможет решить эту проблему.
В ходе формирования требований была выявлена необходимость в учёте извещений, поэтому соответствующая сущность (Procedure) также нуждается в определении. Из информации, которую можно получить путем сканирования электронных торговых площадок, можно выделить название закупки, наименование заказчика, ссылка на извещение, наименование электронной торговой площадки, закон, тип процедуры, номер в реестре, номер на торговой площадке и начальная максимальная цена. Помимо этого, для электронных аукционов также можно определить время начала подачи ценовых предложений, поэтому необходимо выделить отдельную сущность (Auction), которая бы являлась потомком для сущности извещения.
По причине необходимости фиксации факта о принадлежности извещений подходящим фильтрам возникает потребность в еще одной связи «многие-ко-многим» [9] между извещением и фильтром. Вспомогательная сущность фильтр извещения (TopicProcedure) призвана решить эту проблему.
Еще одной важной сущностью является заявка на участие (AppliedProcedureRequest). В ней может содержаться информация об извещении, поставщике, от имени которого была подана заявка, а также о дате формирования заявки.
Среди вспомогательных сущностей также можно выделить представление для файла, хранящее наименование файла, его размер, тип контента, дату создания и т.д. Файл связан отношением «один-к-одному» с документом (Document), хранящим также текстовое описание файла.
В заключение, также важно хранить информацию об администраторах. Важно однозначно идентифицировать администратора, поэтому необходим логин, а также пароль (хэш пароля) для защиты.
Итоговый вариант диаграммы бизнес-классов представлен в функциональной спецификации в разделе логического моделирования [см. Приложение 1].
Паттерны проектирования также играют важную роль в составлении логической модели программной системы. Так, в качестве основного архитектурного паттерна был выбран MVC, так как в программной системе достаточно естественно выделяются модель, описанная диаграммой бизнес-классов, контроллер и представление, отображаемое браузером. Кроме того, применение данного паттерна также обусловлено стремлением разделить бизнес-логику и её визуализацию в целях упрощения сопровождения и тестирования.
Среди паттернов проектирования также были выбраны репозиторий (Repository), позволяющий абстрагироваться от конкретной реализации хранилища данных в целях легкой его замены при возникновении этой необходимости, команда (Command), позволяющий работать с HTTP запросами в событийно управляемой манере [10], естественной для данного протокола, а также единица работы (Unit Of Work), позволяющий неявно использовать транзакции при работе с хранилищем данных, что позволит сохранить их целостность.
2.3 Разработка физической модели
Завершающим звеном является физический проект программной системы, в состав которого входит диаграмма классов, диаграмма активностей, диаграмма последовательностей и диаграмма компонентов.
Диаграмма классов частично повторяет диаграмму бизнес-классов, однако в данном случае она еще дополнена вспомогательными и инфраструктурными классами. Так, для оперирования бизнес-классами были добавлены классы-сервисы. Их роль заключается в том, что они содержат бизнес-логику, которую невозможно включить в бизнес-класс непосредственно (например, проверка сущности на уникальность). Кроме того, все они реализуют пустой интерфейс «IDomainService».
Сами же сервисные классы чаще всего вызываются из классов контроллеров. Как известно, контроллеры оперируют моделями и представлениями. В данном случае оперирование моделями происходит не напрямую, а через сервисные классы.
Помимо этого, для реализации паттерна Command были также добавлены классы, реализующие интерфейсы «IForm» и «IFormHandler». Как ясно из названий, первые представляют собой HTTP форму, а вторые - обработчики для форм.
Итоговая диаграмма классов представлена в функциональной спецификации в разделе физического моделирования [см. Приложение А].
Как диаграмма активностей, так и диаграмма последовательностей реализованные в рамках физической модели, отличаются от ранее описанных применением глобального паттерна MVC. Использование клиент-серверной архитектуры повлекло необходимость разделение программной системы на клиентскую и серверную части, что было также отражено на диаграммах. Обе диаграммы представлены в функциональной спецификации в разделе физического моделирования [см. Приложение А].
Диаграмма компонентов даёт представление о системе с физической точки зрения. Разработанная диаграмма компонентов разделена на три части каждая из которых отвечает за свой уровень приложения.
Клиентская часть представлена набором клиентских библиотек, а также файлов таблиц стилей. Серверная часть представляет собой веб-сервер с библиотеками основного кода программы. Из диаграммы ясно видна структура приложения, реализованного с применением архитектурного паттерна MVC. Помимо этого, серверная часть использует также конфигурационный файл, а также набор сторонних библиотек. Часть работы с данными содержит библиотеку для объектно-реляционного отображения и драйвер базы данных, связанный с СУБД MySQL. Итоговая версия диаграммы компонентов представлена в функциональной спецификации в разделе физического моделирования [см. Приложение А].
Таким образом, в результате проектирования была разработана функциональная спецификация, содержащая в себе модели разрабатываемой программной системы.
2.4 Выбор инструментов разработки
Помимо проекта программной системы важно также выбрать стек технологий для разработки программной системы. Так как программная система, во-первых, имеет клиент-серверную архитектуру, и, во-вторых, спроектирована в объектно-ориентированной манере, то для реализации подойдет любая современная платформа с объектно-ориентированным языком общего назначения. Кроме того, из-за отсутствия требований к работе программной системы в рамках какой-либо конкретной операционной системы важно также подобрать мультиплатформенную платформу для разработки.
Всем перечисленным выше требованиям удовлетворяет платформа «.Net Core» и язык программирования C# 7.3. Платформа включает в себя веб-сервер «Kestrel», компилятор для языка C# 7.3 «Roslyn», интерпретатор байт-кода «RyuJIT», сборщик «MSBuild», дополнительные библиотеки для организации приложений клиент-серверной архитектуры с помощью протокола HTTP, а также множество других средств для разработки и тестирования приложений. Кроме того, программные системы, разработанные с использованием данной платформы, могут быть собраны и развернуты в рамках множества популярных операционных систем, в том числе с использованием технологий контейнеризации. Таким образом, в качестве основного фреймворка для разработки приложения был выбран «.Net Core SDK» версии 2.2.203.
В качестве клиентской части будут выступать HTML-страницы, генерируемые системой и отображаемые браузером. Так как специфических требований к интерфейсу не предъявлялось, то были выбраны базовые библиотеки для работы с интерфейсом, среди которых «Bootstrap» версии 4.3.1, а также его зависимости.
Для работы с данными были выбраны, во-первых, мультиплатформенная и многофункциональная реляционная СУБД «MySQL» версии 8.0.16, и, во-вторых, библиотека для объектно-реляционного отображения «NHibernate» версии 5.2.5. Выбор данной библиотеки обусловлен, во-первых, совместимостью с платформой «.Net Core», и, во-вторых, более широкой функциональностью в сравнении с аналогами.
Помимо этого, также были выбраны некоторые вспомогательные библиотеки, среди которых «MailKit», позволяющий организовать отправление уведомлений по электронной почте, «HtmlAgilityPack», предоставляющий возможности для работы с разметкой некоторых торговых площадок, «RabbitMQ.Client» в качестве клиента для очереди сообщений, а также «Newtonsoft.Json» для работы с файлами соответствующего формата.
Глава 3. Разработка и тестирование программной системы
Основываясь на всех ранее созданных моделях, необходимо разработать и протестировать программную реализацию системы для подачи заявок. В разделе кодирования представлен процесс написания исходного кода программной системы с использованием инструментов, выбранных ранее. Раздел, посвященный тестированию, содержит описание процесса тестирования и отладки системы.
3.1 Разработка программного кода
Процесс разработки программной системы начался с формирования структуры исходного кода. Решение (Solution) было поделено на несколько отдельных проектов. Для начала был создан ключевой проект «Web», содержащий, во-первых, конфигурационный файл с настройками системы, во-вторых, код инициализации системы для указания средств аутентификации, обработки ошибок и конфигурации маршрутов, в-третьих, код для инициализации всех зависимостей, в-четвертых, все представления MVC, и, в пятых, библиотеки и файлы для клиентской части. Данный проект будет содержать точку входа, а также будет иметь все остальные проекты в качестве зависимых библиотек.