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

Если бы ты развил мысль на наглядном абстрактном примере... Т.е. код и полученная схема.

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

Цены бы не было такому парсеру, если бы он генерировал алгоритм наподобие этого:


Есть ещё один важный момент. Что бы диаграмма была более читабельной, необходимо иметь возможность управлять логикой её генерации. Например здесь описана такая возможность, в разделе "Changing arrow direction". По опыту могу сказать, что без этого будет получаться, скажем так, не то. Например:

/*
@startuml
title The architecture of the site

skinparam componentStyle uml2
skinparam component {
  BorderColor<<P>> #FF6655
}

component "Template Engine" as TEN <<P>>
component "Builder" as Builder <<P>>
component "Router" as Router <<P>>
component "Web Server" as Server
component "Data Base,\nCache" as DB

interface "HTTP(S)" as HTTP

Server -r- HTTP

HTTP .r.> Router: Proxy

package "Project" {
    component "Static" as Stat
    component "Templates" as TMPL
    component "Applications" as Apps

    interface "Data\naccess" as API

    TMPL .r.> API
    TMPL .d.> Builder: Configure

    Apps -l- API
    Apps .r.> DB
}

Router -r-> TEN
TEN -d-> TMPL: Rendering
Builder --> Stat: Build
HTTP .d.> Stat: Proxy
TMPL -u-> HTTP

note right of Builder: It works once at initialization

@enduml
*/

Результат:


Здесь практически для каждой связи используются указания направления (.d. - down, -r- - right и т.д.). Вот, что будет без них:

/*
@startuml
title The architecture of the site

skinparam componentStyle uml2
skinparam component {
  BorderColor<<P>> #FF6655
}

component "Template Engine" as TEN <<P>>
component "Builder" as Builder <<P>>
component "Router" as Router <<P>>
component "Web Server" as Server
component "Data Base,\nCache" as DB

interface "HTTP(S)" as HTTP

Server -- HTTP

HTTP ..> Router: Proxy

package "Project" {
    component "Static" as Stat
    component "Templates" as TMPL
    component "Applications" as Apps

    interface "Data\naccess" as API

    TMPL ..> API
    TMPL ..> Builder: Configure

    Apps -- API
    Apps ..> DB
}

Router --> TEN
TEN --> TMPL: Rendering
Builder --> Stat: Build
HTTP ..> Stat: Proxy
TMPL --> HTTP

note right of Builder: It works once at initialization

@enduml
*/

Результат:


Читабельность явно пострадала.

Ну и ещё один момент. PlantUML может генерировать схемы разного типа. Парсер же кода - одного.

Но всё вышесказанное никак не должно восприниматься как попытка отговорить от этой затеи. Я лишь хочу показать подводные камни, которые могут возникнуть. Их скорей всего будет больше, я лишь привел те, что первыми пришли в голову.
В любом случае мысль интересная, я бы понаблюдал как минимум.

Да, верно. Но не всегда, смотря какую схему мы хотим иметь в итоге.

Я бы сказал, смотря что ты хочешь показать. Фаулер пишет, что есть три варианта использования UML: 1) sketch (диаграммы, нарисованные с целью показать "нечто", все несущественные детали опущены), 2) blueprint (весь проект описан с помощью UML со всеми деталями), 3) язык программирования. Он сторонник первого подхода.

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

Мне по сути не нужна идеальная схема. Я провел очень много времени делая разные не нужные дела, изучая различные программы и т.д. Хочу автоматизации процесса.

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

Ну да, так наверно точнее будет.

В принципе логично.

Если говорить в контексте PlantUML, то в этом случае код схемы должен быть в общем родительском уровне описываемого кода. Я думаю это логично.
Например: схема, описывающая работу NodeJS-модуля (состоящего из нескольких файлов) должна находится либо в коде индексного файла, либо отдельным файлом в корне модуля.

Если парсер будет генерировать человеческие диаграммы, то да. Иначе толку не будет.

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

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

Gozar, а думаешь, связи тебе сильно помогут?

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

Они все человеческие :) Главное чтобы мне было понятно. Мне особо без разницы, будут они красивые или просто шарик со стрелками в разные стороны. Мне нужно, чтобы я путь мог отследить. А для этого красота не очень важна. Но если получатся красивые, я буду только рад.

а зачем тебе связи?

А зачем мне схемы?