DRAKON.SU

Может ли оно служить прообразом этих моделей? Как первоначальный вариант вполне.
Визуальную подсистему.

Это хорошо. Значит, всех тянет в одном и том же направлении.

Ну, вообще-то я спросил Алексея Донского - это он взялся что-то создавать, засучив рукава.

GUEST, Вы тоже что-то создаете? Вместе или порознь? Это визуальная подсистема чего?

Ну уж! Пока что я выступал в роли провокатора, пытаясь привлечь внимание как можно большего количества умных мужиков к интересным идеям. Разумеется, я с удовольствием присоединюсь, если кто-то будет делать что-то конкретное... Только очень не хочется заранее ставить жёсткие рамки - вот этот проект или вон тот... Особенно, учитывая, что многих из присутствующих интересуют более конкретные задачи (как-то форма представления алгоритма)... А меня больше интересуют глобальные (как-то представление знаний, в т.ч. Седовские идеи).

На самом деле много конкртеных задач есть и на основной работе. Например, сейчас мы рассматриваем вопрос - стоит ли покупать CoDeSys. Или продолжать развивать собственное CASE-средство (пока имеем FBD, идеально подходящий для предметной области, а вот вопросы кодогенерации проработаны пока только под одну целевую платформу... чего явно недостаточно). Драконом тоже заинтересовал своих ребят... Думаем пока что...

Отвечу немного ниже.Это то, что я имел в виду, когда увидел Ваш вопрос. Подсистема для вмещающей её инструментальной системы. Более определенно можно будеть сказать когда интерес к ней наберет критическую массу. А почему это Вас интересует?

Это то, что я имел в виду, когда увидел Ваш вопрос. Подсистема для вмещающей её инструментальной системы. Более определенно можно будеть сказать когда интерес к ней наберет критическую массу. А почему это Вас интересует?[/quote]

Собираюсь делать из своих детей программистов. Абсолютно надежное программное обеспечение жесткого реального времени нужно для моего собственного проекта. А никакого подходящего инструментария не нахожу. На том, что есть, можно программировать только вопреки, а не благодаря. Сегодняшние системы программирования (все!) - это кошмар. Не зря багаж теряется, космические корабли падают, а к каждой программе нужна толпа персонала - исправлять ошибки.

Хочу добавить, что гибрид из блок-схемы, сплющенной в один столбец, и программного кода неоднороден. Из некоторых блоков (ветвление, цикл, переключатель) управление передается на следующий после блока оператор. А из других блоков (модуль, процедура) управление передается обратно в точку вызова. Было бы целесообразно нижнюю границу блоков второго типа делать сплошной или, например, такой:

В Блэк-Боксе аналогичный маханизм, по сути, уже есть: модули содержатся в отдельных файлах, а процедуры при стандартном форматировании выделяются красным цветом.

Уважаемый Сергей Прохоренко!

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



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

Сергей, да нет как таковых никаких "блок-схем"... Что это такое, опишите внятно? Максимум, к чему придёте - это к тому, что задано некоторым стандартом ГОСТ-ISO.

Вам почему-то кажется, что "Дракон - это блок-схемы", на основании каких-то внутренних ассоциаций... И Вы всё время употребляете этот термин.

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

Это не Дракон-схема.
Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19
Я сторонник будущих графических систем программирования (в широком смысле, т.е. не как формы, на которую кидают контролы, и не как традиционной RAD - системы) и визуальных языков программирования (http://en.wikipedia.org/wiki/Visual_programming), но считаю устаревшими и неудобными блок-схемы, в которых может быть несколько (в высоту и в ширину) веток блоков, соединенных линиями последовательности исполнения.

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

Я согласен с тем, как термин "блок-схема" определен в Википедии:
http://ru.wikipedia.org/wiki/%D0%91%D0%BB%D0%BE%D0%BA-%D1%81%D1%85%D0%B5%D0%BC%D0%B0
Дракон подпадает под это определение.
Да, Дракон в сотни раз лучше, чем UML.
Да, в Драконе есть хорошее средство описания конечного автомата, чего нет в других блок-схемах.
Но от этого Дракон-схема не перестает быть блок-схемой со всеми родовыми недостатками блок-схем. Не надо держаться блок-схем. Есть гораздо более удобные средства для визуального программирования. Разумеется, средства описания конечного автомата должны стать частью будущего языка визуального программирования, например, на основе Оберона.

Илья Ермаков писал(а):
А что взамен, в двух словах?

Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19

Илья Ермаков писал(а):
И Вас не устраивает именно представление в виде графа...?

Да. Именно. То, что можно описать в виде графа, вовсе не обязательно описывать в виде графа, так как есть более удобные способы описания. Граф (мне более привычен термин "блок-схема") может быть хорош для описания микроскопических задачек, для черновой или презентационной декомпозиции моделируемой системы и в учебных целях, но не как рабочий инструмент.

Блоки красивые. Исходник показывать так, может быть, и хорошо. Только Вы кастрируете граф до его маленького класса. Возвращаетсь к топологии, характерной (и необходимой) для текстового представления. Строго линейно-иерархическая блочная структура. Так чего огород городить, чтобы получить всё то же самое?


Так нет другого способа успешно решать задачи как сводить их постепенно, пошаговым погружением, к ансамблю таких вот "микроскопических задачек". Чтобы способ решения и правильность каждой была уже очевидной. Я лично обсуждаю в этих темах Дракон (или его развитие) как язык для описания каждого отдельного узла такого ансамбля... И если узел слишком сложен для описания его таким образом, требует более комплексной формы представления, значит он требует анализа и декомпозиции на подузлы...

А способ проектирования и представления этих самых ансамблей в целом я вообще здесь не затрагиваю. Это отдельная песня...

Да, я избавился от линий передачи управления (это о кастрации несчастного графа), нежелательность пересечений которых столько обсуждалась. Если команды выполняются последовательно сверху вниз, то никакой потребности в линиях нет. А если линейная последовательность нарушается, то для этого используются языковые конструкции структурного программирования (без GOTO). Место, куда передаётся управление, легко зрительно отследить по очертаниям блоков и отступам - без каких-либо дополнительных линий. Если внутри блока должно быть несколько веток, то все они будут показаны изначально в свернутом виде (с комментариями) - одна под другой.

В чем достоинства?

Это, во-первых, возможность оперировать блоком как единым целым: вставлять, дублировать и настраивать шаблон блока, соответствующий выбранной языковой конструкции, удалять блок, копировать, перемещать, свертывать/разворачивать, выделять цветом.

Во-вторых, блок образуется автоматически (и уже со своим отступом), и поэтому нет необходимости вручную указывать, где делать фолдинг. Фолдинг будет возможен везде, где это логично. Нет нужды и в форматтере - форматирование производится изначально.

Третье достоинство - возможность иметь блоки-таблицы, например, таблицы свойств, таблицы переходов конечного автомата и т.п.

Четвертое достоинство - текст блоков в несколько колонок. Например, колонки: идентификаторы, типы, комментарии. Работа парсера упрощается до предела (всю разбивку за него уже сделал программист). Взаимосвязи между любыми объектами (не только в смысле ООП) программы становятся доступными для автоматического анализа еще до какой-либо компиляции.

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




Представляется, что визуальная форма нужна не для того, чтобы сделать толко черновой эскиз, который потом ещё нужно вручную превращать в исходный код. Вся прелесть визуального программирования как раз в том, что исходный код генерится автоматически. Раз это так, то нельзя ограничиться стопкой крохотных блок-схем. Нужно ещё что-то, что объединяло бы "микрозадачи" в большую систему. Чтобы, например, указав на идентификатор, можно было бы посмотреть, с чем он связан (влияющие и зависимые переменные и т.п.). А объединить блок-схемы весьма проблематично, в отличие от предложенного мной гибрида одноколончатой блок-схемы с исходным кодом. К тому же изначально маленькая блок-схема микрозадачи может так разрастись, что станет необозримой, а её разделение на несколько маленьких трудоёмко и чревато ошибками.

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


Согласен.


Нужно. Я просто намеренно не лезу здесь в этот вопрос
Ну ладно, давайте чуть-чуть полезем.
Представьте, что "блок-схема" - это описание автономно функционирующего, изолированного (software-isolated) процесса. Как в Zonnon, Singularity, Composita, Erlang - и подобных перспективных моделей параллельно-распределённого программирования. Никаких общих переменных ("влияющих и зависимых, посмотреть, с чем связан идентификатор..."). Только обмен типизированными сообщениями по протоколам. (ну ещё вызов вспомогательных алгоритмов, но не имеющих состояния (обычная процедурная декомпозициия)).

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

Я думаю, что одномерные и двумерные блок-схемы взаимно обратимы. Но для двумерных существуют всякие топологические проблемы, которые могут быть решены только дизайном вручную. Конструировать программу из блоков проще (и программисту, и системе программирования) в виде одномерной блок-схемы, не заморачиваясь взаимным расположением блоков, пересечениями линий, вылезанием за границы листа и т.п. Если же очень хочется двумерную блок-схему, то компьютер может накидать блоки, а уж потом программист будет таскать их туда-сюда, добиваясь выразительности, лаконичности и верифицируемости (последнее для меня непонятно в данном контексте - чем двумерные блок-схемы лучше для верифицируемости?). Нечто подобное уже существует в MS Access. Что касается языков - двумерных блок-схем, то они вовсе не ограничиваются Драконом, но успеха не завоевали.



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

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

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

Пазвольте... ЕСПД ГОСТ 19.002-80
Там много любопытного:Линии потока,канал связи,модификация и пуск-останов,а? какие паруса....



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



Стал Ваня лазить
В папину кассу
Стал безобразничать
Красть денег массу!
Динь-динь-дон,динь-динь-дон,
Так звенят кандалы.
Так порой из-за баб
Погибают ослы

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

Кстати, автоматы не конечные. А вообще разные бывают. Физически любое вычисление = автомат (в головке машины Тьюринга). И никакого имитационного моделирования я в виду не имею, т.к. им не занимаюсь(лся).

В целом, мы с вами спорим по частным вопросам, опираясь на какие-то свои фоновые мета-соображения. Тот же Дракон у меня - частность, в сетке некоторых общих соображений (и знаний о различных существующих путях/решениях). Удачно в неё вписывающаяся. А прояснять здесь и сейчас эти мета-соображения лично я не готов.