DRAKON.SU

Текущее время: Четверг, 13 Декабрь, 2018 20:30

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 20 Октябрь, 2010 05:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов писал(а):
Уважаемый Владислав!

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


:arrow: Буду рад, если Вы в этой теме повторите все ваши возражения и сомнения
о необходимости лианных структур.

:arrow: Было бы замечательно, если бы Вы сочли возможным изложить
Ваши соображения (возражения, сомнения и т.д.) в виде
ПРОНУМЕРОВАННОГО СПИСКА и подробных комментариев к каждому
пункту (без отсылки к другим материалам, как Вы обычно делаете).

Владимир Паронджанов


Уважаемый Владимир Даниелович!

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

Предлагается:
    * определять комплекс языков визуализации как результат гибридизации с гарантоспособным прогязыком;
    * положить в основу алгоконструкций, заменяющих явные/произвольные БП, цикл Дейкстры.
Смысл в том, что "шапка" ЦД даёт возможность выбрать любую из вертикалей и для цикла с лианным телом, и для произвольного (лианного) ветвления - причём условия, очевидно, будут выводимыми, как показано при "структурировании промышленного цикла", а операций с лианой не потребуется.

Суть ограничений отражается введением диалектов гибридного техноязыка "для эскизов" и "для чертежей". Им должны соответствовать диалекты шампур-метода. При этом расширяется множество типов точек ввода следующим образом (цит. по ДО7Pr-редакции шампур-метода):
Тезис 16. Точка ввода по характеру использования м.б.:

Типа 1 (общего) — если в неё разрешён ввод любого атома данного диалекта (расширения).

Типа 2 (ациклического) — если в неё не разрешён ввод атома, представляющего цикл (любой из определённых в данном диалекте).

Типа 3 (линейного) — если в неё м.б. введены только простые атомы.

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

Тезис 10. Ввод атома — преобразование заготовки или дракон-схемы, выполняемое следующим образом: производится разрыв соединительной линии в валентной точке и в это место вставляется атом, как показано на /1, Рис. 116/.

Тип всех точек ввода во вновь введённом атоме должен устанавливаться по типу использованной точки, если для неё содержание типа уже, чем для точек во введённом атоме.

    Пояснение. Все точки ввода в атоме имеют одинаковый тип использования (см. Тезис 16 выше в ДО7Pr-правиле СГ). Установка типа обеспечивает целесообразное его употребление.

    NB. Возможно, следует ввести типы использования уже в базовый шампур-метод.

Собственно для реализации указанных предложений (поддержки употребления цикла Дейкстры) используется тип 2; тип 3 предназначен для поддержки указания неделимо исполняемых цепочек операторов во взаимодействующих алгопроцессах.

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

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

Вот такие предложения.

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


Последний раз редактировалось Владислав Жаринов Четверг, 21 Октябрь, 2010 04:35, всего редактировалось 5 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 20 Октябрь, 2010 11:11 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Драконограф писал(а):
Предлагается: ...
    * положить в основу алгоконструкций, заменяющих явные/произвольные БП, цикл Дейкстры.
...
Вот такие предложения.
Предложение заслуживает внимания.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Об определении лианы
СообщениеДобавлено: Четверг, 12 Май, 2011 10:30 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Уважаемый Владимир Даниелович!
Всё собираюсь спросить - на практике при визуализации понятий шампур-метода я определяю лиану как цепочку от побочного выхода развилки (варианта переключателя) до первой встреченной вершины-соединителя (что можно видеть, скажем, на схемах здесь или здесь). Т.е. из понятия лианы исключается главная вертикаль примитива (ветки силуэта) - что должно соответствовать смыслу операций с лианой. Вместе с тем в Вашем текстовом определении говорится о любом выходе ветвления как о начале лианы. Тогда получается, что формально мы можем пересадить/заземлить и главную вертикаль... а куда? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Май, 2011 10:21 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3893
Откуда: Москва
Уважаемый Владислав!

Напомню мои тезисы (Как улучшить работу ума... С.241.
Цитата:
ОПЕРАЦИИ С ЛИАНОЙ

Тезис 26. Лиана — часть дракон-схемы, имеющая один вход и один вы-ход, именуемые “началом лианы” и “концом лианы” соответственно. Началом лианы может быть любой выход икон “вопрос” и “вариант”, если он (выход) не является петлей цикла. Концом лианы считается точка слияния, в которой нижняя часть лианы соединяется с другой линией (концом лианы не может быть неразветвленный вход иконы).

Тезис 27. Лиана может быть нагруженной (если она содержит иконы) и ненагруженной (если это просто линия).

Пересадка лианы

Тезис 28. Пересадка лианы — преобразование дракон-схемы, выпол-няемое за четыре шага.

Шаг 1. Производится отрыв конца лианы от точки присоединения (рис. 119).

Шаг 2. Конец лианы с помощью вертикальных и горизонтальных линий присоединяется к любой валентной точке, куда лиана может до-тянуться без пересечения с другими линиями (рис. 119). При этом запрещается:
         формировать второй вход в ветку (ошибка “сиамские близ-нецы” — см. рис. 127);
         образовывать новый цикл;
         создавать второй вход в цикл.

Однако разрешается строить новый путь из середины обычного цик-ла к единственному входу в этот цикл, создавая визуальный эквивалент оператора continue языка СИ (см. рис. 90, пример 7, а также рис. 41).

Шаг 3. Производится эквивалентное преобразование топологии дракон-схемы, чтобы лиане не пришлось загибаться наверх (рис. 128)
и соблюдались правила построения шампур-блока (рис. 129).

Шаг 4. Устраняются неоправданные изломы линий (рис. 130).

Заземление лианы

Тезис 29. Заземление лианы — преобразование дракон-схемы, выпол-няемое за четыре шага.

Шаг 1. Производится отрыв конца лианы от точки присоединения (рис. 120).

Шаг 2. Конец лианы с помощью вертикальной линии присоединяется к любой точке нижней горизонтальной линии силуэта, куда он может дотянуться, не пересекая другие линии.

Шаг 3. Производится разрыв линии в нижней части лианы и в место разрыва вставляется икона “адрес” (рис. 120).

Шаг 4. Устраняются неоправданные изломы линий.

Если Вы обнаружили здесь ошибку, надо дать опровергающий пример.
Мне такие примеры неизвестны.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Май, 2011 10:57 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3893
Откуда: Москва
Драконограф пишет:
Цитата:
Вот на этапе эскизирования можно позволить сочинителю операции с лианой - что в формальном смысле означает введение явных и произвольных (в некотором смысле) БП. В этом случае он излагает предварительное представление о процессе и если ему удобно так выражать своё понимание структуры маршрутов решения - хорошо, главное - чтобы он выразил целостно всю структуру. По шампур-методу она "укладывается" в дракон-силуэт - и это тоже структура с явными, но уже не произвольными БП.
Уважаемый Владислав!

В этом отрывке два раза встречается термин БП (безусловный переход).

В языке ДРАКОН такого понятия нет. Нет никаких безусловных переходов. Ни явных, ни произвольных. Я усматриваю здесь неточность терминологии. И Ваша оговорка "в некотором смысле" положения не спасает.

Мое замечание относится только и исключительно к ДРАКОНУ, который мной описан.

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

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

Сам я склонен к некоторому консерватизму.
Но это не должно никого ограничивать. Потому что вся наша жизнь и вся наука -- это развитие.
По этой причине я приветствую и поддерживаю Ваши творческие поиски.

Я от всей души благодарен Вам за Ваши инновации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Май, 2011 11:21 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3893
Откуда: Москва
Драконограф пишет:
Цитата:
Коль скоро профессионалами принято, что для этого нужно отказаться от "неатомарного" (не "спрятанного" в точки слияния вертикалей структурных конструкций, визуализируемых составными атомами шампур-метода) БП - я принимаю их точку зрения.

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

Цитата:
А "по факту" она поддержана тем, что прогязыки, позиционируемые как гарантоспособные (напр., Оберон), явного БП не имеют.

Вы правы. Но из этого ничего не следует. Для языка Дракон было бы лучше, если бы go to в языках программирования сохранился.
Цитата:
Поэтому и лианные эскизы нужно приводить к структуре, выводимой логически.

Вы постулируете, а не аргументируете.
Здесь наши мнения различаются. Во-первых, лианная структура выводится строго математически. Во-вторых, Вы считаете, что лианные структуры НУЖНО переводить к другому виду. А я считаю НЕ НУЖНО.
Цитата:
И даже силуэт нужно переводить в другую форму - т.к. там хоть и вполне структурные БП, но опять явные. Участники дискуссии, интересующиеся методом визуализации, каждый в своём ключе показали возможность такого перевода.

Здесь наши мнения опять различаются. Вы считете СИЛУЭТ НУЖНО ПЕРЕВОДИТЬ. А я считаю НЕ НУЖНО.
Более того. Предлагая отказаться от силуэта в существующей форме, Вы удаляете главное достоинство языка Дракон (Если я Вас правильно понял).

Уважаемый Владислав!

Благодарю Вас за критические замечания.
Но согласиться с ними, к сожалению, не могу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Май, 2011 11:32 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Владимир Паронджанов писал(а):
Для языка Дракон было бы лучше, если бы go to в языках программирования сохранился.

Не мы определяем правила игры на IT-поле.
Если Oberon и Java отказались от goto, ничего с этим уже не поделать.
Да и так ли это страшно ?

Вложение:
ris22.png
ris22.png [ 69.69 КБ | Просмотров: 13793 ]


Ну придется переход к метке М1 заменить структурными конструкциями,
что слегка усложнит логику. Предложенную Вами, Владимир Даниелович,
форму силуэта Драконограф, если я правильно его понял, не оспаривает.
У меня в программе DAL_VJAZ 0.3 текстовое представление силуэта
выглядит почти как на вашем рисунке.

Другой вопрос, как переводить структурное представление силуэта на
конкретный язык программирования и использовать для этого goto или не
использовать. Но это уже, как мне кажется, компетенция разработчика ПО.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Июнь, 2011 20:19 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов в viewtopic.php?p=63320#p63320 писал(а):
... Уважаемый Владислав!

В этом отрывке два раза встречается термин БП (безусловный переход).

В языке ДРАКОН такого понятия нет. Нет никаких безусловных переходов. Ни явных, ни произвольных. Я усматриваю здесь неточность терминологии. И Ваша оговорка "в некотором смысле" положения не спасает.

Мое замечание относится только и исключительно к ДРАКОНУ, который мной описан.

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


Последний раз редактировалось Владислав Жаринов Пятница, 10 Июнь, 2011 21:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Июнь, 2011 21:02 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Уф-ф! Без отсылок к цитируемым постам сразу не разберёшься... ну ладно, восстановим их и пойдём по порядку :)
Владимир Паронджанов в viewtopic.php?p=63321#p63321 писал(а):
Драконограф в viewtopic.php?p=52666#p52666 писал(а):
Коль скоро профессионалами принято, что для этого нужно отказаться от "неатомарного" (не "спрятанного" в точки слияния вертикалей структурных конструкций, визуализируемых составными атомами шампур-метода) БП - я принимаю их точку зрения.

Не могу с вами согласиться. Вы не приводите аргументов, а лишь аппелируете к авторитету.
...
Аргумент приведён в выпущенном начале цитаты:
Драконограф в viewtopic.php?p=52666#p52666 писал(а):
А последующие формы представления решения при инженерном подходе уже должны проверяться расчётом и моделированием.
Он же и ограничение области необходимого следования данной т. зр. - если не нужен инженерный подход (в "некризисных" задачах в смысле Громова, см., напр. здесь) - то можно и не принимать...

Владимир Паронджанов в viewtopic.php?p=63321#p63321 писал(а):
Драконограф в viewtopic.php?p=52666#p52666 писал(а):
А "по факту" она поддержана тем, что прогязыки, позиционируемые как гарантоспособные (напр., Оберон), явного БП не имеют.

Вы правы. Но из этого ничего не следует. Для языка Дракон было бы лучше, если бы go to в языках программирования сохранился.
Для ДРАКОНа что так, что эдак неплохо :) - поскольку он пригоден и для записи конструкций без явного БП. Что и показано в ряде примеров из этого каталога.
Владимир Паронджанов в viewtopic.php?p=63321#p63321 писал(а):
Драконограф в viewtopic.php?p=52666#p52666 писал(а):
Поэтому и лианные эскизы нужно приводить к структуре, выводимой логически.

Вы постулируете, а не аргументируете.
Здесь наши мнения различаются.
Речь идёт снова об инженерном проектировании процессов (в т.ч. программ) - с применением методов формального вывода и проверки. Аргументация была у Ильи Ермакова (прежде всего здесь) - я просто с ней согласен, потому и не добавлял какой-то ещё формальной аргументации...
Тогда нужно с самого начала выводить маршрутную структуру из логики решения задачи как ЦД - именно это я называл "логическим выводом структуры". А приводить только уже визуализированные лианные структуры в связи с приданием доказательности алгоритму (кстати, не обязательно лианные - см. этот пример хотя бы, где "гнездовая" циклическая структура).
Владимир Паронджанов в viewtopic.php?p=63321#p63321 писал(а):
Драконограф в viewtopic.php?p=52666#p52666 писал(а):
И даже силуэт нужно переводить в другую форму - т.к. там хоть и вполне структурные БП, но опять явные. Участники дискуссии, интересующиеся методом визуализации, каждый в своём ключе показали возможность такого перевода.

Здесь наши мнения опять различаются. Вы считете СИЛУЭТ НУЖНО ПЕРЕВОДИТЬ. А я считаю НЕ НУЖНО.
Более того. Предлагая отказаться от силуэта в существующей форме, Вы удаляете главное достоинство языка Дракон (Если я Вас правильно понял).
...
Опять же переводить НУЖНО тогда, когда имеем "гибрид" с инфор-языком без явных БП. Точнее - опять-таки приводить силуэт к ЦД. Пример этому можно найти здесь. Но, безусловно, метод представления процессов "предметки" нужен подходящий - как тот же автоматный.
Не сформулировано "удаляемое достоинство". Если это представление задачи по веткам - то в ЦД ничего не меняется, просто "шапку" образуют не БП, а развилки - смысл же выбранной ветви легко отразить в комментарии (что и сделано в схемах упомянутого примера).
Если инфор-язык допускает явные БП - то вроде как можно и не переходить к ЦД (тот же Promela). Однако и здесь определяющим будет - инженерный подход или "наивный" допускается. Проблем визуализации опять-таки нет - см. этот пример.

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


Последний раз редактировалось Владислав Жаринов Пятница, 10 Июнь, 2011 21:32, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Июнь, 2011 21:23 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Дмитрий_ВБ писал(а):
Владимир Паронджанов писал(а):
Для языка Дракон было бы лучше, если бы go to в языках программирования сохранился.

Не мы определяем правила игры на IT-поле.
Если Oberon и Java отказались от goto, ничего с этим уже не поделать.
Да и так ли это страшно ?
...
Ну придется переход к метке М1 заменить структурными конструкциями,
что слегка усложнит логику. Предложенную Вами, Владимир Даниелович,
форму силуэта Драконограф, если я правильно его понял, не оспаривает.
...
Вот именно - просто ввожу эквивалентное представление, исходя из чего можно в принципе просто "переводить" (конвертировать) силуэт в ЦД. Но дело в том, что тогда справедливо сказанное Владимиром Даниеловичем о дополнительной переменной выбора ветки (подробнее обсуждено в этом подпункте для петли силуэта). Это не делает модель эргономичнее. Именно поэтому нужно идти с самого начала от ЦД и выбирать его ветвь не от условного номера, а от реальных величин алгопроцесса.
Тем самым не нужно будет "слегка усложнять логику". А наибольший эргономический выигрыш будет достигнут при явном выделении состояний, сопоставляемых веткам.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Июнь, 2011 16:52 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов в viewtopic.php?p=63319#p63319 писал(а):
Уважаемый Владислав!

Напомню мои тезисы (Как улучшить работу ума... С.241.
Цитата:
ОПЕРАЦИИ С ЛИАНОЙ
Тезис 26. ...
Тезис 27. ...
Тезис 28. ...
Тезис 29. ...
Если Вы обнаружили здесь ошибку, надо дать опровергающий пример.
Мне такие примеры неизвестны.

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

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


Последний раз редактировалось Владислав Жаринов Четверг, 16 Июнь, 2011 18:42, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Июнь, 2011 17:18 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Дмитрий_ВБ в viewtopic.php?p=63378#p63378 писал(а):
...
Другой вопрос, как переводить структурное представление силуэта на
конкретный язык программирования и использовать для этого goto или не
использовать. Но это уже, как мне кажется, компетенция разработчика ПО.
Подведу промежуточный итог. Даже если конкретный язык информатического моделирования (в т.ч. прогязык) допускает явный БП - в детальной (в смысле определений на этой странице) импер-модели решения даже для "некризисной" задачи следует рассмотреть возможность замены дракон-силуэта на СЦД с выведением в СЦД-шапку содержательных (а не "от номера следующей ветви") условий выбора СЦД-ветви.
Проще говоря, дракон-силуэт стоило бы строить только как импер-эскиз - если сразу нет очевидной возможности построить СЦД (при автоматной формализации задачи такая возможность есть, что показывает, допустим, этот пример). А затем искать возможности СЦД-информатизации (прежде всего - от состояний предметной области). Замечу, что Владимир Даниелович указывал на это в /Паронджанов, 2001, Рис. 136,137/. Обоснование этому - такой поиск по сути основан на логическом построении алгоритма решения, что облегчает и передачу (средствами гибридного техноязыка) этой логики (а значит, повышает когнитивное качество модели), и верификацию решения. Это показывает, в частности, этот пример (прежде всего в части построения алгопроцессов моделирования кнопок).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Апрель, 2012 14:38 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3893
Откуда: Москва
Дмитрий_ВБ писал(а):
Владимир Паронджанов писал(а):
Для языка Дракон было бы лучше, если бы go to в языках программирования сохранился.

Не мы определяем правила игры на IT-поле.
Если Oberon и Java отказались от goto, ничего с этим уже не поделать.


Уважаемый Дмитрий Владимирович!

Благодарю Вас за точную формулировку.

Но согласиться с Вами, к сожалению, не могу.

Наши позиции ПРИНЦИПИАЛЬНО различаются.
Разница в том, что Вы признаете правила игры на IT-поле.
А я не признаю.

Вы считаете, что правила нельзя менять.
А я считаю, что правила отжили свой век.

Для Вас эти правила игры являются «священной коровой», сакральность которой не подлежит обсуждению.
Я же, напротив, отвергаю сакральные ценности.

Поясню. Оберон и Джава были созданы до появления языка ДРАКОН, то есть в рамках постулатов текстового программирования. В то время это было ХОРОШИМ решением.

Но! Ничто не вечно под луной. Появление ДРАКОНа взламывает традиционные представления. Поэтому я отвергаю старинные правила игры на IT-поле.

Если угодно, я ввожу НОВЫЕ правила игры.
Вы, по-видимому, не верите, что у меня получится.
Что НОВЫЕ правила игры будут признаны ИТ-сообществом.

Я, напротив, убежден, что НОВЫЕ правила игры со временем ВОЗОБЛАДАЮТ.

Хочу напомнить, что в истории науки подобные ситуации (спор нового со старым) были несчетное число раз.

С большим уважением к Вашей точке зрения,
несогласный с Вами

Владимир Паронджанов


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Апрель, 2012 15:17 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Уважаемый Владимир Даниелович!
Как известно, правила, не допускающие явных БП в высокоуровневом представлении потоков управления (т.е. через goto) столь же старинны, сколь и альтернативные правила... :) А пожалуй, вторые и подревнее будут... ибо идут от связи с низкоуровневым представлением для машин с явным БП (jmp-командой)... :wink: Это так, к вопросу о подтексте...

Но. ДРАКОН-то на самом деле допускает выражение и той, и той позиции. Уже и в исходном определении. Недавно в очередной раз указал на это: viewtopic.php?p=71937#p71937. Я так думаю, Вы это уже и читали... :)
Возникает вопрос - значит ли новое отрицание одной из альтернатив, что Вы:

    * допускаете только силуэтную запись потоков управления программ?

    * если текстовый язык не содержит необходимых выразительных средств для веточных/лианных соединителей - goto и/или заменителей - то Вы против гибридизации ДРАКОНа с таким языком?

И зачем требовать от ИТ-сообщества, чтобы оно (я так понимаю, что в идеале - в большинстве или поголовно) признавало только одну из этих альтернатив?...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Апрель, 2012 19:07 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3893
Откуда: Москва
Владислав Жаринов писал(а):
Возникает вопрос - значит ли это, что Вы допускаете только силуэт...?

Мой ответ таков:
Цитата:
ЧАСТЬ 5. ЗАКЛЮЧИТЕЛЬНЫЕ РЕКОМЕНДАЦИИ ПО СОЗДАНИЮ ДРАКОН-СХЕМ

§8. ВЫВОДЫ

1. Головной алгоритм – это алгоритм самого верхнего уровня на лест-
нице декомпозиции.

2. Головной алгоритм может содержать вставки (вызываемые проце-
дуры). Но сам он не может быть вставкой для алгоритма более вы-
сокого уровня.

3. Головной алгоритм – это всегда силуэт. Он не может быть прими-
тивом или системой примитивов.

4. Для создания головного алгоритма используют:

        • метод эргономичной декомпозиции;
        • метод многостраничного силуэта.

5. Головной алгоритм может быть:

        • одностраничным силуэтом;
        • многостраничным силуэтом.

6. Одностраничный силуэт размещается на одном листе бумаги (на
одном экране).

7. Многостраничный силуэт размещают на нескольких листах бума-
ги. При работе с экраном силуэт прокручивают по горизонтали.

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

9. Силуэт – главное достоинство языка ДРАКОН. Он обладает мощ-
ными выразительными средствами.

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

11. На практике силуэт используют в подавляющем большинстве слу-
чаев.

12. Примитив применяют редко, скорее как исключение.

13. Тем не менее, отказываться от примитива не следует, так как он ну-
жен для описания малых алгоритмов.

14. Кроме того, примитив полезен из педагогических соображений.
Основные понятия и правила ДРАКОНа удобно объяснять на са-
мой простой модели. То есть на примитиве. И только после этого
переходить к рассказу о силуэте.

Это цитата из книги "Учись...", которая вскоре появится. См. стр. 376.

Вообще говоря, вставки выполняют три функции:
:!: процедуры
:!: функции
:!: собственно вставки


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Апрель, 2012 20:40 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Владимир Паронджанов писал(а):
Вообще говоря, вставки выполняют три функции:
процедуры
функции
собственно вставки

Надо различать свойства:
схемы - процедура, функция, вставка;
иконы "Вставки" - вызов схемы процедуры, схемы вставки.

Икона "Вставка" не может быть вызовом схемы функции.
Схема функция возвращает значения и следовательно вызывается из выражения.

В ИС Дракон уточнение набора свойств иконы вставки было выполнено в выпуске от 08.04.2012 здесь пункт 1.

В ИС Дракон установленные свойства схемы или иконы отображаются графическим знаком: процедура - отсутствует, функция - ">", вставка - "|". Установленные свойства используются при верификации дракон-схем в проекте.


Последний раз редактировалось ==== Воскресенье, 15 Апрель, 2012 09:33, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 15 Апрель, 2012 08:29 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Существенное замечание. При исполнении к функции из выражения обращаются по имени - поэтому именно оно и м.б. ссылкой на схему при сочинении.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 15 Апрель, 2012 10:58 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3893
Откуда: Москва
Геннадий Тышов писал(а):
В ИС Дракон установленные свойства схемы или иконы отображаются графическим знаком: процедура - отсутствует, функция - ">", вставка - "|". Установленные свойства используются при верификации дракон-схем в проекте.

Геннадий Николаевич, спасибо.

Есть вопрос. Как Вы относитесь к замечанию Сергея Ефанова, что вставка перегружена различными задачами? (Ефанова цитирую по памяти, точность ссылки не проверял).

Вы согласны с этим утверждением? Или нет?

Может быть, вместо одной иконы "вставка" следует использовать две иконы:
— одна икона для процедуры
— вторая икона для собственно вставки?

Или не стоит плодить лишние иконы? Как Вы считаете?

И еще вопрос. Что думают пользователи по этому вопросу?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 15 Апрель, 2012 11:20 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Владимир Паронджанов писал(а):
Наши позиции ПРИНЦИПИАЛЬНО различаются.
Разница в том, что Вы признаете правила игры на IT-поле.
А я не признаю.


С большим уважением к Вашей точке зрения,
несогласный с Вами

Владимир Паронджанов


Тут такое дело, Владимир Даниелович.
В силу производственной необходимости мне сейчас нужно представить
предложения по улучшению документирования УЖЕ СУЩЕСТВУЮЩИХ программных
проектов в нашем отделе.

Поэтому если для Вас естественно направление:
графика -> исполняемый код программы

то для меня в силу производственной необходимости нужно:
исходный код -> документация (графическая)

отсюда и разница в подходах.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Апрель, 2012 13:42 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Дмитрий_ВБ писал(а):
то для меня в силу производственной необходимости нужно:
исходный код -> документация (графическая)

Как Вы обходитесь с оператором return, произвольно появляющимся в тексте функции, при представлении его в графическом виде? (Если, конечно, Вы с таким сталкиваетесь.)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB