Владимир Паронджанов писал(а):
Уважаемый Владислав!
Предполагаю (но не утверждаю), что самое серьезное из Ваших возражений --
это вопрос о необходимости лианных структур. Буду рад, если Вы в этой теме повторите все ваши возражения и сомнения
о необходимости лианных структур.
Было бы замечательно, если бы Вы сочли возможным изложить
Ваши соображения (возражения, сомнения и т.д.) в виде
ПРОНУМЕРОВАННОГО СПИСКА и подробных комментариев к каждому
пункту (без отсылки к другим материалам, как Вы обычно делаете).
Владимир Паронджанов
Уважаемый Владимир Даниелович!
Пожалуй, какого-то длинного списка соображений не будет. Соображение общее одно: знание о решении поставленной задачи сочинитель уточняет постепенно. При этом он переходит от эскиза решения к его спецификации и далее к точной информатической модели, частью которой м.б. (но не обязана) модель программной реализации отдельных подпроцессов решения. Визуализация предполагает, что все компоненты знания о решении описаны на базе некоторых схем (имеем ряд языков, описания на которых взаимосвязаны); в основе построения схем лежит шампур-метод.
Вот на этапе эскизирования можно позволить сочинителю операции с лианой - что в формальном смысле означает введение явных и произвольных (в некотором смысле) БП. В этом случае он излагает предварительное представление о процессе и если ему удобно так выражать своё понимание структуры маршрутов решения - хорошо, главное - чтобы он выразил целостно всю структуру. По шампур-методу она "укладывается" в дракон-силуэт - и это тоже структура с явными, но уже не произвольными БП.
А последующие формы представления решения при инженерном подходе уже должны проверяться расчётом и моделированием. Коль скоро профессионалами принято, что для этого нужно отказаться от "неатомарного" (не "спрятанного" в точки слияния вертикалей структурных конструкций, визуализируемых составными атомами шампур-метода) БП - я принимаю их точку зрения. А "по факту" она поддержана тем, что прогязыки, позиционируемые как гарантоспособные (напр., Оберон), явного БП не имеют. Поэтому и лианные эскизы нужно приводить к структуре, выводимой логически. И даже силуэт нужно переводить в другую форму - т.к. там хоть и вполне структурные БП, но опять явные. Участники дискуссии, интересующиеся методом визуализации, каждый в своём ключе показали возможность такого перевода.
Предлагается:
* определять комплекс языков визуализации как результат гибридизации с гарантоспособным прогязыком;
* положить в основу алгоконструкций, заменяющих явные/произвольные БП, цикл Дейкстры.
Смысл в том, что "шапка" ЦД даёт возможность выбрать любую из вертикалей и для цикла с лианным телом, и для произвольного (лианного) ветвления - причём условия, очевидно, будут выводимыми, как показано при "структурировании промышленного цикла", а операций с лианой не потребуется.
Суть ограничений отражается введением диалектов гибридного техноязыка "для эскизов" и "для чертежей". Им должны соответствовать диалекты шампур-метода. При этом расширяется множество типов точек ввода следующим образом (цит. по
ДО7Pr-редакции шампур-метода):
Тезис 16. Точка ввода по характеру использования м.б.:
Типа 1 (общего) — если в неё разрешён ввод любого атома данного диалекта (расширения).
Типа 2 (ациклического) — если в неё не разрешён ввод атома, представляющего цикл (любой из определённых в данном диалекте).
Типа 3 (линейного) — если в неё м.б. введены только простые атомы.
На схемах характер использования обозначается номером типа внутри кружка, показывающего точку ввода; для типа 1 номер можно не указывать.
Тезис 10. Ввод атома — преобразование заготовки или дракон-схемы, выполняемое следующим образом: производится разрыв соединительной линии в валентной точке и в это место вставляется атом, как показано на /1, Рис. 116/.
Тип всех точек ввода во вновь введённом атоме должен устанавливаться по типу использованной точки, если для неё содержание типа уже, чем для точек во введённом атоме.
Пояснение. Все точки ввода в атоме имеют одинаковый тип использования (см. Тезис 16 выше в ДО7Pr-правиле СГ). Установка типа обеспечивает целесообразное его употребление.
NB. Возможно, следует ввести типы использования уже в базовый шампур-метод.
Собственно для реализации указанных предложений (поддержки употребления цикла Дейкстры) используется тип 2; тип 3 предназначен для поддержки указания неделимо исполняемых цепочек операторов во взаимодействующих алгопроцессах.
Практическая визуализация от эскиза к чертежу должна поддерживаться тем, что при разработке и документировании процессов (в частности, в РДП-редакторе среды автоматизации) на дракон-эскизе (составленном на диалекте с поддержкой лиан, напр. ДРАКОН-Родной) любой лианный блок (выделенный относительно шампура) можно объявить областью, содержание которой при переходе к дракон-чертежу полностью переписывается на диалекте, поддерживающем гарантоспособный ЯВУ (напр. ДРАКОН-Оберон). Хотя вероятно, что в ряде случаев потребуется переписывать весь эскиз (поскольку будет затронут смысл условий развилок и за пределами лианных блоков) - тогда областью объявляется всё тело схемы.
Также это д.б. поддержано в литературе по техноязыку визуализацией методов логического вывода чисто атомарных структур (и взаимосвязанного уточнения неформальной постановки задачи до математической) с разбором примеров. Чтобы как можно большее число сочинителей как можно скорее переходило к постановке задач сразу в форме, допускающей вывод решения, и могло провести этот вывод.
Вот такие предложения.
В свете сказанного вопрос стоит иначе: до какого уровня формализации имеет смысл допускать такие структуры? Предварительная точка зрения такова: для эскизов (с неформальным текстом вершин) не вижу причин не допускать; для исходных чертежей (визуализирующих прогтекст) не следует допускать; для промежуточного уровня спецификаций (которому в импер-компоненте соответствует ДРАКОН-Алго) возможны варианты. Наверное, стоит это обсудить.