3 Требования к разработке утилиты для контроля требований к по
Система для разработки утилиты для контроля требований к ПО должна включать в себя следующий список функциональных требований:
анализ требований документов;
чтение документов формата .docx с помощью Python;
создание шаблонов для поиска идентификаторов;
поиск идентификаторов в документах формата .docx с помощью шаблона модуля re;
создание базы данных для хранения найденных идентификаторов требований;
изъятие ID требований;
запись ID требований в базу;
изъятие ID требований из базы;
сравнение ID требований из базы и документа.
Нефункциональным требованием является:
удобство в использовании для анализа требований.
Средством разработки был выбран Visual Studio Code [10] – редактор исходного кода. Данный редактор отлично подходит для небольших проектов, является быстрым и привычным в использовании.
Также для ID требований был использован браузер баз данных для SQLite – bd browser for sqlite [11]. Он является визуальным инструментом для создания, редактирования и разработки файлов баз данных, а также является самой распространенной СУБД и одновременно встроенным в приложение. Данный выбор основан на том, что такая база удобна в использовании.
4 Разработка и тестирование утилиты для контроля требований к по
4.1 Разработка
В рамках производственной практики были реализованы следующие модули: docs_id, Main, database и compare_doc_database.
Первый модуль docs_id включает в себя библиотеки, позволяющие подключиться к документам формата .docx и поддерживать работу шаблонов для нахождения ID требований в тексте. В функции find_id() на вход поступают название документа и паттерн, являющийся шаблоном. Функция позволяет считывать документы построчно c помощью модуля paragraphs, а затем функция findall() ищет для каждой строки соответствие заданного паттерна [12]. Полученные элементы текста формируются в список, который и возвращает функция find_id(). Результат кода представлен на рисунке 4.1.
Рисунок 4.1 – Модуль docs_id
Модуль database полностью отвечает за работу с базой данных, где хранятся ID требования всех документов. В первой функции save_id() в качестве параметров выступают название документа и сформированный список ID модуля docs_id. В теле функции происходит создание базы данных database и подключение к ней. Создание названия таблицы БД для помещения ID требований происходит в зависимости от типа документа. Тип передается из модуля main. Затем создан цикл, в котором каждый элемент списка оформляется в апострофы и скобки для правильного вывода идентификаторов. Полученный результат записывается в базу данных. Результат кода представлен на рисунке 4.2.
Рисунок 4.2 – Функция save_id() модуля database
Вторая функция fetch_id() модуля database отвечает за извлечение данных из базы. Для этого происходит подключение к БД, а затем выбираются все записи таблицы и формируются в упорядоченный список. Результат кода представлен на рисунке 4.3.
Рисунок 5.3 – Функция fetch_id() модуля database
Модуль compare_doc_database позволяет сравнивать списки ID требований из базы данных и документов для того, чтобы отслеживать изменения в требованиях. Данная функция output_id() на вход получает документ и базу и сверяет: что есть в базе, но нет в документе. Возвращает список найденных ID. Результат кода представлен на рисунке 4.4.
Рисунок 4.4 – Модуль compare_doc_database
Модуль Main предназначен для передачи аргументов функциям других модулей. В нем импортируются все вышеперечисленные модули. В начале создается переменная patterns, содержащая в себе название документа и шаблон. До конечного результата в данном файле осуществлялась проверка работы функций с помощью их вызова. Но целью работы является вывод списков ID требований документов и базы данных, а также извлечение этих идентификаторов. Поэтому в переменные занесены вызовы соответствующих функций. Результат кода представлен на рисунке 4.5.
Рисунок 4.5 – Модуль Main