Обсуждение:ДРАКОН

Об удалении и восстановленииПравить

На каком основании Вы удалили этот материал?

На том, что три человека не прочитав автора внимательно, и не разбираясь в материале написали тупые блок схемы? Или вы сами себя считаете большим специалистом в этом вопросе?

Мне кажется, что прежде, чем что-то удалять, надо хотя бы прочитать, что про это написано. Не говоря уж об том что есть книжка Алистера Коберна "Современные функциональные требования", где выражаются похожие мысли.

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

Что же видим у автора? Он эти вопросы рассматривает и ставит во главу угла (считает основными). Более того он обоснованно использует (см. Паронджанов "Как улучшить работу ума", главы "Концепция когнитивного программирования", "Текст как зрительная сцена", "Симультанное и сукцессивное восприятие", "Как повысить продуктивность человеческого мозга"). Если вы не видите разницы между структурным представлением и эргономичным представлением с учетом особенностей человеческого мозга, то очень жаль.

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

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

фрагментов

Когнитивную сущность изложенных соображений можно охаракте-

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

мышления.

Дальше автор пишет про формат вывода: "КАКИМ ДОЛЖЕН БЫТЬ ФОРМАТ ДИОСЦЕНЫ?". Там он говорит про принцип целостного образа, и обосновывает этот принцип (так где здесь тупые блок схемы? Может они не так уж и тупы, как показалось некоторым?).

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

! Структура диосцены должна быть не хаотичной, а регулярной и предсказуемой.

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

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

! Границы зон (выделяемые пробелами или линиями) должны иметь простую прямоугольную форму.

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

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

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

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

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

! Замкнутые контуры предпочтительнее, чем разорванные линии.

! Следует использовать простые и интуитивно ясные средства, позво- ляющие отделить смысловую фигуру (простую или составную) от фона.

! Линии контура блоков должны быть жирнее, чем соединительные линии.

! Следует использовать также некоторые правила, рекомендуемые в инженерной психологии для проектирования средств отображения информации, например правило метра и ритма [5].

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

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

Про похожесть - вообще смешно. Если Вы или Я похожи на обезьяну, то это совсем не означает, что мы являемся этими животными. Туда же и тупой попил денег. Автор этого сообщения наверное со свечкой стоял, или жалеет что ему не досталось. Крикнуть такое гораздо проще, чем узнать, что тема вообще-то была разработана в 80-х, когда и понятия такого-то и в помине не было.

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

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

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

--188.128.100.242 03:05, 23 октября 2009 (UTC) С уважением Емельяненко Сергей.Ответить[ответить]

Это не сюда надо, а на Википедия:К восстановлению --Морган 03:13, 23 октября 2009 (UTC)Ответить[ответить]

Заявка на восстановление 188.128.100.242 04:09, 23 октября 2009 (UTC) Емельяненко СергейОтветить[ответить]

Прошу ознакомиться с темой автора по адресу http://www.computerra.ru/forum/index.php?PAGE_NAME=read&FID=24&TID=332361&PAGEN_1=1 (Далеко не все там флейм, несмотря на размеры, есть много вопросов по существу, из ответов на которые следует то автор вообще не разбирается в алгоритмике как таковой И заново переоценить ценность статьи 77.246.104.4 21:12, 18 апреля 2011 (UTC)Алекс.Ответить[ответить]

Авторские праваПравить

Ответ Владимира Паронджанова на замечание о нарушении авторских прав

Автором статьи в Компьютерре являюсь я, Владимир Паронджанов. Статья называется "«Буран» и язык программирования ДРАКОН". Опубликована 13 апреля 2009 года. Я действительно использовал этот материал в статье «ДРАКОН (алгоритмический язык)» в Википедии. Таким образом, нарушение авторских прав отсутствует. 25 мая 2011 года Владимир Паронджанов — Эта реплика добавлена участником Владимир Паронджанов (о • в) 2011-05-25 08:18:20 (UTC)

• Владимир, пройдите, пожалуйста, процедуру ВП:ДОБРО, в ином случае, текст, находимый в источнике охраняемом авторским правом будет удалён. bezik 08:55, 25 мая 2011 (UTC)Ответить[ответить]

Уважаемый Bezik!

По Вашему совету я отправил шаблонное разрешение по адресу permissions-ru@wikimedia.org 25 мая 2011 года Владимир Паронджанов — Эта реплика добавлена участником Владимир Паронджанов (о • в) 2011-05-25T13:55:14 (UTC)

• Очень хорошо! Если всё нормально — то вскоре (возможно, после некоторых уточняющих вопросов) придёт идентификатор разрешения на использование материала, и его нужно будет разместить на данной странице обсуждения при помощи шаблона {{OTRS}}, чтобы впредь ни у кого не возникало подозрений в нелегальном использовании стороннего содержимого. bezik 15:29, 25 мая 2011 (UTC)Ответить[ответить]

Уважаемый Bezik!

31 мая 2011 года я получил разрешение от Wikimedia Permissions <permissions-ru@wikimedia.org>, подписанное Линар Халитов. По Вашему совету выставляю шаблон разрешения. Владимир Паронджанов.

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

Владимир, очень хорошо, что такое разрешение появилось, я снял шаблоны о нарушении авторских прав. Теперь и для энциклопедии и для предмета статьи очень важно было бы обеспечить аккуратное, без избыточных подробностей про другие разработки и воды про беспрецедентные по сложности объекты и т.п. Ценность предмета статьи от лаконичного и беспристрастного изложения только возрастёт. Надеюсь на понимание, bezik 06:15, 31 мая 2011 (UTC)Ответить[ответить]

Уважаемый Bezik!

1. Я с Вами полностью согласен. 2. По Вашему совету я удалил слова «беспрецедентный», «особые проблемы». И переписал весь этот абзац в нейтральном ключе. 3. Ваши замечания общего характера (не содержащие конкретных указаний на слабые места) я постараюсь учесть при дальнейшей работе над этой статьей.

1 июня 2011 года. Владимир Паронджанов

Пример диаграммыПравить

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

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

Уважаемый коллега!

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

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

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

4. Использование английского языка в русском разделе Википедии широко распространено. См. например, диаграммы в статьях UML, диаграмма деятельности и др. Или, скажем, РЕФАЛ, созданный русским человеком Валентином Турчиным.

5. Сказанное вовсе не означает, что я против русского языка в дракон-схемах. Совсем нет. Все дракон-схемы в моих книгах выполнены только на русском языке.

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

5 июня 2011 года. Владимир Паронджанов.

Ответы на замечания об отсутствии ссылок на АИПравить

Уважаемый Bezik!

1. Я проставил источники, подтверждающие, что диаграмма действий и диаграмма состояний являются аналогами дракон-схем.

2. Кроме того, я проставил источник для фразы "При создании программ для сложных космических объектов..."

2 июня 2011 года. Владимир Паронджанов

Уважаемый Bezik!

По одному частному вопросу у меня есть возражение. Речь идет о фразе:

«Система управления [9][нет в источнике][10][нет в источнике] космического корабля „Буран“ управляет полетом Бурана и всеми бортовыми системами корабля».

В этой фразе есть две ссылки, разъясняющие понятие „Система управления Бурана“. Эти ссылки решают свою задачу и дают необходимые пояснения об этом понятии. Прошу снять указание [нет в источнике].

5 июня 2011 года. Владимир Паронджанов.

Уважаемый Bezik!

Я указал ссылку на источник для фразы:

«В качестве аксиоматики для ДРАКОНа были выбраны устремлённые графы (специальный класс циклических орграфов). Такое двумерное структурное программирование годится для доказательного построения алгоритмов методом Дейкстры[4][источник?]».

7 июня 2011 года Владимир Паронджанов

Критическое замечание Wikifanat и ответ Владимира ПаронджановаПравить

Из прочитанного сделал вывод - это вариант стандарта для оформления flow charts блок-схем, для которого разработан кодогенератор. Всё. Мы же не называем UML, IDEFx языками программирования? ДРАКОН надо воспринимать как алгоритмический язык? Что такое ДРАКОН на самом деле? Оболочка-обертка над другими языками и компиляторами, методология - может быть, но никак не самостоятельный алгоритмический язык.--Wikifanat 10:17, 4 ноября 2011 (UTC) ________________________________________________________Ответить[ответить]

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

Уважаемый Wikifanat!

Благодарю за критическое замечание и за вопрос.

Является ли язык ДРАКОН языком программирования? Да, является.

В Пилюгинском центре (ФГУП НПЦ автоматики и приборостроения им. акад. Н.А.Пилюгина) язык ДРАКОН является языком программирования в составе САSE-технологии ГРАФИТ-ФЛОКС, которая используется при разработке и отработке программного обеспечения для систем управления ракет-носителей и разгонных блоков космических аппаратов. http://store.oberoncore.ru/lib/paper/grafit_A4.pdf

Геннадий Тышов создал ИС Дракон - интегрированную среду языка Дракон для широкого применения. http://forum.oberoncore.ru/viewtopic.php?f=79&t=1291 позволяющую создавать программы на гибридных языках, в частности на языке Дракон-Си.

Сергей Ефанов использует ИС Дракон для разработки ПО различных устройств с микроконтроллерами http://forum.oberoncore.ru/viewtopic.php?f=79&t=3129

Уважаемый Wikifanat!

Прочитайте внимательно тему «Программируем с и.с. Drakon». http://forum.oberoncore.ru/viewtopic.php?f=79&t=3129

Это не займет много времени – там всего-навсего три страницы, 46 сообщений. Разберите все сообщения, проанализируйте все дракон-схемы, изучите программные коды.

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

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

Цитата 1

Более, чем интересно! Сразу - не понял, в чём тут суть (где библиотеки, где "порты" под целевые процессоры?), попробовал тупо скомпилировать для своего процессора - скомпилировалось. Удивился. Запустил в отладчике - РАБОТАЕТ! Обалдел!

Смотрю теперь на это чудо, вникаю. Просто switch и case с номером строки исходника, и... работает!

Спасибо! Кажется, это именно то, что мне нужно.

http://forum.oberoncore.ru/viewtopic.php?p=57132#p57132

Цитата 2

Спешу поделится первыми практическими результатами применения ДРАКОНа.

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

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

Оказалось, я в иконке "ПЕРЕДАТЬ ПАКЕТ" вписал вызов не той процедуры. Исправление не составило труда, и при втором запуске программа отработала ПОЛНОСТЬЮ!

Не знаю, каковы успехи в программировании у других, но мне еще ни разу не удавалось так легко заставить работать процедуру с 29 развилками!

И почему то я уверен, что ошибок в этом алгоритме у меня нет.

Нет слов, чтобы достойно выразить моё восхищение языком и инструментом этого языка! Огромное спасибо Паронджанову Владимиру Даниеловичу, огромное спасибо Тышову Геннадию Николаевичу! Я пока только чуть-чуть попробовал этот инструмент, и уже вижу огромную пользу, которую он мне принесёт.

С Уважением, Ефанов Сергей.

 http://forum.oberoncore.ru/viewtopic.php?p=57318#p57318

Цитата 3

… мне кажется, что этот язык специально для меня придумали!

http://forum.oberoncore.ru/viewtopic.php?p=58238#p58238

Владимир Паронджанов 14:24, 11 ноября 2011 (UTC)Ответить[ответить]

Дракон не является языком программирования и это доказывается элементарно - Дракон ничего не может если под него не подложить настоящий язык программирования. То-что Вы назвали "гибридными языками" - это как раз и есть проистекающая из неполноценности Дракона попытка поставить его на ноги, используя в качестве костылей языки программирования, созданные не Вами. вуаля - "вклад в науку" в непрошенном "соавторстве" сделан. Ethereal0000 (обс.) 02:34, 10 августа 2020 (UTC)Ответить[ответить]

• • • Коллега, u:Ethereal0000, давайте будем стараться сдерживать свои эмоции и придерживатся этики в общении (обсуждение чужих ног, точно не относится к теме статьи). Исходя из вашей логики, языки высокого уровня - это просто надстройка над ассемблером. К тому же аналогичный ДРАКОНу UML зачастую называют графическим редактором для программирования. — Saramag (обс.) 03:05, 10 августа 2020 (UTC)Ответить[ответить]

О качественном улучшении статьиПравить

Некоторое время назад Паронджанов вынес статью на обсуждение в эту тему: http://forum.oberoncore.ru/viewtopic.php?f=62&t=3303&start=20. Так как это не вики-обсуждение, здесь скажу о ключевых вопросах развития изложения предмета. Сразу не стремлюсь выполнять ВП-совет «Правьте смело», :) ибо есть смысл кое-что определить. Да, чтобы было понятно — дальше использую в тексте РБНФ-обозначения в смысле, определённом здесь: http://grafit-basis.narod.ru/L3/usl_obozn.html#Pril1-n1112 - для удобства «неформального управления вхождениями». Нумерованные источники в тексте — те, которые требуют включения в статью.

Во-первых, пока нет чёткого определения ДРАКОНа через ряд ключевых понятий, также определённых в ВП и/или через ссылки на АИ. Имею в виду прежде всего следующие:

• «формализация»
• «язык< представления знаний>»
• «текстовый»/«визуальный»
• «двумерный структурный»

Первое, на мой взгляд, надо понимать в смысле этого источника: http://www.mgopu.ru/pvu.old/Sprint-Inform/f_ru_text.htm#formaliz. Чтобы снять возможные вопросы к его АИ — уточню, что имеются официальные печатные публикации:

• 1. Фридланд А. Я. Информатика: процессы, системы, ресурсы. — М.: БИНОМ. Лаборатория базовых знаний, 2003. (монография)
• 2. Фридланд А. Я. Основные ресурсы информатики. — М.: АСТ:Астрель; Профиздат, 2005. (учебное пособие)

Для предмета статьи здесь важно, что формализуется часть знания носителя-человека, которую Фридланд называет отчуждаемой. Именно её мы и можем представить на некоторых ЯПЗ как описание. Далее в этом описании мы можем выделить информатическую модель. В терминах Фридланда — алгоритмическую и однозначно понимаемую читателем только на основе владения языками инфор-моделирования, без обращения к носителю/сочинителю за разъяснениями смысла (практически — за счёт того, инфор-модель составляется для [модели ]формального исполнителя алгоритмов, как-то по Тьюрингу/Черчу/Маркову). В целом можно сказать — информодель возникает, когда мы отвечаем на вопрос: «КАК решается задача/устроена предметная область?» — имея в виду формального исполнителя/читателя. Который должен иметь, кроме знания ЯПЗ описания, также «базовую подготовку». Для искусственного исполнителя она «зашита» в аппаратной архитектуре и программах, создающих «платформу» реализации ЯПЗ (начиная с управляющей, то есть ОС, если она есть — хотя бы в виде системного монитора).

То есть второе — ЯПЗ — это средство фиксации отчуждаемой составляющей знания; неотчуждаемое знание также существует и используется читателем описания. И в принципе возможны разные базовые формы представления всего описания или его отдельных частей — текст, графика, таблица (как форма структуризации текста/графики). Далее, сами составляющие знания нужно подразделить и указать приложение ДРАКОНа в рамках этого подразделения. Применительно к инфор-моделям (и «знаковой» форме программ в частности) такое подразделение указывает т. н. расширенный тезис Вирта: «Программа = Алгоритм + Структура данных + Архитектура исполнителя». Эту формулировку он фактически вводит в своей статье:

• 3. Вирт Н. От разработки языков программирования к конструированию компьютеров. — Микропроцессорные средства и системы, № 4/1989. — С. 42-48. (публикация на русском языке Тьюринговской лекции 1988 года)

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

Составляющую описания исполнителя здесь называю активностной (актив-знанием). Это идёт от определения исполнителя в SADT-формализации как «activity».

Подразделение Вирта можно включить в общую структуру отчуждаемого (формализуемого) знания, которую сначала надо определить. Возможный вариант показан здесь: http://grafit-basis.narod.ru/L2/gen_struct_dan.html; это не следует считать АИ, а только иллюстрацией к проблеме. Суть которой такова:

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

Отмечу, что Паронджанов начал решать эту проблему — см. в «Как улучшить работу ума» п. «Классификация знаний».

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

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

• 4. Тюгашев, А. А. Графические языки программирования и их применение в системах управления реального времени [Текст] : монография / А. А. Тюгашев. — Самара : Изд-во Самар. науч. центра РАН, 2009.

Кстати, в работе среди других анализируется и ДРАКОН. Правда, с т. зр. применимости для визуализации инфор-моделей конкретных задач управления определённым классом оборудования в реальном времени. Тюгашев ранее суммировал свои выводы здесь: http://forum.oberoncore.ru/viewtopic.php?p=41836#p41836.

Следует также основательно уточнить понятие «двумерного визуального» представления структуры знания (Паронджанов везде говорит «программирования» — но это будет точнее). Тем более, что в авторских источниках оно то явно, то неявно противопоставляется «одномерному текстовому». К чему нет формальных оснований. И в статью в текущем виде это было перенесено. Прежде всего — нужно отделить физическое структурирование (применительно к предмету — укладку граф-схемы на плоскости при конкретных габаритах того и другого) от логического (подразделения системы маршрутов, представляемой этим графом, на смысловые части — что, понятно, от габаритов не зависит :)). Соответственно и мерность придётся подразделить на физическую и логическую — отдельно для пространства и для схемы.

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

Текст в силу своей линейности (как цепочки литер) просто делает неочевидным то же самое. Что текстовая запись также может представлять нелинейные структуры связей, логически неодномерные. Для выражения связей просто применяются другие средства — скажем, операторы [гипер]ссылки. И равно существует физически двумерная текстовая запись — упорядчивающая в измерении «поперёк строки» посредством перевода строки (разбиения на физические строчки), а «вдоль строки» — посредством позиционного отступа (интендации) физических строчек. И эти средства м.б. применены точно к тем же логическим элементам, что и при графовой записи структуры. Мы даже можем разместить на диосцене столбцы строчек, представляющие цепочки следования, так же как размещаются вертикали следования в дракон-схеме, а связность устанавливать по ключевым маршрутным словам. :) Просто это будет не столь эргономично — но и будет «двумерным текстовым представлением»… А ещё не забудем, что эти строчки мы можем заключить в ячейки таблицы. Форма и расположение которых отражают связность. Так получаются хорошо известные структурограммы. Это уже «двумерное табличное представление»…

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

Обоснование и назначение языкаПравить

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

Информатическая модель (по А. Я. Фридланду) — однозначно понимаемая читателем только на основе владения языками инфор-моделирования, без обращения к носителю/сочинителю за разъяснениями смысла. Инфор-модель составляется для [модели ]формального исполнителя алгоритмов, как-то по Тьюрингу/Черчу/Маркову.

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

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

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

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

Тем самым указывается на существование также составляющей знания, определяющей исполнителя (хотя бы в форме указания на его вид и свойства — напр., параметры конфигурации машины, квалификацию человека). Следуя определению исполнителя в SADT-формализации как «activity», эту часть можно называть активностной (актив-знанием). Оно определялось явно и в текстовых языках - например, в школьной алгоритмической нотации для советского курса ОИВТ (см. ). Кроме того, определение парадигмы программирования в этой части:

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

...

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

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

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

• принцип вложения — схема наращивается вводом атомов, построенных из знаков алфавита и словаря, в специально указанные рёбра заготовок и других атомов (см. Тезисы 10, 36, 37 шампур-метода);
• принцип шампура — вершины при следовании упорядочиваются по вертикали, так что вход всегда сверху, выход снизу и лежат на одной оси (см. Тезисы 2, 6, 8 шампур-метода);
• принцип главной/побочных вертикалей — выходы развилок упорядочены друг относительно друга так, что не лежащий на главной вертикали выход (называемый побочным) всегда располагается правее главного (см. Тезисы 7, 8 шампур-метода);
• принцип силуэта — укладки маршрутов на плоскости в тела веток, промежуточные выходы которых связываются со входами через особую структуру — петлю силуэта - и вершины-соединители (см. Тезис 2 шампур-метода).

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

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

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

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

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

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

Разработчики языка полагают, что двумерное текстовое или табличное представления не дают такого улучшения восприятия, как упорядочение посредством «слепыша» граф-схемы. Т.к. одновременно происходит "замена текста эквивалентным ему чертежом", "удачным чертежом", при которой "Остальные текстоэлементы языка ... становятся ненужными, превращаясь в графические линии и ключевые слова "да" и "нет".". Эти текстоэлементы Паронджанов определяет как "Маршрутный язык - совокупность управляющих операторов. ... язык "картинок" (абстрактных дракон-схем, в которых полностью отсутствует текст).". Исключением м.б. случай, когда человек (сочинитель, читатель) по складу своего ума лучше работает с текстами (иногда такой тип мышления называют "литератор"). "Литератор" не выигрывает от перехода к нетекстовому представлению той или иной части описания. И даже может в чём-то проигрывать. Поэтому в таком переходе он не обязательно заинтересован.

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

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

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

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

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

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

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

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

Наконец, ДРАКОН поддерживает декомпозицию алгоритма выделением вспомогательных алгоритмов-вставок ("предопределённых процессов" в терминах блок-схем по ГОСТ 19.701-90).

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

Сущность языка и методаПравить

Безусловно, ДРАКОН-методология отличается от традиционной визуализации потоков управления блок-схемами. Сам Паронджанов указал на это следующим образом:

Задача формализации и унификации множества профессиональных языков с целью обеспечить эффективное взаимопонимание между специалистами любых профессий, включая программистов, является, хоть и важной, но, увы, неразрешимой. Положение в корне меняется, если ограничиться императивными профессиональными знаниями. Именно эту задачу решает язык ДРАКОН. Он построен путём формализации, неклассической структуризации и эргономизации блок-схем алгоритмов и программ, описанных в стандартах ГОСТ 19.701-90 и ISO5807-85.

Дракон-схему (граф маршрутов алгоритма) можно вывести путём исчисления над алфавитом вершин-[псевдо]операторов и словарём подграфов-макро[псевдо]операторов из аксиомы-заготовки.
Исчисление, разработанное для ДРАКОНа, называется шампур-методом. Оно основано на следующих принципах:

• формальной эргономизации лексики — определения состава вершин и их графики с учётом реальных операторов и директив языков программирования; при этом среди вершин выделяются нелинейные, с участием которых образуются подграфы, построенные из знаков алфавита и словаря, даваемые как единицы лексики языка схем. Такой подграф называется атомом и всегда имеет один вход и один выход; также даются исходные конфигурации схем - заготовки (см. Тезисы 1..8, 11..14 шампур-метода);
• вложения - схема наращивается вводом атомов; среди рёбер атомов и заготовок выделены такие, что допускают замену на тот или иной атом — т.н. рёбра ввода; рёбра указываются вершинами - точками ввода (см. Тезисы 9..10, 15..25, 36, 37 шампур-метода);
• «шампура» - расположения входа и выхода линейной вершины и атома на одной оси, направленной всегда сверху вниз и упорядочения вершин при следовании по вертикали так, что они лежат на одной оси (см. Тезисы 2, 6, 8 шампур-метода);
• главной/побочной осей — выделения в нелинейной вершине (подграфе) из ряда входов (выходов) главного и упорядочения остальных (называемых побочными) вправо от него (см. Тезисы 7, 8 шампур-метода);
• силуэтной укладки - применения соединителей, принятых для блок-схем как межстраничные, в новом качестве — как внутрисхемных для укладки схемы на плоскости без пересечений цепей; соединители разделяют схему, называемую «силуэтом», на блоки-ветки, в тела которых уложены цепи; промежуточные выходы веток связываются со входами через особую структуру — петлю силуэта - и вершины-соединители (см. Тезис 2 шампур-метода);
• лианного вывода — представления неструктурных топологий схем (которые невозможно получить путём вложения) через операции переноса точек соединения без образования пересечений и/или новых входов в ветки силуэта и/или в циклы (любой формы схемы) (см. Тезисы 26..29 шампур-метода).

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

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

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

• вложения — схема наращивается вводом атомов, построенных из знаков алфавита и словаря, в специально указанные (точками ввода) линии заготовок и других атомов (см. Тезисы 10, 36, 37 шампур-метода);
• шампура — вершины при следовании упорядочиваются по вертикали, так что вход всегда сверху, выход снизу и лежат на одной оси (см. Тезисы 2, 6, 8 шампур-метода);
• главной/побочных вертикалей — выходы развилок упорядочены друг относительно друга так, что не лежащий на главной вертикали выход (называемый побочным) всегда располагается правее главного (см. Тезисы 7, 8 шампур-метода);
• силуэта — укладки маршрутов на плоскости в тела веток, промежуточные выходы которых связываются со входами через особую структуру — петлю силуэта - и вершины-соединители (см. Тезис 2 шампур-метода).
• операций с лианой — сочинитель также может переносить (с ограничениями) концы побочных маршрутов, чтобы образовать конфигурацию схемы, недостижимую вводом атома, но соответствующую конструкциям управления некоторых прогязыков; перенос возможен и в примитиве (см. Тезисы 26..29 шампур-метода).

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

Тут, думаю, понятно, почему не сразу править следовало. Ведь разъяснение необходимости занимает, как видим, больший объём, чем предварительный вариант. ;) А поправь без объяснения — у многих м.б. вопросы…

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

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

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

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

Наконец, прогязыки бывают разные. В частности, машинно-зависимые и высокого уровня. Отличительной чертой первых является наличие среди машинных команд явного безусловного перехода (БП). Это также можно изложить с позиций, развивающих шампур-метод и сопрягающих его с теми самыми моделями исполнителей алгоритмов. Так, можно говорить о лиоформе алгоритмического процесса как размещении его описания на «ленте памяти» машины Тьюринга. При этом нелинейная (а при определённых условиях — и линейная) структура требует разрывов между некоторыми линейными её участками. Что означает невозможность естественного перехода к следующему элементу структуры. Для указания следующего элемента в этом случае и служит БП. Следует различать случаи безусловного перехода:

• явный — вводимый по желанию сочинителя или по ограничениям исполнителя;
• неявный — требуемый маршрутной структурой алгоритма при её выкладке — размещении на «ленте памяти»;

Так, даже запись линейной маршрутной структуры (скажем, машинный код) может не поместиться целиком в любой свободный фрагмент «ленты» — но м.б. доступны также и другие фрагменты. Это типичное ограничение исполнителя с сегментацией адресуемой памяти. Тогда нужно разорвать код, введя для связи явный БП. Как это выглядит — можно посмотреть здесь: http://drakonografika.narod.ru/L3/linsubstrproc.html#n2211. Неявными являются БП, которые нужны для возврата на предыдущую вертикаль (главную или побочную) из более правой (побочной) в ветвлениях и циклах. То есть неявный БП представляет соединительную вершину дракон-схемы. Как это выглядит — можно посмотреть здесь для ветвлений: http://drakonografika.narod.ru/L3/vetvsubstproc.html#n2222 и здесь для циклов: http://drakonografika.narod.ru/L3/ciklsubstproc.html#n2231.

В ряде ЯВУ есть представление для безусловного перехода — в виде оператора произвольного БП (goto) и ограниченного БП внутри циклов (break и continue). В других ЯВУ явного БП нет. Это предполагает не «физическое» в своей основе структурирование маршрутов (как было изначально по шампур-методу — для укладки нелинейного графа на плоскости без пересечений). А «логическое» — то есть определение оснований для выбора каждой цепочки следования как логических условий от величин алгоритма.

Разумеется, известно о «войнах языков», и в частности — по поводу явных БП. ;) Но ДРАКОН как маршрут-нотация, претендующая на универсальность, должен здесь находиться «над схваткой». То есть, соответствуя ВП:НТЗ, предоставлять средства выражения структуры как с явными БП, так и без них. В исходном определении эта «нейтральность» не прослеживается. Есть выразительные средства для явных БП при укладке маршрутного графа без пересечений (силуэт), но нет — для укладки без явных БП (имеется примитив, где потенциально можно избежать пересечений — если исключить операции с лианой — но нет средств структурировать целиком алгоритм, как в силуэте). Тогда как классическое структурное программирование предоставляет такие средства в рамках метода Дейкстры. Дело только за их визуализацией — поскольку изначально они определялись в чисто текстовой форме. Более того, в п. 1.8 «Гибридные языки ДРАКОН-семейства и оператор GOTO» утверждается о желательности goto — что однозначно не-нейтрально и противоречит позиции об универсальности ДРАКОНа как маршрутной нотации и об унификации с его помощью граф-представления маршрутной части неопределённого круга прогязыков.

Как итог, к предлагаемому определению выше добавляется следующее:

Преемственность и развитиеПравить

Предложения Паронджанова можно рассматривать как развитие языка, заданного стандартом на блок-схемы в части алгоритмов и программ (далее — БСАП). Смысл сказанного о сущности техноязыка и шампур-метода можно раскрыть через «формулу новизны», как это и принято для официального описания существа изобретений. Здесь можно сказать, что техноязык отличается от БСАП-языка тем, что:

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

Также эти предложения сохраняют общность с БСАП-языком в отношениях:

• структуры схем — объектом вывода также является т.н. сводимый (аранжируемый, устремлённый; на эквивалентность этих определений указано в /3, п. 6/) граф - ориентированный циклический, с выделенной начальной вершиной;
• отношения к разметке — как и в БСАП, рассматривается неразмеченный граф, который Паронджанов называет «слепышом»;
• интерпретации — как и БСАП, примитивы и силуэты понимаются как графы потока управления, а их цепи — как маршруты алгоритмических процессов.

В /3, п. 7/ указано, что топология «слепышей» (схем-примитивов и внутри каждой ветки схем-силуэтов) соответствует классу устремлённых (сводимых, аранжируемых) циклических ориентированных графов, с дополнительно наложенным ограничением планарности (укладки на плоскости без пересечений). Также подчёркивается, что примитивы и силуэты — наиболее общие классы топологий устремлённых графов, ещё сохраняющие свойство управляемости структуры — когда из двух вершин, соединённых дугой, однозначно можно выбрать «старшую» и «младшую» относительно начальной вершины в графе. При размещении в информационном пространстве исполнителя нелинейная (а при определённых условиях — и линейная) структура требует разрывов между некоторыми линейными её участками. Что означает невозможность естественного перехода к следующему элементу структуры. Для указания следующего элемента в этом случае и служит БП. С позиций структурности, следует различать случаи безусловного перехода в период сочинения:

• явный — вводимый по желанию сочинителя на указанную им метку;
• неявный — требуемый маршрутной структурой алгоритма при её выкладке — размещении на «ленте памяти»;

Также очевидно, что соединители у Паронджанова являются разновидностями явного безусловного перехода (БП), причём:

• веточные — БП произвольные (типа goto), ограниченные планарностью;
• лианные — в циклах БП-заменители goto (типа break и continue), вне циклов (включая выходы-заземления из веток) — goto, сохраняющие планарность.

Можно раскрыть эти отличия (а также сходства, оставшиеся с БС) и одновременно оценить метод и язык, возможности его развития.

Графика вершинПравить

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

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

Можно видеть, что в ШМ принято единственное правило — располагать фигуры вершины «лесенкой» всегда справа налево и направленные формы фигур направо - простое, но не использующее информативность графики полностью. Имеется в виду, что для графики вершин схем можно выделить информативные признаки её расположения:

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

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

Вложение и структурные операции на графахПравить

В текстовом программировании известны применения вложения в той или иной форме (например, в архитектуре и программировании отечественных машин семейства «Эльбрус»). В рамках ШМ это понятие было применено к графам. Сущность вложения обсуждалась выше.

В исходном ШМ на ребре ввода определена т.н. валентная точка — вспомогательная вершина, на месте которой ребро как бы можно разорвать и вставить в разрыв атом так, что части разорванного ребра становятся продолжениями рёбер вставляемого атома.

В процессе обсуждения ШМ было предложено называть валентные точки точками ввода (Г. Тышов), а также отказаться от определения этих точек как вершин и считать само ребро допускающим ввод (Р. Блинов, В. Жаринов).

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

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

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

Принципы ШМ эргономически выгодно отличаются от принятого в блок-схемах порядка, при котором:

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

Иногда такую организацию блок-схем называют «анархической». Она критикуется рядом авторов, скажем, Б. Мейером .

По сути, в стандартах на БС и не существует чётких правил упорядочения элементов и подсхем. Тогда как ШМ, в общем-то, и есть система таких правил, только данная в математическом смысле не формально («что есть правильная схема»), а конструктивно («как построить правильную схему из правильной заготовки»).

Шампур-схема закономерно асимметрична. Это даёт возможность показать упорядоченность маршрутов по какому-то критерию. Не всегда такой критерий нужно или можно определить по смыслу схемы; в этом случае порядок м.б. произвольным или введён по какому-то абстрактному правилу. В то же время запрещение ступенек и загибов сужает возможности компоновки схемы в конкретном формате. Однако это можно понимать как плату за упорядоченность схемы.

Укладка схемы на плоскостиПравить

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

Непланарная схема с пересечениями (в терминах ШМ — примитив) разделяется веточными соединителями на блоки-единицы укладки — ветки — так, что из каждой пары пересекающихся цепей одна оказывается проходящей через подграф связи веток — петлю силуэта. Тем самым пересечение устраняется. Уложенная на плоскости аранж-схема в ШМ называется силуэтом. Силуэт можно и получать сразу — выводом из заготовки (ШМ-аксиомы). Только такой путь и допустим в ШМ; поэтому Паронджанов рекомендует мало-мальски сложный алгоритм визуализировать сразу как силуэт — чтобы избежать его вывода заново. Заготовка имеет исходно минимальноое число веток (две); определены операции добавления/удаления ветки в силуэт.

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

Силуэтная укладка есть физическое подразделение структуры маршрутов. Петля силуэта представляет связи веток как совокупность возвратных переходов с выходных соединителей на входные. В импер-смысле (для дракон-силуэта) это простые безусловные переходы. Достоинство их силуэтного употребления — в том, что передачи возможны не в произвольные места схемы, а лишь в заданные делением на ветки. Тем самым допускается goto, но также ограниченный — только на начала веток. Недостаток — в том, что переходы явные, и в терминах программирования дракон-силуэт м.б. представлен только на языках с явным БП (на ЯВУ с goto и на машинах с командой jmp-типа).

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

Атомарные и лианные структурыПравить

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

Все теоретически возможные структуры маршрутов не всегда можно получить только вложением. Имеются в виду структуры с БП — произвольным внутри программы (goto) и изнутри цикла на его начало/конец (т.н. break/continue-заменители). Для их представления Паронджановым было введено понятие лианной структуры маршрутов и операция пересадки лианы. В результате в техноязыке возможно представить структуры с заменителями, и только (если и в силуэте ограничиваться только пересадками лиан). В силуэте у ветки возможны и побочные выходы. Они получаются как в результате укладки примитива с пересечениями, так и при изначальном сочинении силуэта. Для создания побочных выходов в ШМ включена операция заземления лианы.

Очевидное достоинство такого подхода — техноязык практически нейтрален к структурности алгоритмов («войне языков» высокого уровня по поводу goto и заменителей). Если принять подход противников явных БП в ЯВУ — можно отказаться от операций с лианой и алгоритмизовать только атомарными структурами. Если принять подход сторонников — разрешить лианные операции и структуры.

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

Структурная алгоритмизация и шампур-методПравить

На техноязыке можно представить конструкции выбора и цикла Дейкстры для управления. Они описаны, в частности, в работе Ю.Г. Карпова, посвящённой той же проблеме, для решения которой предлагается техноязык - гарантоспособному программированию. Возможность и логической укладки, и отказа от явных БП в теле схемы даёт цикл Дейкстры как иная форма универсальной программы. Его использование возможно двумя путями:

• вывода тела дракон-схемы или его части как ЦД в рамках ШМ-правил (как варианта вложенного цикла);
• модификации метода для использования ЦД-организации схем, начиная с аксиом.

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

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

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

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

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

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

Важное преимущество ЦД как замены силуэта в том, что его ветви имеют один выход. Тем самым отпадает нужда в ШМ-операции «заземление лианы».

Кроме того, в рамках доказательного программирования Дейкстрой, Виртом и другими исследователями было показано, что в теле ЦД также не нужно употреблять явных БП, чтобы получить те же маршруты, что и с их использованием; соответственно не требуется операция «пересадка лианы».

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

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

Разметка схемПравить

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

• выделения в чисто текстовом языке управляющей части и замены её на маршрутный язык (синтаксис «слепышей»);
• разметки остальным содержанием текстового языка вершин и рёбер «слепыша».

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

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

Проще говоря, любой формальный ЯПЗ распадается на четыре подъязыка, один из которых играет интегрирующую роль. И нужно определить синтаксис каждого языка. Создатель техноязыка указывает на необходимость единых правил построения объектных имён, информативных и удобных для восприятия; для этого нужна и достаточная длина имени:

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

/1, с.163/. В то же время командная часть императивного подъязыка (так сказать, «имена действий») также должна иметь текстовый синтаксис. Нужен и синтаксис их сочетания в дракон-вершинах.

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

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

Во-вторых, для некоторых парадигм, не императивных по своей сути, возможность выделить управляющую часть вообще неопределённа. Это возможно для языков высокой абстракции, тяготеющих к декларационнности («ЧТО-формализации»). В частности, тех или иных языков спецификации программ/задач.

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

Преоодолеть недостатки частной гибридизации можно следующим образом:

• визуализировать в каждой составляющей текстового языка её структурную часть;
• рассматривать парадигмы «ЧТО-формализации» на предмет выделения их структурной части и нахождения структур графов, формально и эргономично представляющих эту часть;
• выявлять содержание, не отражённое в конкретном языке явно, и находить средства его выражения.

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

Реализация и применениеПравить

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

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

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

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

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

• Мейер Б. Почувствуй класс. - М.: НОУ «ИНТУИТ»; БИНОМ, 2011. - п. 7.7.
• Свердлов С.З. Языки программирования и методы трансляции. - СПб.: Питер, 2007. - Рис. 3.9.

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

• представление силуэта как конечного автомата с индексацией состояний именами (номерами) веток;
• представление силуэта как цикла Дейкстры с переходом также по дополнительному индексу.

Первый путь вытекает из структурной программной реализации КА, описанной, в частности, в работе:

• Поликарпова Н.И., Шалыто А.А. Автоматное программирование. - СПб.: Питер, 2010. - Гл. 2.

Здесь реализуется реагирующий (потенциально бесконечный) алгопроцесс вызова программ-автоматов. Второй путь м.б. обоснован реализацией ЦД, предложенной Ф.В. Ткачёвым для структурных прогязыков типа Оберон с бесконечным циклом в:

• Вирт Н. Алгоритмы и структуры данных. Новая версия для Оберона. – М:ДМК–Пресс, 2010. – Приложение С.

Такая реализация известна как "зацикленный выбор".

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

Ну, по поводу веток уже говорили - это конечный автомат, т.е. LOOP-CASE.

.

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

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

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

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

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

Впервые предложения по комплексной визуализации выдвинул Я. Романченко, в частности, здесь: http://forum.oberoncore.ru/viewtopic.php?p=17137#p17137 и здесь: http://forum.oberoncore.ru/viewtopic.php?p=17243#p17243. В настоящее время он планирует реализовать их для новой версии транслятора ДРОН. В целом гибридизация развивалась следующим образом:

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

В случае ДРОНа Романченко на этапе А) выбрал для остального содержания дракон-комментарии. И ввёл специальный формат текста. На этапе Б) Романченко предлагает представление структурной части деклар-знания как дерева типов; атрибутивная часть предлагается в виде таблиц объявления.

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

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

Другая технология реализована Д. В. Барановским в его приложениях разработки и документирования программ для микроконтроллеров. Здесь применена версия импер-граф-языка с минимальным алфавитом и некоторыми оригинальными решениями по структуре шампур-схем и формату их разметки.

Для визуализации произвольных алгоритмов удобнее пользоваться разработками Э. Ильченко и С. Митькина. Первая представляет модуль расширения редактора OpenOffice.org Draw для построения шампур-схем с графикой вершин из стандартных автофигур. Вторая — автономное приложение на Tcl для построения шампур-схем и выдачи их текстового описания (в новых версиях также поддерживает гибридное программирование на некоторых ЯВУ).

Вообще то, что говорится сейчас в статье о развитии ДРАКОНа, его распространении, носит существенно «трибунный» характер. Замечу — это отнюдь не упрёк в несоответствии ВП:ЧНЯВ. Просто если ДРАКОН как языковое средство эргономизации программирования БЦВМ по технологии ГРАФИТ-ФЛОКС существует порядка четверти века, то как средство предполагаемой визуализации маршрутной части инфор-моделей произвольных задач и предметных областей — примерно вдвое меньше (мы можем видеть первые публикации на тему такого развития во второй половине 1990-х годов). Но ещё важнее — что такое обобщение требовало (и требует) соответствующей теории формализации произвольной деятельности. Которая в принципе сейчас только вырабатывается. И возможно, опыт развития ДРАКОНа даст здесь что-то. Но развитие д.б. не только эмпирическим — «применим тут, там и обобщим опыт» — но и теоретическим.

В целом можно сказать, что предмет статьи ещё недавно считался ВП:ОРИСС (а где-то - даже и ВП:МАРГ :)), как можно понять из обсуждения её удаления/восстановления. В итоге это не было признано, и было решено оставить статью. Что, IMHO, хорошо (хотя из всего мной выше написанного, думаю, понятно, что я не являюсь "безоглядным" сторонником автора ;)). В то же время предмет статьи относительно новый по сути. И статья как ВП-допустимая (как я это пока понимаю) должна в итоге развития интегрировать предмет в систему понятий и представлений, либо давно установившихся, либо недавно введённых вне ВП. И также освещать предмет спокойно, показывая разные возможные позиции. И показать, что в сущности именно ДРАКОН не является чем-то "маргинальным" - это закономерное применение положений инженерной психологии к документам. VladZharinov 19:18, 7 января 2012 (UTC)Ответить[ответить]

Новое выставление на удаление. И полная переработка статьиПравить

28 сентября 2012 года администратор Bezik выставил статью на удаление. После этого статья ДРАКОН была полностью переработана под руководством администратора EvalnCat.

Думаю, что статья достаточно переработана для подведения итога по ней. Я не буду подводить итог самостоятельно, так как принимал непосредственное участие в переработке - это должен сделать незаинтересованный администратор или ПИ. Откладывать сроки дальше смысла нет. --EvaInCat 19:10, 27 ноября 2012 (UTC)

--Владимир Паронджанов 14:42, 4 декабря 2012 (UTC)Ответить[ответить]

Не сметь !Править

Отличная статья. 95.153.191.183 21:03, 11 декабря 2012 (UTC) Алхас СадиковаОтветить[ответить]

PEP-8Править

Ах вот оно как! Оказывается PEP-0008 -- это новый язык программирования (сарказм). --Freezeman 17:13, 16 февраля 2013 (UTC)Ответить[ответить]

Окулова Л.П. как АИПравить

Окулова Л. П. Проектирование образовательного процесса в соответствии с требованиями педагогической эргономики.

Складывается впечатление, что текст её статьи основан на информации от разработчика ДРАКОНа, а не на независимом анализе языка. Стоит ли рассматривать её статью как АИ? Насколько я смог найти, данная статья не была опубликована в авторитетном научном журнале. Поправьте, если не прав. --Freezeman 15:25, 17 февраля 2013 (UTC)Ответить[ответить]

• Статья кандидата педагогических наук доцента Л. П. Окуловой опубликована в авторитетном источнике — периодически издаваемом сборнике трудов международных научных конференций (Окулова Л. П. Проектирование образовательного процесса в соответствии с требованиями педагогической эргономики // Вестник. Наука и практика. Материалы конференции «Инновации и научные исследования, а также их применение на практике \ Innowacje i badania naukowe, jak rowniez ich zastosowanie w praktyce. — 29.05.2012- 31.05.2012. Варшава \ Warszaw».). Сборник называется по-русски «Вестник. Наука и практика», по-польски «Zwiastowac. Nauki i praktyki». Это легко проверить. Открыв ссылку, в самом верху написано название сборника и по-русски, и по-польски. --Владимир Паронджанов 16:14, 3 марта 2013 (UTC)Ответить[ответить]

Сообщаю дополнительные сведения:

• Материалы научных конференций за 2012 год. В этом году (в данной серии) было организовано 11 конференций. На :одной из них делала доклад Л. П. Окулова. См. следующую строку. --Владимир Паронджанов 16:14, 3 марта 2013 (UTC)Ответить[ответить]
• Материалы конференции «Инновации и научные исследования, а также их применение на практике \ Innowacje i :badania naukowe, jak rowniez ich zastosowanie w praktyce. — 29.05.2012- 31.05.2012. Варшава \ Warszaw». По этой ссылке можно найти название доклада :Окуловой — см. Секция 13. Педагогические науки --Владимир Паронджанов 16:14, 3 марта 2013 (UTC)Ответить[ответить]

Зачем вы мне дали три ссылки на один и тот-же сайт? Да ладно, я уже посмотрел статистику в индексе цитируемости. Однако, ее мнение в данном вопросе не может считаться авторитетным, т.к. она не является специалистом в данной области. Почему название ДРАКОН не вынесено в заголовок статьи? Почему ДРАКОН не сравнивается с, например, YAML, XML и т.п.? --Freezeman 20:41, 4 апреля 2013 (UTC)Ответить[ответить]

Видимость переменныхПравить

Есть ли в языке такое понятие, как видимость переменных? Существуют ли в структуре языка механизмы защиты на этот случай для больших проектов? --Freezeman 20:53, 4 апреля 2013 (UTC)Ответить[ответить]

Стиль статьиПравить

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

1. убрать ВСЕ фразы на тему "только в нашем йогурте самые правильные бактерии", за исключением одной (возможно, ее стоит несколько детализировать):

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

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

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

   а оставить только описание самих особенностей. Т.е. например:

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

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

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

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

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

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

93.125.42.74 06:53, 1 июня 2013 (UTC)Ответить[ответить]

• Что-ж, это хорошее "техзадание" по приведению статьи к стандартам Википедии --be-nt-all 09:31, 1 июня 2013 (UTC)Ответить[ответить]

Ошибки уважаемого участникаПравить

Уважаемый участник Xqt 14:18, 26 февраля 2015‎ произвел правку статьи ДРАКОН, удалил примерно 9 килобайт и при этом допустил ряд ошибок.

• Первая ошибка. До правки в разделе Примечания было 9 ссылок на автора "Окулова". После правки стало 11 ссылок, причем они разбиты на две изолированные части: 8 ссылок и 3 ссылки. Откуда взялись две лишние ссылки на "Окулова"? Это явная ошибка.

• Вторая ошибка. До правки в разделе Примечания было 5 ссылок на автора "Титова". После правки стало 6 ссылок. Откуда взялась лишняя ссылка?

Ответ прост. До правки в тексте "существенно ослабить недостатки блок-схем" ссылка [13] указывала на автора "Аллашев". После правки эта же ссылка указывает на автора "Титова".

Отсюда я делаю предположительный вывод. Уважаемый участник Xqt использовал для правки бот phabricator:T90422 rubin16. Этот бот уже несколько раз ошибался при правке статьи ДРАКОН. Поэтому я попросил уважаемого участника rubin16 запретить боту править статью ДРАКОН.

• Третья ошибка. До правки в разделе Примечания было 9 ссылок на автора "Аллашев". После правки стало 8 ссылок. Почему исчезла одна ссылка?

Ответ прост. Ошибка бота phabricator:T90422 rubin16 привела к тому, что ссылка на "Аллашев" парадоксальным образом превратилась в ссылку на "Титова".

Почему ошибается бот phabricator:T90422? Потому что статья ДРАКОН очень большая (240 килобайт), а в разделе Примечания свыше 200 ссылок на литературу. По-видимому, бот phabricator:T90422 НЕ РАССЧИТАН на работу с такими большими объемами.

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

• Нечаянная, но очень неприятная ошибка. Удален раздел статьи "Нотация для моделирования потоков работ". Я думаю, что эта последняя ошибка сделана нечаянно, по недоразумению.

Мне кажется, что правку уважаемого участника Xqt 14:18, 26 февраля 2015‎ надо либо откатить, либо сильно изменить. Спасибо за внимание.

--Владимир Паронджанов 07:52, 28 февраля 2015 (UTC)Ответить[ответить]

Кажется, я случайно попал на ту версию, как я пытался исправить шаблон . Извините! Xqt 16:49, 2 марта 2015 (UTC)Ответить[ответить]

Чистка сносокПравить

Проводится первичная чистка сносок в соответствии с правилом ВП:СНОСКИ («Сноска — это ссылка вне основного текста на источник информации, использованный при написании статьи, или комментарий»). — Ле Лой (kf8) 14:08, 15 марта 2015 (UTC)Ответить[ответить]

КарточкаПравить

• Ссылка http://store.oberoncore.ru/lib/paper/grafit_A4.pdf не содержит упоминания ЯП ДРАКОН. Удалена.
• Ссылка http://citforum.ru/programming/prg96/85.shtml не содержит упоминания ЯП ДРАКОН. Удалена.
• Ссылка http://www.keldysh.ru/papers/2008/prep29/prep2008_29.html не содержит упоминания ЯП ДРАКОН. Удалена.
• Публикация, призванная подтверждать влияние R-языка на ДРАКОН (Вельбицкий И. В., Ходаковский В. Н., Шолмов Л. И. Технологический комплекс производства программ на машинах ЕС ЭВМ и БЭСМ-6 ), опубликована в 1980 году, то есть за 6 лет до начала разработки этого языка. Удалена.
• Межгосударственный стандарт ГОСТ не может подтверждать влияние R-языка на ДРАКОН. Удалён.

Подтверждением для упомянутых утверждений должны быть источники по теме статьи, содержащие соответствующие сведения, приведённые ссылки таковых не содержат. — Ле Лой (kf8) 14:08, 15 марта 2015 (UTC)Ответить[ответить]

Вы, конечно, правы. Попробую сообщить то, что мне известно. По поводу языков Прол2, Диполь и Лакс приведу цитату из "Паронджанов В. Д. Графический синтаксис языка ДРАКОН. — 1995. — Т. 3. — С. 45—62. — (Программирование)".

При создании бортовых и наземных программ орбитального корабля "Буран" использовались языки Прол2, Диполь, Пси Фортран, Лакс, Ассемблер и др. (первые три разработаны в ИПМ РАН). Обобщение опыта работы с этими языками привело к формированию концепции графического языка дракон... Дракон разрабатывается в НПО автоматики и приборостроения совместно с ИПМ РАН и предназначен для создания программ реального времени, а также для обучения программированию

— С. 45

. --Владимир Паронджанов 17:37, 15 марта 2015 (UTC)Ответить[ответить]

Отлично, поставил их как сноски, спасибо. — Ле Лой (kf8) 17:41, 15 марта 2015 (UTC)Ответить[ответить]

По поводу графит-флокс — это технология программирования, основанная на языке ДРАКОН. Вот цитата:

Для управления бортовыми системами и проведения испытаний применяется технология разработки алгоритмов и программ "Графит-Флокс", основанная на языке ДРАКОН... Применение при программировании языков высокого уровня U и ДРАКОН (технология Графит-Флокс) в значительной степени сокращает количество ошибок программистов.

— Морозов В. В., Трунов Ю. В., Комиссаров А. И., Пак Е. А., Жучков А. Г., Дишель В.Д, Залихина Е. Е., Паронджанов В. Д. Система управления межорбитального космического буксира «Фрегат» \ Вестник ФГУП «НПО им. С. А. Лавочкина», 2014, № 1. — С. 16-25.

--Владимир Паронджанов 18:14, 15 марта 2015 (UTC)Ответить[ответить]

Готово. — Ле Лой (kf8) 18:26, 15 марта 2015 (UTC)Ответить[ответить]

По поводу R-технологии и SDL. Нашел источник, где они в связи с ДРАКОНом. Заголовок "От редакции". Это редакционное предисловие к моей статье. Вот цитата:

В 1988 г. в США вышла книга Н.К. Шу под названием «Визуальное программирование». Термин прижился и стал общепринятым. Одним из пионеров нового направления был киевский ученый И. В. Вельбицкий, еще двадцать лет назад выступивший с идеей Р-технологии, которая явилась одной из первых ласточек визуализации в мире компьютерных программ. С тех пор было придумано немало новых визуальных языков: SDL, FPL....

В помещенной ниже статье предлагается осуществить поэтапную визуализацию школьного курса информатики с помощью визуального языка ДРАКОН. При этом используется оригинальный метод формализации блок-схем. Если обычная блок-схема всего лишь "картинка", непригодная для ввода в компьютер и к тому же зачастую неряшливо оформленная, то ДРАКОН-схема — эстетически безупречная «выполняемая графика», т.е. компьютерная программа в строгом смысле слова. Разумеется, это далеко не первая попытка формализации блок-схем — достаточно вспомнить язык SDL, проект Cados, пакет Lab View.... Однако ДРАКОН выгодно отличается более высокими когнитивно-эргономическими и дидактическими свойствами, что особенно важно в условиях школы. .

— От редакции. предисловие к статье Паронджанов В.Д. Каким будет школьный алгоритмческий язык XXI века? // Информатика и образование, 1994, №3. — С. 78–91.

--Владимир Паронджанов 08:43, 17 марта 2015 (UTC)Ответить[ответить]

Проблема в том, что здесь единственная указанная связь - это то, что и то, и другое относится к визуальному программированию. В целом, об эволюции ДРАКОНа из Р-схем в приведённой цитате не сказано. Р-схемы - это один из случаев визуальной технологии, а непосредственная связь их с ДРАКОНом из источника неясна. Я думаю, в статье достаточно упомянуть Р-схемы и перечислить отличия ДРАКОНа от них, а сами Р-схемы должны описываться в отдельной статье. Если ДРАКОН напрямую базировался на Р-схемах, думаю, это вполне можно дать дать и по Вашим словам в какой-нибудь рецензированной книге - лучше всего с атрибуцией "по воспоминаниям разработчика..." в теле статьи, а в карточке - и без атрибуции. Я думаю так. Dr Bug (Владимир² Медейко) 16:54, 17 марта 2015 (UTC)Ответить[ответить]

Хорошо, забудем Р-схемы. А язык SDL? В цитате сказано: «Разумеется, это далеко не первая попытка формализации блок-схем — достаточно вспомнить язык SDL… Однако ДРАКОН выгодно отличается…». Разве это не является основанием, чтобы оставить в карточке SDL? Как Вы считаете? --Владимир Паронджанов 18:00, 17 марта 2015 (UTC)Ответить[ответить]

Дракон не язык програмированияПравить

А разве язык Дракон является вообще языком программирования? Насколько можно судить по примерам в данной статье дракон полностью зависим от своего "второго языка", он едва дотягивает до уровня регулярного языка (тип 3 по иерархии Хомского). --Rst256 19:21, 19 октября 2015 (UTC)Ответить[ответить]

• Уважаемый участник Rst256! Информация в Википедии должна быть проверяемой на основании опубликованных авторитетных источников. Если это не так (как в Вашем критическом замечании), это называется оригинальным исследованием — см. ВП:ОРИСС. Ни в одном из опубликованных авторитетных источников не утверждается, что ДРАКОН не является языком программирования. Тем не менее, мне кажется, что Ваше замечание можно поместить в статью в раздел ДРАКОН#Критика.

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

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

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

• Уважаемый участник Rst256! Благодарю Вас за интерес к языку ДРАКОН. Более подробную информацию Вы можете (если захотите) почерпнуть из книг, которые можно бесплатно скачать на официальном сайте языка ДРАКОН. Спасибо за внимание. --Владимир Паронджанов 07:04, 2 июня 2016 (UTC)Ответить[ответить]

Отчёт о переработке статьиПравить

• Источник «Материалы XXV Международной конференции „Применение новых технологий в образовании“» удалён из статьи по причине неавторитетности и цитирования статьи «Графический синтаксис языка ДРАКОН». — Ле Лой 10:18, 4 июня 2016 (UTC)Ответить[ответить]
• Источник История создания языка «ДРАКОН», размещённый на сайте Российского трансгуманистического движения, удалён ввиду неавторитетности (РТД не является авторитетным в теме статьи). — Ле Лой 10:22, 4 июня 2016 (UTC)Ответить[ответить]
  • Частично поискал. Выглядит словно накопированно целыми предложениями из разных других источников. Ссылок нет, что правда, а что примешано не отделить. --Hrum-Hrum (обс) 11:45, 14 июня 2016 (UTC)Ответить[ответить]
• Источник-слайд о ГРАФИТ-ФЛОКСе удалён ввиду неавторитетности и отсутствия в нём сведений, которые он предположительно подтверждает. — Ле Лой 10:30, 4 июня 2016 (UTC)Ответить[ответить]
• Сноски переименованы для упрощения восприятия. Параллельно исправлено несколько конфликтов и внесены следующие изменения:
  • Удалена ссылка, подтверждающая текст «В этом состоит одно из ключевых преимуществ, поскольку ДРАКОН можно использовать как язык взаимопонимания между непрограммистами и программистами, между не программирующим большинством специалистов и программирующим меньшинством» ввиду отсутствия в источнике autogenerated12 (это имя было присвоено сразу двум публикациям — Аллашева и Окуловой, ни в одной не обнаружено).
  • «Через 10 лет на базе ДРАКОНа была построена автоматизированная Технология разработки алгоритмов и программ» — исправлено на 11 в соответствии с источником.
  • «руководство Пилюгинского центра приняло решение об использовании ДРАКОН-технологии во всех последующих проектах» — исправлено на «в последующих проектах» в соответствии с источником. — Ле Лой 11:05, 4 июня 2016 (UTC)Ответить[ответить]
• Из текста удалена ссылка на файловое хранилище, не являющееся авторитетным источником. Ссылка уже имеется в соответствующем разделе. — Ле Лой 11:48, 4 июня 2016 (UTC)Ответить[ответить]
• Из фрагмента Аналогом семейства языков ДРАКОН является «R-технология производства программ, или технология двумерного программирования»<ref>Вельбицкий И. В., Ходаковский В. Н., Шолмов Л. И. Технологический комплекс производства программ на машинах ЕС ЭВМ и БЭСМ-6. — М.: Статистика, 1980. — 263с. — С. 5.</ref>, созданная в [[Институт кибернетики имени В. М. Глушкова|Институте кибернетики имени В. М. Глушкова]]<ref>Стогний А. А. Предисловие. // Вельбицкий И. В., Ходаковский В. Н., Шолмов Л. И. Технологический комплекс производства программ на машинах ЕС ЭВМ и БЭСМ-6. — М.: Статистика, 1980. — 263с. — С. 3.</ref>, причём графика дракон-схем в ДРАКОН-семействе служит аналогом графики Р-схем<ref name=gost19-005-85>Межгосударственный стандарт ГОСТ 19.005-85. Единая система программной документации. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения. Unified system for program documentation. R-charts. Graphical chart symbols and conventions for charting. 1985.</ref> в R-технологии. удалены ссылки на публикацию 1980 года, которая по очевидным причинам не может описывать язык ДРАКОН, созданный после её публикации, а также ссылка на ГОСТ, не содержащая заявленного утверждения. — Ле Лой 12:37, 4 июня 2016 (UTC)Ответить[ответить]
• Информация про резервы мозга и т. п. в источнике не найдена, сам источник (Материалы научно-методической конференции) неавторитен. — Ле Лой 12:47, 4 июня 2016 (UTC)Ответить[ответить]
• Фраза «По мнению кандидата технических наук, доцента Евгения Пышкина, изучение структурного программирования исключительно как инструмента разработки текстов программ, построенных на базе основной «структурной триады» (линейная последовательность, ветвление и цикл), является недостаточным и, по сути дела, сводит на нет анализ преимуществ структурного подхода» во-первых скопирована из источника, а во-вторых, не имеет смысла. Изучение чего-либо не может сводить на нет анализ чего-либо ещё. Фраза закомментирована. — Ле Лой 13:12, 4 июня 2016 (UTC)Ответить[ответить]
• Фраза о непротиворечивости критериев к ПО (понимаемости и пр) удалена ввиду тривиальности. Комментарий с цитатой из ГОСТа удалён по причине тривиальности определения «понимаемости программы». — Ле Лой 13:31, 4 июня 2016 (UTC)Ответить[ответить]
• Фраза «улучшение понимаемости графического представления алгоритмов» сокращена до «упрощение визуального восприятия алгоритмов». — Ле Лой 13:31, 4 июня 2016 (UTC)Ответить[ответить]
• Ссылки на материалы студенческой конференции и учебник «Алгоритмы в гистологии» не являются авторитетными источниками и удалены вместе с фразой «говорят, что дракон-схемы удовлетворяют „критерию сверхвысокой понимаемости“», так как понятие «критерий сверхвысокой понимаемости» не определено, а подтверждающие это источники неавторитетны. — Ле Лой 13:31, 4 июня 2016 (UTC)Ответить[ответить]
• Фраза «Это обстоятельство ставит непреодолимый барьер для непрограммистов, то есть специалистов, работа которых связана с алгоритмами, но которые не имеют резерва времени, чтобы научиться выражать свои профессиональные знания в форме алгоритмов и программ» сокращена до «особенно людьми, не занимающимися программированием» для устранения нарушения авторских прав Величко. — Ле Лой 13:53, 4 июня 2016 (UTC)Ответить[ответить]
• Ссылка на публикацию «Язык и технология автоматного программирования» удалена ввиду отсутствия в ней заявленного текста (по всей статье). ДРАКОН упомянут там лишь один раз в заключении, причём в критической фразе «Эргономические методы, применяемые в графическом языке Дракон [10], существенно улучшают восприятие программы, однако не могут уменьшить ее сложность». — Ле Лой 13:53, 4 июня 2016 (UTC)Ответить[ответить]

Статья написанная по большей части по источникам автора предмета статьи.Править

Ужас. Алёна — говор 09:13, 7 августа 2020 (UTC)Ответить[ответить]

ПочемуПравить

[1] этот источник не выглядит явно авторитетным, а по нему даётся оценка эффективности дракон-схем. Алёна — говор 13:32, 7 августа 2020 (UTC)Ответить[ответить]

МаргПравить

«Разработка нотации драгон включала когнитивно-эргономического подход к проектированию»

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

«за счет использования когнитивно-эргономического подхода к проектированию (синтаксиса и семантики) языка добиться значительного улучшения качества программного обеспечения по критерию «понятность алгоритмов и программ»»

Невероятно. Алёна — говор 14:48, 7 августа 2020 (UTC)Ответить[ответить]

Ошибочное удаление файлаПравить

 

Кадр из фильма «Жирограф и ДРАКОН Пилюгина»

Алёна Синичкина удалила данный файл как нарушающий авторские права.

Это не так. Я, Владимир Паронджанов, создал этот файл в редакторе CorelDraw и разместил его в Wikimedia с соблюдением всех процедур и правил Wikimedia. Следовательно, я являюсь правообладателем этого файла.

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

Фильм «Жирограф и ДРАКОН Пилюгина» создан Телестудией Роскосмоса. Данный файл необходим в статье, так как он подтверждает, что язык ДРАКОН действительно создан в одном из предприятий Роскосмоса — Научно-производственном центре автоматики и приборостроения имени академика Н.А. Пилюгина.

К данному файлу (иллюстрации) в статье относится следующий текст:

Во время работы над «Бураном» был придуман язык технических символов — ДРАКОН: «Дружелюбный русский алгоритмический, который обеспечивает наглядность». Он и стал своеобразным инструментом взаимопонимания в пилюгинском коллективе инженеров и конструкторов. Разработки академика Пилюгина и сегодня применяются в современной ракетной технике. Тяжелые «Протоны» уходят в небо с его системой управления, а грозные ракетные комплексы «Тополь-М» обеспечивают оборону страны.

— Документальный видеофильм «Жирограф и ДРАКОН Пилюгина»

Я восстановил в статье удаленный файл, но, к сожалению, Алёна Синичкина повторно удалила данный файл из статьи.

Не желая вступать в войну правок, прошу администратора Википедии восстановить данный файл и принять решение по остальным правкам Алены Синичкиной.

Владимир Паронджанов (обс.) 16:52, 8 августа 2020 (UTC)Ответить[ответить]

• Я не администратор, но у меня есть вопрос: вы утверждаете, что файл создали сами в CorelDraw, но в описании указал "Кадр из фильма "Жирограф и ДРАКОН Пилюгина"" - так это кадр из фильма или нет?— Saramag (обс.) 05:32, 9 августа 2020 (UTC)Ответить[ответить]
  • Saramag, спасибо за вопрос. Да, это кадр из фильма. В редакторе CorelDraw я создал точную копию кадра из фильма. Вы можете это проверить, посмотрев фильм http://www.tvroscosmos.ru/3559/ в момент времени 3:07 — 3:12 Владимир Паронджанов (обс.) 09:07, 9 августа 2020 (UTC)Ответить[ответить]
    • В таком случае вы нарушили ВП:АП - копия без разрешения владельца авторского права является нарушением.— Saramag (обс.) 11:02, 9 августа 2020 (UTC)Ответить[ответить]
      • Вы говорите о фотокопии. Но здесь нет фотокопии. Здесь есть собственная работа. Цитирую:

[Рекомендации по указанию источника] Если произведение выполнено непосредственно участником русской Википедии и загружено им же, то в качестве источника принимается текстовое описание собственная работа и соответствующий шаблон-лицензия группы -self или -user.

Владимир Паронджанов (обс.) 12:54, 9 августа 2020 (UTC)Ответить[ответить]

• Оно слишком простое чтобы быть защищаемым вроде. — Ailbeve (обс.) 13:00, 9 августа 2020 (UTC)Ответить[ответить]
  • Перерисовывать кадр из фильма и назвать его "кадром из фильма" - это не самостоятельная работа.— Saramag (обс.) 13:13, 9 августа 2020 (UTC)Ответить[ответить]
    • Суть в том что если я точно перерисую рисунок защищённый АП то он будет защищён теми же АП. Алёна — говор 13:18, 9 августа 2020 (UTC)Ответить[ответить]
      • Википедия живет по правилам. Я привел правило Википедии, которое относится к делу. Два последних замечания не подкреплены ссылками на правила Википедии. --Владимир Паронджанов (обс.) 15:18, 9 августа 2020 (UTC)Ответить[ответить]
        • Чтобы выяснить истину в данной дискуссии, я задал вопрос на форуме Википедии по авторскому праву. --Владимир Паронджанов (обс.) 05:42, 10 августа 2020 (UTC)Ответить[ответить]

Администратор и бюрократ Butko (обс.) дал ответ на форуме по авторскому праву. Цитирую:

Я думаю, что это тривиальное изображение, которое не защищается авторским правом. См. commons:Template:PD-text — Butko (обс.) 20:58, 13 августа 2020 (UTC)

--Владимир Паронджанов (обс.) 07:59, 27 августа 2020 (UTC)Ответить[ответить]

• Оно тривиально, но абсолютно не нужно. В статьи не вставляют картинки с повторённым на них ещё раз первым предложением преамбулы. — Ле Лой 10:12, 27 августа 2020 (UTC)Ответить[ответить]

Значимость файла для статьи?Править

Всё что есть в файле есть и в статье в точно в таком же виде. Алёна — говор 13:16, 9 августа 2020 (UTC)Ответить[ответить]

• Это не так. Картинка воспринимается быстрее и легче, чем текст.

Согласно ВП:Иллюстрирование "В Википедии приветствуется размещение изображений, видео и звуков на страницах статей". Картинка с расшифровкой слова ДРАКОН воспринимается легко и без усилий.

 

Кадр из фильма «Жирограф и ДРАКОН Пилюгина»

--Владимир Паронджанов (обс.) 06:13, 10 августа 2020 (UTC)Ответить[ответить]

• • На самом деле на картинке помимо расшифровки ещё куча мусорной информации, что в купе со нестандартным сочетанием цветов лично меня вводит в диссонанс.— Saramag (обс.) 15:05, 10 августа 2020 (UTC)Ответить[ответить]

Одно слово пропущено в аббревиатуреПравить

Исходя из расшифровки аббревиатуры, более правильным вариантом написания был бы «ДРАЯКОН». 5.44.168.86 09:21, 16 июля 2022 (UTC)Ответить[ответить]