Разработка автоматизированной системы подачи заявок на участие в электронных аукционах, проводимых по 44-ФЗ

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

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

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

Таким образом, для проектируемой системы было выявлено несколько групп пользовательских сценариев, разделенных в соответствии с ролевой моделью. Все пользовательские сценарии были добавлены в спецификацию [см. Приложение А].

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

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

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

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

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

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

Активности, не требующие ввода данных, могут проходить несколько проще. Так, если администратор захочет удалить поставщика, то сначала ему необходимо будет нажать кнопку «Список поставщиков/Удалить», затем системой будет удалена запись о поставщике и будет произведен переход на окно списка поставщиков.

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

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

Итоговый вариант всей диаграммы активности представлен в функциональной спецификации в разделе концептуального моделирования [см. Приложение А].

В качестве дополнения диаграммы активностей может выступать диаграмма последовательностей. Каждой активности, зафиксированной ранее, можно поставить в соответствие последовательность. Так, для активности добавления поставщика в систему соответствующая последовательность будет иметь схожий вид. Администратор нажимает кнопку «Список поставщиков/Добавить», после чего система в течение некоторого времени формирует и возвращает страницу для заполнения данных. Администратор заполняет данные и отправляет их, после чего система либо возвращает страницу с введенными данными и сообщением об ошибке, либо возвращает страницу добавленного поставщика. В процессе взаимодействия явно видны объекты (например, страницы), передаваемые одной стороной другой.

Полная диаграмма последовательностей представлена в функциональной спецификации в разделе концептуального моделирования [см. Приложение А].

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

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, и, в пятых, библиотеки и файлы для клиентской части. Данный проект будет содержать точку входа, а также будет иметь все остальные проекты в качестве зависимых библиотек.

Вся основная информация о сущностях, а также методах для оперирования над ними была расположена в проекте «Domain», являющемся ядром в данной системе. Выделение сущностей и классов для работы с ними (сервисов) в отдельный проект обусловлена принципами предметно-ориентированного проектирования. Кроме того, данный проект будет инкапсулировать модель приложения в терминах паттерна MVC.

Для хранения логики работы контроллера MVC был добавлен проект «Web.Application». Помимо контроллеров в него также были включены некоторые инфраструктурные части кода (например, работа с электронной почтой), а также фоновые сервисы.

Работа с хранилищем, включающая формирование конкретных запросов и команд к СУБД, была организована в проектах «Domain.Persistence» и «Web.Application.Persistence». Вынесение команд и запросов позволит разгрузить код с бизнес-логикой, что может оказаться полезным при сопровождении программной системы.

Наконец, для конфигурирования средств объектно-реляционного отображения также был создан проект «Infrastructure.NHibernate». Выделение данного проекта позволит безопасно и удобно вносить изменения в настройки схемы БД.

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

Далее были реализованы классы-сервисы, предназначенные для оперирования сущностями. Так, например, сервис поставщика реализует добавление записи о нем в хранилище, что предусматривает проверку на наличие других поставщиков с аналогичными данными. Каждый из сервисов реализует интерфейс «IDomainService», что позволяет упростить процесс их регистрации в системе инверсии зависимостей.

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

После реализации домена были разработаны реализации команд и запросов к хранилищу данных. Для наиболее часто используемых запросов, среди которых поиск сущности по идентификатору и поиск всех сущностей, были разработаны обобщенные реализации, принимающие в качестве аргумента не только параметры запроса, но и тип сущности. Кроме того, команды для сохранения и удаления сущностей также получили обобщенные реализации, позволяющие повысить степень переиспользования кода [11]. В данных командах используется экземпляр класса репозитория, реализующего соответствующий паттерн, рассмотренный ранее. Реализации команд и запросов были добавлены в проект «Domain.Persistence».

На следующем этапе разработки была реализована часть логики, именуемая контроллером в терминах MVC. Для большинства сущностей, добавленных в рамках домена, были разработаны соответствующие им контроллеры. Каждый из контроллеров был унаследован от общего контроллера «FormControllerBase», основная задача которого - реализация логики паттерна «Единица работы», которая сводится к подтверждению или откату транзакции (зависит от успешности обработки HTTP-запроса).

В рамках каждого контроллера были реализованы активности, описанные в соответствующей диаграмме. Так как каждая активность представляет собой HTTP-запрос, то для каждой активности был добавлен собственный обработчик запроса. В рамках паттерна «Команда» как параметры каждого запроса, так и его обработчик были инкапсулированы в соответствующие классы. Параметры извлекались из HTTP-запроса посредством встроенного механизма биндинга, а затем записывались в поля соответствующего класса для параметров, реализующего интерфейс «IForm». Для каждого такого класса был реализован обработчик, реализующий интерфейс «IFormHandler».

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

Помимо этого, были также добавлены классы, оперирующие поисковыми выражениями фильтров и некоторые другие, играющие вспомогательную роль. Все вышеописанные контроллеры, обработчики запросов, фоновые сервисы и вспомогательные классы были помещены в проект «Web.Application».

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

Как для скачивания извещений, так и для подачи заявок также были разработаны отдельны проекты в рамках собственных решений. Загрузка извещений производится в отдельном потоке для каждой электронной торговой площадки. Каждый поток раз в 30 секунд опрашивает электронную торговую площадку на предмет наличия новых извещений о проведении электронных аукционов. В случае успеха данные об аукционе агрегируются и подаются в электронную очередь для последующей обработки и сохранения. Подача заявок производится похожим образом: сервис подачи заявок получает данные об извещении и пользователе, составляет из них заявку и подаёт на ту площадку, с который было скачано извещение. В случае успеха в электронную очередь подаётся результат в виде номера извещения.



3.2 Тестирование и отладка программной системы

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

Первая группа ошибок, выявленная на стадии тестирования, включала в себя исключительные ситуации, порождаемые средствами объектно-реляционного отображения. Для того, чтобы отображение осуществлялось корректно, необходимо, во-первых, правильно настроить соглашения (конвенции), и, во-вторых, всюду следовать им при разработке отображаемых классов-сущностей. Кроме того, также важно соблюдать правила и ограничения, введенные разработчиком используемой библиотеки для отображения, которые в данном случае включают наличие пустых конструкторов у всех классов-сущностей, наличие спецификатора «virtual» у всех полей и методов классов-сущностей и некоторые другие. В процессе отладки были перепроверены и исправлены все упомянутые правила и ограничения, а также были пересмотрены участки кода, связанные с конвенциями. Как результат, процедуры создания и обновления базы данных стали происходить штатно и без каких-либо исключительных ситуаций.

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

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

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



Заключение

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

1) анализ процесса осуществления закупок:

· обзор существующей законодательной базы в сфере госзакупок,

· обзор существующих систем для поиска извещений о закупках и подачи заявок на участие, с выделением в них достоинств и недостатков,

· формулирование необходимых требований к разрабатываемой системе;

2) создание проекта программной системы, включающее разработку концептуальной, логической и физической моделей;

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

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

программный закупка законодательный



Библиографический список

1. «Федеральный закон «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». М.: Эксмо-Пресс, 2019. - 224.

2. «Федеральный закон «О закупках товаров, работ, услуг отдельными видами юридических лиц». М.: Проспект, 2019. - 64 с.

3. Министерство Финансов Российской Федерации [Электронный ресурс] (дата обращения: 15.04.2019).

4. Димитри Н. Руководство по закупкам / Н. Димитри, Г. Пига, Дж. Спаньоло. Пер. с англ. - М.: Изд. Дом Высшей школы экономики, 2013. - 695с.

5. Поиск тендеров по всем площадкам на OTC [Электронный ресурс] (дата обращения: 15.04.2019).

6. СТАР - бесплатный поиск тендеров по всей России [Электронный ресурс] URL: https://star-pro.ru/ (дата обращения: 15.04.2019).

7. Система мониторинга закупок My-Tender [Электронный ресурс] URL: https://www.my-tender.ru/ (дата обращения: 15.04.2019).

8. Tenders [Электронный ресурс] URL: https://github.com/ssds-team/Tenders (дата обращения: 15.04.2019)

9. Маклафлин Б. Объектно-ориентированный анализ и проектирование, 4-е изд.: Пер. с англ. - СПБ.: Питер, 2013. - 608 с.

10. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. - СПб: Питер, 2001. - 368с.

11. Троелсен Э. Язык программирования C# 5.0 и платформа.NET 4.5, 6-е изд.: Пер. с англ. - М.: ООО “И.Д. Вильямс”, 2013. - 1312 с.



Приложение А

Функциональная спецификация

1. Видение и рамки

Автоматизированная программная система для поиска извещений о проведении электронных аукционов, проводимых по 44-ФЗ, а также формирования и подачи заявок на участие в них разрабатывается в целях:

· Минимизации количества рабочего времени поставщиков, затрачиваемого на поиск закупок, а также формирование и подачи заявок на участие в них.

· Минимизации времени между появлением извещения о проведении электронного аукциона на какой-либо электронной торговой площадке и подачей заявки на участие в нем.

2. История проекта

День от начала проекта	События
1	Принято решение о начале проекта
2	Сформированы функциональные и нефункциональные требования к программной системе
3	Разработаны диаграмма прецедентов и спецификация
4	Разработаны диаграммы активностей и последовательностей
5	Разработана диаграмма бизнес-классов
11	Изучены и выбраны необходимые паттерны проектирования
12	Разработана диаграмма последовательностей с учетом выбранного паттерна
15	Разработана диаграмма классов
16	Разработана диаграмма компонентов
22	Разработана программная система
23	Протестирована программная система

3. Цели дизайна

3.1 Требования пользователя

С точки зрения администратора системы

· Наличие опции добавления/редактирования/удаления/просмотра поставщиков.

· Наличие опции добавления/редактирования/удаления/просмотра фильтров для поставщиков.

С точки зрения поставщика

· Наличие опции для добавления/редактирования сведений и документации для подачи заявок.

· Наличие опции просмотра извещений, соответствующих профилю деятельности поставщика.

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

· Наличие средств для оповещения поставщика о появлении извещений, соответствующих профилю его деятельности.

3.2 Системные требования

1. Бесперебойный доступ к сети Интернет с полосой пропускания не менее 64 Кб/сек.

2. Доступная память в виде 5 Гб ПЗУ и 2 Гб ОЗУ.

3. Программная система должна состоять из подсистем мониторинга электронных торговых площадок, учета данных пользователей и найденных извещений и подачи заявок на участие на электронные торговые площадки, а также обеспечивать постоянное хранение данных и доступ к ним посредством пользовательского интерфейса.

4. Программная система должна обеспечивать обработку и хранение до 10000 извещений в день без видимых з

5. адержек.

6. Программная система должна обеспечивать устойчивость к возможным изменениям интерфейсной части электронных торговых площадках.

7. При возникновении сбоев программа должна производить их регистрацию, а также производить попытки восстановления.

8. Надежность программной системы должна быть обеспечена минимальными задержками при восстановлении, а также длительным временем непрерывной работы.

3.3 Сценарии использования

Добавление пользователя.

1. Администратор проходит аутентификацию.

2. Администратор выбирает пункт меню для работы с поставщиками, где затем нажимает кнопку добавления.

3. Администратор вводит логин и пароль нового поставщика.

4. Администратор нажимает кнопку сохранения

Редактирование пользователя.

1. Администратор проходит аутентификацию.

2. Администратор выбирает пункт меню для работы с поставщиками, где затем нажимает кнопку редактирования.

3. Администратор вводит новый логин поставщика.

4. Администратор нажимает кнопку сохранения

Удаление пользователя.

1. Администратор проходит аутентификацию.

2. Администратор выбирает пункт меню для работы с поставщиками, где затем нажимает кнопку удаления.

Добавление фильтра.

1. Администратор проходит аутентификацию.

2. Администратор выбирает пункт меню для работы с фильтрами, где затем нажимает кнопку добавления.

3. Администратор вводит название и выражение нового фильтра.

4. Администратор нажимает кнопку сохранения

Редактирование фильтра.

1. Администратор проходит аутентификацию.

2. Администратор выбирает пункт меню для работы с фильтрами, где затем нажимает кнопку редактирования.

3. Администратор вводит новый новое название фильтра или выражение.

4. Администратор нажимает кнопку сохранения

Удаление фильтра.

1. Администратор проходит аутентификацию.

2. Администратор выбирает пункт меню для работы с фильтрами, где затем нажимает кнопку удаления.

Назначение фильтра.

1. Администратор проходит аутентификацию.

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

3. Администратор выбирает поставщика из списка доступных.

4. Администратор нажимает кнопку сохранения.

Редактирование настроек профиля поставщика.

1. Поставщик проходит аутентификацию.

2. Поставщик выбирает пункт меню для работы с профилем, где затем нажимает кнопку редактирования настроек профиля.

3. Поставщик вводит настройки своего профиля.

4. Поставщик нажимает кнопку сохранения

Редактирование параметров подачи заявок.

1. Поставщик проходит аутентификацию.

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

3. Поставщик вводит параметры подачи заявок, среди которых его контактная информация и его документы для участия.

4. Поставщик нажимает кнопку сохранения

Просмотр извещений.

1. Поставщик проходит аутентификацию.

2. Поставщик выбирает пункт меню для работы с извещениями, где затем нажимает кнопку списка извещений.

3. Поставщик вводит параметры фильтрации извещений и нажимает кнопку применения фильтра.

Просмотр извещений, соответствующих назначенным поставщику фильтров.

1. Поставщик проходит аутентификацию.

2. Поставщик выбирает пункт меню для работы с извещениями, где затем нажимает кнопку списка его извещений.

Просмотр заявок на участие.

1. Поставщик проходит аутентификацию.

2. Поставщик выбирает пункт меню для работы с заявками, где затем нажимает кнопку списка заявок.

Отзыв заявок на участие.

1. Поставщик проходит аутентификацию.

2. Поставщик выбирает пункт меню для работы с заявками, где затем нажимает кнопку списка заявок.

3. Поставщик нажимает кнопку отзыва заявки.

4. Исключенные возможности и неподдерживаемые сценарии

Исключительные возможности и неподдерживаемые сценарии не определены.

5. Предположения и зависимости

Предположения и зависимости не определены.

6. Проект решения

6.1 Концептуальный проект

Диаграмма прецедентов



Расширенное описание прецедентов

Название	Добавление поставщиков
Акторы	Администратор
Краткое описание	Добавление в систему запись о новом поставщике.
Триггер	Нажатие на кнопку «Список поставщиков», а затем «Добавить».
Основной поток	После нажатия на кнопку администратор вводит данные нового поставщика (логин и пароль) и сохраняет их в системе.
Альтернативные потоки	-

Название	Редактирование поставщиков
Акторы	Администратор
Краткое описание	Редактирование данных существующего поставщика
Триггер	Нажатие на кнопку «Список поставщиков», а затем «Редактировать».
Основной поток	После нажатия на кнопку администратор заполняет новые данные пользователя (логин) и сохраняет их в системе.
Альтернативные потоки	-



Название	Удаление существующих поставщиков
Акторы	Администратор
Краткое описание	Удаление из системы записи о существующем поставщике
Триггер	Нажатие на кнопку «Список поставщиков», а затем «Удалить»
Основной поток	После нажатия на кнопку удаления в системе удаляется запись о существующем поставщике
Альтернативные потоки	-

Название	Добавление фильтра
Акторы	Администратор
Краткое описание	Добавление записи о новом фильтре в систему
Триггер	Нажатие на кнопку «Список фильтров», а затем «Добавить»
Основной поток	После открытия формы добавления фильтра администратор вводит данные (название, выражение) и сохраняет их в системе
Альтернативные потоки	-

Название	Редактирование фильтра
Акторы	Администратор
Краткое описание	Изменение ранее сохраненных данных о фильтре
Триггер	Нажатие на кнопку «Список фильтров», а затем «Редактировать»
Основной поток	После открытия формы редактирования администратор вводит новые данные фильтра (название, выражение) и сохраняет их в системе
Альтернативные потоки	-

Название	Удаление фильтра
Акторы	Администратор
Краткое описание	Удаление ранее сохраненного фильтра
Триггер	Нажатие на кнопку «Список фильтров», а затем «Удалить»
Основной поток	После нажатия кнопки запись о фильтре удаляется из системы
Альтернативные потоки	-



Название	Назначение фильтра поставщикам
Акторы	Администратор
Краткое описание	Добавление записи о принадлежности фильтра какому-либо поставщику
Триггер	Нажатие на кнопку «Список фильтров», а затем «Назначить»
Основной поток	После открытия формы назначения фильтра администратор выбирает поставщика и подтверждает выбор
Альтернативные потоки	-

Название	Изменение настроек оповещения и подачи заявок
Акторы	Поставщик
Краткое описание	Включение или отключение оповещений или функции автоматической подачи заявок
Триггер	Нажатие на кнопку «Профиль», а затем «Изменить настройки профиля»
Основной поток	После нажатия кнопки поставщик может указать галочками функции, в которых он заинтересован, и сохранить указанные настройки.
Альтернативные потоки	-

Название	Изменение данных для подачи заявок
Акторы	Поставщик
Краткое описание	Добавление и изменение сведений и файлов, необходимых для автоматической подачи заявок
Триггер	Нажатие на кнопку «Профиль», а затем «Изменить параметры подачи заявок»
Основной поток	После нажатия кнопки поставщик может указать сведения (ФИО, телефон) и документы (файлы для первых и вторых частей заявок) и сохранить их в системе
Альтернативные потоки	-

Название	Просмотр извещений
Акторы	Поставщик
Краткое описание	Просмотр списка извещений, сохраненных в системе
Триггер	Нажатие на кнопку «Извещения», а затем «Список извещений»
Основной поток	После нажатия кнопки поставщик может просматривать список с информацией об извещениях, а также загружать их выборку, отфильтрованную по ключевым словам, стоп-словам и наименованиям заказчиков
Альтернативные потоки	-

Название	Просмотр извещений, соответствующих фильтрам поставщика
Акторы	Поставщик
Краткое описание	Просмотр списка извещений, соответствующих фильтрам поставщика
Триггер	Нажатие на кнопку «Извещения», а затем «Мои извещения»
Основной поток	После нажатия кнопки поставщик может просматривать список с информацией об извещениях, подходящих под критерии, указанные в его фильтре
Альтернативные потоки	-

Название	Просмотр поданных заявок на участие
Акторы	Поставщик
Краткое описание	Просмотр списка поданных от имени поставщика заявок на участие
Триггер	Нажатие на кнопку «Заявки», а затем «Мои заявки»
Основной поток	После нажатия кнопки поставщик может просматривать список с информацией о заявках, поданных системой
Альтернативные потоки	-

Название	Отклонение заявок
Акторы	Поставщик
Краткое описание	Отклонение поданной от имени поставщика заявки на участие
Триггер	Нажатие на кнопку «Заявки», а затем «Отозвать»
Основной поток	После нажатия кнопки система посылает запрос на отзыв поданной заявки на участие
Альтернативные потоки	-



Диаграмма активностей



Диаграмма последовательностей



6.2 Логический проект

Паттерны проектирования

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

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

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

· Команда (Command), позволяющий работать с HTTP запросами в событийно управляемой манере, естественной для данного протокола.

· Единица работы (Unit of Work), позволяющий неявно использовать транзакции при работе с хранилищем данных, что позволит сохранить их целостность.



Диаграмма бизнес-классов



6.3 Физический проект

Диаграмма классов



Диаграмма последовательностей с учетом архитектуры



Диаграмма активностей с учетом выбранного паттерна



Диаграмма компонентов



7. Требования к инсталляции и деинсталляции

Для инсталляции необходим выделенный сервер с операционной системой Windows или Linux, соответствующий системным требованиям программной системы. Перед инсталляцией необходимо произвести сборку программной системы с использованием «.Net SDK» версии 2.2.203 или выше с указанием конфигурации типа «Release», а также названием целевой архитектуры и операционной системы. Собранную программную систему необходимо разместить на сервере запустить каждый из сервисов путем исполнения файла «Web.exe» или «Web.so». Перед запуском необходимо указать дополнительные параметры (строки подключения к СУБД, электронным очередям, почтовым серверам, а также внешним сервисам) конфигурации в файлах «appsettings.json». Кроме того, для запуска требуется развертывание БД на сервере СУБД.

Для деинсталляции необходимо удалить папку с бинарными файлами программы, а также удалить БД из СУБД.

8. Риски

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

Размещено на Allbest.ru