> -- Владислав Жаринов писал(а):
> Какие обнаруживаются у них возможности и ограничения, что можно улучшить?
Здесь нужно говорить не столь в адрес конкретных решений от Дмитрия_ВБ, а в контексте этой темы:Схемы в описании программ. Вотздесьсообщение А.С. Усова на счёт языков для системного моделирования. Выделю ключевое:

> -- А.С. Усов писал(а):
> ... Для схем на UML, наоборот, характерно огромное количество разных типов элементов (едва ли не каждый элемент схемы имеет уникальный тип/класс), и большое разнообразие свя­зей. Такое положение дел не является специфичным для программирования, это следствие низкой культуры проектирования, которая, хочется надеяться, со време­нем повысится....Основная цель этого сообщения состояла в том, чтобы показать, что1. На любом уровне системы, применяемые языковые средства, имеют одну и ту же семантическую основу: элементы и связи;2. В различных областях человеческой деятельности применяются схожие гра­фические описания систем, и данная однородность языковых средств не слу­чайна, а исходит из семантики систем;3. Повышение уровней системы приводит к одинаковым изменениям в языковых средствах, независимо от области применения систем.4. Требования к языковым средствам достаточно просты от функциональных на исполнительских уровнях до логических на уровнях управления и целеполага­ния, что, конечно, тоже не случайно.
И ключевое из "Схемы в описании программ":
> -- Владислав Жаринов писал(а):
> ...Рассуждая для графовой формы записи, можно предложить такой состав классов структур графит-схем:    * маршрутная — такая, что схема есть устремлённый (аранжируемый, сводимый) граф, планарный (без пересечений при укладке на плоскости) либо нет;    * древовидная —такая, что схема есть дерево, каждая ветвь которого м.б. ребром или маршрутной подсхемой с разветвлением/соединением их через ОС-узлы, а также, возможно, «прошивкой» дерева и/или сращением двух и более деревьев;    * сетевая — такой, что схема есть конечное множество вершин с конечными чис­лами входов и выходов, причём входы и выходы м.б. либо связаны попарно (при­надлежа в паре одной или разным вершинам), либо не связаны (временно присо­единяясь к вершинам-туннелям).Предполагается, что в этом составе можно представить любые практически тре­буемые схемы....С учётом сказанного здесь, можно конкретизировать. Так, в ДАЛВЯЗ фактически определены "ордер-блок-схемы" как разновидность структур маршрутного класса.Целесообразные ограничения возможны и для структур древовидного класса.Можно предложить и общие ограничения порядка. Например, такие:    * связи схем всегда ведутся в одном направлении;    * входы элементов всегда с одной стороны, а выходы с другой;    * линии связей всегда прямые, кроме исключений, единичных на одном формате;    * наложения, стыковка и/или вписывание элементов не допускаются, если этому не приписан какой-либо смысл в языке схем данного вида;    * пересечения связей не допускаются, кроме исключений, единичных на одном формате и специально обозначаемых....
В Р-нотации все вопросы уже отработаны. Объединив Р-схемы (плюс Р-методологию в целом) с "Р-таблицами" (таблицы решений + схематические), мы получим "new UML", с новым качественным "уровнем культуры проектирования" (хотя всё это уже было в прошлом). Конкурировать с подобным "Р-стэком" проблематично, в т.ч. и в плане реализации методики построения схем, сделать процесс "клепания" диаграмм таким же лёгким, быстрым и интуитивно понятным, как и работа с текстом или таблицами. Без потенциала для "поточного конвейера" о "мэйнстриме" вряд ли можно говорить. Хотя, например, в области "блок-схемных" решений попалась на глаза такая штука:cloudextend.com, где имеется графический DSL:
Вложение:
sales_force.PNG [ 80.19 КБ | Просмотров: 18740 ]

НапоминаетInteloGraf, только ещё проще. Клепай себе как Mind Maps, думая только над прикладной проблемой, вся укладка автоматом без головоломок и гаданий с лианами и т.д. (даже циклы заданы как концевые переходы, кружочек со стрелкой). В какой-то мере, это некий шаг навстречу к "Р-блокам".

Но лично я предпочту Р-схемы + таблицы (и "Р-текст"). Они обеспечивают не только однородность моделей для всех уровней системы, но и однородность всего рабочего окружения. Если взглянуть на картинку ниже (отсюда), то вполне легко представить вместо связанных "кодо-кусочков" зависимые "Р-кусочки", которые не нарушат "табличную" гармонию всего пространства (фактически, будет тот же текст, подкреплённый линиями):
Вложение:
light-full.png [ 97.38 КБ | Просмотров: 18740 ]

Решения на базе блок-схем имеют более нагруженный характер подачи информации, часто и перегруженный, а то и агрессивный. Эффект усиливается при отсутствии строгой упорядоченности (а ее сложно обеспечить за рамками Дракона, для схем иного типа), при обильном использовании ярких агрессивных указателей вида "адрес-переход" (в т.ч. и горизонтальных) им им подобные, плюс жару может поддать среда формирования изображения, когда применяются, скажем, жирные кричащие линии, и т.д. Собственно, можно и аскетичную Р-среду изуродовать. В целом, важно подумать о правильном построении инженерного рабочего места, без лишних визуальных нагрузок и "графических шумов", и без лишнего нагибания в работе.

Как-то так.