DRAKON.SU

Текущее время: Суббота, 24 Июль, 2021 13:58

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




Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
СообщениеДобавлено: Четверг, 27 Октябрь, 2016 21:47 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5202
Откуда: Москва
Глава 36. ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ И ПРОГРАММАМ (ШАМПУР-МЕТОД) Удобнее читать здесь

§1. ВВЕДЕНИЕ

Напомним, что книга посвящена алгоритмам. Вопросы программирования в ней не рассматриваются. Данная глава является исключением. Глава посвящена исследованию и развитию фундаментального понятия «структурное программирование». Мы будем использовать это понятие в первую очередь применительно к алгоритмам. И лишь иногда – к программам.

§2. ТЕРМИНОЛОГИЯ

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

Наряду с термином «визуальный структурный подход к алгоритмам и программам» мы будем для краткости (в качестве синонима) использовать термин «шампур-метод».
Можно сказать, что данная книга – это подробное описание шампур-метода.

§3. ДВА СТРУКТУРНЫХ ПОДХОДА

Как показано в работе [1], следует различать два структурных подхода:
• одномерный (текстовый) подход;
• двумерный (визуальный) подход.

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

§4. ПОСТАНОВКА ПРОБЛЕМЫ

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

• Традиционный (текстовый) структурный подход является, по-видимому, наилучшим решением соответствующей задачи для традиционного (текстового) структурного программирования

• Для визуального подхода подобное утверждение неправомерно. Можно, конечно, тупо перенести правила текстового структурного программирования на визуальный случай. Но это не будет хорошим решением.

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

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

§5. СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ

Понятие «структурное программирование» во многом связано с именем Эдсгера Дейкстры. Данное понятие охватывает две темы:
• доказательство правильности программ (program correctness proof);
• метод структуризации программ.

Ниже рассмотрены обе темы. Первая тема изложена в §§6 и 7. Вторая описана, начиная с §8.

§6. СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ КАК ДОКАЗАТЕЛЬСТВО ПРАВИЛЬНОСТИ ПРОГРАММ

В середине ХХ века появились компьютеры и компьютерные программы. В ту раннюю эпоху теория программирования еще не существовала.

Разработка программ велась методом проб и ошибок. И выглядела примерно так: «написать код программы – проверить код на компьютере (протестировать) – найти ошибки – исправить код – снова протестировать – снова найти ошибки – снова исправить и т. д.».

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

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

В «Заметках по структурному программированию» Дейкстра пишет:
Цитата:
«… необходимость продуманной структурной организации прог раммы представляется как следствие требования о доказуемости правильности программы» [2, с. 52].

В толковом словаре читаем:
Цитата:
«Основным назначением общего метода структурного программирования, разработанного в значительной степени Э. Дейкстрой, является обеспечение доказательства правильности программы… (program correctness proof)» [3, с. 463].

Таким образом, согласно Дейкстре, структурное программирование подразумевает доказательство правильности программ.

§7. ЧЕМ РАЗЛИЧАЮТСЯ НАШ ПОДХОД К ДОКАЗАТЕЛЬСТВУ ПРАВИЛЬНОСТИ И ПОДХОД ДЕЙКСТРЫ?

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

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

В чем отличие от подхода Дейкстры? Во-первых, мы говорим не о полном, а о частичном доказательстве правильности.

Во-вторых, Дейкстра предлагает программистам доказывать правильность программ не автоматически, а вручную с помощью разработанных им математических методов (преобразование предикатов и др.) [4].

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

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

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

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

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

§8. СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ КАК МЕТОД СТРУКТУРИЗАЦИИ ПРОГРАММ

Основные положения метода общеизвестны:
• Алгоритм (программа) строится из частей (базовых управляющих структур).
• Каждая базовая управляющая структура имеет один вход и один выход.

• Для передачи управления используются три базовые управляющие структуры: последовательность, выбор, цикл.

§9. РАЗВИТИЕ КОНЦЕПЦИИ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ

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

Почему возникла необходимость в таком развитии, то есть в существенной доработке классических идей?

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

• Создатели структурного программирования недооценили потенциальные возможности блок-схем (flow-charts). И не сумели дать блок-схемам строгое математическое обоснование, пригодное для трансляции блок-схем в объектные коды.

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

§10. ПЕРЕХОД ОТ ОДНОМЕРНОГО ТЕКСТА К ДВУМЕРНОЙ ГРАФИКЕ РОЖДАЕТ НОВЫЕ ВОЗМОЖНОСТИ

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

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

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

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

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

Задача состоит в том, чтобы значительно уменьшить число запретов и ограничений. То есть предоставить алгоритмистам и программистам дополнительную свободу действий.

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

Каким образом? Благодаря замене одномерного (текстового) структурного подхода на двумерный (визуальный) структурный подход. Последний, разумеется, также является системой правил. Но в «двумерной» системе правил значительная часть запретов снимается. То, что раньше было нельзя, теперь можно.

Многие запреты (неизбежные при текстовом структурном программировании) «перегибают палку». Они противоречат здравому смыслу и затрудняют понимание алгоритмов и программ.

§11. УПРАВЛЯЮЩИЕ СТРУКТУРЫ, КОТОРЫЕ ЗАПРЕЩЕНЫ В ТЕКСТОВОМ СТРУКТУРНОМ ПРОГРАММИРОВАНИИ И РАЗРЕШЕНЫ В ВИЗУАЛЬНОМ

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

В классическом структурном программировании управляющая структура на рис. 260 и многие другие запрещены. Они считаются неструктурными. Но такие алгоритмы часто встречаются на практике.

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

Недопустимо запрещать правильный процесс мышления. Его надо разрешить. И ДРАКОН разрешает.

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

§12. НОВАЯ ФИЛОСОФИЯ ПРОЦЕДУРНОГО ПРОГРАММИРОВАНИЯ

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

Смена понятийного аппарата – это переход к новому пониманию глубинной сущности вещей. То есть к новому мировоззрению в области императивного, процедурного программирования.

ДРАКОН – это не просто новый язык (новое семейство языков). Это новый взгляд на процедурное программирование. Если угодно – новое мировоззрение.

§13. ЗАМЕНИТЕЛИ GOTO

Согласно классической теореме Бома и Джакопини, всякий реальный алгоритм (программа) может быть построена из функциональных блоков (операций) и двух конструкций: цикла и дихотомического выбора (развилки) [5]. Эдсгер Дейкстра обогатил и усилил эту идею, предложив отказаться от оператора безусловного перехода goto и ограничиться тремя управляющими конструкциями: последовательность, выбор, цикл [2, с. 25–28].

Дональд Кнут подверг критике тезис Дейкстры о полном исключении goto, продемонстрировав случаи, где goto полезен [6]. В итоге возникла плодотворная дискуссия, в ходе которой выявились четыре варианта мнений (табл. 1).
Таблица 1

Вариант 1 описывает ортодоксальную позицию Дейкстры, согласно которой оператор goto имеет «гибельные последствия» и поэтому «должен быть исключен из всех языков программирования высокого уровня». Исходя из этого, были разработаны языки без goto: Джава, Питон, Tcl, Модула-2, Оберон и др.

Вариант 2 отражает мнение ранних критиков Дейкстры, позиция которых выражается словами:
Цитата:
«использование оператора goto может оказаться уместным в лучших структурированных программах» [7];

Цитата:
«всегда были примеры программ, которые не содержат goto и аккуратно расположены лесенкой в соответствии с уровнем вложенности операторов, но совершенно непонятны, и были другие программы, содержащие goto, и все же совершенно понятные» [8, с. 134].

Цитата:
Нужно «избегать использования goto всюду, где это возможно, но не ценой ясности программы» [8, c. 137–138].

Как известно, полемика по goto «растревожила осиное гнездо» и всколыхнула «весь программистский мир». Варианты 1 и 2 выражают крайние позиции участников дискуссии, между которыми, как казалось вначале, компромисс невозможен.

Однако ситуация изменилась с изобретением и широким распространением заменителей goto, примерами которых являются:
• в языке Си – операторы break, continue, return и функция еxit ( );
• в языке Модула-2 – операторы RETURN, EXIT, процедура HALT и т. д.

Заменители – особый инструмент, который существенно отличается как от трех структурных управляющих конструкций, так и от goto. Они обладают двумя важными преимуществами по сравнению с goto:

1) не требуя меток, заменители исключают ошибки, вызванные путаницей с метками;

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

Вариант 3 описывает языки Си, Дельфи, Ада, и др., где имеются заменители и на всякий случай сохраняется goto.

Вариант 4 соответствует языкам Модула-2, Джава, где также есть заменители, однако goto исключен. Следует подчеркнуть, что при наличии заменителей сфера применения goto резко сужается. Так что удельный вес ошибок, связанных с его применением, заметно уменьшается. Поэтому вопрос об исключении goto, по-видимому, теряет прежнюю остроту.

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

§14. ЧЕТЫРЕ ПРИНЦИПА СТРУКТУРИЗАЦИИ БЛОК-СХЕМ, ПРЕДЛОЖЕННЫЕ Э. ДЕЙКСТРОЙ

Попытаемся еще раз заглянуть в темные переулки истории и внимательно перечитаем классический труд Дейкстры «Заметки по структурному программированию» [2].

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

Непосредственный анализ первоисточника со всей очевидностью подтверждает простую мысль. Дейкстрианская «структурная революция» началась с того, что Дейкстра, использовав блок-схемы как инструмент анализа структуры программ, предложил наряду с другими важными идеями четыре принципа структуризации блок-схем! К сожалению, в дальнейшем указанные принципы были преданы забвению или получили иное, по нашему мнению, слишком вольное толкование.

Эти принципы таковы.

1. Принцип ограничения топологии блок-схем. Структурный подход
должен приводить «к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись ...тремя типами операторов управления, мы следуем тем самым некоей последовательностной дисциплине» [2, с. 28].

2. Принцип вертикальной ориентации входов и выходов блок-схемы. Имея в виду шесть типовых блок-схем (if-do, if-then-else, case-of, while-do, repеat-until, а также «действие»), Дейкстра пишет:
Цитата:
«Общее свойство всех этих блок-схем состоит в том, что у каждой из них один вход вверху и один выход внизу» [2, с. 27].

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

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

Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов, они однозначно вытекают из имеющихся в его работе иллюстраций [2, с. 25–28]. Чтобы у читателя не осталось сомнений, мы приводим точные копии подлинных рисунков Дейкстры (рис. 261, средняя и левая графа).

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

§15. ПОЧЕМУ НАУЧНОЕ СООБЩЕСТВО НЕ ПРИНЯЛО ВИДЕОСТРУКТУРНУЮ КОНЦЕПЦИЮ Э. ДЕЙКСТРЫ?

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

Неприятность в том, что изложенные выше рекомендации Дейкстры не были приняты во внимание разработчиками национальных и международных стандартов на блок-схемы (ГОСТ 19.701–90, стандарт ISO 5807–85 и т. д.). В итоге метод стандартизации, единственный метод, который мог бы улучшить массовую практику вычерчивания блок-схем, не был использован.

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

Здесь уместно сделать отступление. Американский историк и философ Томас Кун в книге «Структура научных революций» говорит о том, что в истории науки время от времени появляются особые периоды, когда выдвигаются «несоизмеримые» с прежними взглядами научные идеи. Последние он называет парадигмами [9].

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

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

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

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

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

Начнем по порядку. Формальная блок-схема – это двумерный чертеж. Следовательно, она является инструментом визуального программирования.

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

Однако в 1972 году, в момент публикации работы Дейкстры [2], визуальное программирование как термин, понятие и концепция фактически еще не существовало. Поэтому, что вполне естественно, суть концепции Дейкстры была воспринята сквозь призму господствовавших тогда догматов текстового программирования со всеми вытекающими последствиями.

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

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

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

§16. ПАРАДОКС СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ

Мы подошли к наиболее интригующему пункту в истории структурного подхода. Чтобы выявить главное звено проблемы, зададим вопрос. Являются ли блок-схемы и структурное программирование взаимно исключающими, несовместимыми решениями? В литературе по этому вопросу наблюдается редкое единодушие. Да, они несовместимы. Вот несколько отзывов. По мнению многих авторов, блок-схемы:
Цитата:
«не согласуются со структурным программированием, поскольку в значительной степени ориентированы на использование goto» [8, с. 150].

Цитата:
Они «затемняют особенности программ, созданных по правилам структурного программирования» [3, с. 193].

Цитата:
«C появлением языков, отвечающих принципам структурного программирования, ... блок-схемы стали отмирать» [10].

Парадокс в том, что приведенные высказывания основываются на недоразумении. Чтобы логический дефект стал очевидным, сопоставим две цитаты по методу «очной ставки» (табл. 2).

Сравнивая мнение современных авторов с позицией Дейкстры, нетрудно убедиться, что описываемый критиками изъян действительно имеет место.
Но! Лишь в том случае, если правила вычерчивания блок-схем игнорируют предложенный Дейкстрой принцип ограничения топологии блок-схем. И наоборот, соблюдение указанного принципа сразу же ликвидирует недостаток.
Таблица 2

Цитата:
«Основной недостаток блок-схем заключается в том, что они не приучают к аккуратности при разработке алгоритма. Ромб можно поставить в любом месте блок-схемы, а от него повести выходы на какие угодно участки. Так можно быстро превратить программу в запутанный лабиринт, разобраться в котором через некоторое время не сможет даже сам ее автор» [10].

Цитата:
Структуризация блок-схем с неизбежностью приводит «к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись... тремя операторами управления, мы следуем тем самым некоей последовательностной дисциплине» [2, с. 28]


§17. ПЛОХИЕ БЛОК-СХЕМЫ ИЛИ ПЛОХИЕ СТАНДАРТЫ?
Проведенный анализ позволяет сделать несколько замечаний.

• Обвинения, выдвигаемые противниками блок-схем, неправомерны, потому что ставят проблему с ног на голову. Дело не в том, что блок-схемы по своей природе противоречат принципам структуризации. А в том, что при разработке стандартов на блок-схемы указанные принципы не были учтены. На них просто не обратили внимания, поскольку в ту пору – именно в силу парадигмальной слепоты – считалось, что на практике структурный подход следует применять к текстам программ, а отнюдь не к блок-схемам.

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

• Видеоструктурная концепция Дейкстры – это фундаментальная идея, высказанная более тридцати лет назад и оказавшаяся невостребованной, поскольку она значительно опередила свое время.

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

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

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

§18. ВИЗУАЛЬНОЕ И ТЕКСТОВОЕ СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ

Можно предложить ряд правил, устанавливающих соответствие между понятиями двумерного (визуального) и одномерного (текстового) структурного подхода.

1. Макроикона «развилка» (рис. 242), в которую произведен ввод функционального атома в левую или обе критические точки, эк-вивалентна конструкциям if-then и if-then-else соответственно [11, с. 120, 121]. См. также две верхние графы на рис. 261.

2. Макроикона «обычный цикл» (рис. 242), в которую произведен ввод функционального атома в одну или обе критические точки, эквивалентна конструкциям do-until, while-do, do-while-do соответственно [11, с. 120, 121]. См. также две нижние графы на рис. 261.

3. Непустая макроикона «переключатель» (рис. 242), в которую введено нужное число икон «вариант» с помощью операции «добавление варианта», эквивалентна конструкции case [2, с. 27]. См. также рис. 261.

4. Непустая макроикона «цикл ДЛЯ» (рис. 242) эквивалентна циклу for языка Си.

5. Непустая макроикона «переключающий цикл» (рис. 242), в которую введено нужное число икон «вариант», эквивалентна циклу с вложенным оператором саse, используемым, например, при построении рекурсивных структурированных программ по методу Ашкрофта-Манны [11, с. 141, 142].

6. Шампур-блок – видеоструктурный эквивалент понятия «простая программа» [11, с. 102].

7. Атом – общее понятие для основных составляющих блоков, необходимых для построения программы согласно структурной теореме Бома и Джакопини [5]. Оно охватывает также все элементарные конструкции структурного подхода, кроме последовательности [11, с. 119–121]. (Последняя в визуальном структурном подходе считается неэлементарной структурой).

8. Операция «ввод атома» позволяет смоделировать две операции:
• построить последовательность из двух и более атомов;
• методом заполнения критических точек осуществить многократное вложение составных операторов друг в друга.

Благодаря этому единственный функциональный блок «постепенно раскрывается в сложную структуру основных элементов».

§19. СТРУКТУРНЫЕ, ЛИАННЫЕ И АДРЕСНЫЕ БЛОКИ

Введем понятие «базовые операции» для обозначения операций «ввод атома», «добавление варианта» и «боковое присоединение» (см. главу 33). Применяя к заготовке-примитив базовые операции любое число раз, мы всегда получим структурную дракон-схему в традиционном смысле слова (рис. 262).
Введем три понятия.


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

Чтобы смоделировать полезные функции оператора goto, в шампур-методе предусмотрены операции «пересадка лианы» и «заземление лианы».

§20. СИЛУЭТ КАК КОНЕЧНЫЙ АВТОМАТ И ДИАГРАММА СОСТОЯНИЙ

Силуэт на рис. 265 можно интерпретировать как детерминированный конечный автомат (рис. 266). Каждую ветку при желании можно характеризовать как состояние автомата. Переход с ветки на ветку означает переход из одного состояния в другое.

Силуэт можно также рассматривать как диаграмму состояний (state machine diagram).

§21. АНАЛОГИ ДРАКОН-СХЕМ

Аналогом дракон-схем являются диаграммы поведения (behaviour diagrams) языка UML, в частности, диаграмма деятельности (activity diagram), диаграмма состояний (UML state machine diagram) и некоторые
диаграммы взаимодействия (interaction diagrams), например, диаграмма синхронизации (timing diagram).

Другая группа аналогов дракон-схем охватывает блок-схемы алгоритмов по ГОСТ 19.701–90, диаграмму Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.

§22. ОПЕРАЦИИ С ЛИАНОЙ И ОПЕРАТОР GOTO

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

С эргономической точки зрения, действия с лианой на порядок эффективнее и удобнее, чем goto и заменители. Кроме того, они весьма эффективно корректируют недостатки классического (текстового) структурного программирования.

Приведем пример. В главе 7 мы рассмотрели эргономические преимущества схемы на рис. 62 по сравнению с рис. 61. Показано, что улучшение эргономичности достигнуто за счет использования равносильных преобразований алгоритмов: вертикального и горизонтального объединения. При этом за кадром осталась важная проблема – проблема синтаксиса.

Как построить указанные схемы? Теперь мы имеем возможность осветить этот вопрос. Схема на рис. 61 представляет собой структурный блок, полученный с помощью операции «ввод атома». В отличие от нее схема на рис. 62 – это лианный блок, построенный методом пересадки лианы.

Уместно вспомнить предостережение Гленфорда Майерса:
Цитата:
«Правила структурного программирования часто предписывают повторять одинаковые фрагменты программы в разных участках модуля, чтобы избавиться от употребления операторов goto. В этом случае лекарство хуже болезни. Дублирование резко увеличивает возможность внесения ошибок при изменении модуля в будущем» [8, с. 138].

Как видно на рис. 53, 56, 62 пересадка лианы позволяет элегантно и без потерь решить эту непростую проблему, одновременно улучшая наглядность и понятность алгоритма, обеспечивая более эффективное топологическое упорядочивание маршрутов.

Пересадка лианы узаконивает лишь некоторые, отнюдь не любые передачи управления, поскольку определение операции «пересадка лианы» (см. главу 33, тезис 28) содержит ряд ограничений. Запрет на образование нового цикла вызван тем, что переход на оператор, расположенный выше (раньше) в тексте программы, считается
«наихудшим применением оператора goto [8, с. 135]. Указанный запрет вводится, чтобы выполнить требование: использовать goto только для передачи управления вперед по программе, которое считается более приемлемым.

Запрет на образование второго входа в цикл соответствует требованию структурного программирования, согласно которому цикл, как и любая простая программа, должен иметь не более одного входа.

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

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

В визуальном структурном подходе аналогом goto и заменителей служат формальные операции «пересадка лианы» и «заземление лианы».

§23. ПОЧЕМУ САМОЛЕТ НЕ МАШЕТ КРЫЛЬЯМИ?

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

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

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

Это значит, что столь тщательно обоснованная Дейкстрой и его коллегами коллекция ключевых слов структурного программирования (if, then, else, case, of, while, do, repeat, until, begin, end [2, с. 22, 26, 27]) при переходе к визуальному подходу становится ненужной. Для программиста она просто перестает существовать!

В равной степени становятся лишними и отмирают и другие ключевые слова, используемые оппонентами Дейкстры в различных вариантах расширения структурного подхода: goto, continue, break, exit и т. д.

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

Предвижу возражения: хотя названные ключевые слова действительно исчезают, однако выражаемые ими понятия сохраняют силу и для визуального случая. Например, два визуальных алгоритма на рис. 60, 62 можно построить с помощью понятий if-then-else и goto.

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

Что касается собственно визуальных программ, то они, будучи «выполнимой графикой», строятся из «выполняемых» икон и «выполняемых» соединительных линий. Подчеркнем еще раз: при построении алгоритма (программы) с помощью дракон-конструктора пользователь не применяет понятия if-then-else и goto, ибо в этом нет никакой необходимости.

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

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

Очевидно, что использование понятий, выражаемых ключевыми словами текстового структурного программирования, не является самоцелью. Оно служит для того, чтобы «делать наши программы разумными, понятными и разумно управляемыми» [4, с. 272]. Указанные понятия решают эту задачу не во всех случаях, а только в рамках текстового программирования.

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

Поэтому высказываемое иногда критическое замечание: «недостаток шампур-метода в том, что он не удовлетворяет требованиям структурного программирования» является логически неправомерным. Нельзя упрекать самолет за то, что он не машет крыльями.

§24. ВЫВОДЫ

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

2. Правила двумерного структурного программирования существенно отличаются от традиционного одномерного (текстового) структурного программирования.

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

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

5. С появлением компьютерной графики ситуация изменилась. Появилась возможность заменить текстовые управляющие структуры на управляющую графику, то есть использовать двумерное структурное программирование.

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

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

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

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

10. Недопустимо запрещать правильный процесс мышления. Его надо разрешить. Шампур-метод и язык ДРАКОН устраняют этот недостаток.

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

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

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

14. ДРАКОН – это не просто новый язык (новое семейство языков). Это новый взгляд на процедурное программирование. Если угодно – новое мировоззрение.

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

16. Язык ДРАКОН позволил эффективно решить эту задачу.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 01:44 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Владимир Паронджанов писал(а):
• Для визуального подхода подобное утверждение неправомерно. Можно, конечно, тупо перенести правила текстового структурного программирования на визуальный случай. Но это не будет хорошим решением.

Почему это не будет хорошим решением?

Владимир Паронджанов писал(а):
В середине ХХ века появились компьютеры и компьютерные программы. В ту раннюю эпоху теория программирования еще не существовала.

Разработка программ велась методом проб и ошибок. И выглядела примерно так: «написать код программы – проверить код на компьютере (протестировать) – найти ошибки – исправить код – снова протестировать – снова найти ошибки – снова исправить и т. д.».

Неверно. Как велась разработка в ту раннюю эпоху описано в http://www.cs.utexas.edu/~EWD/transcrip ... D1308.html

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

Не так.

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

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

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

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

Владимир Паронджанов писал(а):
Многие запреты (неизбежные при текстовом структурном програм-мировании) «перегибают палку». Они противоречат здравому смыслу и затрудняют понимание алгоритмов и программ.

Какие запреты затрудняют понимание алгоритмов и программ?

Владимир Паронджанов писал(а):
Недопустимо запрещать правильный процесс мышления. Его надо разрешить. И ДРАКОН разрешает.

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

Владимир Паронджанов писал(а):
Так родилась приписываемая Дейкстре и по праву принадлежащая ему концепция текстового структурного программирования.

Нет такой концепции текстового структурного программирования. Есть просто концепция структурного программирования. У нас может не быть текста, мы можем не уметь рисовать блок-схемы, мы можем только устно общаться и можем применять концепцию структурного программирования.

Владимир Паронджанов писал(а):
6. ...Эти ограничения и запреты вытекают из природы текста, из природы текстового представления управляющих струк¬тур.

Они не вытекают из природы текста, а являются следствием законов математики.

Владимир Паронджанов писал(а):
7. Недостаток выразительных средств, проявляющийся через ограни¬чения и запреты, тормозит повышение производительности труда алгоритмистов и программистов.

Не обосновано.

Владимир Паронджанов писал(а):
10. Недопустимо запрещать правильный процесс мышления. Его надо разрешить. Шампур-метод и язык ДРАКОН устраняют этот недос¬таток.

Для начала нужно определить что есть правильный процесс мышления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 02:09 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Владимир Паронджанов писал(а):
В чем отличие от подхода Дейкстры? Во-первых, мы говорим не о полном, а о частичном доказательстве правильности.

Здесь происходит подмена понятия.
Далее происходит переопределение понятия "доказательство правильности":
Владимир Паронджанов писал(а):
... будут иметь автоматически доказанную правильную графику.


То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ.

(Например, если переопределить понятие доказательство корректности АЛГОРИТМА понятием доказано правильным начертанием букв, то можно будет говорить, что если мы не записывает алгоритм от руки, а печатает на печатной машинке, то мы получим доказано правильное начертание букв и, соответственно, мы будет говорить, что доказана частичная правильность программы)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 12:12 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Rifat писал(а):
Владимир Паронджанов писал(а):
В чем отличие от подхода Дейкстры? Во-первых, мы говорим не о полном, а о частичном доказательстве правильности.

Здесь происходит подмена понятия.
Далее происходит переопределение понятия "доказательство правильности":
Владимир Паронджанов писал(а):
... будут иметь автоматически доказанную правильную графику.


То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ.

(Например, если переопределить понятие доказательство корректности АЛГОРИТМА понятием доказано правильным начертанием букв, то можно будет говорить, что если мы не записывает алгоритм от руки, а печатает на печатной машинке, то мы получим доказано правильное начертание букв и, соответственно, мы будет говорить, что доказана частичная правильность программы)


1
То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ,
выражающую этот алгоритм.

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

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

2
Например, если переопределить понятие доказательство корректности АЛГОРИТМА понятием доказано правильным начертанием букв

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 12:23 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
andr писал(а):
1
То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ,
выражающую этот алгоритм.

Что здесь не так,


АЛГОРИТМ не равняется ГРАФИКА.
Это взаимонезависимые понятия.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 12:32 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
andr писал(а):
Но это гарантирует только синтаксическую корректность алгоритма.
Семантика зависит от содержания графических операторов (блоков).
И она должна доказываться какими-то дополнительными средствами.

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

Семантика алгоритма не может доказываться отдельно. Алгоритм может доказываться или не доказываться. Если использовать этот неправильный термин семантика должна доказываться дополнительными средствами, то это означает, что алгоритм не доказывается, а алгоритм должен доказываться дополнительными средствами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 13:06 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Rifat писал(а):
andr писал(а):
Но это гарантирует только синтаксическую корректность алгоритма.
Семантика зависит от содержания графических операторов (блоков).
И она должна доказываться какими-то дополнительными средствами.

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

Семантика алгоритма не может доказываться отдельно. Алгоритм может доказываться или не доказываться. Если использовать этот неправильный термин семантика должна доказываться дополнительными средствами, то это означает, что алгоритм не доказывается, а алгоритм должен доказываться дополнительными средствами.

1
Любой алгоритмический язык имеет:
1)
Синтаксис - правила записи (правильно построенных) алгоритмов - алгоритмических выражений
(литерных или графических):
это наиболее разработанные формализованные системы;
2)
Семантику - правила интерпретации (правильно построенных) алгоритмических выражений,
включая:
а)
правила выполнения алгоритма - реализуется человеком и автоматом (без человеческого понятия);
б)
правила понимания и объяснения смысла записей алгоритма:
не реализуется простыми автоматами - без человеческого понятия.
(в)
прагматика - далее не обсуждается.

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

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

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

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

4
Существуют методы доказательного программирования,
но это особая статья.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 13:20 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
andr писал(а):
1
Любой алгоритмический язык имеет:
1)
Синтаксис - правила записи (правильно построенных) алгоритмов - алгоритмических выражений
(литерных или графических):
это наиболее разработанные формализованные системы;
2)
Семантику - правила интерпретации (правильно построенных) алгоритмических выражений,
включая:

Речь идет про подмену понятия.
То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ.
Если быть еще более точным, то понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильный синтаксис алгоритмического графического языка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 14:13 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Задачи по курсу Логика.
Задача 1.
Даны следующие утверждения:
A. Дейкстра правильно записывал корректные алгоритмы.
B. Дейкстра правильно записывал некорректные алгоритмы.
С. Мы правильно записываем алгоритмы.

Следует ли из этих утверждений:
1) Что мы записываем корректные алгоритмы?
2) Что алгоритмы, которые мы записываем, корректны?
3) Что алгоритмы, которые мы записываем, правильно записаны?

Задача 2.
Даны следующие утверждения:
A. Дейкстра правильно записывал структурные алгоритмы.
B. Дейкстра правильно записывал неструктурные алгоритмы.
С. Мы правильно записываем алгоритмы.

Следует ли из этих утверждений:
1) Что мы записываем структурные алгоритмы?
2) Что алгоритмы, которые мы записываем, структурны?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 14:20 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Rifat писал(а):
andr писал(а):
1
Любой алгоритмический язык имеет:
1)
Синтаксис - правила записи (правильно построенных) алгоритмов - алгоритмических выражений
(литерных или графических):
это наиболее разработанные формализованные системы;
2)
Семантику - правила интерпретации (правильно построенных) алгоритмических выражений,
включая:

Речь идет про подмену понятия.
То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ.
Если быть еще более точным, то понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильный синтаксис алгоритмического графического языка.

1
Цитата:
То есть понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильную ГРАФИКУ
Если уточнить:
доказательство синтаксической корректности алгоритма, то да,
надо доказать, что он правильно-построенный алгоритм.
В данном случае, надо доказать правильную (правильно построенную) графику алгоритма.

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

2
Цитата:
Если быть еще более точным, то понятие доказательство корректности АЛГОРИТМА заменяется на понятие доказано правильный синтаксис алгоритмического графического языка
Но это уже совсем не то, что по п. 1.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 14:54 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
andr писал(а):
Алгоритмический (графический) язык - это (потенциально бесконечное) множество
правильно-построенных (графических) алгоритмических выражений,
которое конструктивно определяется (порождается)
(конечной) системой правил синтаксиса языка - правил построения (правильно-построенных) выражений.

Еще одна ошибка считать Дракон алгоритмическим языком.

Определение из Wikipedia:
Алгоритми́ческий язык — формальный язык, используемый для записи, реализации или изучения алгоритмов.

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

Поэтому Дракон - это язык записи шаблонов, которые могут определять алгоритм (а могут и не определять).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Октябрь, 2016 16:02 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Rifat писал(а):
andr писал(а):
Алгоритмический (графический) язык - это (потенциально бесконечное) множество
правильно-построенных (графических) алгоритмических выражений,
которое конструктивно определяется (порождается)
(конечной) системой правил синтаксиса языка - правил построения (правильно-построенных) выражений.

Еще одна ошибка считать Дракон алгоритмическим языком.

Определение из Wikipedia:
Алгоритми́ческий язык — формальный язык, используемый для записи, реализации или изучения алгоритмов.

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

Поэтому Дракон - это язык записи шаблонов, которые могут определять алгоритм (а могут и не определять).
Вот это да. :shock:
Неожиданный поворот.
Что-то здесь есть.
Спасибо за промывку мозгов.

Хотя есть возможность наполнения УГО (условных графических обозначений) литерными текстами.
Но этот аспект не формализуется.

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

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

Как, например, язык Akgol-68 - это не конкретный язык,
а генератор конкретных языков
(сходных и различных по лексике и синтаксису).
Хотя это сильно другое, но есть аналогии.

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

Вставки литерных текстов обычно не формализуются.
И никого это не беспокоит - берут и применяют.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Октябрь, 2016 10:55 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Rifat писал(а):
Еще одна ошибка считать Дракон алгоритмическим языком.

Определение из Wikipedia:
Алгоритми́ческий язык — формальный язык, используемый для записи, реализации или изучения алгоритмов.

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

Поэтому Дракон - это язык записи шаблонов, которые могут определять алгоритм (а могут и не определять).
Вот это да. :shock:
Неожиданный поворот.
Что-то здесь есть.
Спасибо за промывку мозгов.

Хотя есть возможность наполнения УГО (условных графических обозначений) литерными текстами.
Но этот аспект не формализуется.

.................
.................

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

Как, например, язык Akgol-68 - это не конкретный язык,
а генератор конкретных языков
(сходных и различных по лексике и синтаксису).
Хотя это сильно другое, но есть аналогии.

................
................

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

Итого:

1
Графический язык Дракон - это язык графических алгоритмических шаблонов,
и это, все таки, алгоритмический язык - обобщенного абстрактного типа:
без регламентации наполнения УГО в шаблонах конкретикой.

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

2
Также, как язык структурных формул параллельных (и последовательных) алгоритмов.
Например:

A10 = (Z1 -> Z2 -> Z3) = Z1-Z2-Z3 - последовательный алгоритм:
последовательное (->) выполнение трех команд Z1, Z2, Z3.

A2 = ((Z1 || Z4) -> Z5) = (Z1 || Z4)-Z5 =
= (Z1 #$ Z4)-Z5 .=. #(Z1, Z4)$-Z5 = #Z1,Z4$-Z5
- параллельный алгоритм:
параллельное ( || ) выполнение двух команд Z1, Z4, и затем (->) выполнение команды Z5.

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

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

3
В частности, это алгоритмы для вычисления площади трапеции по расчетной формуле:
s = ((a + b) / 2) * h = (a + b) * (h / 2)
Соответственно этому (с введением промежуточных переменных):

A10 = (v1 = a + b) -> (v2 = v1 / 2) -> (s = v2 * h)
конкретный последовательный (вычислимый) алгоритм;

A2 = [(v1 = a + b) || (v3 = h / 2] -> (s = v1 * v3)
конкретный параллельный (вычислимый) алгоритм.

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

Но для аппаратной реализации параллельный алгоритм имеет преимущества.

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

4
Здесь также алгоритмический язык структурных формул (СФА)
задает (строго регламентирует и формализует)
только абстрактные структуры алгоритмов разных структурных классов:
для решения разных теоретических и практических алгоритмических задач.

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

Спасибо уважаемому товарищу господину Rifat. :shock:
Кое что допонял в своей системе.
Сей же час внесу поправки в описание языка и примеров СФА

5
Однако СФА широко используются как шаблоны (шаблон2)
для построения по ним структурных схем алгоритмов алгоритмов (ССА) и псевдокодов алгоритмов (ПКА)
(возможно с промежуточными синтаксическими преобразованиями).

Например:

1)
A10 = Z1-Z2-Z3 = -Z1-Z2-Z3->
шаблон (шаблон2) для построения с структурных схем алгоритмов:
блок-схем, штрих-схем, граф-схем и т.п.

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

2)
A10 = (Z1-Z2-Z3)
шаблон (шаблон2) для построения псевдокода алгоритма:

alg A10: begin Z1; Z2; Z3 end

алг A10: нач Z1; Z2; Z3 кон

Это алгол-подобный текст алгоритма в стиле языка программирования Algol-68
и его русифицированной версии Алгол-68.
Это (в русской нотации) учебный алгоритмический язык (УАЯ)
или школьный алгоритмический язык (ШАЯ):
https://ru.wikipedia.org/wiki/Учебный_алгоритмический_язык
[url]http://seoulschool.ru/wp-content/uploads/2014/11/Школьный-алгоритмический-язык.pdf[/url]
http://seoulschool.ru/wp-content/uploads/2014/11/Школьный-алгоритмический-язык.pdf
[url]http://seoulschool.ru/wp-content/uploads/2014/11/Школьный-алгоритмический-язык.pdf[/url]

Это уже шаблон (шаблон1) для наполнения псевокода конкретикой:

алг A10: нач v1 := a + b; v2 := v1 / 2; s = v2 * h кон

--------------------------
Хорошо разобрался со своими шаблонами.
Обратно спасибо уважаемому товарищу господину Rifat.
Сей же час внесу все поправки в описание языка и примеров СФА

=============
Сам не сетую и другим советую.
Делайте с нами, делайте как мы, делайте лучше нас. :shock:


-----------------------
Вопрос к читателям поста.
Не работают ссылки на Википедию и другие источники
с русифицированными текстами хвостов
.
Что нужно сделась?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Октябрь, 2016 15:17 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
1
Графический язык Дракон - это язык графических алгоритмических шаблонов,
и это, все таки, алгоритмический язык - обобщенного абстрактного типа:
без регламентации наполнения УГО в шаблонах конкретикой.

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

Для выяснения этого аспекта следует обратиться к первоисточнику данной темы:
Глава 36. ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ И ПРОГРАММАМ (ШАМПУР-МЕТОД)
http://forum.oberoncore.ru/viewtopic.php?p=99079#p99079

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

Цитата:
§2. ТЕРМИНОЛОГИЯ

Введем понятие «визуальный структурный подход к алгоритмам и программам».
Определим его как набор правил, совпадающий с визуальным синтаксисом языка ДРАКОН.
Судя по всему, здесь уже заложено определение сути визуального языка Дракон,
которую точно сформулировал уважаемый Rifat:
http://forum.oberoncore.ru/viewtopic.php?p=99107#p99107
Rifat писал(а):
Еще одна ошибка считать Дракон алгоритмическим языком.

Определение из Wikipedia:
Алгоритми́ческий язык — формальный язык, используемый для записи, реализации или изучения алгоритмов.

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

Поэтому Дракон - это язык записи шаблонов, которые могут определять алгоритм (а могут и не определять).

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

1)
Это обобщенные правила формирования абстрактной структуры алгоритмов:
предельно обобщенные графические записи абстрактных алгоритмов,
с полным абстрагированием (отвлечением) от содержательной конкретики УГО
(условных графических обозначений визуального языка):
рабочих операторов (в прямоугольниках), решателей алгоритмов (в ромбиках) и т.п.

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

2
Цитата:
которые могут стать алгоритмами, если в пустые квадратики и ромбики вписать правильные действия
(а могут и не стать алгоритмом,
если в шаблон вписать что-нибудь неправильно,
это уже правилами Дракона не регламентируется)

Поэтому Дракон - это язык записи шаблонов[/color], которые могут определять алгоритм
(а могут и не определять)
Эту ситуацию (а может и не быть ...)
нужно исключить из исходной концепции Дракона:
Дракон не регламентирует и не формализует наполнение УГО языка конкретикой.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Ноябрь, 2016 08:22 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Двухуровневые грамматики

В связи с информацией по постам:
http://forum.drakon.su/viewtopic.php?p=99114#p99114
http://forum.drakon.su/viewtopic.php?p=99116#p99116
обнаруживается целесообразность рассмотреть визуальный язык Дракон
в аспекте концепции двухуровневых грамматик.
Википедия:
Двухуровневая грамматика
[url]https://ru.wikipedia.org/wiki/Двухуровневая_грамматика[/url]
https://ru.wikipedia.org/wiki/Двухуровневая_грамматика

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

2
Достоинства:
Цитата:
Это делает двухуровневые грамматики более мощными,
чем одноуровневые контекстно-свободные грамматики,

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

3
Пример применения:
Цитата:
Именно так грамматика ван Вейнгаардена была использована
для определения языка Алгол-68.
Контекстно-свободная грамматика,
которая определяет правила для другой грамматики,
может породить в сущности бесконечное множество правил производной грамматики.

1. Пересмотренное сообщение об АЛГОЛЕ 68. – М.: Мир, 1979. – 533 с.
2. Васильев В.А. Язык АЛГОЛ-68. М.: Наука. Гл. ред. физ.-мат.-лит., 1972. – 128 с.
3. Линдси Ч., Ван дер Мюйлен С. Неформальное введение в Алгол 68. – М.: Мир, 1973. – 407 с.
4. Практическое руководство по Алголу 68. – М.: Мир, 1979. – 240 с.

Язык Алгол-68
это было гениальное достижение в области конструирования языков программирования в свое время:
Цитата:
это "беспримерное достижение" в литературе по языкам программирования …" [1, с. 9]

Однако, это была абсолютно неудачная разработка с точки зрения эргономики:
она ориентирована, фактически, на "тупой" формальный синтаксический автомат.
В частности:
Цитата:
Однако, это язык требует [1, с. 5]:
1) "определенного привыкания к формализму" – именно к его уникальному и весьма необычному и специфическому формализму;
2) "способности к терпеливому "разматыванию" индуктивных и рекурсивных определений …".
Причем часто формируются многостраничные "клубки" таких определений,
требующие способности их терпеливого "разматывания".

В целом такое описание данного языка [1] – это сильно заформализованное построение
обширного (огромного) материала,
вполне подходящее для формальных автоматов (без человеческого "понятия"),
но не для массового практического пользователя такого языка
(с "понятием" – с естественным человеческим мышлением).

Этот язык так и не получил массового практического применения,
несмотря на появление литературы с идеологией типа "неформальное введение в Algol 68" [3]

Но гениальное, есть гениальное,
и язык Algol-68 оставил разветвленный след в программировании в разных отношениях.
Но много еще не понято, не освоено и не адаптировано массовым программным специалистом разных уровней.

4
Википедия далее. Другая интерпретация термина
Цитата:
Двухуровневой грамматикой может также называться
формальная грамматика для двухуровневого формального языка,
то есть языка, заданного на двух уровнях, например
уровень слов и уровень предложений
То есть это грамматика любого традиционного языка программирования, включающая в себя
лексику и синтаксис языка.

Это (пока) не имеет отношения к визуальному языку Дракон (???).
Но это показывает возможность разных интерпретаций термина,
и развязывает руки для свободы действий.

---------------------------
Применительно к языку Дракон в принципе можно ввести два уровня его грамматики
(возможно с подуровнями):

1)
Уровень1: Основной уровень грамматики визуальной части языка:
язык графических алгоритмических шаблонов.

Пустых
или
с формальными (литерными) надписями типа:
Оператор1, Оператор2 ... ОператорN.
Возможно короче типа:
Оп1, Оп2 ... ОпN.
Или еще короче - с одним корневым символом.

Автор это поста используется два общих индесированных корневых символа:
Ai - общее литерное обозначение операторов алгоритмов
(A - первая буква латинского алфавита).
Zi - общее обозначение операторов команд
(Z - последняя буква латинского алфавита).

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

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

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

Это в отношении последовательных алгоритмов и последовательного программирования.

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 15 ] 

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


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

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


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

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