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

Вся основная информация о сущностях, а также методах для оперирования над ними была расположена в проекте «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. История проекта

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