Различия

Здесь показаны различия между двумя версиями данной страницы.

--- jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:drakon_shampur_ocenka [2012/03/10 13:43]
Владислав Жаринов [Разметка схем и гибридные техноязыки] - ссылки, формат
+++ jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:drakon_shampur_ocenka [2012/03/22 17:13] (текущий)
Владислав Жаринов [Разметка схем и гибридные техноязыки: ДРАКОН начинает, ГРАФИТ выигрывает]
@@ Строка 1: / Строка 1: @@
 Эта страница только формируется.
-====== Оценка техноязыка и шампур-метода ======
-Безусловно, ДРАКОН-визуализация отличается от традиционной визуализации потоков управления блок-схемами. Сам Паронджанов указал на это следующим образом:
-Задача формализации и унификации множества профессиональных языков с целью обеспечить эффективное взаимопонимание между специалистами любых профессий, включая программистов, является, хоть и важной, но, увы, неразрешимой. Положение в корне меняется, если ограничиться императивными профессиональными знаниями. Именно эту задачу решает язык ДРАКОН. Он построен путём формализации, неклассической структуризации и эргономизации блок-схем алгоритмов и программ, описанных в стандартах ГОСТ 19.701-90 и ISO5807-85. (Паронджанов В.Д. Как улучшить работу ума, с. 36)
-Смысл сказанного можно раскрыть через «формулу новизны», как это и принято для официального описания существа изобретений. Напомним, что она имеет вид: «<Предлагаемый сабж> отличается от <такого-то существующего сабжа> тем, что имеет <такие-то новые фичи> и/или <такие-то фичи>, имевшиеся в <существующем сабже>, здесь реализованы с <такими-то отличиями>».
-Здесь можно сказать, что техноязык отличается от языка, заданного стандартами на блок-схемы (далее - БС), тем, что:
-  * устанавливает требования к графике вершин и линий схем с учётом удобства восприятия «слепыша» и компоновки содержания вершин;
-  * использует понятие вложения для применения принципов исчисления к графам;
-  * упорядчивает схемы за счёт принципов шампура и главной/побочной вертикалей;
-  * использует соединители, принятые для блок-схем как межстраничные, в новом качестве — как внутрисхемные для укладки схемы на плоскости без пересечений цепей и с возможностью структуризации содержания;
-  * даёт возможности выразить топологии потоков управления, характерные как для структурной, так и для неструктурной алгоритмизации (программирования), также через операции исчисления;
-  * предлагает некоторые правила разметки вершин и линий.
-Можно раскрыть эти отличия (а также сходства, оставшиеся с БС) и одновременно оценить шампур-метод (далее - ШМ) и язык, возможности его развития.
-На рисунках далее мы будем пользоваться элементами когнитивной графики, как принятой у Паронджанова, так и новой. Словарь обозначений можно найти [[http://grafit-basis.narod.ru/L3/usl_obozn.html#Pril1-n12|здесь]].
-===== Графика вершин =====
-По идее когнитивной формализации знаний, в ШМ она должна прежде всего удобно вмещать текст (и/или таблицы, если они допустимы как содержание вершины некоторого типа). Поэтому из БС-графики заимствуются только такие формы икон и их частей, которые и наглядны сами по себе, и удобно и экономично вмещают текст.
-Как следствие, по сравнению с блок-схемами некоторые формы блоков получают новые значения (к примеру, форма-трапеция – как основа хронизаторов реального времени), а другие (скажем, ромб) не используются.
+==== Доалгоритмическая формализация: хороший командир указывает, ЧТО, но не указывает, КАК ====
-В то же время композиция многофигурных вершин м.б. более стройной, если ввести общие законы их построения. Возможны следующие:
-вертикалей окружения — вводятся условные оси, параллельные шампуру схемы и представляющие совокупные потоки управления процессов, взаимодействующих с алгоритмическим процессом, описываемым схемой;
-событийного следования — фигуры в вершине и/или части её содержания упорядочиваются по шампуру в порядке исполнения.
-В части первого нужно раздельно представлять процессы того же исполнителя и процессы его внешней среды; поэтому следует ввести оси по обе стороны шампура; фигуры, представляющие связь с соответствующей категорией процессов, для удобства чтения нужно сделать как по форме направленными на ось, так и по положению смещёнными к ней.
-В части второго предшествующие события представляются фигурами, расположенными ближе к началу шампура; кроме того, можно использовать уровни глубины, если допускать частичное перекрытие фигур в вершине.
+Это правило (своего рода неформальное военное поучение) для нашей темы отражает важное обстоятельство — алгоритмизация (и последующее программирование/инструктирование) требуют от сочинителя понимания постановки задачи (что «дано» решателю и что «надо» от него — включая различные начальные и граничные условия). А эта постановка, в свою очередь, отражается на соответствующих языках представления отчуждаемых знаний — дескриптивных — по своей сути ничего общего с императивными языками не имеющих. И решение в этом случае тоже отражается дескриптивно — какие отношения и сущности надо преобразовать и что для этого надо сделать (формально — какие логико-математические операции, функции и где применить).
-Можно видеть, что в ШМ принято единственное правило — располагать фигуры вершины «лесенкой» всегда справа налево и направленные формы фигур направо - более простое, но менее информативное.
+«ЧТО»-язык отражает некие сущности решаемой задачи и её предметной области (не обязательно объекты алгоритма) и некие отношения между ними. Такие языки тоже бывают как чисто текстовыми, так и графитными. Пример последнего — язык информационного моделирования IDEF1X. Он отражает только систему отношений между сущностями. Для записи преобразований (отдельно или вместе с сущностями-отношениями) существуют другие языки — скажем, т.н. функционального или логического программирования. Ряд таких языков имело бы смысл «графитизировать» — но делать это нужно по иным принципам, чем для императивных языков. Примером могут служить языки схем зависимостей, потоков данных, такие как [[http://grafit-basis.narod2.ru/L3/mental-vspom.html#Pril2-n38|функциональные схемы, ДПД]], [[http://forum.oberoncore.ru/viewtopic.php?f=28&t=3884|Анимо]]. Следует выработать эргономические оптимальные правила организации таких схем. В чём-то может помочь опыт эргономизации системных схем, частично зафиксированный в стандартах на такие схемы (типа ЕСКД).
-Также алфавит БС функционально шире, чем в ДРАКОНе. Блок-схемы предназначены для представления содержания всей программы (в смысле расширенного тезиса Вирта). Поэтому, кроме подалфавита импер-части (называемой в БС «схема алгоритма»), предусмотрен также подалфавит для деклар-части («схемы данных»). Имеются также средства для представления материальных действий («техпроцессов» по Паронджанову) и структур (актив-части). Однако назначение ДРАКОНа — представлять только императивные знания; поэтому остальной алфавит здесь не нужен.
+Условия применения «ЧТО»-описаний хорошо сформулированы у Кауфмана:
-===== Вложение и структурные изменения на графах =====
+//Людей как исполнителей характеризует прежде всего наличие у них модели реального мира, в достаточной мере согласованной с моделью мира у создателя плана <т.е. описания поведения исполнителя>. Поэтому в плане для людей можно указывать цели, а не элементарные действия. ([[http://forum.oberoncore.ru/download/file.php?id=3066|ЯП. Концепции и принципы, с. 31]])//
-В текстовом программировании известны применения вложения в той или иной форме (например, в архитектуре и программировании отечественных машин семейства «Эльбрус»; см. [[http://forum.oberoncore.ru/viewtopic.php?p=52411#p52411|это сообщение]]).
+Такую возможность как раз даёт аппарат мышления человека. Не случайно идут поиски объяснений механизмов мышления, попытки их формализации.
-В рамках ШМ это понятие было применено к графам. При этом среди рёбер графа выделяются такие, что допускают замену на тот или иной подграф — т.н. //рёбра ввода//. Этот подграф называется //атомом// и всегда имеет один вход и один выход; оба они представлены рёбрами ввода, между которыми располагается смысловая часть — так сказать, «ядро» атома. Оно м.б. единственной вершиной или также подграфом (для ДРАКОНа - типа ветвления или цикла). Во втором случае рёбра ввода также м.б. в «ядре».
-В исходном ШМ на ребре ввода определена т.н. //валентная точка// — вспомогательная вершина, на месте которой ребро как бы можно разорвать и вставить в разрыв атом так, что части разорванного ребра становятся продолжениями рёбер вставляемого атома.
-В процессе обсуждения ШМ было предложено называть валентные точки //точками ввода//, а также отказаться от определения этих точек как вершин и считать само ребро допускающим ввод.
-Принцип вложения (ввода атома) показан на рисунке ниже.
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_m5d093cb2.gif? |}}
-===== Операция ввода атома в шампур-методе =====
-Для исчисления схем на конкретном шампур-языке задаются множества атомов и заготовок схем. На каждом определяются рёбра ввода. При этом для более удобного представления ветвления на множество вариантов Паронджановым предложена атомарная структура «переключатель».
-Кроме вложения, в ШМ определены также операции изменения топологии схемы, не нарушающие структурности. Это добавление/удаление варианта переключателя, удаление конца схемы («зацикливание» алгоритма в целом — от начала до конца), боковое присоединение (добавление вершины-модификатора к другим вершинам).
-Схематически можно представить сказанное о вершинах, атомах и заготовках, как на следующих рисунках.
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_f52ad4a.gif? |}}
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_30622066.gif? |}}
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_1fc6b470.gif? |}}
-Здесь также представлены основные структурные операции (кроме удалений).
-===== Упорядочение маршрутов =====
-Принципы ШМ эргономически выгодно отличаются от принятого в блок-схемах порядка, при котором:
-  * выходы развилок (предикатных вершин) обычно направлены в разные стороны от оси входа;
-  * вход и выход вершин следования не требуется располагать на одной оси (а обычно даже их оси составляют прямой угол, т.е. вершина в то же время является точкой излома следования; часто это делают, чтобы «сэкономить» на звене вертикали перед/после излома);
-  * возможны наклонные линии связей, часто «ступеньки» на них, порой даже «обратное следование» - загиб вертикали против направления от начала к концу схемы.
-Иногда такую организацию блок-схем называют «анархической». Она критикуется рядом авторов, скажем, Б. Мейером в [[http://forum.oberoncore.ru/viewtopic.php?p=69170#p69170|"Почувствуй класс", Гл. 7]].
-По сути, в стандартах на БС и не существует чётких правил упорядочения элементов и подсхем. Тогда как ШМ, в общем-то, и есть система таких правил, только данная в математическом смысле не формально («что есть правильная схема»), а конструктивно («как построить правильную схему из правильной заготовки»).
-В сравнении с БС упорядоченность шампур-схемы можно видеть на рисунках ниже.
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:part_viz_know_html_m5dd068a.gif? |}}
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:part_viz_know_html_2ef165be.gif? |}}
-Шампур-схема закономерно асимметрична. Это даёт возможность показать упорядоченность маршрутов по какому-то критерию. Не всегда такой критерий нужно или можно определить по смыслу схемы; в этом случае порядок м.б. произвольным или введён сочинителем по какому-то абстрактному правилу.
-В то же время запрещение ступенек и загибов сужает возможности компоновки схемы в конкретном формате. Однако это можно понимать как плату за упорядоченность схемы.
-===== Укладка схемы на плоскости =====
-Структуру связей предмета описания не всегда можно показать двумерно без пересечений. В математике схему типа представляющей структуру императивного знания — маршрутов деятельности, потоков управления — называют **//аранжируемым/устремлённым/сводимым графом//**, а если в этом графе нет пересечений — говорят, что он также **//планарный//**.
-В текстовой форме связи подразумеваемы совпадением имён начал и концов, и пересечения неявны. В форме же схемы они становятся явными. Как считает Паронджанов, это затрудняет восприятие структуры. Для исключения этого на шампур-схему как аранжируемый граф как раз и накладывается ограничение планарности. Непланарный же устремлённый граф нужно «уложить» на плоскости, устранив пересечения. Как это делается по шампур-методу?
-Непланарная аранжированная схема с пересечениями (в терминах ШМ — //примитив//) разделяется веточными соединителями на блоки-единицы укладки — //ветки// — так, что из каждой пары пересекающихся цепей одна оказывается проходящей через подсхему связи веток — своего рода **//кросс//** (по аналогии с сетями связи; в проводке компьютерных сетей часто называется «патч-панель»). Тем самым пересечение устраняется. Уложенная на плоскости аранж-схема в ШМ называется //силуэтом//, а кросс-подсхема — //петлёй силуэта//.
-Силуэт можно и получать сразу — выводом из заготовки (ШМ-аксиомы). Только такой путь и допустим в ШМ; поэтому Паронджанов рекомендует мало-мальски сложный алгоритм визуализировать сразу как силуэт — чтобы избежать его вывода заново. Заготовка имеет исходно минимальноое число веток (две); определены операции добавления/удаления ветки в силуэт.
-Пример укладки показан ниже (для той же схемы, на которой демонстрировалась упорядоченность маршрутов).
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_468e7188.gif? |}}
-Видно, что в петлю силуэта можно уложить и петлю цикла. Так образуется т.н. //веточный макроцикл// (далее — ВМЦ).
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:part_viz_know_html_260e06df.gif? |}}
-Паронджановым доказаны теоремы о представимости любой структуры маршрутов алгоритма (т.е. фактически любой устремлённой схемы) как силуэта. Т.е. силуэт есть т.н. универсальная программа.
-Силуэтная укладка есть физическое подразделение структуры маршрутов. Петля силуэта представляет связи веток как совокупность возвратных переходов с выходных соединителей на входные. В императивном смысле (для дракон-силуэта) это простые безусловные переходы. Достоинство их силуэтного употребления — в том, что передачи возможны не в произвольные места схемы, а лишь в заданные делением на ветки. Тем самым допускается goto, но также ограниченный — только на начала веток. Недостаток — в том, что переходы явные, и в терминах программирования дракон-силуэт м.б. представлен только на языках с явным БП (на ЯВУ с goto и на машинах с командой jmp-типа).
-Недостаток можно преодолеть, если перейти к логической укладке маршрутов. Имеется в виду, что вход в единицу укладки определяют не соединители, а условия выбора. Проще говоря, нужно перейти от деления схемы соединителями к делению разветвителями. Фактически они присутствуют в «петле силуэта», но их условия (т.н. охраны) имеют смысл исключительно проверок совпадения значений адреса целевой ветки и имени текущей.
-===== Атомарные и лианные структуры =====
-Известно, что минимально для представления любой структуры маршрутов достаточно только следования и цикла; менее строго к этому добавляется также ветвление. По ШМ такое представление очевидно выводимо одним вложением соответствующих атомов. Поэтому можно называть получаемые структуры //атомарными// — такими, что тело схемы всегда можно «без остатка» подразделить на атомы языка этой схемы (и без перекрытия границ подразделений — только с плным вхождением, если подразделяется «матрёшка»). Другие упомянутые выше ШМ-операции атомарности тела схемы не нарушают.
-Все теоретически возможные структуры маршрутов не всегда можно получить только вложением. Имеются в виду структуры с БП — произвольным внутри программы (goto) и изнутри цикла на его начало/конец (т.н. break/continue-заменители). Для их представления Паронджановым было введено понятие лианной структуры маршрутов и операция ''пересадки лианы''. В результате в техноязыке возможно представить структуры циклов с заменителями, и сверх того — некоторые случаи goto в разветвлённых алгоритмических структурах (на ближайшие слева/справа вертикали). Как результат пересадок лианы могут возникать связи, нарушающие атомарность тела примитива (ветки силуэта), и их соединения тоже требуют представления явными БП.
-В силуэте у ветки возможны и побочные выходы. Они получаются как в результате укладки примитива с пересечениями, так и при изначальном сочинении силуэта. Для создания побочных выходов в ШМ включена операция ''заземления лианы''.
-Примерное выполнение этих операций показано на рисунках.
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_m78d9ffef.gif? |}}
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:proekt_statja_-_ocenka_texnojazyka_i_ishm_kak_razvitija_stbs_html_m139b893d.gif? |}}
-Очевидное достоинство такого подхода — техноязык практически нейтрален к структурности алгоритмов («войне языков» высокого уровня по поводу goto и заменителей). Если принять подход противников явных БП в ЯВУ — можно отказаться от операций с лианой и алгоритмизовать только атомарными структурами. Если принять подход сторонников — разрешить лианные операции и структуры.
-Недостаток разрешения лианных структур — тот же, что в случае силуэтной укладки схемы — необходимость в явных БП для представления соединителей. Аналогично он и преодолевается.
-===== Структурная алгоритмизация и шампур-метод =====
-Недостаток силуэтной укладки как физической можно преодолеть, если перейти к логической укладке маршрутов. Имеется в виду, что вход в единицу укладки определяют не соединители, а условия выбора. Часто об условных переходах говорят, что их условие «охраняет» выход, соответствующий истинности (или просто называют условное выражение //**охраной**//). Тогда любой набор значений входящих в это выражение величин, при котором условие истинно, можно называть «паролем» охраны. Понятно, что паролей м.б. и больше одного — это зависит от выражения (вида условий, значений входящих переменных и констант).
-Проще говоря, нужно перейти от деления схемы соединителями к делению разветвителями. Фактически они присутствуют в «петле силуэта», но их условия (охраны) имеют смысл исключительно проверок совпадения значений адреса целевой ветки и имени текущей. Возможность и логической укладки (исключения межветочных БП), и отказа от явных БП в теле схемы даёт //**цикл Дейкстры**// (далее - ЦД) как иная форма универсальной программы. Это можно видеть на схемах ниже.
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_6ead9a8e.gif? |}}
-Для упрощения силуэт мы показали одноадресным и без дополнительных входов.
-Здесь фактически вводится новый тип устремлённого планарного графа, называемый //дейкстралом//. Он обеспечивает универсальность за счёт того, что ЦД-ветви можно выбирать в любом порядке (пока мы не вышли из цикла). Если представить, что телом каждой ветви служит простой шампур-блок (отдельный линейный участок) схемы алгоритма — скажем, примитива, — то это значит, что мы можем организовать в ЦД любой из порядков выбора, возможный в этой схеме.
-В силуэте реален как циклический (действительно идёт против шампура) только один переход — с конца на начало силуэта, когда он «зацикленный» (реагирующий). Остальные переходы на главном маршруте силуэта реально идут по шампуру. Поэтому разветвления для выбора их в петле силуэта фиктивны — никаких условных переходов на самом деле для этой цели не нужно. Как следствие, адрес перехода с главного выхода ветки предопределён — всегда на следующую справа ветку. Можно считать — хотя в шампур-методе это не оговорено, ибо он исходно определён только для «слепышей» — что тексты икон Адрес для главных выходов веток назначаются автоматически по правилу «чем правее, тем позже» — соответственно и циклы по этим выходам невозможны.
-В многоадресном силуэте побочные выходы, возможные в любой неконечной (т.е. заземлённой по шампуру) ветке, могут давать как прямые, так и возвратные переходы — всё зависит от желания сочинителя, т.к. он имеет право ввести в икону Адрес любое имя ветки данного силуэта. Если это имя текущей или более левой ветки — образуется ВМЦ. Вообще говоря, такие циклы тоже нельзя образовывать произвольно, если хотя бы два из них охватывают более, чем по одной ветке. Поскольку тогда возможно пересечение циклов, что в структурной алгоритмизации не допускается.
-В дейкстрале каждый переход между его ветвями реально циклический — т.е. идущий против шампура. Потому и выбор ветви реальный — каждый раз надо проверять условие на входе каждой ветви, начиная слева, пока не обнаружится первое истинное — в эту ветвь и войдёт исполнитель на очередной итерации цикла. Задача сочинителя — так сформулировать выражения охран, чтобы выбирались ветви, нужные по условию задачи. Конечно, и тела ветвей дейкстрала не обязаны быть линейными — в них также м.б. развилки (плечи которых не выходят за пределы тела ветви).
-В принципе можно организовать внутри ветви и один или больше локальных циклов — но часто бывает удобнее замкнуть все циклы алгоритма через кросс дейкстрала. Тогда тело простого цикла целиком будет телом какой-то ветви, а тело гибридного — двух ветвей (для ДО- и ПОКА-частей).
-Принцип практической реализации всех упомянутых типов схем можно показать совмещённо, как на следующем рисунке.
-{{ :jazyk:soobschenija_o_jazyke_i_metode_ischislenija_ikon:st_drakonsu_-_ocenka_texnojazyka_i_ishm_html_7405715d.gif? |}}
-Здесь можно видеть, чем представляются вершины кросса в системе команд типичного исполнитля алгоритмов — машины с адресной архитектурой. Это команды БП — простого и с возвратом.
-Использование ЦД возможно двумя путями:
-  * вывода тела дракон-схемы или его части как ЦД в рамках ШМ-правил (как варианта вложенного цикла);
-  * модификации метода для использования ЦД-организации схем, начиная с аксиом.
-Первый путь требует только единообразного порядка вложения при выводе схемы как примитива — новая ветвь ЦД добавляется вводом дракон-атома обычного цикла как ДО-подтела цикла предыдущего уровня вложенности.
-Второй путь предполагает определение заготовки для вывода схемы как ЦД, ЦД-атома, а также операций добавления/удаления ветви (аналогично добавлению/удалению ветки силуэта).
-Определённая сложность логической укладки в том, что структуру нужно логически выводить изначально, пользуясь методами т.н. доказательного программирования. Для неподготовленного сочинителя это может представлять известную проблему. Возможны следующие пути её решения:
-  * пользоваться известными методами формальной спецификации задачи, хорошо разработанными и допускающими эргономизацию;
-  * приводить разработанные силуэты и/или лианные макроблоки к форме ЦД.
-Среди первых можно выделить т.н. [[http://forum.oberoncore.ru/viewtopic.php?p=52313#p52313|автоматное программирование]]. Спецификации конечными автоматами естественны для задач управляющего (реагирующего) рода и рядом специалистов считаются наглядными.
-Показано, что дракон-силуэт можно преобразовать в ЦД-схему. Тем самым ЦД-укладка обратно совместима с силуэтной. Т.е. можно переводить «силуэтно-унаследованные» визуализации алгоритмов и потоков управления программ в ЦД-запись.
-Важное преимущество ЦД как замены силуэта в том, что его ветви имеют один выход. Тем самым отпадает нужда в ШМ-операции «заземление лианы». Кроме того, в рамках доказательного программирования Дейкстрой, Виртом и другими исследователями было показано, что в теле ЦД также не нужно употреблять явных БП, чтобы получить те же маршруты, что и с их использованием; соответственно не требуется операция «пересадка лианы». Как следствие, редактор, реализующий только логическую укладку, м.б. упрощён в плане как алгоритмов, так и структур данных; очевидно, это даст большую его производительность.
-Другое преимущество в том, что доказательность достигается с участием текста вершин. Тем самым сочинитель уходит от частичной корректности программы в визуализированной форме (которую только и обеспечивает ШМ, как указывал Паронджанов) к полной. Но визуализация может облегчать правильное построение программы и проверку корректности.
-===== Разметка схем и гибридные техноязыки =====
-В ШМ она, по сути, не рассматривается. По определению это исчисление «слепышей», т.е. неразмеченных графов (без учёта текстоэлементов синтаксиса схем). Однако на практике возникает необходимость по крайней мере в двух типах разметки шампур-схем:
-  * для выходов развилок — надписями «да»/«нет» при выходных рёбрах;
-  * для веточных макроциклов (ВМЦ) — какими-нибудь индексами, позволяющими отличить разные ВМЦ в одном силуэте.
-Первый тип можно реализовать и иначе — вершинами, несущими надписи. Такое решение можно видеть в предложениях Рэйлвей Кагена для его ПРОТОН-нотации. По сути, такие вершины — эквиваленты икон ''Вариант'' в макроиконе ''Переключатель''.
-Второй тип может иметь синтаксис, предложенный некоторыми пользователями техноязыка и показанный у Паронджанова(см. выдержку в [[http://forum.oberoncore.ru/viewtopic.php?p=57898#p57898|этом сообщении]]). В веточные соединители добавляется поле индекса ВМЦ.
-По Паронджанову предлагается разделять шампур- и гибридную формализацию императивных знаний. В первом случае определён т.н. маршрутный граф-язык «слепышей», представляющий только управляющие знания — т.е. структурную часть императивной составляющей знания — для любых существующих и мыслимых чисто текстовых языков (узко императивных или содержащих императивную составляющую). В этом понимании маршрутный язык есть полиязык для текстовых. Во втором определяется гибридный техноязык путём:
-  - выделения в чисто текстовом языке управляющей части и замены её на маршрутный язык (синтаксис «слепышей»);
-  - разметки остальным содержанием текстового языка вершин и рёбер «слепыша».
-Выделение управляющей части может оказаться нетривиальной задачей; её наличие определяется высотой абстракции языка от алгоритмического исполнителя (машины или арифметической модели алгоритма).
-Управляющие знания логически есть одна часть из двух (структурной и атрибутивной) в одной составляющей из четырёх (императивной, декларативной, активностной и обобщающей). Это следует из известного тезиса Н. Вирта (программа = алгоритм + структура данных + систематическое представление об исполнителе; см. в [[http://forum.oberoncore.ru/download/file.php?id=1881|этой статье]]), а также из факта существования т.н. [[http://ru.wikipedia.org/wiki/Парадигма_программирования#.D0.A0.D0.B0.D0.B7.D0.BB.D0.B8.D1.87.D0.BD.D1.8B.D0.B5_.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F|парадигмы программирования]] как способа увязки частей описания программы (по Вирту) в единое целое. Однако синтаксический объём этих частей в разных языках не обязательно одинаков. Существует и [[http://forum.oberoncore.ru/viewtopic.php?p=71247#p71247|подход В.Ш. Кауфмана]] — язык программирования определяет данные, операции и их связывание.
-Проще говоря, любой язык программно строгой формализации распадается на ряд подъязыков, один из которых играет интегрирующую роль. И нужно определить синтаксис каждого языка. Создатель техноязыка указывает на необходимость единых правил построения объектных имён, информативных и удобных для восприятия; для этого нужна и достаточная длина имени:
-«...множество 32-символьных идентификаторов образует весьма выразительный, хотя и своеобразный, язык, законы и правила оптимизации которого ещё предстоит открыть, обсудить и подвергнуть экспериментальной проверке.» /Как улучшить работу ума, с.163/.
-В то же время командная часть императивного подъязыка (так сказать, «имена действий») также должна иметь текстовый синтаксис. Нужен и синтаксис их сочетания в дракон-вершинах.
-Определённое достоинство такого пути (можно сказать, частной гибридизации) в его простоте — определение гибридного языка можно получить без больших видимых усилий. На практике же проявляются недостатки. Их можно объяснить, исходя из сказанного выше при обосновании языка и метода.
-Во-первых, неуправляющее содержание языка, полного в смысле Вирта и парадигмы программирования, как нетрудно видеть, логически составляет семь восьмых от всего содержания любого описания на этом языке. Поэтому объём разметки м.б. весьма значительным. Практически в любом случае возникает «перекос» в сторону текста в гибридной схеме, что может умалять эргономический эффект от визуализации маршрутов.
-Во-вторых, для некоторых парадигм, не императивных по своей сути, возможность выделить управляющую часть вообще неопределённа. Это возможно для языков высокой абстракции, тяготеющих к дескриптивности («ЧТО-формализации»). В частности, тех или иных языков спецификации программ/задач.
-В-третьих, существует часть знания, отражаемая в формальном тексте неявно. На это, в частности, указывал И. Ермаков при обсуждении визуализации [[http://forum.oberoncore.ru/viewtopic.php?p=68824#p68824|здесь]]. При буквальном переводе части текстового синтаксиса в графику нет оснований полагать, что эта часть станет явной.
-Преодолеть недостатки частной гибридизации можно следующим образом:
-  * визуализировать в каждой составляющей текстового языка её структурную часть;
-  * рассматривать парадигмы «ЧТО-формализации» на предмет выделения их структурной части и нахождения структур графов, формально и эргономично представляющих эту часть;
-  * выявлять содержание, не отражённое в конкретном языке явно, и находить средства его выражения.
-Тем самым определение гибридного языка на базе только дракон-схем для языка программирования или спецификации м.б. лишь началом гибридизации.
-Безусловно, путь, намеченный Ермаковым, требует и теоретических изысканий, на что он [[http://forum.oberoncore.ru/viewtopic.php?p=26640#p26640|также указывал]].
+В более практическом смысле дескриптивные языки можно применять для более качественной постановки задач. А их графические разновидности — и для эргономизации представления «ЧТО»-описаний.

Визуальный язык ДРАКОН

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы