Модель должна охватывать следующие сущности:

• АРМы;
• Базы, используемые в системе;
• Файлы исходников;
• Соединения АРМов с базами;
• Компоненты форм для работы с БД (с текстами запросов);
• Таблицы баз данных;
• Представления, процедуры и функции - те объекты, которые содержат SQL;
• Взаимосвязи между компонентами, таблицами и процедурами;

Связь между объектами является отдельной сущностью и обладает характеристиками;

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

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

• Пути к АРМам;
• Данные для соединения с рабочей БД;
• Данные для соединения с БД информационной системы;

Как вариант https://github.com/masonwheeler/DFMJSON
Можно попробовать преобразовать файл в YAML, выполнив несколько глобальных замен;

• Приделать orm events;
• Пустые поля - где можно, где нельзя;
• Значения по умолчанию;
• Причесать repr;
• методы from_components для ClientConnection и ClientQuery;
• попробовать положить все прямые связи объекта в relationship;

И добавить соответствующие тесты

Итоговый продукт должен справляться с реальными файлами форм из боевой системы (4-5 тысяч строк с русскими буквами, SQL-запросами и т.д.)

Добавить скрипты для обработки *.dproj и *.pas

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

У АРМов есть файл конфигурации .ini, в нём содержатся названия подключаемых БД;
Иногда в коде прописано полное имя таблицы (база.схема.название);

За подключение отвечает компонент TADOConnection с атрибутом ConnectionString;

Отправку запроса в большинстве случаев осуществляет какой-нибудь компонент с формы, который подключен к ADOConnection через свойство Connection.

База, с которой соединяется компонент, может динамически меняться в рантайме.

Текст SQL-запроса тоже может динамически изменяться.

При чтении структуры проекта в путь к модулю добавляются лишние папки.

Научить парсер анализировать файлы быстрее - при обработке всех исходников ждать придётся довольно долго.

Файлы форм закодированы в UTF-8 с BOM, придумать, что делать с этим.

Возникает при декодировании кириллицы в некоторых файлах форм. В самих файлах написана двоичная белиберда; надо определить что это и найти способ привести исходники во вменяемый вид.

Такие случаи есть, надо внести правки в delphitools

• reader и тесты
• tokenizer и тесты
• parser и тесты
• 4 уровень и тесты
• окончательный тест

Интегрировать delphitools, реализовать обработку исходников:

• извлечение данных по АРМам;
• перебор файлов проекта;
• извлечение компонентов;
• поиск соединений АРМа с базами;
• обновление по запросу данных об АРМе/файле по запросу;
• занесение информации в базу.

propertyName = 
anotherProperty = 2

Проверку на выброс исключения при обработке такой ситуации нужно вынести из тестов парсера в тесты токенайзера.

Добавить обработку закодированных символов

Сделать формальное описание синтаксиса формата по форме Бэкуса — Наура. Если это поможет, будет хорошо.

Для справки
https://proglib.io/p/6-diagram-services/

Как итог - все исходники обработаны, структурированы и залиты в базу

• Разделить классы моделей и создание таблиц;
• Отделить работу с сессиями;
• Использовать обычную (не в памяти) базу sqlite;

Добавить токены, тесты - короче, всё, что нужно, чтобы вместо "False" было False

Задокументировать models.py, заготовить диаграмму классов и т.д.

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

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

Задействовать это -
https://github.com/google/styleguide/blob/gh-pages/pyguide.md

Нужно переводить файлы форм в нативные типы данных питона, а оттуда - в json/xml/yaml (yaml выбран потому что он синтаксически намного ближе к dfm, чем любой другой), чтобы иметь возможность быстро обрабатывать содержащуюся в них информацию, пользуясь готовыми инструментами.
Уже кем-то написанные решения, переводящие dfm во что-то разумное либо написаны на делфи и не работают, либо просто не работают.
Превратить dfm в yml, выполнив несколько глобальных замен не получится, надо создавать полноценное решение.
Обратное преобразование (yaml-dfm, json-dfm) делать не нужно.

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

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

• Узнать, как связываются классы;
• Понять, как извлекаются и читаются токены;
• Как разрешаются конфликты между токенами (например '-' как маркер списка и как обычный символ;
• Как детектится конец файла;
• Как происходит переключение состояний;
• Понять, как происходит разбор данных от открытия файла до формирования готовой структуры в памяти;
• Как конструируются структуры данных;
• Как строится дерево документа;

• Parser - переход в предыдущее состояние после разбора бинарника (ещё одно свойство после '}');
• Tokenizer - декодирование русских букв: форматы, временные таблицы с '#' и '##';
• Tokenizer - тесты многострочников во всех вариантах: со сложением строк и без, с разными вариантами конца строки (русская буква, кавычка, '+');
• Tokenizer - закодированная табуляция в начале строки;
• Composer - одинаковые ключи, вложенный объект;

В том числе с учётом русских букв

Некоторые ошибки тяжело засечь на месте без отслеживания отступов и переносов строк;

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

• plotly - визуализация;
• graphviz - визуализация;
• tableprint - вывод данных.

При тестировании боевых компонентов скорее всего придётся читать все эти последовательности как строки, т.к. данных слишком много, всё в массивы не переведёшь.

Написать скрипт для извлечения из БД перечня таблиц, представлений, процедур и функций (пока без связей)