OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 13:02

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




Начать новую тему Ответить на тему  [ Сообщений: 114 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Вторник, 27 Март, 2012 13:26 

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

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

В книгах создателя техноязыка этого нет. Возможно, есть в составе ГРАФИТ-ФЛОКС-технологии (но не [м.б. ]опубликовано) - видимо, это и хотел сказать Дмитрий?..

А публикации "автоматчиков" могут оказаться сложноваты для освоения "интуитивными" программистами/спецификаторами. И тут визуализация логики и структур управления м.б. полезной. Здесь TAU прав - и, как я понимаю, он стоит за достаточно развитый графический язык. И тут главное - динамическое соответствие текстовой и графитной записи - о чём говорил давно - а сейчас снова это обсуждается в этой теме.
Можно принять и его критику вот в какой части. Автоматный пдход давно известен - но пока не видел массовой публикации по синтезу системы переходов для общего случая. А ведь именно на этом д.б. основана промышленная технология программирования... Но это же говорит и Дмитрий... :)

Ещё раз - если будем упирать только на "мозговую проверку" слепыша маршрутов - решение будет ограниченным. Такими условиями, как: хорошо сложившийся коллектив, инкрементальность разработки, конкретная "предметка". Всё это можно предполагать в задачах, под которые создавалась и ЯПЗ-связка ДРАКОН-ФЛОКС, и ГРАФИТ-ФЛОКС как технология её применения. На более широкое применение нужно и расширять подход, и по-своему его излагать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Вторник, 27 Март, 2012 16:54 

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

Это не так. Назначение адресов веткам сформулировано математически строго. Более того, это работает. И никто не ставит это под сомнение.

Шампур-метод математически строго назначает адреса веткам. Все это четко сформулировано в рамках шампур-метода.

Предполагаю, что в Ваше утверждение (которое я процитировал) вкралась опечатка.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Среда, 28 Март, 2012 13:49 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Владислав Жаринов писал(а):
Под "разницей в весе" можно понимать (и я бы лично понимал) уровень
проработанности методов и средств формализации.
... если будем упирать только на "мозговую проверку"
слепыша маршрутов - решение будет ограниченным.

Согласен.

Владимир Паронджанов писал(а):
Владислав Жаринов писал(а):
Действительно, шампур-метод - он же для "слепышей". Потому даже назначение адресов веткам в его рамках не сформулируешь.
Уважаемый Владислав!

Это не так. Назначение адресов веткам сформулировано математически строго. Более того, это работает. И никто не ставит это под сомнение.

Шампур-метод математически строго назначает адреса веткам. Все это четко сформулировано в рамках шампур-метода.

Предполагаю, что в Ваше утверждение (которое я процитировал) вкралась опечатка.


Мне кажется, тут возникло недопонимание
Вложение:
shemy.JPG
shemy.JPG [ 15.42 КБ | Просмотров: 14706 ]

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Среда, 28 Март, 2012 20:43 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Так, да не совсем... :) Дело всё в том же, о чём говорил igor здесь: viewtopic.php?p=70149#p70149 - в спецификации. Принимаем за неё Гл.15 "Как улучшить..." - ну, вместе с Гл. 14. Дмитрий, а теперь сравните свою запись с теми, которые фигурируют в этих главах... :wink: Там сплошь "слепыши" - нет даже тех текстов, которые Вы вписали. В спецификации же д.б. не просто тексты - но формулировки для общего случая...

Есть ли такие формулировки в публикациях Владимира Даниеловича в принципе? Да, есть многое (если не всё в том ключе, как он понимает) - но за пределами того, что по определению можно считать текстом спецификации техноязыка и шампур-метода. Так, правило назначения адресов главным выходам веток можно найти в Гл. 6 той же книги. Но... это за пределами спецификации. Кстати, оно дано на примерах (общая же формулировка естественно-языковая - "чем правее, тем позже") - поэтому мне, скажем, пришлось сформулировать то же здесь в Правиле 240 действительно математически (в терминах порядка нумерации веток и их выходов). Ну и то же обсуждалось здесь: viewtopic.php?p=70745#p70745 (уже без формул, но вполне строго) - и аких текстов в шампур-тезисах тоже нет... Как и правило назначения адресов побочным выходам - которое вообще примерное. А с ним как раз связаны и правила образования веточных макроциклов - обсуждалось здесь: viewtopic.php?p=70770#p70770.
Вот об этом igor и говорил в первую очередь - сообщение о языке д.б. самостоятельным целостным и полным документом. В книге, скажем - как приложение. Для работы (скажем, на сайте) нетрудно сделать извлечение маршрутной части из того же графит-метода в качестве проекта... но требует времени...

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

Это не так. Назначение адресов веткам сформулировано математически строго. Более того, это работает. И никто не ставит это под сомнение.
...
- и я это не ставлю под сомнение... :) Потому что мне, исходя из понимания состава и ролей "голов ДРАКОНа" (вообще методологии формализации) ясно - для реализации (ГРАФИТ-ФЛОКС-системы) были заложены необходимые правила. То, что есть в графит-методе для примитива/силуэта - и, возможно, больше (ибо я не считаю, что полностью раскрыл для себя возможности исчисления графов).
Можно спросить - а есть ли в этом необходимость (на таком уровне)? Для сторонней реализации - да, безусловно. О последствиях "ручной сборки" определения по разным местам разных источников igor тоже говорил...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Среда, 28 Март, 2012 21:38 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Итак, разберем все по порядку.

http://is.ifmo.ru/news/:
«Язык программирования "Дракон" (http://ru.wikipedia.org/wiki/ДРАКОН_(алгоритмический_язык)). Зачем управляющие алгоритмы описывать так громоздко (http://www.youtube.com/watch?v=Ua9dUUON ... e=youtu.be), когда есть автоматное программирование (http://is.ifmo.ru/), в котором используются схемы связей и графы переходов (http://is.ifmo.ru/books/_book.pdf). Что применять схемы, похожие на схемы алгоритмов, применять нецелесообразно, показано здесь (http://is.ifmo.ru/books/djvu/pdf/A009.pdf).»

Но ведь если силуэт — это визуальный аналог автомата, то он сам же и представляет собой свою собственную
таблицу переходов (В цикле-силуэте вообще идут прямые ссылки на номера веток-состояний).
Заголовок ветки — это состояние, а сама ветка — эта функция перехода к другим состояниям.
Для получения полной аналогии поместим силуэт внутрь метода Handle объекта и при каждом
вызове Handle силуэт будет стартовать с ветки, являющейся текущим состоянием объекта.
Для цикла-силуэта ситуация вообще тривиальная — при вызове obj.Handle(N) первым действием
обработчика будет: wetka := N;

Хассан Гома
«Проектирование систем реального времени,
распределенных и параллельных приложений»
серия под ред. Буч, Джекобсон, Рамбо
«Для описания конечных автоматов применяются диаграммы и таблицы перехода
состояний.
Диаграмма перехода состояний — это представление конечного автомата в виде графа,
вершины которого соответствуют состояниям, а ребра — переходам между ними.
Таблица переходов состояний — это табличное представление конечного автомата.
В системах с высокой степенью зависимости от состояния диаграммы или таблицы
состояний могут оказаться очень полезными для понимания функционирования систем.
Такая спецификация конечного автомата зачастую более точна и понятна, чем
словесное описание.»

Причем понятно, что силуэт будет выглядеть более эргономично, чем граф переходов
общего вида.

По поводу спецификации:

igor пишет:
«Представьте себе, некая фирма предлагает мне закупить у них и использовать в своих изделиях партию микросхем. Причём, выясняется, что эти микросхемы были неплохо описаны в каком-то техническом журнале, но data-sheet на них отсутствует. Если я заложу эту микросхему в наше изделие, то на следующий день начальство меня уволит, и будет право. Потому что через год (когда заказчику отгружено уже 500 новых изделий) выяснится, что при температурах ниже +10гр эти микросхемы "тошнит", что нагрузочная способность по такому-то выходу не достаточна и т. д. Пусть аналогия несколько натянута, но моя мысль думаю ясна. Описания в каких-то книжках не имеют никакого значения. Нужен официальный документ. Такова практика делопроизводства. И не нам её менять.»
Но в случае, когда все микросхемы сертифицированы должным образом (ура!), то собираем из них
электронную схему и горя не знаем — она у нас будет работать при температурах от -50 до +50.

Но ведь силуэт — это логический аналог электронной схемы, собираемый из графоэлементов.
И условие вроде тут должно работать одинаково при любых температурах, как впрочем и остальные
элементы силуэта. Так что если твердо определены функции всех элементарных элементов и
возможные отношения между ними, то это в каком-то смысле равно спецификации.
И это Владимир Даниелович сделал, см. например, документ DrakonDescription.pdf.

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

Так что, перефразируя классика, можно сказать:

Силуэт — оружие [программиста], огнестрельный метод.
Применяй умеючи метод этот!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Среда, 28 Март, 2012 23:14 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Дмитрий_ВБ писал(а):
Язык программирования "Дракон" (http://ru.wikipedia.org/wiki/ДРАКОН_(алгоритмический_язык)). Зачем управляющие алгоритмы описывать так громоздко (http://www.youtube.com/watch?v=Ua9dUUON ... e=youtu.be), когда есть автоматное программирование (http://is.ifmo.ru/), в котором используются схемы связей и графы переходов (http://is.ifmo.ru/books/_book.pdf). Что применять схемы, похожие на схемы алгоритмов, применять нецелесообразно, показано здесь (http://is.ifmo.ru/books/djvu/pdf/A009.pdf)

Ну, почитал. Вообще, я со "swith-подходом" познакомился на конференции в Петербурге еще в 1998 году, по-моему.
"Нецелесообразно"? :lol: Во-первых, преимущество графов переходов - мнение Шалыто, о котором в узких кругах питерских ученых в области информатики слышал, мягко выражаясь, неоднозначные оценки. :)
Во-вторых, достаточно легко обратить внимание на факт, что "автоматное программирование" по Шалыто подходит далеко не ко всем алгоритмам, а лишь к достаточно узкому их классу.

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

Дмитрий_ВБ писал(а):
если силуэт — это визуальный аналог автомата

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Четверг, 29 Март, 2012 06:42 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ну вот, вроде согласились, что автоматные программы - частный случай "программ вообще", которые и описываются, например, шампур-схемами в императивной интерпретации... :)

Конкретно по силуэту - ессно, можно задать разные правила разадресации переходов. Правило "ветки друг за другом" - одно из возможных. Можно и так, как говорил здесь (кстаати, подобное было ещё у кого-то). В общем-то обсуждалсь систематически здесь: http://drakonografika.narod.ru/L3/algos ... l#Doc-n322. Важно лишь, чтобы каждое такое правил было точно определено - с указанием назнчения и сферы применения. Иначе рискуем оказаться в положении, описанном Вениамином Александровичем... :wink:

И по автоматам. Да ясно, что Шалыто несколько субъективен. Реально же силуэт - это вьюшка потока управления программы. Например, и автоматной. Как модели процесса императивной, "КАК"-класса. Тогда как граф (диаграмма) переходов - модель скорее дескриптивная, "ЧТО"-класса. Посему силуэт можно рассматривать как уточнение этой диаграммы. Весь вопрос - как уточнять при разных свойствах системы переходов, задаваемых диаграммой.
Конкретно для случая полной и непротиворечивой системы построение структуры управления по диаграмме можно описать одной фразой:
Жаринов В.Н. в http://grafit-basis.narod.ru/L3/part_vi ... otnote2anc писал(а):
...визуализация логики состояний тривиальна; мы просто вводим по условию (единственному и определяющему пару переходов) единственную развилку с заземлением плеч; по ложности «петляем» на то же состояние (организуя одноветочный цикл), по истинности переходим на следующее.

Для случая же, когда эти свойства не имеют места, нужно предварительно перейти к полной и непротиворечивой системе. Как - Поликарпова и Шалыто говорят лишь в общих чертах (в п. 2.2.2 книги). А для широкого применения желательна конкретная методика. В которой графит-визуализация (т.к. нужен и текст и правила над ним) представляется естественной.
Кое-что для этого предлагалось:
Сергей Прохоренко в viewtopic.php?p=60982#p60982 писал(а):
Драконограф в viewtopic.php?p=60921#p60921 писал(а):
Сергей Прохоренко в viewtopic.php?p=60916#p60916 писал(а):
Я предложил ввести в PureBuilder конечный автомат, то есть, автомат, имеющий только входную ленту. Вы идете дальше, и предлагаете автомат с двумя лентами - входной и выходной. Я тоже думал об этом, но решил отложить это как-нибудь на потом. Мотивация следующая. Конечный автомат необходим для создания управляющих алгоритмов, поэтому это приоритет номер один. Автомат с двумя лентами имеет гораздо более узкое применение - в основном при разработке трансляторов языков программирования и, может быть, естественных языков.
...
как будем в редакторе описывать противоречивые и/или неполные системы переходов и какие сочинителю дадим средства приведения к непротиворечивым и полным?


Так же, как в текстовых и программных редакторах: цветом, подчеркиванием волнистой линией, серым шрифтом "недоступности", значками с восклицательным знаком и т.п.

Сергей Прохоренко в viewtopic.php?p=61065#p61065 писал(а):
Драконограф в viewtopic.php?p=61019#p61019 писал(а):
...
Видимо, Вы имеете в виду, что в PureBuilder сочинителю будут даны средства информатизации таблиц (диаграмм) переходов, перечисленные в /Поликарпова, Шалыто, с 77/ (атрибуты приоритезации и пр.) - или ещё что-то, что Вы найдёте возможным реализовать - а кроме того, структурный редактор будет проверять таблицы (диаграммы), принадлежащие каждой автоматной модели, на программируемость и вот этими "расцветками" указывать, где осталась противоречивость и/или неполнота?
Ага.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Четверг, 29 Март, 2012 08:27 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
TAU писал(а):
Дмитрий_ВБ писал(а):
если силуэт — это визуальный аналог автомата

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


Зато автоматное программирование - не в редакции профессора Шалыто, если он для вас не
авторитет, а сразу берем первоисточник (тоже относительный, конечно) - отцов-основателей UML - это
один из наиболее простых и понятных случаев применения силуэта.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Четверг, 29 Март, 2012 08:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Наверное, можно и без эмоций... :wink: :| Не думаю, что TAU куда-то воспаряет... И вообще вы оба правы... и давайте подумаем вместе, какую именно среду для реальности делать... Тем более, что продвигать надо в "критических" предметках программирование "с полной ответственностью" - а силуэтное или нет - решать, исходя из того, только ли силуэт помогает этой цели достичь (кстати, ЦС Дмитрия - это ведь реально эмуляция ЦД)...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Четверг, 29 Март, 2012 11:09 

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


Уважаемый Дмитрий!

Огромное Вам спасибо за термин "силуэтное программирование".

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

Еще раз, большое спасибо


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Четверг, 29 Март, 2012 20:00 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Пятница, 30 Март, 2012 08:11 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Только основные моменты:

1) Основная мысль Владимира Даниеловича:

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

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

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


Но свободного времени у меня, как я уже сказал выше, в ближайший месяц почти не
будет. Иногда буду на формум заглядывать, чтобы быть в курсе дела, но не больше.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Пятница, 30 Март, 2012 19:12 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В ЦС-конструкции есть (кроме того, что она допускает доказательность и не требует БП для своей реализации) также своя "эргономическая правда" в приложении к автоматам. И вот в чём. Поскольку это фактически ЦД (или дейкстрал - смотря как вписать в программу) - то не надо показывать веточных циклов - всё и так зациклено. А автоматная программа ведь м.б. не такой простой, как в этом примере - где "главный порядок" смены состояний в одном цикле (ну и одноветочные циклы для повтора текущего состояния).

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Воскресенье, 01 Апрель, 2012 22:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Дмитрий_ВБ в viewtopic.php?p=71820#p71820 писал(а):
...
Так что если твердо определены функции всех элементарных элементов и
возможные отношения между ними, то это в каком-то смысле равно спецификации.
И это Владимир Даниелович сделал, см. например, документ DrakonDescription.pdf.

По поводу силуэтов-слепышей — тут тоже не все так просто, это тема нуждается в подробном обдумывании.
С одной стороны — ну ничего не понятно, что там происходит и может происходить.
А с другой стороны — это шаблон алгоритма, который ждет, чтобы его наполнили реальным содержанием.
...
Да, это в каком-то смысле равно. Имелось в виду, что в определение должны включаться также и элементы разметки схемы - не только её структура. Т.е. реальное содержание должно подчиняться шаблону и в этой части. Конечно, если мы говорим о реальном языке...
Если речь об анализе абстрактных схем - то да, там мы отвлекаемся от разметки. И тогда это уже часть шаблона алгоритма.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Пятница, 06 Апрель, 2012 19:47 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Решил выложить описание языка ДАЛВЯЗ 2, максимально абстрагированное от программы,
реализующей работу с этим языком.
Документ получился достаточно компактным - всего 21 страница.

Вложение:
dalvjaz2_description.pdf [442.72 КБ]
Скачиваний: 553


ДАЛВЯЗ 2 - ОПИСАНИЕ

ДРУЖЕЛЮБНЫЙ АЛГОРИТМИЧЕСКИЙ ВИЗУАЛЬНЫЙ ЯЗЫК, версия 2
(семейство языка ДРАКОН)

БЛАГОДАРНОСТИ
ИСПОЛЬЗУЕМЫЕ СОКРАЩЕНИЯ
НАЗНАЧЕНИЕ ЯЗЫКА ДАЛВЯЗ 2
ВИЗУАЛЬНЫЕ ЭЛЕМЕНТЫ ЯЗЫКА ДАЛВЯЗ 2
ЧТО ТАКОЕ ЛСП
ПСЕВДОКОД ПкДАЛВЯЗ
ФАЙЛ КОНФИГУРАЦИИ
ТЕКСТОВАЯ И ПРОГРАММНАЯ ЗАПИСИ
СОВМЕСТНАЯ РАБОТА СО СРЕДАМИ ПРОГРАММИРОВАНИЯ
СПЕЦИФИКА РАБОТЫ СО СРЕДОЙ БЛЭКБОКС
КОДОГЕНЕРАЦИЯ И ДОКУМЕНТИРОВАНИЕ
ОПРЕДЕЛИТЕЛЬ РИСУНКА И СОКРАЩЕНИЯ
ЦИКЛ-СИЛУЭТ
БЛОК ПЕРЕКЛЮЧАТЕЛЕЙ
ОБОБЩЕННЫЙ ЦИКЛ
ПОЛНАЯ ФОРМА ОТОБРАЖЕНИЯ ВИЗУАЛЬНОЙ СХЕМЫ
ЛИТЕРАТУРА И ССЫЛКИ В СЕТИ ИНТЕРНЕТ


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Пятница, 06 Апрель, 2012 21:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Тут, наверное, пока много всё же от руководства по работе с программой. Однако само по себе изложение интересно.
Благодарность в свой адрес видеть приятно :) - в то же время считаю нужным привлечь внимание к другим. А именно - что реализацию ЦД в той форме, которая предложена в ДАЛВЯЗ как ЦС для эмуляции силуэта, предложил Ткачёв: viewtopic.php?p=52405#p52405. Описание здесь: download/file.php?id=1691.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Воскресенье, 08 Апрель, 2012 08:09 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Я, Владислав, в теоретики не рвусь - мое дело запрограммировать (конечно, проявляя в процессе
этого некоторую инициативу). Это Вы там сами решайте, кто из Вас что первый придумал: Дейкста,
Вирт, Федор Васильевич или Вы (а в будущем и такое возможно, будем надеяться).
Я как выпускник факультета кибернетики знаю постулат структурного программирования - от него,
плюс от книг Владимира Даниеловича и от ваших предложений и отталкивался в своей работе.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
И я особо не рвался... :) однако в своё время призадумался над красноречивым молчанием Info21 и Igor по поводу идеи, что можно бы и доработать текстовый язык под гибридизацию с "контактными" схемами здесь: viewtopic.php?p=47232#p47232. Так и сформулировал утверждение о преобразуемости силуэта в ЦД и постарался его доказать... :wink: Видимо, возникло где-то интуитивное понимание, что это из разряда варварства, описанного Зелинским... когда "в языке могло бы быть и иначе"... :wink: Потом, кстати, помимо вопросов графит-метода, были ещё идеи по математике операций с лианой... но надо дорабатывать, а это не первоочередное... да и народ по-своему с этим справляется (Вы, в частности)... :)

Вот, кстати, как получается теория, думаю неплохо Акимов показал. Уже развёртывал здесь - но тут одно место существенно, так что уж повторю:
Акимов О.Е. в download/file.php?id=1946 на с. 337 писал(а):
На уровне идеи математическая структура чаще всего возникает в нашем сознании помимо логики и даже вопреки ей, когда многие необходимые звенья для правильного вывода отсутствуют. Затем уже этой индивидуальной идее сообщается общезначимая логическая форма, чтобы она могла быть воспринята коллективным сознанием. (курсив автора)
Понятно, что это как результат работы над темой - тут и Александр Сергеевич писал "О познании": viewtopic.php?p=69525#p69525. И о небходимости синтеза интуиции и логики... и о том, что "не без труда удят рыбку из пруда" и в этом случае... Так что необязательно рваться - достаточно, как и Вы, серьёзно относиться к проблеме (вот и получился у Вас цикл Дейкстры для силуэта)...

Что мне нравится в Вашем подходе - что никакие составляющие общего случая не игнорируются (типа, "[не]структурность мне не интересна - ну и не будем её рассматривать"). И что при этом есть установка на чёткое отграничение (пока - как "основные" и "дополнительные"). Вот "силуэтное" программирование на самом деле не чисто силуэтное... и требует другого слова... ну это как-нибудь потом...


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Итак, как определить структуры, стоящие за дополнительными маршрутными операторами в классификации Дмитрия_ВБ? Наверное, надо понять, что за ними стоит. И не только в языке - но и в технологии его применения. Попробуем сделать это "методом подбора". :)

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

Тогда, быть, может, "веточно-лианного", как я это называл недавно? А здесь уже "перелёт" - кое в чём слишком широкое определение. Так, силуэт предоставляет для выражения goto свои "контакты" как в одно-, так и в многоадресном случаях, и потому целиком подходит под "дополнительность". А вот среди структур, получаемых пересадкой лианы, не всякая будет дополнительной. М.б. и так, что она как была до пересадки атомарной, так и останется.
    Это можно понять, взяв какой-то реальный пример - скажем, схемы визуализации логики отсюда. Представим, что между любой парой вершин Сп* находится какой-то шампур-блок. И пусть мы можем перенести один из этих соединителей в пределах этого ШБ (скажем, если он представляет просто цепочку лин-вершин). Очевидно, что набор формул маршрутов изменится - а вот структур-подкласс конструкции - нет (первая так и будет атомарной).
Аналогично не будет удачен и термин "лианно-адресное" - тут ещё и не все силуэтные goto отражены.

Теперь вспомним - а что общего у всех этих операторов? А то, что они требуют для своего выражения явных БП. Однако ни "безусловно-переходное", ни "goto"-"программирование" не будут удачными. Буквальный перевод "иди на" вообще сообщает определению ненужную эмоциональность - вроде вроде как называние здесь "правил игры без goto" "старинными"... ;)
В следующем посте говорилось о jmp-команде как естественном представлении явного БП. Так что можно назвать вроде "джамп-программированием". Но здесь уже было показано, что для обычного машинного исполнителя и "основные" соединители тоже представляются как "джампы"... Так что опять общность слишком широкая.

Так что же общего у "дополнительных" структур? В понятиях шампур-метода - то, что их нельзя вывести вложением. Т.е. оони неатомарны смысле сказанного здесь: viewtopic.php?p=71937#p71937.
Но атомы сами м.б. неструктурны (хотя в авторском техноязыке таких нет - но нет и ШМ-ограничений на их "придумывание"). Так что естественным допограничением служит условие, чтобы атомы представляли только конструкции Дейкстры, описанные здесь. А уж как назвать то, что выходит за эти ограничения (желательно - ёмко и нейтрально) - надо подумать... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Программы AB_VJAZ и DAL_VJAZ
СообщениеДобавлено: Среда, 11 Апрель, 2012 14:34 

Зарегистрирован: Четверг, 09 Февраль, 2012 09:51
Сообщения: 1
А почему нельзя оформить ветку силуэта как функцию?
Только не простую функцию, а без возврата.
Напрмер, в GCC есть специальные аттрибуты, которые сообщают компилятору, что функции не требуется возврат.
Есть конкретный адрес, не нарушается структурность.
Вдобавок ко всему, появляется возможность изолировать ветки друг от друга и передавать туда внешние параметры, а внутри использовать локальные. Или я слишком узко мыслю в академическом плане?


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

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


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

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


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

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