Визуализатор смысла исходников. Версия lite. Продолжение старых мыслей о VMDL. Пусть для простоты над проектом работает пара инженеров. Один системный архитектор, второй кодер. Различие в кличках != различию в ЗП, они просто решают разные задачи.

Прямая задача.

Придумал архитектор нечто. И надо это нечто донести до кодера. Писать отдельный документ - маразм. Надо писать сразу исходник. На неком обобщенном языке. С мыслями, каментами и пояснениями. Который кодер "по месту" "откомпилит" в С.

Обратная задача.

Написал кодер исходник. Крутой. Одну строку "макроязыка" "раскрыл" в 10 экранов. По ходу усовершенствовал то, что системный архитектор родил. И теперь надо архитектору вкурить всю гениальность кодера.

Тупорылый способ решения.

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

Продвинутый способ решения.

Вводим псевдомакросы. При компиляции они раскрываются в пробелы. VMDL_BLOCK_START ("инициалируем контроллер прерывания") VMDL_BLOCK_END ("инициалируем контроллер прерывания") VMDL_VIZ_START VMDL_VIZ_END Последние два макроса дают возможность выборочной визуализации кода. Например, если это какое-то выражение, по которому идет ветвление, то его надо целиком засунуть в картинку (не копированием!!! Чтобы визуализировалось именно то, что компилится!!!). А если это законченный блок кода, то его визуализируем при помощи VMDL_BLOCK_START и VMDL_BLOCK_END. Парсим исходник "тулзой на питоне". Получаем некий список сущностей. Присваиваем им уникальные номера (автоматом), рисуем граф: номер и название. Стрелочки проставляем в порядке очередности, а также по логике (if, switch,...). Отдельно в конце файла есть закомментированная секция, где мы руками прописываем связи между модулями (если "автоматическому проставляльшику" трудно справиться, или исходник пока не написан - мы его только проектируем). Типа link: "инициалируем контроллер прерывания" "инициалируем UART" link: "блокируеся на таймере" "устройство готово?" Т.е. тулза "стаскивает" в конец файла названия сущностей, по названию на одной строке, ну а мы через copy-paste "рисуем" связи. GraphViz - и вуаля! У нас есть логическая структура кода!!!

Еще более продвинутый способ решения.

Ввести понятие уровень визуализации. VMDL_BLOCK_START (1,"инициалируем контроллер прерывания") VMDL_BLOCK_END ("инициалируем контроллер прерывания") VMDL_VIZ_START (1) VMDL_VIZ_END Тогда можно строить схему с разной глубиной детализации.

Автофолдинг

Вероятно, можно написать макрос для хорошего редактора (VIM, например), который сделает "сворачивание" кода аналогично фолдингу функций.

Дальнейшее развитие.

Ввести понятие модуль кода. И его характеристики:

config - параметры конфигурации модуля

import - какие сущности других модулей использует

export - что экспортирует во внешний мир

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

. Тогда можно визуализировать на уровне крупных модулей (OS, IP, FS, задача под управлением ОСи - это все модули). Так можно будет эффективно разбираться в сложных проектах.