DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 12:24

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




Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9, 10, 11 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 29 Март, 2008 19:27 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В этом сообщении изложена Часть 6, в которой представлены ответы Паронджанова на два сообщения Сергея Губанова: 1)Суббота, 29 Март, 2008 01:08 и 2)Суббота, 29 Март, 2008 01:15 .
Примерно через десять дней последует Часть 7, в которой я продолжу отвечать на вопросы и критические замечания участников форума.

С глубоким уважением Владимир Паронджанов

Часть 6. Ответ Паронджанова на сообщения Сергея Губанова Суббота, 29 Март, 2008 01:08 и Суббота, 29 Март, 2008 01:15 .

Сергей Губанов Суббота, 29 Март, 2008 01:08


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


Ответ Паронджанова

Уважаемый Сергей! Благодарю Вас за удачно поставленный вопрос. От всей души приветствую Ваш вопрос. Он предельно конкретен. И поэтому позволяет высветить и устранить многие недоразумения.

Мой ответ будет состоять из 3-х пунктов.

Пункт 1.

При ответе на Ваш вопрос я буду ссылаться на стр. 241 книги, где описаны «Операции с лианой». Чтобы избавить участников дискуссии от необходимости листать книгу, я процитирую нужное место прямо здесь.

Пункт 2.

Далее следует точная цитата из моей книги (стр.241).

ОПЕРАЦИИ С ЛИАНОЙ

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

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

ПЕРЕСАДКА ЛИАНЫ

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

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

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

    • Формировать второй вход в ветку (ошибка «сиамские близнецы» — см. рис. 127;
    • Образовывать новый цикл;
    • Создавать второй вход в цикл.

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

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

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

Конец точной цитаты из книги «Как улучшить работу ума…».

Пункт 3. Ответ Паронджанова по существу сообщения Сергея Губанова

Уважаемый Сергей! В Вашем рисунке красная линия является нарушением изложенных выше правил. Следовательно, она является незаконной и запрещенной.

Поясню эту мысль. Чтобы провести Вашу красную линию, ее надо построить. Единственный путь, чтобы сделать это — использовать операцию «Пересадка лианы». Но использование операции «Пересадка лианы» в Вашем случае является недопустимым. Почему?

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

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

Ответ таков. В Тезисе 26 сказано: «Началом лианы может быть любой выход икон «вопрос» и «вариант», если он (выход) не является петлей цикла». А Ваша синяя линия как раз и является петлей цикла.
Значит, она не является лианой. И к ней нельзя применить операцию «Пересадка лианы»

Возможно, Вы скажете. Хорошо, я возьму и сотру синюю линию. В качестве лианы я возьму правый выход нижней иконы «вопрос». А потом я загну этот выход кверху и превращу в красную линию. Разве нельзя?

Да, нельзя. В тезисе 28 (Шаг 2) ясно сказано. Выполняя операцию «Пересадка лианы» запрещается:
    • Образовывать новый цикл;
    • Создавать второй вход в цикл.

Отсюда следует вывод: красная линия на Вашем чертеже является категорически запрещенной

Конец ответа Паронджанова на первое сообщение Сергея Губанова.

Сергей Губанов писал(а):
Кстати, структурную линию обратной связи (ту что нарисована синим пунктиром) можно провести как слева так и справа. То есть структурные линии обратной связи симметричны относительно правостороннего или левостороннего пути вверх.


Уважаемый Сергей! Это неверно. У иконы «вопрос» есть только правый и нижний выходы. Левый выход запрещен.

Об этом сказано во многих местах книги. Например, на стр. 105 сказано: «Икона вопрос имеет один вход сверху и два выхода: вниз и вправо. Выход влево запрещен и никогда не используется».

Отсюда следует вывод (в терминах Сергея Губанова): СТРУКТУРНУЮ ЛИНИЮ ОБРАТНОЙ СВЯЗИ МОЖНО ПРОВЕСТИ ТОЛЬКО СПРАВА. СЛЕВА ЕЕ ПРОВЕСТИ НЕЛЬЗЯ.

Конец Части 6. Конец ответов Паронджанова на сообщения Сергея Губанова.

Продолжение (Часть 7) последует примерно через 10 дней.


Последний раз редактировалось Владимир Паронджанов Воскресенье, 06 Апрель, 2008 10:48, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Март, 2008 21:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
К вопросу о наших постоянных спорах с Сергеем Прохоренко...

Цитирую книжку Владимира Даниловича "Парадоксальная энциклопедия...", про язык графического конспектирования ГРАФ:

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Март, 2008 23:18 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Конец анархии на письме и в рисунке :cry:
Сначала пришёл Дейкстра, потом пришёл Паронджанов... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 10:44 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
К вопросу о наших постоянных спорах с Сергеем Прохоренко...

Цитирую книжку Владимира Даниловича "Парадоксальная энциклопедия...", про язык графического конспектирования ГРАФ:

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


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

Кстати, любимые Вами соединительные линии мне тоже нравятся. Но они возможны не только в блок-схемах. Мне, например, очень нравится подход к графическому программированию, реализованный в Visual2k. Это интегрированная среда программирования аппаратуры.
http://gurin.tomsknet.ru/visual2k.html
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=454
http://www.wentor.ru/img/products/ring.gif

См. также http://zouev.blogspot.com/2007/09/blog-post.html начиная со слов "Вот несколько моих постов ..."


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 12:22 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Кстати, помимо линий связей высьма эргономичны выделения формой (даже 3D) и цветом:

http://scratch.mit.edu/pages/help-screens/
http://scratch.mit.edu/about

Блок-схемы отдыхают.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 12:38 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Я же вообще считаю необходимым переход от правил к использованию графического интерфейса программирования/редактора (вместо клавиатурного ввода), который сделает неправильные синтаксические конструкции невозможными.
И не только Вы так считаете. Если бы Вы внимательнее читали книгу про ДРАКОН, то заметили бы, что ДРАКОН-редактор по определению не допускает ввод некорректных схем. Если нет этого условия, то это уже не ДРАКОН-редактор. Какие же устройства ввода редактор будет использовать клавиатуру/клавиатуру-мышь/мышь/или ещё чего - от этого зависит только удобность его использования для конкретного индивида.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 12:49 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Кстати, помимо линий связей высьма эргономичны выделения формой (даже 3D) и цветом:
Весьма эргономичны для Вас? А как на счёт остальных?

Тут я соглашусь с высказыванием "...Автор-фантазёр обычно забывает объяснить, какое значение он приписывает линиям, фигурам и их комбинациям."

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 14:34 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Евгений Темиргалеев писал(а):
Сергей Прохоренко писал(а):
Кстати, помимо линий связей высьма эргономичны выделения формой (даже 3D) и цветом:
Весьма эргономичны для Вас? А как на счёт остальных?

Тут я соглашусь с высказыванием "...Автор-фантазёр обычно забывает объяснить, какое значение он приписывает линиям, фигурам и их комбинациям."

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 14:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Мне, например, очень нравится подход к графическому программированию, реализованный в Visual2k. Это интегрированная среда программирования аппаратуры.
http://gurin.tomsknet.ru/visual2k.html

Вы это уже показывали. Как раз неудачный пример. Это обычная линейная текстовая программа, в которой ключевые слова заменены на значки и допускается свёртка конструкций. Никакой двумерности и усиления выразительности для показа структуры программ нет. Если в схемах (любых) алгоритма графика по крайней мере содержательна (линии показывают связи - переходы управления), то здесь графика абсолютно произвольна - от балды выбрали значок для отдельно взятого знака формальной системы...
Про скретч - практически то же самое. Какая разница, как отображать repeat - текстом, или фигуркой - он repeat-ом и останется... Компоновка программы на диосцене отстаётся той же самой, а после некоторого времени работы зрительному анализатору человека совершенно всё равно, что искать на листе - REPEAT или ромбик. Выразительность нотации не увеличивается. Зато представление намертво привязывается к конкретному редактору.
Ещё раз повторю - никакой разницы между ключевым словом и красивой картинкой вместо него для зрения человека нет. Вообще. Графическая схема хороша настолько, насколько она способна отобразить скрытую семантику, которая при текстовом представлении неочевидна (которую человек постоянно вынужден реконструировать в голове).

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 15:15 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Для непредвзятых читателей - еще один образец:
http://www.osenkov.com/diplom/screenshots/cs/LightHorizontalGradient.png


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Март, 2008 15:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Ну, хороший пример. К неуклюжему языку сделали симпатичные полированные костыли. Только вот обычно язык делает кто-то вроде MS, а костыли потом ваяют бедные энтузиасты, которым приходится на этом языке писать....

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Март, 2008 12:16 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 10
Откуда: Россия, Нижний Новгород
Владимир Паронджанов писал(а):
Уважаемый Сергей! В Вашем рисунке красная линия является нарушением изложенных выше правил. Следовательно, она является незаконной и запрещенной.

Спасибо. Я невнимательно прочитал описанные в тексте правила.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Март, 2008 15:11 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В этом сообщении изложена Часть 7, в которой представлен ответ Паронджанова на сообщение Сергея Губанова Понедельник, 31 Март, 2008 12:16 .
Примерно через десять дней последует Часть 8, в которой я продолжу отвечать на вопросы и критические замечания участников форума.

С глубоким уважением Владимир Паронджанов

Часть 7. Ответ Паронджанова на сообщение Сергея Губанова Понедельник, 31 Март, 2008 12:16

Сергей Губанов Понедельник, 31 Март, 2008 12:16


Сергей Губанов писал(а):
Владимир Паронджанов писал(а):
Уважаемый Сергей! В Вашем рисунке красная линия является нарушением изложенных выше правил. Следовательно, она является незаконной и запрещенной.

Спасибо. Я невнимательно прочитал описанные в тексте правила.

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


Уважаемый Сергей! Вы рассуждаете абсолютно правильно. Ошибки должны быть исключены не потому что человек должен помнить кучу правил и старательно соблюдать их.

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

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

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


:arrow: Первый инструмент: операция "Ввод атома".
Все атомы показаны на рис. 122. Операция "Ввод атома" описана на стр.237-240.

Обратите особое внимание на Тезис 10. Он гласит:

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

Операция "Ввод атома" осуществляется путем ввода атома либо в заготовку-примитив, либо в заготовку-силуэт (рис.115). Впрочем, это теория. На практике операция "Ввод атома" осуществляется путем вставки в заготовку (заготовку-примитив или заготовку-силуэт) графоэлементов, взятых из Меню графоэлементов на рис. 114.

Что при этом получается?

:!: Первый ответ дан на рис. 118. Там показано как заготовка-примитив постепенно превращается в полноценную дракон-схему примитив.

:!: Второй ответ дан на рис. 121. Там показано как заготовка-силуэт постепенно превращается в полноценную дракон-схему силуэт.

Операция "Ввод атома" есть не что иное как операция ВЛОЖЕНИЯ атома (но не куда попало, а только) в валентную точку. В помощью этой операции получается СТРУКТУРНАЯ ПРОГРАММА ПО ДЕЙКСТРЕ (мелкие отклонения не в счет).

:arrow: Второй инструмент: операции "Пересадка лианы" и "Заземление лианы" (стр.229 и 231).
Эти операции уже НЕ ЯВЛЯЮТСЯ СТРУКТУРНЫМИ ПО ДЕЙКСТРЕ. Но они очень полезны.

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

Говоря Вашими словами, "используя эти графические примитивы неправильно и нарисовать-то не получится как ни крути"

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

Конец Части 7. Конец ответов Паронджанова на сообщение Сергея Губанова.

Продолжение последует примерно через 10 дней


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Март, 2008 23:10 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Инструментарий любителям блок-схем: http://www.elderscrolls.net/conference/lofiversion/index.php/t1733.html после слов "Есть программа но нужны блок-схемы?"


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

Зарегистрирован: Среда, 19 Март, 2008 23:02
Сообщения: 2
Тогда уж вот здесь посмотреть стоит:
http://www.visual-paradigm.com/product/ ... arison.jsp
(1MB страничка весит, перечисляются возможности)
но это всё не то...


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

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Владимир Паронджанов писал(а):
Возможно, Вы скажете, что эти правила слишком сложны. Это не так. Эти правила вагоновожатому (то бишь пользователю) знать вовсе не обязательно. Трамвай все равно поедет только по рельсам. Ездить без рельсов он просто не умеет. Потому что все изложенные выше правила служат не для того чтобы их зубрили люди, а для того чтобы их автоматически выполнял дракон-редактор.
Нет, не скажу. Но то что эти правила не заданы вне контекста дракон-редактора скажу. Точнее, не эти, а те которым дракон-схемы подчиняются.
Владимир Паронджанов писал(а):
Продолжение последует примерно через 10 дней

Мое предложение из этого срока уже вышло, вроде.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В этом сообщении изложена Часть 8, в которой представлен ответ Паронджанова на сообщения GUEST: Пятница, 28 Март, 2008 00:26 и Вторник, 01 Апрель, 2008 05:07 .
Примерно через десять дней последует Часть 9, в которой я продолжу отвечать на вопросы и критические замечания участников форума.

С глубоким уважением Владимир Паронджанов

Часть 8. Ответ Паронджанова на сообщения GUEST Пятница, 28 Март, 2008 00:26 и Вторник, 01 Апрель, 2008 05:07

GUEST Пятница, 28 Март, 2008 00:26

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

GUEST Вторник, 01 Апрель, 2008 05:07


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

Мое предложение из этого срока уже вышло, вроде.


Ответ Паронджанова

Уважаемый GUEST!

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

Благодарю за Ваши критические замечания. Но согласиться с Вами не могу по следующим причинам:

1. Графический синтаксис языка Дракон определен математически строго: полностью, без пробелов и двусмысленностей (см. главы 15-17).
(Впрочем, если Вы со мной не согласитесь, я с большим вниманием выслушаю Ваши возражения).

2. Описание графического синтаксиса языка Дракон дано БЕЗ КАКИХ-ЛИБО ССЫЛОК НА ГРАФИЧЕСКИЙ ДРАКОН-РЕДАКТОР.

3. Указанные правила сохраняют силу даже если графический дракон-редактор НЕ СУЩЕСТВУЕТ. В этом случае эти правила могут быть использованы при построении дракон-схем вручную (карандашом на бумаге) или с помощью универсальных графических редакторов (WORD, VISIO, CorelDRAW и т.д.).

4. Правила графического синтаксиса языка Дракон являются исходными данными для проектирования дракон-редактора.

5. Таким образом, графический синтаксис языка Дракон никак не зависит от существования или несуществования дракон-редактора.

6. Наоборот, дракон-редактор целиком определяется этими правилами. Если правила графического синтаксиса отсутствуют, дракон редактор построить невозможно.

7. Правила графического синтаксиса языка Дракон первичны. Они являются исходными данными для проектирования дракон-редактора. Дракон-редактор вторичен.

8. СНАЧАЛА ПОЯВЛЯЮТСЯ ПРАВИЛА ГРАФИЧЕСКОГО СИНТАКСИСА.
И ТОЛЬКО ПОСЛЕ ЭТОГО СОЗДАЕТСЯ ДРАКОН-РЕДАКТОР.

9.Уважаемый GUEST! Вы пишете: "До сих пор не определено, какие Дракон-схемы являются некорректными. Из описания языка это не следует".
Это утверждение является ошибочным.

10.В книге определены правила графического синтаксиса.
Дракон-схемы, удовлетворяющие этим правилам, являются корректными.
Если же схема построена с нарушением правил, она является некорректной.
А дракон-редактор здесь ни при чем.

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

Уважаемый GUEST! Возможно, я затронул далеко не все вопросы, которые Вы желали обсудить. В таком случае поправьте меня.

Конец Части 8. Конец ответов Паронджанова на сообщения GUEST.

Продолжение (Часть 9) последует примерно через 10 дней.


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

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Попробую пояснить позицию. Очевидно она не совпадает с Вашей.
Владимир Паронджанов писал(а):
2. Описание графического синтаксиса языка Дракон дано БЕЗ КАКИХ-ЛИБО ССЫЛОК НА ГРАФИЧЕСКИЙ ДРАКОН-РЕДАКТОР.
Описание языка Дракон описанием графического синтаксиса языка не исчерпывается. Как и любого другого.
Владимир Паронджанов писал(а):
6. Наоборот, дракон-редактор целиком определяется этими правилами. Если правила графического синтаксиса отсутствуют, дракон редактор построить невозможно.

Первое утверждение не следует из второго. Против второго не имею никаких замечаний.
Владимир Паронджанов писал(а):
9.Уважаемый GUEST! Вы пишете: "До сих пор не определено, какие Дракон-схемы являются некорректными. Из описания языка это не следует".
Это утверждение является ошибочным.
10.В книге определены правила графического синтаксиса.
Дракон-схемы, удовлетворяющие этим правилам, являются корректными.
Если же схема построена с нарушением правил, она является некорректной.
А дракон-редактор здесь ни при чем.
Владимир Данилович, если дракон-схему нельзя создать в дракон-редакторе, то она для него будет некорректной, даже в случае если не нарушает правила синтаксиса, описанные в Вашей книге.
Владимир Паронджанов писал(а):
Уважаемый GUEST! Возможно, я затронул далеко не все вопросы, которые Вы желали обсудить. В таком случае поправьте меня.
Было предложение о судьбе публикации статьи в Интернете. Если это возможно, просьба ознакомиться с ней по e-mail.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Апрель, 2008 20:13 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В этом сообщении изложена Часть 9, в которой представлен ответ Паронджанова на сообщение GUEST Вторник, 01 Апрель, 2008 17:42
Примерно через десять дней последует Часть 10, в которой я продолжу отвечать на вопросы и критические замечания участников форума.

С глубоким уважением Владимир Паронджанов

Часть 9. Ответ Паронджанова на сообщения GUEST Вторник, 01 Апрель, 2008 17:42 .

Уважаемый GUEST! Благодарю Вас за то, что Вы разъяснили свою позицию.
Я понял, что мой предыдущий ответ является явно недостаточным. Вы подняли очень глубокий вопрос. Поэтому мой ответ будет подробным. Я разобью ответ на 6 пунктов.

Сначала объясню назначение каждого пункта.

Пункты 1 и 2 носят теоретический характер и представляют обширные цитаты из моей книги.

Пункт 3 дает краткую выжимку из теоретической части.

Пункт 4 содержит заключение по теоретической части.

В Пункте 5 (Дискуссия) я возвращаюсь к Вашему сообщению (GUEST Пятница, 28 Март, 2008 00:26), где Вы утверждаете: «ДО СИХ ПОР НЕ ОПРЕДЕЛЕНО, КАКИЕ ДРАКОН-СХЕМЫ ЯВЛЯЮТСЯ НЕКОРРЕКТНЫМИ. ИЗ ОПИСАНИЯ ЯЗЫКА ЭТО НЕ СЛЕДУЕТ». Я попытаюсь доказать, что это утверждение является ошибочным.

В Пункте 6 отвечаю на Ваше предложение о статье.

Пункт 1. Маршрутный, командный и декларативный языки — три части императивного языка (Отрывок из книги Паронджанова (стр. 192)).

ФИЛОСОФИЯ ЯЗЫКА ДРАКОН

Любой императивный язык (СИ, ПАСКАЛЬ, АДА, МОДУЛА, БЕЙСИК
и т. д.) можно разбить на три части, три относительно самостоятельных языка: маршрутный, командный и декларативный.

Маршрутный язык — совокупность управляющих операторов.

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

Декларативный язык служит для описания данных, классов и др.

Поясним сказанное на примере. Абстрактная дракон-схема, приведенная на рис. 97, есть некоторая “фраза” маршрутного языка. Чтобы сделать ее содержательной, внутри икон следует поместить текст. Этот текст пишется на командном языке. Однако описания данных и классов иногда целесообразно вынести за рамки дракон-схемы и поместить их где-нибудь в другом месте, например, в виде отдельной записи или таблицы.

Отсюда вытекает принцип разграничения трех подъязыков. Маршрутный язык — это язык “картинок” (абстрактных дракон-схем, в которых полностью отсутствует текст). Командный язык служит для записи текста внутри дракон-схемы. Декларативный — для тех записей, которые можно вынести за ее пределы.

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

Таким образом, дракон-семейство имеет только одно жесткое звено — маршрутный язык, который есть не что иное, как визуальные компоненты ДРАКОНА (визуальный синтаксис и семантика).

Маршрутный язык — это визуальный стандарт дракон-семейства, поддерживаемый визуальным дракон-редактором (см. гл. 14), который имеет небольшие размеры и легко запоминается. Он является неизменной визитной карточкой ДРАКОНА, его стандартизованным зрительным образом (рис. 97).

Конец пункта 1.

Пункт 2. Исчисление икон, шампур-метод и т.д. (Отрывок из книги Паронджанова стр. 271—281).

ИСЧИСЛЕНИЕ ИКОН

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

    • Множество икон И (букв визуального алфавита) задано тезисом 1 (см. гл. 15) и показано на рис. 1.

    • Множество So правил визуального синтаксиса описано в гл. 15 в тезисах 2—37.

    • Множество А визуальных аксиом включает всего два элемента: заготовку-примитив и заготовку-силуэт (рис. 115). Далее будем называть их аксиома-примитив и аксиома-силуэт.

    • Множество Т, охватывающее все видеотеоремы исчисления V, есть не что иное как множество абстрактных дракон-схем. Заметим, что множество Т не включает аксиомы, так как последние содержат незаполненные критические точки и, следовательно, эквивалентны пустым операторам. Множество Т распадается на две части: множество примитивов Т1 и множество силуэтов Т2.

    • Множество F правил видеовывода также делится на две части F1
    и F2. Множество F1 позволяет выводить все теоремы-примитивы, принадлежащие множеству Т1, из единственной аксиомы-примитива. Оно содержит пять правил вывода: ввод атома, добавление
    варианта, пересадка лианы, боковое присоединение, удаление конца примитива. Эти правила описаны в тезисах 10, 21, 28, 30, 31, 34 гл. 15.

    • Множество F2 дает возможность выводить все теоремы-силуэты множества Т2 из единственной аксиомы-силуэта. Оно содержит восемь правил вывода: ввод атома, добавление варианта, добавление ветки, пересадка лианы, заземление лианы, боковое присоединение, удаление последней ветки, дополнительный вход. Правила вывода для силуэта описаны в тезисах 10, 21, 28—33, 35 гл. 15.

На этом построение исчисления икон заканчивается.

Известно, что изучение исчислений составляет синтаксическую часть математической логики. Кроме того, последняя занимается семантическим изучением формальных языков, причем основным понятием семантики служит понятие истинности [1].

В исчислении икон семантика тривиальна. Различные видеоформулы (блок-схемы) могут быть истинными или ложными. Видеоформула называется истинной, если она —либо аксиома, либо выводится из аксиом с помощью правил вывода (т. е. является теоремой), и ложной в противном случае.
Таким образом, все правильно построенные абстрактные дракон-схемы (теоремы) истинны. И наоборот, неправильно построенные схемы, не удовлетворяющие визуальным правилам языка ДРАКОН, считаются ложными. Примеры ложных схем показаны на рис. 131 и 132 в левой графе.

ЕЩЕ РАЗ О ШАМПУР-МЕТОДЕ

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

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

Шампур-схема — абстрактная дракон-схема. Подчеркнем, что шампур-схема по определению является абстрактной, т. е. полностью лишенной текста.
Шампур-язык — язык шампур-схем. Для шампур-языка задан только визуальный синтаксис, текстовый синтаксис не определен.

ШАМПУР-СХЕМА КАК АБСТРАКТНАЯ
МОДЕЛЬ ПРОГРАММЫ

Уже говорилось, что для видеопрограммирования характерно “расщепление синтаксиса”. Синтаксис S распадается на визуальный синтаксис S0, определяющий правила построения шампур-схем, и текстовый синтаксис S1, задающий алфавит текстоэлементов и правила записи текстовых операторов внутри икон. Исходя из этого, можно сказать, что шампур-программа В состоит из двух частей: В0 и В1, где В0 — шампур-схема с синтаксисом S0; B1 — текстовая часть программы, т. е.
совокупный текст, находящийся во всех иконах программы, определяемый синтаксисом S1.

Бросается в глаза несомненное сходство между шампур-схемами и схемами программ. Заметив эту аналогию и повторяя — с некоторыми, почти очевидными изменениями — общую канву рассуждений, принятую в схематологии [7], можно сделать вывод, что шампур-схема В0 описывает уже не одну программу, а целый класс программ, т. е. является полипрограммой, а шампур-язык служит мультиязыком — языком полипрограммирования [8].

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

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

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

ПРЕОБРАЗОВАНИЕ ШАМПУР-СХЕМЫ
В ШАМПУР-ПРОГРАММУ

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

Для этого необходимо дополнительно задать текстовый синтаксис S1 и семантику Q1 текстовых операторов, помещаемых в иконах шампур-схемы. Например, если взять текстовый синтаксис и семантику, соответствующие языку ПАСКАЛЬ, получим язык визуального программирования, который можно назвать “шампур-паскаль”. Аналогично можно построить языки шампур-бейсик, шампур-си и т. д.

Используя терминологию схематологии, можно сказать, что шампур-программа есть интерпретированная шампур-схема, однако понятие интерпретации в нашем случае заметно отличается от классического [7].

Детальное рассмотрение вопроса выходит за рамки книги, ограничимся лишь кратким замечанием. Чтобы задать интерпретацию шампур-схемы и превратить ее в шампур-программу, необходимо, во-первых, доопределить шампур-язык и превратить его в язык программирования, описав синтаксис S1 и семантику Q1 текстовых операторов.
Во-вторых, следует указать конкретные текстовые операторы, записанные в соответствии с синтаксисом S1 и размещенные в иконах шампур-схемы В0. Тем самым будет задана текстовая часть В1 шампур-программы В. Таким образом, интерпретация шампур-схемы определяется как тройка < S1, Q1, B1 >.

Отсюда вытекает следующее очевидное замечание. Поскольку шампур-язык есть абстрактная модель любого императивного языка программирования (импер-языка), постольку импер-язык есть интерпретированный шампур-язык. При этом интерпретация шампур-языка, превращающая его в конкретный импер-язык, определяется как пара < S1, Q1 >.

ШАМПУР-МЕТОД И ДОКАЗАТЕЛЬСТВО
ПРАВИЛЬНОСТИ ПРОГРАММ

Согласно Р. Андерсону, “целью многих исследований в области доказательства правильности программ является... механизация таких доказательств” [10].
Д. Грис указывает, что “доказательство должно опережать построение программы” [11]. Объединив оба требования, получим, что автоматическое доказательство правильности должно опережать построение программы.

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

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

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

А теперь добавим ложку дегтя в бочку меда. К сожалению, данный метод позволяет доказать правильность шампур-схемы и только. Это составляет лишь малую часть от общего объема работы, которую нужно выполнить, чтобы доказать правильность программы на все 100%.

Правда, есть небольшое утешение: частичное доказательство правильности программы с помощью ДРАКОН-редактора осуществляется без какого-либо участия человека и достигается совершенно бесплатно, так как дополнительные затраты труда, времени и ресурсов не требуются. А дареному коню в зубы не смотрят.

ВОЗМОЖНА ЛИ ТЕОРИЯ ВИЗУАЛЬНОГО ПРОГРАММИРОВАНИЯ?

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

    «Для визуального программирования необходимо провести строгие научные обоснования, математические определения и модели — большинство разработок в этой области носит пока эмпирический характер. Перспективным может быть применение при графическом интерфейсе техники искусственного интеллекта, которая обычно используется для описания прикладной области. Система представления знаний может включать набор визуальных примитивов, их символические описания и правила вывода заключений» [12].

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

Отличие заключается в следующем. Авторы цитированной работы говорят о “символических описаниях” визуальных примитивов, подразумевая текстовые правила вывода заключений, принятые в традиционной текстовой математической логике.

Однако еще А. Ершов при построении исчисления равносильных преобразований схем Янова предпринял первую попытку отойти от “чисто текстовой” математической логики, используя в формулах правил вывода не только символические описания, но и графические изображения [9, 13]. Вместе с тем метод Ершова из-за дефектов визуального синтаксиса нельзя считать полностью формальным.

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

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

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

ГИПОТЕЗА О БУДУЩЕМ ИМПЕРАТИВНЫХ
ЯЗЫКОВ ПРОГРАММИРОВАНИЯ

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

    • Несмотря на резкую критику со стороны Джона Бэкуса и ряда других ученых фон-неймановские (императивные) языки по-прежнему находят широкое применение и продолжают занимать прочные, а в некоторых областях — господствующие позиции. Логично предположить, что такая или примерно такая ситуация сохранится и впредь. Сходную позицию занимают и другие авторы, по мнению которых императивные языки “в обозримом будущем сохранят доминирующее положение в практическом программировании” [14].

    :( Этот материал частично устарел. Следует читать: в обозримом будущем многие языки сохранят в своем составе императивную часть.

    • В грядущем столетии вследствие дальнейшего уменьшения удельной стоимости аппаратуры у многих персональных компьютеров экраны, по-видимому, увеличатся до размеров письменного стола, что облегчит визуализацию программирования за счет возможности непосредственной работы с чертежами формата А1 или даже А0 на экране ПЭВМ по принципу WYSIWYG — What You See Is What You Get (Что видишь, то и имеешь). Согласно развиваемой гипотезе, это позволит более полно использовать телесный угол и структуру человеческого поля зрения, покончить, наконец, с систематическим недоиспользованием богатейших возможностей человеческого глаза, задействовать мощные резервы симультанного восприятия и тем самым значительно увеличить скорость работы и продуктивность мозга программистов и пользователей. Учитывая эти соображения и остроту проблемы производительности труда в программировании, мы предполагаем, что ожидаемое увеличение габаритов экранов даст мощный стимул для широкомасштабной замены текстовых императивных языков на визуальные.

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

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

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

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

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

    • Очевидно, в принципе можно построить компилятор, преобразующий чертеж шампур-программы непосредственно в ассемблер и объектный код, без промежуточного преобразования в исходный текст языка высокого уровня. Не исключено, что прогнозируемый процесс визуализации программирования и образование на этой основе нового поколения (визуальных) императивных языков создаст предпосылки, при которых подобная прямая компиляция во многих случаях окажется более предпочтительной. В подобных ситуациях понятие исходный текст программы, видимо, полностью исчезнет из лексикона “императивных” программистов, уступив место термину исходный чертеж программы.

ВИЗУАЛИЗАЦИЯ ЛОГИКИ
И ИНТЕНСИФИКАЦИЯ ИНТЕЛЛЕКТУАЛЬНОЙ ДЕЯТЕЛЬНОСТИ

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

    • Сам факт формализации системы визуальных образов в виде логического исчисления икон можно, по-видимому, рассматривать как доказательство полной несостоятельности “принципа абсолютизации текста” (см. с. 269). Иными словами, формализация человеческих знаний отнюдь не сводится только к текстовой форме, но включает также и визуальные представления. Важно подчеркнуть, что визуальная формализация знаний не является “продуктом второго сорта”, она удовлетворяет самым строгим критериям математической логики и в этом смысле представляет собой вполне законный и полноценный интеллектуальный продукт. Наибольшая интеллектуальная эффективность достигается при использовании синтетического метода, объединяющего достоинства текстовой и визуальной формализации.

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

    • Известно, что “богатые формальные языки математической логики и успешный опыт работы с ними создали одну из объективных предпосылок для создания... вычислительных машин, пользующихся в настоящее время весьма разнообразным спектром формальных языков программирования” [1]. Это утверждение до последнего времени было ограничено рамками текстовой парадигмы: и в отношении логики, и в отношении программирования. Появление визуальных исчислений позволяет расширить эти рамки и распространить их на визуальный случай.

    • Необходимость в этом давно назрела, так как теория в данном вопросе отстает от практики. С появлением интегрированных CASE-технологий компьютерные чертежи (например, схемы “сущность-связь”, схемы декомпозиции, схемы потоков данных и т. д.) приобрели целый ряд замечательных свойств. Они превратились в формальные визуальные языки высокой точности. Компьютер может понимать точные значения указанных чертежей, хранить их в виде, пригодном для глубокой обработки, преобразовывать чертежи друг в друга, выявлять несоответствие между ними, а также их неполноту, чтобы гарантировать целостность общей картины. И, что особенно важно, извлекая из чертежей нужную информацию, компьютер с помощью программы “генератор кода” получает выполнимый код. Таким образом, можно надеяться, что в будущем традиционная дружба математической логики и информатики уже не будет ограничена дряхлым забором текстовой парадигмы и распространится на более широкое визуальное проблемное поле.

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

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

    • Логическая формализация знаний, восходящая к силлогистике Аристотеля, который впервые использовал буквы для обозначения понятий, явилась замечательным достижением человеческого гения. За две тысячи лет своего существования логическая наука добилась выдающихся успехов. Но вот парадокс: называя себя наукой о законах и формах человеческого мышления [5], логика вместе с тем полностью абстрагировалась от конкретных характеристик человеческого мышления и мозга, изучаемых в психологии, нейробиологии и эргономике. На предыдущих этапах развития человечества, когда интеллектуальные задачи были относительно простыми, а число интеллектуальных работников невелико, подобное игнорирование не приносило заметного вреда. Однако сегодня положение изменилось.

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

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

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

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

Это громадная, поистине необъятная по сложности задача, выходящая далеко за рамки данной книги. Для ее решения необходим перелом в сознании: надо уяснить, что человеческий мозг обладает колоссальными интеллектуальными резервами, которые сегодня не используются, но которые можно и нужно задействовать с помощью когнитивно-эргономических методов. Снова оговоримся: существующие когнитивные методы для этого недостаточны, нужны новые подходы. Откуда их взять? По мнению автора, материалы данной книги, хотя и относятся к частному случаю, тем не менее, обладают достаточной общностью и могут послужить основой для разработки — с необходимыми уточнениями — нового поколения формализованных когнитивно-эргономических методов.

ВЫВОДЫ

1. Противоречие между скромными интеллектуальными возможностями отдельного человека и почти неограниченным объемом знаний, который он должен приобрести в течение жизни, — одно из наиболее драматических противоречий современного общества, основанного на знаниях. Сегодня наука не располагает эффективными средствами для решения этой проблемы.

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

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

4. Стихийный процесс визуализации логики, который начинает разворачиваться в последнее время (см., например [15]), должен опираться на прочную эргономическую основу.

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

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

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

Конец Пункта 2. (Конец цитаты из книги «Как улучшить работу ума…» стр. 271—281).

Пункт 3. Краткая выжимка из только что изложенной теоретической части

1) Любой императивный язык (СИ, ПАСКАЛЬ, АДА, МОДУЛА, БЕЙСИК
и т. д.) можно разбить на три части, три относительно самостоятельных языка: маршрутный, командный и декларативный.

2) Маршрутный язык — совокупность управляющих операторов.

3) Командный язык содержит все неуправляющие операторы, например оператор присваивания, правила записи арифметических и логических выражений, идентификаторов, ключевые слова и т. д.

4) Декларативный язык служит для описания данных, классов и др.

5) Все правильно построенные абстрактные дракон-схемы (теоремы) истинны. И наоборот, неправильно построенные схемы, не удовлетворяющие визуальным правилам языка ДРАКОН, считаются ложными (стр. 272).

6) Шампур-схема — абстрактная дракон-схема. Подчеркнем, что шампур-схема по определению является абстрактной, т. е. полностью лишенной текста.

7) Шампур-язык — язык шампур-схем. Для шампур-языка задан только визуальный синтаксис, текстовый синтаксис не определен.

8) Шампур-программа В состоит из двух частей: В0 и В1, где В0 — шампур-схема с синтаксисом S0; B1 — текстовая часть программы, т. е. совокупный текст, находящийся во всех иконах программы, определяемый синтаксисом S1.

9) Шампур-схема В0 описывает уже не одну программу, а целый класс программ, т. е. является полипрограммой, а шампур-язык служит мультиязыком — языком полипрограммирования [8]. (стр. 273).

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

11) Для этого необходимо дополнительно задать текстовый синтаксис S1 и семантику Q1 текстовых операторов, помещаемых в иконах шампур-схемы. (стр. 274).

12) Шампур-программа есть интерпретированная шампур-схема. Чтобы задать интерпретацию шампур-схемы и превратить ее в шампур-программу, необходимо, во-первых, доопределить шампур-язык и превратить его в язык программирования, описав синтаксис S1 и семантику Q1 текстовых операторов. Во-вторых, следует указать конкретные текстовые операторы, записанные в соответствии с синтаксисом S1 и размещенные в иконах шампур-схемы В0. Тем самым будет задана текстовая часть В1 шампур-программы В. Таким образом, интерпретация шампур-схемы определяется как тройка < S1, Q1, B1 > (стр. 274).

13) Поскольку шампур-язык есть абстрактная модель любого императивного языка программирования (импер-языка), постольку импер-язык есть интерпретированный шампур-язык. При этом интерпретация шампур-языка, превращающая его в конкретный импер-язык, определяется как пара < S1, Q1 > (стр. 274).

14) В алгоритмах ДРАКОН-редактора закодировано исчисление икон, поэтому любая шампур-схема, построенная с его помощью, является истинной, т. е. правильно построенной. Это означает, что ДРАКОН-редактор осуществляет 100%-е автоматическое доказательство правильности шампур-схем, гарантируя принципиальную невозможность ошибок визуального синтаксиса (стр. 275).

15) С точки зрения шампур-метода, любой визуальный императивный язык включает три языка: маршрутный, командный и декларативный (см. гл. 12).

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

Пункт 4. Краткое заключение

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

Маршрутный язык — это пустая дракон-схема (слепыш).

Командный язык определяет синтаксис и семантику текста, который разрешается записывать в клеточках слепыша.

Декларативный язык служит для определения данных и объектов.

Маршрутный и командный язык задаются с помощью двух редакторов (графического и текстового), которые удобно совместить в одном редакторе.
Для декларативного языка в ряде случаев удобно использовать отдельный редактор.
В нашей (ракетной) технологии используется два редактора:
    • графит-редактор (для маршрутного и командного языков);
    • флокс-редактор (для декларативного языка, описывающего данные и объекты).

Пункт 5. Дискуссия GUEST и Паронджанова

GUEST Вторник, 01 Апрель, 2008 17:42


GUEST писал(а):
Попробую пояснить позицию. Очевидно она не совпадает с Вашей.
Владимир Паронджанов писал(а):
2. Описание графического синтаксиса языка Дракон дано БЕЗ КАКИХ-ЛИБО ССЫЛОК НА ГРАФИЧЕСКИЙ ДРАКОН-РЕДАКТОР.
Описание языка Дракон описанием графического синтаксиса языка не исчерпывается. Как и любого другого.

Ответ Паронджанова

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

GUEST Вторник, 01 Апрель, 2008 17:42 (продолжение)

Владимир Паронджанов писал(а):
9.Уважаемый GUEST! Вы пишете: "До сих пор не определено, какие Дракон-схемы являются некорректными. Из описания языка это не следует".
Это утверждение является ошибочным.
10.В книге определены правила графического синтаксиса.
Дракон-схемы, удовлетворяющие этим правилам, являются корректными.
Если же схема построена с нарушением правил, она является некорректной.
А дракон-редактор здесь ни при чем.
Владимир Данилович, если дракон-схему нельзя создать в дракон-редакторе, то она для него будет некорректной, даже в случае если не нарушает правила синтаксиса, описанные в Вашей книге.

Ответ Паронджанова

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

    • графит-редактор для разработки алгоритмов;
    • флокс-редактор для описания данных и объектов.

Графит-редактор НЕ УМЕЕТ описывать данные и объекты. А флокс-редактор НЕ УМЕЕТ конструировать алгоритмы. Чтобы создать законченный продукт (программу) нужно использовать оба редактора. Следовательно, законченную программу нельзя создать с помощью одного редактора — нужны оба. Но это вовсе не означает, что законченная программа будет для каждого из этих редакторов некорректной. Почему? Потому что здесь имеет место разделение труда между редакторами. Некорректность здесь ни при чем.

Есть и еще один немаловажный момент. Давайте учтем вопросы теоретического программирования, описанные выше. В рамках этого теоретического подхода мы имеем право рассматривать пустую дракон-схему (слепыш) как математический объект, обладающий определенными свойствами. И мы вправе эти свойства изучать, временно отвлекаясь от других свойств.
Приведу цитату из книги «Касьянов В.Н. Оптимизирующие преобразования программ. М.: Наука, Главная редакция физико-математической литературы, 1988». С. 35.
    "Крупноблочная схема программы может быть представлена в виде текста на некотором языке «полипрограммирования», который в отличие от обычного языка программирования допускает семантическую многозначность данных и операций. Фиксация одной из возможных интерпретаций превращает крупноблочную схему, которая до этого времен является «полипрограммой» (описанием целого множества крупноблочных полипрограмм, имеющих одну и ту же структуру) в конкретную программу для некоторой гипотетической вычислительной машины…"

Пункт 6. Судьба статьи

GUEST Пятница, 28 Март, 2008 00:26

Владимир Паронджанов писал(а):
Уважаемый GUEST! Возможно, я затронул далеко не все вопросы, которые Вы желали обсудить. В таком случае поправьте меня.
Было предложение о судьбе публикации статьи в Интернете. Если это возможно, просьба ознакомиться с ней по e-mail.


Ответ Паронджанова

У меня нет электронного текста этой статьи. Есть очень некачественный бумажный экземпляр, присланный по факсу. Его надо набивать «ручками» и еще что-то делать с рисунками. Но я постараюсь что-нибудь придумать. Но не очень скоро.

Конец Части 9. Конец ответов Паронджанова на сообщения GUEST

Продолжение (Часть 10) последует примерно через 10 дней.


Последний раз редактировалось Владимир Паронджанов Четверг, 29 Май, 2008 13:18, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Апрель, 2008 21:52 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Владимир Паронджанов писал(а):
• Стандартизация выделенного инварианта императивных языков осуществляется благодаря использованию стандартных шампур-редакторов, применение которых должно регламентироваться процедурой сертификации, согласованной с международной организацией стандартизации ISO. Опыт создания национальных и международных стандартов на блок-схемы и их повсеместного использования позволяет надеяться на успех предлагаемого предприятия.
Полностью согласен, но пока достаточно их прописать. Внутрифирменная документация их заменить не может.
Владимир Паронджанов писал(а):
• Очевидно, в принципе можно построить компилятор, преобразующий чертеж шампур-программы непосредственно в ассемблер и объектный код, без промежуточного преобразования в исходный текст языка высокого уровня. Не исключено, что прогнозируемый процесс визуализации программирования и образование на этой основе нового поколения (визуальных) императивных языков создаст предпосылки, при которых подобная прямая компиляция во многих случаях окажется более предпочтительной. В подобных ситуациях понятие исходный текст программы, видимо, полностью исчезнет из лексикона “императивных” программистов, уступив место термину исходный чертеж программы.
Большое спасибо за предоставленную схему. Есть ли какая-либо открытая информация по выходу анализатора и его алгоритму?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9, 10, 11 ... 19  След.

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


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

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


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

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