DRAKON.SU

Текущее время: Вторник, 16 Октябрь, 2018 15:26

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




Начать новую тему Ответить на тему  [ Сообщений: 81 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 12 Август, 2012 17:08 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов писал(а):
Подытожу сказанное выше в моих сообщениях.
И дам заключительный ответ на критическое замечание Ильи Ермакова
Илья Ермаков в сообщении viewtopic.php?p=73786#p73786 писал(а):
Владимир Паронджанов писал(а):
Практическая ценность состоит в том, что управляющие операторы алгоритма, представленные в виде шампур-схемы оказываются безошибочными, гарантированно правильными.
Владимир Даниелович, синтаксически безошибочными, но не семантически.
Конструктор обеспечивает то же самое, что синтаксический анализатор обычных языков, но другим способом.

Уважаемый Илья Евгеньевич!
Это не совсем так.
1. Дракон-конструктор обеспечивает НЕ то же самое, что синтаксический анализатор обычных языков.
2. Дракон-конструктор делает БОЛЬШЕ, чем синтаксический анализатор обычных языков. Может быть, ненамного, но все таки БОЛЬШЕ.
3. Разница состоит в следующем:
      — Синтаксический анализатор глуп. Он позволяет обнаружить синтаксическую ошибку. Но он не может ее исправить. Единственное, что он может, это сообщить ЧЕЛОВЕКУ: есть ошибка и указать место ее локализации.
      — После этого человек должен прочитать листинг компилятора и понять этот листинг. Для этого он должен быть программистом, то есть человеком, имеющим квалификацию и умеющим читать такие сложные вещи, как листинг компилятора.
      — После этого человек (программист) должен вызвать исходный текст своей программы и найти в исходном тексте место с ошибкой. Затем внести исправление в исходный текст.
      — После этого человек должен еще раз скомпилировать программу и убедиться, что ошибок нет.
      (Если я что-то неправильно сказал, просьба меня поправить).
В случае дракон-конструктора НИЧЕГО ЭТОГО ДЕЛАТЬ НЕ НУЖНО. Потому что дракон-конструктор, в отличие от синтаксического анализатора, «умен». И не позволяет делать ошибки визуального синтаксиса.
...
Значит, так. В этой части ответа Вы, Владимир Даниелович, отчасти правы. Потому, что Илья, как можно понять место, выделенное (мною) курсивом, смешал там две вещи. Сначала дал общее утверждение (справедливое для любого "машинного творчества" на современном научном уровне) - семантику искусственному исполнителю-читателю мы передать в полной мере не можем. С помощью иного синтаксиса, чем текстовый - тоже.
А затем начал сравнивать два способа реализации синтаксического уровня работы с данными. И тут очевидно - "обычный" анализатор работает с неограниченным вводом сочинителя. Потому он именно анализирует - и выявляет ошибки синтаксиса. Тогда как исчислитель заранее ограничивает ввод сочинителя - потому, как Вы и отметили, при безотказной работе исключает необходимость анализа.

Но. Здесь есть "кое-какие оговорочки и недоговорочки".

1. "Кто устережёт стражника?" - самое очевидное. В реальной реализации :) мы должны допускать искажение результатов самого однозначного ввода (скажем, из-за сбоя аппаратуры). Потому машинное описание всё-таки надо проверять. Здесь обычные методы неспецифичны для содержания (защитное кодирование и пр.) - но мы можем добавить специфический - проверку синтаксиса.

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

3. Всегда ли устраняется необходимость синт-анализа? Нет - это зависит от глубины и характера ограничений ввода. Так, при исчислении мы уверенно можем отказаться от анализа конкретной части синтаксиса, если:
    * мы исчисляем только вложением в заданном алфавите (вводом простых/составных атомов);
    * для всех атомов доказано их соответствие принятым ограничениям (прежде всего касается составных, конечно).
Как только оослабляем требования относительно этого - всё, в правильности схем мы просто "по определению" уверены быть не можем. И надо вводить проверочные правила и процедуры.
Яркий пример сему - всё те же веточные циклы...

4. Замечу - нигде не говорил про "текстовый или иной" синтаксис. Потому что непринципиально это... исчисление точно также м.б. реализоовано над текстовыми конструкциями (пример - редактор группы Лаптева и РВ-проект Прохоренко).

5. Ограничивая сочинителя при исчислении - мы требуем от него анализа при вводе. Дабы правильно строить описание. Проблему описал, скажем, Алексей:
Alexey_Donskoy в viewtopic.php?p=39806#p39806 писал(а):
...
Смысл-то ведь проще некуда - в процессе выполнения действия (в том числе редактирования текста) система может находиться в несогласованном состоянии, но по завершении действия обязана иметь корректное и согласованное состояние.

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

Сводить всё к последовательности (неизбежно жёсткой) атомарных действий - неэргономично.
Давать максимальную свободу (без внутренней самодисциплины юзера) - в конечном счёте тоже неэргономично.
Добавлю - не только не эргономично, но и возвращает нас к проблемам, описанным у тех же Вторникова и Гаджиева... и о которых говорил здесь: viewtopic.php?p=73807#p73807 (тем более, что речь идёт именно о синтаксисе, как уже говорил тут: viewtopic.php?p=73809#p73809)...

И про "конкретную часть" тоже не просто так сказано... но это разговор отдельный...

Так что, хоть исчисление обеспечивает не то же самое, что синтаксический анализ свободного ввода - но замечание Ильи в его первой, более общей части:
Илья Ермаков в viewtopic.php?p=73786#p73786 писал(а):
Владимир Паронджанов писал(а):
Практическая ценность состоит в том, что управляющие операторы алгоритма, представленные в виде шампур-схемы оказываются безошибочными, гарантированно правильными.

Владимир Даниелович, синтаксически безошибочными, но не семантически.
...
- остаётся в силе...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 12 Август, 2012 17:29 

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

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

Понятно, что дракон-редактор решает более скромную задачу, чем классические методы доказательного программирования.
Ох-хо-хонюшки... ибо сразу вспоминается Муми-Мама... которой приходилось по-житейски разбираться с последствиями решения задач более скромных, чем реально ставит жизнь... в частности, с испоользованием "шляпы Волшебника"... :wink: :|

Уж совсем сжато о том, что говорилось здесь: viewtopic.php?p=73796#p73796. Вот есть дракон-конструктор. Пусть он строго ограничивает ввод сочинителя (как я описал выше) для импер-структур-схем. Но. На разметку этих схем (заполнение атрибутов вершин и рёбер - текстом, скажем) ему плевать - т.к. и исчисление задано для "слепышей". Ну, рёбра в ШМ сочиняемого смысла не имеют (ибо такова семантика - они представляют только подразумеваемое отношение "следовать за").
Сочинитель ввёл какие-то тексты заполнения вершин. Получилось то, что он считает программой. Как правильность "слепыша" доказывает правильность программы? А если он неверно задал выражения? параметры ввода/вывода? взаимодействия процессов? типизацию величин? их области видимости?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 12 Август, 2012 19:27 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3782
Откуда: Москва
Владислав Жаринов писал(а):
... рёбра в ШМ сочиняемого смысла не имеют (ибо такова семантика - они представляют только подразумеваемое отношение "следовать за").

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

Это не так. Семантика совсем не такова, как Вы утверждаете.

Например, если в макроикону "развилка" в обе критические валентные точки ввести пустые (абстрактные) иконы действие, то полученный слепыш будет математически равносилен конструкции если-то-иначе (if-then-else).

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

Это подробно доказано в книге "Дружелюбные алгоритмы, понятные каждому" на стр. 159, 160. См. Рис. 93. Абстрактный алгоритм.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 12 Август, 2012 22:52 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
Владислав Жаринов писал(а):
Как правильность "слепыша" доказывает правильность программы? А если он неверно задал выражения? параметры ввода/вывода? взаимодействия процессов? типизацию величин? их области видимости?


Никак!

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 12 Август, 2012 23:50 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владислав Жаринов писал(а):
2. Т.к. мы о верификации ...

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

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

Назовите, пожалуйста, конкретные вещи в первом и втором случае и я попробую ответить на Ваш вопрос. Боюсь, что не совсем понимаю что названо «рабочей точкой».


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Понедельник, 13 Август, 2012 15:41 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3782
Откуда: Москва
Владислав Жаринов писал(а):
Как правильность "слепыша" доказывает правильность программы? А если он неверно задал выражения? параметры ввода/вывода? взаимодействия процессов? типизацию величин? их области видимости?


usr345 писал(а):
Никак!

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


В обеих цитатах чувствуется недооценка слепыша.
Поэтому я хотел бы выступить

В ЗАЩИТУ СЛЕПЫША
СЛЕПЫШ — ЭТО ОЧЕНЬ ВАЖНО!


Возражение Владиславу Жаринову. Я никогда не утверждал, что "правильность слепыша доказывает правильность программы". Поэтому формулировка Жаринова некорректна.

Формулировка usr345 полностью корректна. Действительно "никак".

Вместе с тем я хотел привести несколько долнительных соображений.

====================================

План моего рассказа таков.

1. Сначала я приведу большую цитату из Сергея Ефанова.

2. Потом я сокращу текст Сергея Ефанова и представлю его в виде 12 тезисов.

3. Далее я попытаюсь доказать, что эти 12 тезисов можно истолковать как убедительную защиту слепыша.

4. Развивая эту мысль, я докажу, что слепыш — это отнюдь не мелочь, а очень важная вещь.

В начале сообщений я буду обозначать их как
ШАГ ДОКАЗАТЕЛЬСТВА 1

ШАГ ДОКАЗАТЕЛЬСТВА 2

и т.д.

====================================
Прошу критиковать мои рассуждения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Понедельник, 13 Август, 2012 15:50 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3782
Откуда: Москва
ШАГ ДОКАЗАТЕЛЬСТВА 1

Автор статьи Сергей Ефанов

Программирование микроконтроллеров на ДРАКОНе
http://we.easyelectronics.ru/drakon/pro ... akone.html

Цитата:
Некоторое время назад мне на глаза попалось упоминание о языке ДРАКОН. Я немного почитал, ничего не понял, закрыл, забыл.
Но почему-то забылось не совсем.
Тут подвернулась поездка. Снова нашёл, закачал файл в электронную книжку, взял с собой. В поезде всё равно делать нечего.

Медленно и со вкусом прочитал.

И — понял! Это просто клад!

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

Функция заработала сразу! Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!

В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!

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

Написание программы распалось на два этапа — проработка алгоритма, и собственно программирование.

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

Но есть несколько строгих правил, которые не позволяют схеме превратиться в запутанный клубок линий, квадратов и ромбиков.
Правила, на первый взгляд, простые. Но эффект от их применения — колоссальный!

На ДРАКОНЕ запутанный и непонятный алгоритм нарисовать просто нельзя. И наоборот, любой сложный алгоритм, нарисованный согласно этим правилам, становится очень понятным.

При разработке алгоритма теперь его не надо держать в голове при написании текста программы. Работа сводится к визуальному конструированию алгоритма. Это гораздо легче. Не требуется такое сосредоточение, как обычно. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент, потом легко вернуться к её продолжению.

И только когда весь алгоритм «отлизан» — переходим к собственно программированию. В чём оно теперь заключается? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка. На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.

В этом месте, наверняка, у многих вырвется вопрос: — «Ну и зачем весь этот огород, если код всё равно надо писать самому?!».

Не торопитесь!

В чём сложность программирования? (с тем, что программирование — сложная работа, думаю, никто спорить не будет?).

Разве в написании строчек типа printf(«Hello, Word»);?
Станет ли сложной программа от того, что мы напишем 1000 подобных строчек? А 10000?
Нет, она не станет от этого сложной. Сложной программу делают сложные взаимосвязи между её частями.

Так вот, на этапе программирования икон об этом думать уже не надо.

Совсем. Вообще. Никак. Не надо, и всё тут!

Всё, что нужно — аккуратно запрограммировать ОДНУ икону. Только ОДНУ! Когда будем программировать другую — про предыдущую уже можно не вспоминать. В тот код, который сгенерирует редактор — смотреть не нужно. Так же, как мы не смотрим в машинные коды, полученные после компиляции.

Программирование на этом этапе превратилось в чисто техническую процедуру. Несложную.

Уже перестал удивляться тому, что программы работают сразу после включения…

=======

Как начать использовать ДРАКОН?

Нужно потрудится. Нужно прочитать книгу «Язык Дракон».

Прочитать неспеша и вдумчиво.

Мне помогло, что я её читал в поезде, где не было отвлекающих факторов. Книга написана очень хорошо, просто, доходчиво, интересно. drakon-practic.ru/drakon.pdf

Если по прочтении возникло желание попробовать ( а я не сомневаюсь, что возникнет ) — тогда скачивайте ИС ДРАКОН, и начинайте. drakon-practic.ru/is_drakon.zip

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

Дело в том, что сегодня за пределами РосКосмоса почти нет инструментов, пригодных для практической работы с языком ДРАКОН. «ИС ДРАКОН» пишется на голом энтузиазме одним человеком, в свободное время.

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

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

Но конечно же, Вы начнёте с видеороликов! Ну что же. Имеющий уши — услышит, имеющий глаза — увидит.
drakon-practic.ru/is_drakon_part1.zip
drakon-practic.ru/is_drakon_part2.zip
drakon-practic.ru/is_drakon_part3.zip
drakon-practic.ru/is_drakon_part4.zip

Видеоролики уроков теперь размещены и на youtube:

http://www.youtube.com/watch?v=Ua9dUUON ... re=related
http://www.youtube.com/watch?v=zeIq_JQh ... re=related
http://www.youtube.com/watch?v=Sp6AMGzT ... ure=relmfu
http://www.youtube.com/watch?v=1PWDuPeJ ... re=related

Урок 1. Текст http://www.youtube.com/watch?v=1PWDuPeJ ... re=related
Урок 2. Текст http://drakon-practic.ru/is_drakon_part2.pdf


Последний раз редактировалось Владимир Паронджанов Понедельник, 13 Август, 2012 16:44, всего редактировалось 5 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Понедельник, 13 Август, 2012 16:08 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3782
Откуда: Москва
ШАГ ДОКАЗАТЕЛЬСТВА 2


ДВЕНАДЦАТЬ ТЕЗИСОВ СЕРГЕЯ ЕФАНОВА

Эти 12 тезисов сформулировал я на основании статьи Сергея Ефанова.
Я старался очень точно передать основной смысл статьи. Но я, конечно, мог допустить неточности.

Если кто-нибудь обнаружит неточности, просьба указать на них и подсказать, что именно надо исправить.
Я обязательно исправлю.

Цитата:
Тезис 1. Написание программы на языке ДРАКОН распадается на два этапа:
— разработка алгоритма,
— собственно программирование.

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

Тезис 3. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент. Потом легко вернуться к её продолжению.

Тезис 4. Когда весь алгоритм нарисован и «отлизан», переходим к программированию.

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

Тезис 6. Управляющие операторы программы писать не нужно, потому что они формируются автоматически при трансляции алгоритма.

Тезис 7. В чём теперь заключается программирование? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка.

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

Тезис 8. В чём сложность программирования? В сложных взаимосвязях между частями программы.

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

Тезис 10. Поэтому на этапе программирования икон об этих сложностях думать уже не надо. (Совсем. Вообще. Никак. Не надо, и всё тут!)

Тезис 11. Всё, что нужно — аккуратно запрограммировать ОДНУ икону. Только ОДНУ! Когда будем программировать другую — про предыдущую уже можно не вспоминать.

Тезис 12. Программирование на этом этапе превратилось в чисто техническую процедуру. Несложную.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Вторник, 14 Август, 2012 08:17 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов писал(а):
Владислав Жаринов писал(а):
... рёбра в ШМ сочиняемого смысла не имеют (ибо такова семантика - они представляют только подразумеваемое отношение "следовать за").

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

Это не так. Семантика совсем не такова, как Вы утверждаете.

Например, если в макроикону "развилка" в обе критические валентные точки ввести пустые (абстрактные) иконы действие, то полученный слепыш будет математически равносилен конструкции если-то-иначе (if-then-else).

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

Это подробно доказано в книге "Дружелюбные алгоритмы, понятные каждому" на стр. 159, 160. См. Рис. 93. Абстрактный алгоритм.
Пример не доказывает отрицание сказанного. И вот почему. Начнём с того, что утверждение "текста нет, а семантика есть" - слишком общее по отношению к моему. Я не утверждал, что "текста нет - и семантики нет"... :wink: Было сказано другое - что:
    1) неразмеченный граф представляет только часть семантики, которую Вы в "Как улучшить..." назвали "управляющей" (применительно к императивной компоненте знания, формализуемого в программе) - и которую более общо можно называть "структурной" (и так можно - и нужно - прикладывать и к неимперативным компонентам);
    2) что в этой частной семантике для императивной компоненты принято, что рёбра отражают только отношение порядка следования вершин по маршрутам.
Ясно, что для других компонент смысл отношения, представляемого рёбрами, м.б. другим.

Это можно показать на предмете нашего обсуждения. Если бы это было иначе (отражалось бы более одного рода отношений - скажем, следование и ещё что-то) - Вам пришлось бы ввести атрибуцию разных отношений на шампур-схеме. Как это делается на ИМ-графах (IDEF1X etc). Однако почему-то рёбра схем по исходному ШМ-определению никак не размечены... именно потому, что это не требуется - достаточно "по определению" знать единственный род...
Кстати, помнится, уже обсуждалось понятие оператора сочленения... это на ту же тему...

Далее. Как установить соответствие между таким графом и текстом? Для линейных участков/схем всё просто - в тексте тоже д.б. принят порядок следования. Он и принят - линейный участок есть последовательность строк/абзацев, которым в изоморфном графе соответствуют вершины (размеченные или нет - во втором случае абзац содержит только текстовое определение "слепыша" вершины). Ессно, при европейской организации текста абзацы эргономично упорядочить в колонку... что соответствует порядку следования и на импер-шампур-графах...
А для нелинейных? Там тоже всё решается без приписывания рёбрам какоого-то иного смысла. Семантика нелинейности кодируется: 1) фактом наличия более, чем одного входа и/или выхода вершины; 2) их относительным расположением (и задаваемой направленностью присоединяемых рёбер).
    Так, в предложенном Вами примере семантика if-then-else кодируется наличием у вершины-разветвителя Вопрос главного и побочного выходов. Но нужно помнить ещё о семантике end[then]-end[else]. Она кодируется уже наличием главного и побочного входов у вершины-соединителя.
Побочный выход/вход, как мы помним, оформляется также с участием горизонтального отвода вправо/слева и вершины-излома (напомним, что у Тышова изломы даже первоначально изображались)... Они имеют семантику "сменить уровень доминантности в нелинейном представлении/обойти подпоследовательность в линейной выкладке" (второму соответствует асм-джамп - который есть всегда и в составе машинной команды ветвления). Причём и тут необязательно приписывать горизонтальным рёбрам какой-то особой семантики - смысл нелинейного перехода естественно приписывается излому...
Аналогично и в случае циклов - только вершины-маршрутизаторы (разветвитель и соединитель) меняются местами относительно хода следования (направления "по шампуру").

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

Но. Это физически одномерная текстовая запись ("текстовое программирование"). А возможна также физически двумерная. В этом случае осям порядка отводятся разные колонки текста. А переходы по отводам кодируются явными текстовыми операторами.
В этом направлении следует ЛСП-таблица в неграфовом варианте ДАЛВЯЗ у Дмитрия_ВБ. Как можно видеть, мы с ним обсуждали возможность и полного соответствия расположения одинаковых сущностей в тексте и на схеме.

Таково положение вещей - семантика структуры действительно кодируется "слепышами", но вершины и рёбра передают разные её составляющие.
Заметим, что необязательно и предполагать ввод каких-то шампур-вершин на места точек ввода - эти точки логично наделяются смыслом "любого допустимого оператора/блока" (что в ТЯП-грамматиках обычно называется "statement").

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Вторник, 14 Август, 2012 09:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов писал(а):
Владислав Жаринов писал(а):
Как правильность "слепыша" доказывает правильность программы? А если он неверно задал выражения? параметры ввода/вывода? взаимодействия процессов? типизацию величин? их области видимости?
usr345 писал(а):
Никак!
Потому что на основе слепыша можно доказать лишь некоторые формальные свойства алгоритма, а не содержательные.
В обеих цитатах чувствуется недооценка слепыша.
Поэтому я хотел бы выступить
В ЗАЩИТУ СЛЕПЫША
СЛЕПЫШ — ЭТО ОЧЕНЬ ВАЖНО!

Возражение Владиславу Жаринову. Я никогда не утверждал, что "правильность слепыша доказывает правильность программы". Поэтому формулировка Жаринова некорректна.

Формулировка usr345 полностью корректна. Действительно "никак".

Вместе с тем я хотел привести несколько долнительных соображений.

...
Ну, о соображениях отдельно... Пока по поводу возражения.
Я и не утверждал, что Вы это утверждали... :wink: хотя бы имея в виду сказанное Вами о "ложке дёгтя"...
Ещё раз об этом:
Владислав Жаринов в viewtopic.php?p=73809#p73809 писал(а):
Дык вот об чём и речь... :wink:

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

Этот метод следует дополнить другими методами.
Какими?

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

Поскольку важной проблемой является СЛОЖНОСТЬ, то желательно уменьшить сложность с помощью когнитивно-эргономических методов.
- в таком виде не проясняет суть дела. Точнее будет:
Цитата:
Традиционно принятую текстовую форму изложения/представления/записи этого метода <Дейкстры[-Хоара etc]> следует дополнить другими формами.

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

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

Почему так (примерно)? Да потому, что ведь не развитие (усовершенствование, дополнение) методов доказательного программирования предлагается. Т.е. не собственно то, что Эдуард назвал "простые способы доказательства программ" и/или "культура доказательного программирования". А именно "способы проще разбираться в доказательствах программ" и/или "легче прививать себе (и другим) культуру доказательного программирования"...
...
- и что здесь сказано?

А то, что шампур-методом можно дополнить такую вещь у Дейкстры, как "видеоструктурную концепцию". Причём здесь "дополнить" слабо - можно говорить об усовершенствовании.

Тогда как метод доказательного программирования по Хоару и др. не дополняется (в естественном смысле этого слова - предполагающем влияние на суть дополняемого) шампур-методом - это принципиально иной процесс. ШМ не предлагает новой семантики и/или новых способов её анализа. Он даёт новый синтаксис, который:
    а) представляет часть (управляющую в императивной компоненте программы) всей семантики предмета доказательного программирования (программы) в иной форме - графовой;
    б) совместим с текстовым синтаксисом, традиционно принятым для записи этой части в доказательном программировании.
Что это даёт? Предполагается, что граф-запись императивно-управляющей части знания существенно облегчает участникам формализации восприятие смысла предмета в целом. Ну и формально-логических рассуждений относительно этого смысла как целого - что и есть суть доказательности.
    То, что эта часть выведена исчислением - само по себе не приближает нас к цели доказательства. Т.е. здесь не будет корректно говорить о проценте, который может дать доказательство отдельной части - это будет "поверка гармонии алгеброй" в пушкинском смысле... Что и хотели сказать Илья... и usr345...
Уже не говорю о том, что такой вывод можно проводить и для неграфового представления - как предполагается у Лаптева и Прохоренко...

Ну а что же может именно дополнить метод доказательного программирования как формальной верификации? А вот, в частности, те или иные методы проверки моделей и могут. При некоторых условиях даже могут заменить. Равно и какой-то метод из третьего направления - проверки эквивалентности. Это уже требует привлечения эквациональной логики (кажется, это так называется) - тут уже математикам судить...

А вот теперь та "ложка дёгтя", которая реально имеет место. Сначала эргономического. Всегда ли предположение справедливо? На самом деле - только при условии, что каждый участник доказательства в состоянии судить о его предмете настолько формально, насколько это нужно.
И вот тут снова вспоминаем, что у нас роолевая триада формализации. Что тогда? Аналитик должен сформулировать цель доказательства - опираясь на требования, предъявляемые к решению задачи предметником. Требования к программе оказываются частью задачных - и связаны с тем, что возлагается при решении на человека. Многое зависит от того, качественно ли предметник задал требования. И вот тут, если тип мышления предметника образный - то переход к графовой записи дествительно может помочь. А это, видимо, часто так. Тогда как аналитику - по сути, логику и математику - по своей роли важно, чтобы предметник максимально чётко объяснил, что требуется от решения заадачи - и если предметнику нужно для этого перевести структурную часть в граф, то это, конечно, д.б. обеспечено.
    Притом аналитик может иметь тип мышления текстовый, "символьный". И ему или всё равно, граф или нет - или даже сложнее, если он тяготеет к тексту. Так что уже здесь м.б. не лишним изоморфная текстовая запись...
Если аналитика не выделяем - то уже придётся для эффективной работы требовать от предметника и программиста примерно равных логико-математической культуры и типа мышления. Что, разумеется, практически далеко не всегда достижимо. Потому и Усов опять же говорил:
alexus в viewtopic.php?p=52774#p52774 писал(а):
Драконограф писал(а):
alexus писал(а):
Талантливый инженер не обязан быть хорошим токарем. И не факт, что талантливый токарь станет хорошим инженером. А создание систем - это инженерная прерогатива...

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

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

И снова - о некоторых аспектах возражения. Зачем нужно прописными жирными защищать "слепыш", когда он является неотъемлемой частью целостного описания? Кстати, из сказанного в предыдущем посте, думаю, очевидно, что эквивалент "слепыша" м.б. выделен и в тексте, изоморфном размеченному графу... :) Важность же граф-"слепыша" определяется лишь тем, насколько он облегчает восприятие и мышление по поводу размеченного графа конкретной аудитории сочинителей и читателей[-исполнителей].


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Вторник, 14 Август, 2012 11:49 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владимир Паронджанов писал(а):
...
Эти 12 тезисов сформулировал я на основании статьи Сергея Ефанова.
Я старался очень точно передать основной смысл статьи. Но я, конечно, мог допустить неточности.

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

Цитата:
Тезис 1. Написание программы на языке ДРАКОН распадается на два этапа:
— разработка алгоритма,
— собственно программирование.
Ну, это так не только для конкретного языка - следует, скажем, из определения формализации/моделирования как двуединоого процесса... Только первый этап не сводится к разработке только алгоритма - имея в виду снова целостность результата. Уже говорилось об этом:
Илья Ермаков в viewtopic.php?p=48436#p48436 писал(а):
... когда алгоритмизация выполнена, программировать тоже ещё рано. В программных системах большая часть решений сегодня ложится на архитектуру - структуру компонентнов, их связей, структуру информационного обмена и т.п.
И только потом - программирование.
Владислав Жаринов в viewtopic.php?p=72837#p72837 писал(а):
Вероятно, наиболее очевидный ответ на это "почему" - потому, что тем самым вполне реализуется сказанное здесь (курсив мой):
...
Однако речь именно об алгоритмике – о программировании, очищенном от всего случайного.
...
Здесь прежде всего мы видим, что алгоритмика понимается не как определение одного лишь потока управления процесса, описываемого программно строго, т.е. для исполнителя-"машины". Но как определение процесса решения в целом.
...
Почему у Сергея проще? Очевидный ответ - в силу простоты решаемых задач. Если смотреть глубже - дело также м.б. в том, что программы не рассматриваются как системы в смысле Усова.

Цитата:
...
Тезис 2. Алгоритм проектируют (рисуют) в графической форме, то есть составляют из графических элементов. Это гораздо легче. Не требуется такое сосредоточение, как обычно.
Первое. Легче - тому, кому естественнее/привычнее не с текстом работать. Надо думать, это случай Сергея.
Второе. Про то, какое сосредоточение требуется, уже говорил А. Донской - всё зависит от реализации транзакций редактирования. Можно понять, что конкретно Сергея Ты-решение устраивает. Если и не очень - то ему м.б. настолько легче формализовать на осноове маршрутного графа программы, что это перевешивает неудобства. У Kori, как можно видеть из этого поста, не перевешивает - он хотя и внедрил в практику, но фактически настаивает на доработке того, что "спустя полгода ещё вызывает активный протест" - и готов подключиться сам (это к проприетарному-то изделию :|)...

Цитата:
...
Тезис 3. Так как нарисованный алгоритм очень понятен — работу можно спокойно прервать в любой момент. Потом легко вернуться к её продолжению.

Тезис 4. Когда весь алгоритм нарисован и «отлизан», переходим к программированию.

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

Цитата:
...
Тезис 7. В чём теперь заключается программирование? В том, что для каждой иконы нужно написать код, который выполнит то, что написано на этой иконе. Как правило это 1 строчка.
Как раз достижение такого соответствия в общем случае и требует той самой детализации схемы.
Однако при простых и типовых проектах опять же можно дублировать и редактировать схемы, а также копипастить куски...
Только придётся, например, перебивать ручками имена величин, не такие же в новом проекте... с риском ошибиться... и схемная запись этого не упростит... особенно когда часть текста скрыта в примечааниях...

Цитата:
...
        На высоких уровнях иерархии проекта — это может быть вызов одной функции, или одного метода класса (заметим, что все функции и классы тоже нарисованы на ДРАКОНЕ). На нижнем уровне — это может быть изменение одного бита.
Заметим, что функции (в части потока управления) на ДРАКОНе действительно "нарисованы" (структура схемная)... а вот классы на ДРАКОНе прежде всего "написаны" (определены текстом в отдельных вершинах) - без представления их структуры так же ясно, как и структур управления...
Вот у Мейера классы в ЭС-реализации Эйффеля действительно нарисованы...

Цитата:
...
Тезис 8. В чём сложность программирования? В сложных взаимосвязях между частями программы.
"И этот тезис не вызывает у меня возражений" :) - и не только у меня:
Илья Ермаков в viewtopic.php?p=68824#p68824 писал(а):
1) Я думаю, что эффект от графового представления есть только тогда, когда оно делает явным что-то, что оказывается неявным в тексте. Граф управления для реактивных программ проясняет структуру поведения программы - все возможные маршруты, "грамматику событий". Для вычислительных программ в структуре поведения прояснять особо нечего. Зато там может быть полезным прояснять структуру зависимостей данных при вычислениях. Так что.... можно на эту тему поразмышлять.

2) Говорить "контроль за соблюдением структурности программы остается за исполнителем (программистом)" (утв. П. Приклонского - В.Ж.) я думаю, некорретктно. Очень мутное высказывание.

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

Цитата:
...
Тезис 9. Сложные взаимосвязи между частями программы полностью показаны в дракон-схеме алгоритма.

Тезис 10. Поэтому на этапе программирования икон об этих сложностях думать уже не надо. (Совсем. Вообще. Никак. Не надо, и всё тут!)
Опять же это потому, что объёмы/архитектура программ у Сергея позволяют управлять сложностью теми средствами, какие имелись в Ты-реализации (на момент написания его поста - в 2011 году - в настоящее время, как мы знаем, Г.Н. уже думает о новых возможностях).

Цитата:
...
Тезис 11. Всё, что нужно — аккуратно запрограммировать ОДНУ икону. Только ОДНУ! Когда будем программировать другую — про предыдущую уже можно не вспоминать.
А что значит - программировать только текущую икону? Это значит - что для каждой иконы требования к программной части (аспекту) уже продуманы. И тут вот какая штука. Если их не записали в проект (ну или на бумагу начерно, скажем) - то, получается, всё равно держат в голове (противоречие с Тезисом 5). А если записали - то, получается, дали столь исчерпывающую спецификацию (скажем, в алгоритмическом приложении), что осталось только переложить её на синтаксис прогязыка разработки...

Цитата:
...
Тезис 12. Программирование на этом этапе превратилось в чисто техническую процедуру. Несложную.
А здесь уже вопрос серьёзный возникает, если попытаться перенести на общий случай механически...

Потому что для простых программ с этим можно согласиться - сочинитель имеет целостную модель решения и реализует её.
А для сложных, где есть, как говорит Илья, "неочевидное из текста программы"?.. Тут придётся вспомнить кое-что из цитированного Владимиром Даниеловичем здесь:
В. Аджиев в http://www.osp.ru/os/1998/06/179592/ писал(а):
Рассмотрим еще один инцидент с Therac-25, которому суждено было стать последним. Он произошел в Yakima Valley Memorial Hospital (штат Вашингтон) в январе 1987 г. Пациенту было предписано сначало проделать два рентгеновских снимка с дозой в 4 и 3 рад соответственно, а затем произвести в фотонном режиме облучение в 86 рад. Все это и было выполнено, однако, как потом было установлено, пациент получил переоблучение фотонной дозой до 10000 рад. (Установлено было "потом", а не сразу - оператор, сделав снимки, забыл вынуть рентгеновскую пленку из-под пациента, из-за чего у него на консоли горели все те же 7 рад; однако, и правильная индикация уже выданной дозы была бы здесь как - в буквальном смысле слова - мертвому припарки).

Что же произошло? Выявленная в итоге расследования проблема выходит далеко за пределы частного случая еще одной программистской ошибки. В данном случае не сработала блокировка, реализованная программно позволившая прибору действовать (испускать поток фотонов) при ошибочной установке параметров. Ситуация возникла в момент, когда введенные параметры уже верифицированы подпрограммой Datent и монитор Treat в соответствии со значением переменной Tphase = 3 вызвал подпрограмму Set Up Test.

Во время установки и подгонки параметров подпрограмма Set Up Test вызывается несколько сотен раз - пока все параметры не будут установлены и верифицированы, о чем эта подпрограмма судит по нулевому значению разделяемой переменной F$mal. Если же значение ненулевое - цикл повторяется. F$mal, в свою очередь, устанавливается подпрограммой Chkcol (Check Collimator) из критической задачи Housekeeper, проверяющей, все ли с коллиматором нормально; а вызывает Chkcol другая подпрограмма задачи Housekeeper под названием Lmtchk (analog-to-digital limit checking), и вызов этот происходит, только если значение разделяемой переменной Class3 ненулевое. А ненулевым его делает как раз сама Set Up Test, которая (пока F$mal=0) каждый раз выполняет над Class3 операцию инкремента.

Эта переменная - однобайтовая, следовательно каждый 256-й проход заставляет ее сбрасываться в ноль. А ведь этот ноль - свидетельство, что все параметры, наконец, установлены. Если повезет, что именно в этот момент оператор нажмет клавишу "set" для запуска установки коллиматора в надлежащую позицию (а он это может сделать в любой момент, так как уверен, что система позволит коллиматору начать позиционироваться, только если все параметры заданы и верифицированы), то основываясь на случайно возникшем нулевом значении Class3, подпрограмма Lmtchk уже не станет вызывать Chkcol, а значит установить ненулевое значение F$mal будет некому. Иными словами, в ситуации, когда параметры не установлены должным образом (в данном конкретном случае "челюсти" коллиматора были еще раскрыты слишком широко), программная блокировка не сработала: Set Test Up установила Tphase = 2, что позволило монитору Treat прекратить цикл вызова Set Up Test, а инициализировать подпрограмму Set Up Done, по существу запускающую процесс излучения, который и потек бурным потоком, а не узеньким ручейком, как предполагалось.

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

Вот как раз случай того самого "неявного". Для анализа ситуации разработчику как минимум нужно было иметь "схему подключений по вызовам" для процедур - то, что у меня ДМ-схема. Но, с учётом сказанного далее:
В. Аджиев в http://www.osp.ru/os/1998/06/179592/ писал(а):
Можно долго перечислять проявившиеся в этом проекте проблемы, например, касающиеся принципов построения человеко-машинного интерфейса (выдаваемые оператору сообщения о критических с точки зрения безопасности ситуациях выглядели как рутинные; при этом не включалась блокировка, препятствующая дальнейшей деятельности оператора и т.д.). Все это является отражением того факта, что - как позволяет утверждать ставшая доступной информация о проектных и технологических особенностях разработки - квалификация коллектива разработчиков и организация их работы не позволяли реализовать столь сложный и тонкий проект с обеспечением безопасности функционирования, необходимой в данной предметной области.

Что же до системной "глобальной особенности", то к ней можно отнести принципиальную переусложненность построения мультизадачной управляющей системы. С чисто программистской точки зрения можно отметить, что для реализации тонкой синхронизации параллельных процессов был выбран механизм разделения переменных, требующий очень внимательной проработки (это именно та область, где необходимо выполнять формальное доказательство правильности алгоритма, благо соответствующие методы разработаны и могут считаться рутинными - для тех, кто ими владеет); получилось же так, что потенциально опасные в плане возникновения "race conditions" операции типа "set" и "test" не были сделаны "неделимыми" (indivisible), что и привело к наложению друг на друга их "критических секций" и - соответственно - к печальным последствиям.
- и этого недостаточно - нужна схема потоков работ... вроде той, что обсуждается сейчас в этой теме ...

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

Так что сформулированное для относительно простых случаев - нельзя переносить на общий. Иначе и получим то самое:
В. Аджиев в http://www.osp.ru/os/1998/06/179592/ писал(а):
...
Торжествует "good enough software", когда критерии качества не имеют столь высокого приоритета, как удобство пользования, простота освоения и дешевизна - и все это в сочетании с избыточной функциональностью, пожирающей компьютерные ресурсы, и отсутствием у производителя стимула выбрасывать на рынок действительно отлаженный продукт. Весьма взрывчатая смесь. В обозримом будущем мы можем оказаться свидетелями катастрофических ситуаций, в которые попадут пользователи массовых продуктов, и, похоже, что только это способно сдвинуть ситуацию с ее нынешнего печального положения.

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

Небезынтересно в этом контексте упомянуть, что та же Microsoft пытается проникнуть на рынок "ответственных" систем; во всяком случае, она не прочь получить подряд на поставку большой партии Window NT для федеральных организаций, чья работа завязана на "обеспечение национальной безопасности". А для этого надо сертифицировать эту ОС на соответсвие одному из базовых уровней безопасности компьютерных систем С2 (в соответствии с критериями, определенными в "Оранжевой книге" Агенства Национальной Безопасности США). Хотелось бы, конечно, надеяться, что осваивая сегмент рынка с принципиально иными требованиями к продуктам, производители массового ПО поднимут планку качества и в своей традиционной вотчине. А ну как окажется наоборот?
...
- о чём писал и Голубицкий:
Владислав Жаринов в viewtopic.php?p=71257#p71257 писал(а):
...
С. Голубицкий в http://www.computerra.ru/sgolub/567463/ писал(а):
...взятки далего не гладки и если фриварная карта GPS сбросит машину пользователя с обрыва, то при достаточном врении - если конечно получится после падения выжить! - пользователь вытрясет из фриварного гоблина всю душу ничуть не хуже, чем из гоблина коммерциализированного. Если уж не прикрывают даже ... дискламеры, которыми коммерческие гоблины любят обкладывать свои продукты, то что говорить о битниковской дурашливости "по баблу ко мне не в кассу".
Тут интересное "смешение жанров", думаю, произошло. Совершенно верно ставится вопрос о том, что полнота ответственности создателя чего-либо зависит не от того, чего он требует за свой труд, а от того, "критическая" ли предметка применения его создания. Однако тут же вместе с упоминанием о проблемах коммерческого ПО утверждается, что только бесплатное "... культивирует тотальную безответственность разработчика перед потребителем". А то "дисклаймеры" не для того изобретались, чтобы ни за что не отвечать... :wink: А есть ещё стратегия вначале открытой разработки с последующим закрыванием... примеры чему, думается, участники могут привести... :wink:
...
- и если не следовать инженерной дисциплине разработки - то нельзя рассчитывать избежать подобных последствий...

И ещё раз - дедуктивная верификация является лишь одним из возможных направлений. И она как раз требует жёсткой структурности - иначе практическое осуществление становится проблематичным. Об этом говорил Лавров в Гл. 2 своей книги. Так что тут пойдёт только вывод вложением из структурных атомов.
Тогда как проверка моделей по сути своей метод имитационный - и потому в принципе может допускать отступления от структурности. Здесь уже возможны и операции с лианами.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Четверг, 16 Август, 2012 11:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Некоторые дополнения и уточнения:
Владислав Жаринов в viewtopic.php?p=73874#p73874 писал(а):
...
    Так, в предложенном Вами примере семантика if-then-else кодируется наличием у вершины-разветвителя Вопрос главного и побочного выходов. Но нужно помнить ещё о семантике end[then]-end[else]. Она кодируется уже наличием главного и побочного входов у вершины-соединителя.
...
Точнее можно сказать, что семантика if кодируется графикой контура вершины.
С этим связано и такое обстоятельство. Как известно, для дракон-схем определена рокировка (хотя и за пределами исходных ШМ-тезисов). В изоморфном тексте это должно значить следующее (слева до, справа - после):

    * для физически "полуторамерного" синтаксиса:
    Код:
     IF <smth-cond>                        IF <smth-cond>
     THEN                                 [ELSE
       <smth-stmt>                           <smth-stmt>]
    [ELSE                                  THEN
       <smth-stmt>]                          <smth-stmt>
     END                                   END

    * для физически двумерного синтаксиса:
    Код:
    IF <smth-cond>                                       IF <smth-cond>
    THEN               [ELSE                            [ELSE               THEN
      <smth-stmt>         <smth-stmt>]                     <smth-stmt>]      <smth-stmt>
    END                                                  END
- не знаю, как будет отображаться отступ пробелами при разных разрешениях, но таблицы, увы, движок не поддерживает...
Приняты такие соглашения:
    * текст написан по-обероновски, что предполагает также составной оператор - т.е. сколь угодно сложный, лишь бы был "шампур-блоком исхтекста";
    * РБНФ неполная, без взятия манифестированных литерных цепочек в апострофы или другие спецзнаки;
    * оператор предполагается непустым - в случае пустого отстутствует ИНАЧЕ-ветвь целиком.

Суть же, думаю, понятна - придётся менять порядок ключевых слов.

Можно ли этого избежать? В принципе видятся такие способы:
    * при рокировке добавить инверсию условия развилки - т.е. "явное отрицание в предикате в угоду красивой теории :)(здесь - жёсткой структурности)" ((С) С. Губанов);
    * явно писать ответ "для главного" в предикате, как В.Д. делал в переложении шампур-схем на псевдокод - но это только "для человека", для машины всё равно придётся вводить инверсию в код, когда "нет по главному".
Но. Если в "полуторамерной" текстовой записи сложновато следить за порядком ключевых слов в одной колонке (пусть и с отступами) - то в двумерном тексте те же слова, напротив, становятся идентификаторами ветвей (а вот здесь отступ как раз поможет). И выделить конструкцию с "нет по главному" несложно. И без усложнения условия - добавлением инверсии ли, явного ли ответа.

Вот так подлинно двумерная физическая структурность текста помогает нам представить ёмко и эргономично логическую неодномерность содержания...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Четверг, 16 Август, 2012 12:09 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владислав Жаринов в viewtopic.php?p=73874#p73874 писал(а):
...
Кстати, помнится, уже обсуждалось понятие оператора сочленения... это на ту же тему...
Имеется в виду, что сочленение (в машине классической архитектуры представленное аппаратной/микропрограммной операцией взятия адреса следующей команды в командном цикле текущей) в импер-графе (не обязательно шампур-упорядоченном) представлено ребром от главного/единственного выхода командной вершины. В неупорядоченном графе (на блок-схеме, скажем) мы можем принять за главный, допустим, самый левый выход нелинейной вершины.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Среда, 29 Август, 2012 20:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владислав Жаринов в viewtopic.php?p=73791#p73791 писал(а):
...
Теперь о синтаксической правильности для части целого (в данном случае - импер-структурной). Реализовали мы построение схем для этой части - и что? Алексей ведь правильно о тексте вспомнил - потому что так можно понять, что это даёт. А вот что - гарантию, что структура ключевых слов из той самой "тщательно обосновываемой коллекции" (напр. Дейкстрой для структурного программирования) будет всегда корректной по определению текстового инфор-языка, взятого для реализации. Скажем, какого-то ТЯП... или стандарта псевдокода. Т.е. в тексте, изоморфном схеме (а он д.б. всегда) эти слова будут образовывать корректные конструкции (проходимые для синтразбора).
При этом остальное содержание целого (программы, инфор-инструкции) с т.зр. "слепышей" нужно считать ведь некими полями, параметризующими импер-структуру до целого. А вот чего там будет в этих полях - зависит уже от реализации других частей синтаксиса... И от того, что сформулирует сочинитель. А редактор, "заточенный" только на доказательность в импер-структурной части, эти остальные части никак не проверит... и корректность исполнения программы/инфор-инструкции как целого не установит...
Притом заметим - синтаксис этих остальных частей м.б. ох каким разным... в своих РБНФ-определениях я ведь дал возможные варианты только примерно.
...

Владислав Жаринов в viewtopic.php?p=73841#p73841 писал(а):
... - "обычный" анализатор работает с неограниченным вводом сочинителя. Потому он именно анализирует - и выявляет ошибки синтаксиса. Тогда как исчислитель заранее ограничивает ввод сочинителя - потому, как Вы и отметили, при безотказной работе исключает необходимость анализа.

Но. Здесь есть "кое-какие оговорочки и недоговорочки".
...
3. Всегда ли устраняется необходимость синт-анализа? Нет - это зависит от глубины и характера ограничений ввода. Так, при исчислении мы уверенно можем отказаться от анализа конкретной части синтаксиса, если:
    * мы исчисляем только вложением в заданном алфавите (вводом простых/составных атомов);
    * для всех атомов доказано их соответствие принятым ограничениям (прежде всего касается составных, конечно).
Как только оослабляем требования относительно этого - всё, в правильности схем мы просто "по определению" уверены быть не можем. И надо вводить проверочные правила и процедуры.
Яркий пример сему - всё те же веточные циклы...

4. Замечу - нигде не говорил про "текстовый или иной" синтаксис. Потому что непринципиально это... исчисление точно также м.б. реализоовано над текстовыми конструкциями (пример - редактор группы Лаптева и РВ-проект Прохоренко).

5. Ограничивая сочинителя при исчислении - мы требуем от него анализа при вводе. Дабы правильно строить описание.
...

Ну, вот и аналогичные вещи от создателей структурного редактора:
Дмитрий Грачёв в viewtopic.php?p=74182#p74182 писал(а):
Сергей Прохоренко писал(а):
Валерий Лаптев писал(а):
Ну и исследовательские работы по изучению возможных пользовательских операций вместо текстовых.

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

Текстовый редактор позволяет быстро, полностью нарушая синтаксис языка, преобразовать одну конструкцию в другую.
Очевидно, что за этим преобразованием лежит некий смысл ("у меня есть это, я хочу это, delete/cut/copy/paste/d&d/rename/insert - если повезло, то синтаксис потом снова правильный").
В семантическом редакторе нельзя нарушить синтаксис, а, следовательно, и сделать такое быстрое преобразование вручную.
Кроме того, в целях обучения отключены copy/paste и drag&drop.
Но каждое действие имеет смысл и автоматизировано.

Рассмотрим пример:
Код:
функция Ф(): целое
    # действия
    вернуть имя;
конец

И тут нам пришло в голову, что перед тем как возвращать имя, надо его проверить на какое-то условие.
Действия в текстовом редакторе:
1) удаляем ключевое слово "вернуть"
2) вместо него пишем "если", после "имя" пишем "то"
3) добавляем "конец" (закрываем блок согласно синтаксису).
4) дописываем после "имя" нужное нам условие
5) реализуем логику, которую хотели, и возвращаем, что-надо.

В семантическом редакторе ключевые слова удалять нельзя. Поэтому придется удалить оператор "вернуть" (а представьте, что там было не просто имя, а очень длинное выражение),
вставить "если" и там заново написать выражение из "вернуть".
Но то, что мы проделали, имеет смысл. Даже можно тут увидеть много смыслов:
1) возвращаемое выражение надо проверить
2) выражение надо проверить
3) выражение надо присвоить новой переменной, чтобы проверить
4) выражение надо присвоить новой переменной (это прямо рефакторинг "extract variable").
5) и т.д.

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

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

Чтобы определить то, какие проводки применить к конкретному документу, нужны эвристики... Собственно, знанием эвристик и умением их применять... и отличаются бухгалтера.
Что такое эвристики в контексте бухгалтерии. Это знание того, что допустимая проводка со счёта А на счёт Б может применяться в таких-то случаях (для таких-то документов/позиций документов). Другими словами, для каждой допустимой проводки задаются признаки её применения. С другой стороны, каждый документ, подлежащий проводке, должен обладать значениями, каких-то признаков. Накладывая значения на признаки допустимых проводок, получаем набор возможных проводок для данного документа или его позиции.
    В ручном режиме бухгалтер выбирает нужную проводку из предложенных возможных проводок;
    В автоматизированном режиме документу назначаются дополнительные признаки для выбора нужной проводки;
    В автоматическом варианте допустимые проводки сопровождаются системой приоритетов, на основе которых выбирается проводк(а/и) из предложенных возможных проводок.
...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 23 Сентябрь, 2012 22:45 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 342
Что бы я добавил по поводу синтаксической и семантической правильности программ.

Оставляя за скобками смежную и весьма важную (как правильно указывалось в цитированной литературе) проблему правильности спецификаций.

Итак: и редактор, вставляющий сразу блоки текста, и конструктор ГРАФИТа (а кстати и [url=http//grafkont.ru]ГРАФКОНТ[/url]а ))) ) позволяют избежать некоторых ошибок. Мы кстати это неоднократно подчеркивали перед заказчиком: "нельзя потерять "веточку" алгоритма". Но - увы! - и в этом Илья Ермаков совершенно прав - это избежание все же в основном синтаксических ошибок. Это лучше, чем ничего - безусловно.

Однако, у подобных методов (ГРАФИТ и ГРАФКОНТ) есть определенный потенциал и в плане доказательства семантической правильности - в синергии с формальными методами! У метода model checking, например, существует следующий принципиальный порок. Даже из названия видно, что проверяется модель программы, а не она сама. Соответственно, если модель неадекватна программе - результаты проверки сомнительны. А модель строит обычно человек (впрочем, были некоторые сообщения что Жераром Хольцманном и его лабораторией "за правильно ПО" в НАСА ведутся в том числе и работы по автоматическому извлечению модели из текста программы) - коему свойственно мы знаем что - ошибаться!

А в принципе ничего не мешает составить алгоритм и построить инструмент, который будет по ГРАФИТ-описанию (или ГРАФКОНТ-описанию) строить модель, проверяемую затем методом model checking, автоматически. Что не представляется непреодолимо сложным в силу регулярности и упорядоченности этих представлений. Это кстати одна из тем, которые я, возможно, дам своим магистрантам для исследований. По этому же описанию автоматически генерируется программа (это умеют делать и среды Митькина и Тышова). Если сами алгоритмы корректны, мы здесь можем гарантировать соответствие модели, проверяемой с помощью model checking, сгенерированной программе.

Вот бы еще они умели генерировать программы реального времени... С поддержкой икон реального времени...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2012 12:46 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Это интересно. В то же время проблема-то лежит также и в алгоритмической разрешимости и других вещах подобного рода, так ведь?..

Ведь проверку программы как модели самой себя было бы нетрудно реализовать, если снять основные ограничения метода. Что обсуждалось вкратце, скажем, здесь: viewtopic.php?p=54049#p54049 и здесь: viewtopic.php?p=50236#p50236. А всегда ли мы можем автоматически (по алгоритму, который можно передать машине) расставить границы атомарности исполнения системы процессов? И/или отказаться от неконечных типов данных?..

Вы при разработке ГРАФКОНТа определили некоторые условия формализации смысла предметки - отсюда и применимое при этих условиях исчисление УА РВ. Это - важное достижение. И вот тут надо исследовать - а легко ли это обобщить на произвольные предметки и постановки задач? И возможно ли вообще?..

Потому и озвученная Вами цель весьма значима. И даже если она недостижима с позиций сегодняшнего знания (в первую очередь математического) - это не означает, что нельзя найти каких-то путей расширения возможностей автоматической верификации (и тестирования - помнится, в ГРАФКОНТ-системе это тоже есть).

Ну а генерить исходные тексты - это само собой. Кстати, тут снова можно учесть позицию такого рода, как у Петра Алмазова - что человек должен иметь дело с математической формализацией, ибо информатическая неудбна для его восприятия/мышления что в тексте, что в графе.
И здесь регулярность, во-первых, достигается не обязательно полноценной граф-схемой. Во-вторых, кроме маршрутов алгоритма, имеют значение также структуры данных и "связывание" того и другого в подразумеваемом исполнителе.
И также важно - что конструкции, принятые как атомы исчисления, сами д.б. структурными, чтобы можно было говорить о структурности результатов вывода. Т.е. языки, произвольные в смысле определения здесь: http://forum.easyelectronics.ru/viewtop ... 47#p204947, в общем случае могут препятствовать достижению обсуждаемой цели...

Кстати, во многих отношениях наиболее подходящей реализацией всё более представляется семантический редактор... Тем более, что среда должна иметь потенциал прежде всего для создания таких спецификаций, по которым можно хотя бы полуавтоматически генерить программы... допустим, как говорилось здесь: viewtopic.php?p=74873#p74873. Вот ему бы возможности программирования реального времени - как либы и их связи с понятиями спецификаций систем процессов, очевидно...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2012 17:06 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 213
TAU писал(а):
...
А в принципе ничего не мешает составить алгоритм и построить инструмент, который будет по ГРАФИТ-описанию (или ГРАФКОНТ-описанию) строить модель, проверяемую затем методом model checking, автоматически. Что не представляется непреодолимо сложным в силу регулярности и упорядоченности этих представлений. Это кстати одна из тем, которые я, возможно, дам своим магистрантам для исследований. По этому же описанию автоматически генерируется программа (это умеют делать и среды Митькина и Тышова). Если сами алгоритмы корректны, мы здесь можем гарантировать соответствие модели, проверяемой с помощью model checking, сгенерированной программе.
...

Имхо, такие исследования сейчас "в самом соку". Яркий пример: C-компилятор CompCert, который использует известный доказатель теорем Coq (разработанный в тех же лабораторных стенах) для автоматической верификации генерируемого кода. Но, компилятор даёт гарантии только того, что конечный код точно соответствует семантике исходного кода (ANSI C, но со своей спецификой) после всех оптимизаций и с учётом особенностей конкретной архитектуры (PowerPC, ARM, x86). Т.е. логику прикладного алгоритма он не верифицирует, фактически, выполняется проверка на соответствие вычислительной модели целевой платформы. Для проверки своих прикладных моделей необходимо самостоятельно задействовать инструментарий, тот же Cog.

Или другой подход решения задачи - в самом коде (или исходном ГРАФИТ-представлении, или где-то рядом во "ФЛОКС"-описании) приводить доказательства своей прикладной модели, как в популярном ATS, где верификация основана на системе типов.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Вторник, 25 Сентябрь, 2012 07:07 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 01 Ноябрь, 2014 14:19 

Зарегистрирован: Суббота, 06 Июнь, 2009 07:52
Сообщения: 29
О, ещё одни феминистки:
Цитата:
В контексте данной статьи интересно мнение главного редактора журнала "Automated Software Engineering" Башара Нузейбеха (Bashar Nuseibeh) [5], который, дав обзор разных точек зрения на причины аварии и придя к выводу, что "все правы", связал все-таки катастрофу Ariane 5 с более общими проблемами разработки программных систем.

Теперь я понимаю, почему на данном форуме нет отдельной темы Юмор :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 22 Ноябрь, 2014 10:57 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3782
Откуда: Москва
В сообщении viewtopic.php?p=73787#p73787 Степан Митькин писал(а):
Разница между идеальным ДРАКОН-конструктором и компилятором обычного текстового языка вот в чём:

— В случае с текстовой программой человек может написать всё, что угодно. А синтаксический анализатор потом проверит текст и укажет на ошибки.

— В случае с конструктором человек не может нарисовать неправильную схему. Конструктор не даст.
Поэтому и проверять потом ничего не надо.

Если я правильно понял концепцию ДРАКОН-конструктора, она такова:

1) В каждый момент времени на листе находится правильная ДРАКОН схема.

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

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

Но это не все. Далее Степан Митькин писал(а):
Это хорошая гарантия. Но у неё есть и минусы.
Например:

Пусть есть какая-то ДРАКОН-схема А. Я смотрю на неё, и она мне не нравится. Её нужно изменить так, чтобы получилась схема Б. Что делать?

1) В идеальном редакторе я должен придумать последовательность шагов, которые приведут схему из точки А в точку Б. Это тяжёлый умственный труд.

2) В графическом, свободном редакторе думать не надо. Можно просто передвинуть иконы туда, куда нужно.

Мне не нравится идеальный конструктор, потому что я люблю рисовать.
А вот с этим я не согласен. Объясню почему.

:idea: 1. Проблема программных ошибок (проблема корректности программ) — фундаментальная проблема. Лучшие умы бились и до сих пор продолжают биться над ней. Они добились немалых успехов, но в полной мере проблема не решена. Она по-прежнему продолжает оставаться актуальной. Чрезвычайно актуальной.
Особенно в критических приложениях, когда речь идет о жизни людей или о больших материальных и финансовых потерях. Например, при неудачном запуске ракеты, причиной которого стала не выявленная ошибка в программе.

:idea: 2. Создание безошибочных программ (не мелких учебных примеров, а больших и ответственных программных комплексов) — исключительно сложная задача. Любое продвижение вперед в этом направлении дается с большим трудом. Создание гарантоспособных программных комплексов обходится дорого. Очень дорого.

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

:idea: 4. Желание решить проблему другим способом — кавалерийским наскоком (Мне не нравится идеальный конструктор, потому что я люблю рисовать) здесь неуместно.
Почему неуместно? Потому что оно равносильно отказу от требования безошибочности. Я убежден: отказ (пусть даже временный) от требования работать без ошибок является недопустимым.

:idea: 5. У части специалистов уже сложилось мнение, что ДРАКОН — безошибочный язык. Такие высказывания можно встретить в интернете. Это, разумеется, не значит, что ДРАКОН позволяет на 100% исключить ошибки. Однако ДРАКОН создан именно для этой цели. И он содействует ее достижению.

:idea: 6. Язык ДРАКОН, как новая идея, тесно связан с идеей безошибочности. Ни в коем случае и ни при каких обстоятельствах нельзя разрушать эту связь.

Я постарался подчеркнуть следующую мысль. Я полностью согласен с первым тезисом уважаемого Степана Борисовича Митькина, но я решительно не согласен со вторым тезисом.


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

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


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

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


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

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