Блок-схемы алгоритмов по ГОСТ 19.701-90
ГОСТ 19.701-90 является действующим, но морально устарел; он не годится для записи алгоритмов, так как не обеспечивает удобочитаемость сложных алгоритмов. Это объясняется тем, что концепция стандарта отстала от жизни и построена без учета идей когнитивной эргономики.
Предлагаю:
— для записи алгоритмов создать новый стандарт, основанный на визуальном алгоритмическом языке ДРАКОН;
— удалить из ГОСТ 19.701-90 упоминание об алгоритмах .
Чтобы обосновать предложения, я написал несколько книг. Под спойлером указаны последние книги:
(2021) Паронджанов В. Д. Алгоритмические языки и программирование: ДРАКОН : учебное пособие для вузов. — Москва : Издательство Юрайт, 2021. — 436 с. — (Высшее образование).
(2019) Паронджанов В. Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М., 2019. — 374 с. — Иллюстраций: 195.
(2012, 2014, 2016) Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с.
(2017) Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины. Клиническое мышление высокой точности и безопасность пациентов. / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.
Статья содержит критику стандарта ГОСТ 19.701-90 и обоснование необходимости создания нового стандарта для представления алгоритмов.
Желающие могут посмотреть две статьи на Хабре по языку ДРАКОН: здесь и здесь.
Дракон-схема алгоритма
Рис. 0. Пример дракон-схемы
На Рис. 0 показана дракон-схема, или дракон-алгоритм.
Дракон-схема есть упорядоченная, правильно построенная блок-схема, наглядно показывающая все маршруты алгоритма.
На Рис. 0 хорошо видны особенности дракон-алгоритма:
— Иконы Заголовок и Конец находятся на единой вертикали, которая называется шампур. По шампуру проходит главный (наиболее благоприятный) маршрут алгоритма.
— Все вертикали (маршруты алгоритма) упорядочены слева направо по принципу "чем правее, тем хуже".
— Шампур рисуют жирной (highlighted) линией.
— Все иконы и соединительные линии расположены справа от шампура. Шампур занимает крайнюю левую вертикаль.
— Пересечения линий запрещены.
— Икона Заголовок всегда находится на фиксированном месте — вверху алгоритма.
Эргономичность — это набор правил
Наша ближайшая цель — разъяснить, что эргономичность есть набор правил, которым должны подчиняться зрительные образы алгоритма, представленные на бумаге или экране. Возьмем за основу зрительные образы языка ДРАКОН, построенные из икон и их комбинаций.
Рассмотрим ряд правил ДРАКОНа и на конкретных примерах покажем, что в блок-схемах по ГОСТ 19.701-90 правила систематически нарушаются, а в дракон-схемах — строго соблюдаются.
Правило шампура
На первое место следует поставить правило шампура: в схеме необходимо иметь шампур. Он создает систему отсчета, в которой проектируется графическая схема алгоритма.
Ниже на многих примерах будут продемонстрированы типичные ошибки блок-схем:
— нет шампура;
— разрыв шампура.
Схема должна быть лаконичной
Схема алгоритма должна содержать лишь те элементы, которые необходимы для сообщения читателю существенной информации, точного понимания ее смысла и стимулирования правильных решений и разумных действий. Пустые украшения, избыточные, затемняющие детали должны быть удалены из схемы.
Рис. 1 (слева). Плохая схема. Недостатки: слишком много изгибов; имеются паразитные элементы
Рис. 2 (справа). Хорошая (эргономичная) схема. Она нарисована по правилам языка ДРАКОН
Следует избегать неоправданных изгибов соединительных линий
Существуют вредные мелочи, которые затрудняют понимание схемы. Одна из них — неоправданные изгибы соединительных линий.
Сравним две схемы на Рис. 1 и 2. На Рис. 1 показана обычная блок-схема, заимствованная из книги сотрудников IBM. На Рис. 2 изображена эквивалентная дракон-схема.
Рисунки позволяют выявить различия между неприглядной блок-схемой и красивой дракон-схемой. С точки зрения правил удобочитаемости, блок-схема на Рис. 1 имеет следующие недостатки:
— неоправданно большое число изгибов линий (в блок-схеме 12 изгибов, а в дракон-схеме — только 4);
— большое число паразитных элементов: 14 стрелок и 3 кружка, которые в дракон-схеме отсутствуют (поскольку они совершенно не нужны и представляют собой визуальные помехи, затемняющие суть дела).
Мы рассмотрели два эргономических правила (правило лаконичности и правило минимизации изгибов) и убедились, что в дракон-схеме они строго соблюдаются, а в блок-схеме грубо нарушены.
Сравнительный анализ двух схем
Обратимся снова к Рис. 1 и 2. Мы сделали лишь первый шаг к устранению графических недочетов. На Рис. 1 осталось еще немало огрехов, которые необходимо выявить и исправить.
Итак, продолжим наш критический анализ. Блок-схема на Рис. 1 имеет следующие недостатки:
— для обозначения развилки используется ромб, который занимает слишком много места. Ромб не позволяет поместить внутри необходимое количество удобочитаемого текста, состоящего из строк равной длины. В дракон-схеме верхний и нижний углы ромба отрезаны, поэтому схема становится компактной и удобной как для записи текста, так и для чтения;
— функционально однородные иконы Д, Е, Ж, И хаотично разбросаны по всей площади чертежа, занимая три разных горизонтальных уровня (что запутывает читателя). В дракон-схеме они расположены на одном уровне, что служит для читателя подсказкой об их функциональной однородности;
— ромбы имеют выход влево, что разрушает шампур и не позволяет применить правило главного маршрута. В дракон-схеме выход влево не допускается;
— икона Д и ее вертикаль расположены слева от шампура (в дракон-схеме это запрещено);
— ниже икон Ж и И находится три уровня горизонтальных линий, которые имеют паразитный характер. В дракон-схеме три уровня сведены в одну линию, что делает схему более наглядной и компактной.
Каждое из этих улучшений является незначительным и не делает погоды. Но когда мелкие улучшения повторяются многократно и становятся массовыми, ситуация может измениться. Количество переходит в качество. В этом случае облегчение умственного труда может стать значительным.
Критика блок-схем алгоритмов по ГОСТ 19.701-90
Цивилизация не может жить без чертежей, как не может жить и без алгоритмов. Схемы алгоритмов очень важны для понимания секретов и тайн современного производства и управления. Однако многие преподаватели и разработчики алгоритмов создают неприглядные и путаные блок-схемы, в которых трудно разобраться. Иногда их даже называют «мусорными» блок-схемами, потому что хитросплетения блоков, соединенные хаосом петляющих линий, больше напоминают кучу мусора, нежели регулярную структуру.
Образчик подобного мусора представлен на рис. 3. Этот «мусорный» алгоритм можно вылечить и превратить в изящную дракон-схему (рис. 4). Сравним: что было и что стало.
Рис. 3 (слева). Плохая схема. Такие схемы часто рисуют многие уважаемые ученые, забывающие об эргономике
Рис. 4 (справа). Хорошая (эргономичная) схема. Она нарисована по правилам языка ДРАКОН
Схема на рис. 3 имеет много изъянов:
— слева от иконы Ж есть пересечение линий (в дракон-схеме пересечения запрещены);
— возле иконы Е имеется линия под углом 45° (в дракон-схеме наклонные линии не допускаются);
— иконы Д, Е и Ж имеют более одного входа (в дракон-схеме это запрещено);
— иконы В, Д, Е, Ж имеют входы сбоку, что придает схеме неряшливый вид. В дракон-схеме вход разрешается только сверху, что упорядочивает алгоритм и создает в нем четкую ориентацию «сверху вниз»;
— отсутствует шампур, так как выход иконы Заголовок и вход иконы Конец не лежат на одной вертикали. Исчезновение шампура означает, что в схеме отсутствует зрительный остов, художественно-композиционная главная вертикаль. Тем самым уничтожается основа для выделения главного маршрута.
Блок-схема на рис. 3, как и схема на Рис. 1, по всем параметрам проигрывает дракон-схеме. Мы убедились, что алгоритмическая красота достигается благодаря совокупному действию многих правил, каждое из которых, взятое по отдельности, выглядит скромным и будничным.
Разрыв шампура — серьезная ошибка
Разорванный шампур искажает зрительный образ схемы и может повлечь за собой неприятности. Между тем такая схема не только не осуждалась, а наоборот, в свое время была рекомендована стандартом ANSI (Американский национальный институт стандартов).
Рис. 5 (слева). Плохая схема. В ней много эргономических ошибок, что затрудняет понимание алгоритма
Рис. 6 (справа). Хорошая (эргономичная) схема. Она нарисована по правилам языка ДРАКОН
На рис. 5 представлена схема, взятая из источника, где она характеризуется как «стандартная блок-схема ANSI». Сравнение этой схемы с эквивалентной дракон-схемой на Рис. 6 позволяет выявить различные дефекты:
— ниже иконы G имеется разрыв шампура (нарушено правило, согласно которому один из путей, идущих от входа к выходу, должен проходить по главной вертикали);
— икона G имеет два входа (в дракон-схеме разрешается только один вход);
— икона G имеет вход сбоку (в дракон-схеме это запрещено);
— у иконы G выход находится слева (в дракон-схеме он должен быть снизу);
— две петли обратной связи цикла находятся слева от шампура и закручены по часовой стрелке (в дракон-схеме они расположены справа от шампура и закручены против часовой стрелки);
— используются неудобные ромбы (в дракон-схеме их заменяют эргономичной иконой Вопрос);
— ромб L имеет выход слева (в дракон-схеме он должен быть справа);
— используется 12 стрелок, из которых 10 — паразитные (в дракон-схеме всего 2 стрелки);
— имеется один избыточный изгиб линии (в блок-схеме 9 изгибов, в дракон-схеме — 8).
Таким образом, данная блок-схема, как и предыдущие примеры, проигрывает дракон-схеме.
Анализ вложенного цикла ПОКА (while)
Графическое изображение цикла должно быть удобным, стандартным и легко запоминающимся. В блок-схемах эта проблема не решена: нередко каждый автор изображает цикл по-своему, что запутывает читателей. Язык ДРАКОН предлагает стандартное начертание для каждого типа цикла.
Рис. 7 (слева). Плохая схема. Вложенный цикл ПОКА изображен без учета правил эргономики. Шампур разорван.
Рис. 8 (справа). Хорошая (эргономичная) схема. Вложенный цикл ПОКА нарисован по правилам языка ДРАКОН
На рис. 7, 8 изображены блок-схема и дракон-схема вложенного цикла ПОКА (while). Блок-схема взята из учебного пособия.
На блок-схеме (см. рис. 7) можно указать следующие недочеты:
— между иконами E и K имеется разрыв шампура (нарушено правило, согласно которому один из путей, идущих от входа к выходу, должен проходить по главной вертикали);
— ниже иконы Е через разрыв шампура проходят две нежелательные горизонтальные линии;
— две петли обратной связи циклов ПОКА закручены по часовой стрелке (в дракон-схеме они закручены против часовой стрелки);
— используются неудобные ромбы (в дракон-схеме их заменяют эргономичные иконы Вопрос);
— используется 8 стрелок, из которых 6 — паразитные (в дракон-схеме всего 2 стрелки);
— имеется 2 избыточных изгиба линии (в блок-схеме 10 изгибов, в дракон-схеме — только 8);
— в блок-схемах отсутствует графическая стандартизация циклов. В дракон-схемах стандартизация циклов строго соблюдается. Об этом можно судить по рис. 8. Голубая заливка окружает внутренний цикл ПОКА. Белая заливка окружает внешний цикл ПОКА.
Сравнивая рис. 7 и 8, легко убедиться, что дракон-схемы во всех отношениях лучше, чем блок-схемы.
Неэргономичные «образцы итоговых заданий»
В журнале «Информатика и образование» опубликованы рекомендуемые «образцы итоговых заданий по оценке качества подготовки школьников по информатике». В материале приведены четыре блок-схемы с блоком «Решение», которые препятствуют использованию шампура. Причина эргономической ошибки состоит в том, что нижний выход ромба удален и нарисован слева (рис. 9). Ошибку можно легко исправить, как показано в дракон-схеме на рис. 10.
Рис. 9 (слева). Плохая схема. Выход из ромба влево (а не вниз) мешает правильному изображению шампура
Рис. 10 (справа). Хорошая (эргономичная) схема. Шампур нарисован верно, так как икона Вопрос имеет выход вниз.
Типичные ошибки в блок-схемах алгоритмов
На основании анализа алгоритмов на Рис. 1—10 можно составить перечень эргономических ошибок, которые мы выявили:
— нет шампура;
— разрыв шампура;
— блоки Заголовок и Конец на разных вертикалях;
— ненужные стрелки;
— ненужные изгибы линий;
— ненужные кружки;
— два входа в один блок;
— три входа в один блок;
— вход в блок слева;
— вход в блок справа;
— пересечение линий;
— наклонная линия;
— выход из блока Процесс слева.
Примитив и силуэт
Мы рассмотрели простые блок-схемы, состоящие примерно из 10 блоков. Их можно «вылечить» с помощью дракон-схемы Примитив.
В сложных проектах могут использоваться большие многостраничные блок-схемы. В таких случаях работать с блок-схемой по ГОСТ 19.701-90 становится трудно, поскольку она полностью теряет как наглядность, так и регулярность структуры. Чтобы исправить ситуацию, нужно использовать алгоритмическую конструкцию Силуэт языка ДРАКОН, которая сохраняет наглядность даже для многостраничных схем. (В данной статье конструкция Силуэт не описана. Посмотреть можно здесь).
Замечания
Стандарт ГОСТ 19.701—90 не может обеспечить наглядность при вычерчивании сложных алгоритмов, так как концепция стандарта устарела и построена без учета идей когнитивной эргономики.
Дракон-схемы принципиально отличаются от блок-схем тем, что подчиняются когнитивно-эргономическим правилам.
В данной теме указаны эргономические недостатки блок-схем и описаны парные им достоинства дракон-схем.
В зрительно-смысловой структуре алгоритма шампур играет важную роль. Шампур способен быстро и естественно привлечь к себе внимание читателя, правильно сориентировать его в структуре алгоритма.
При отсутствии шампура уничтожается основа для выделения главного маршрута.
Разрыв или отсутствие шампура делает зрительный образ алгоритма «бесформенным», лишенным композиционного центра. Читатель лишается необходимых зрительных ориентиров, что затрудняет чтение алгоритма.
Зрительный образ алгоритма должен быть лаконичным. Все ненужные, лишние детали должны быть исключены.
Схема должна содержать лишь те элементы, которые необходимы читателю для понимания смысла алгоритма и выявления ошибок.
Чтобы схема была удобной для чтения, количество изгибов соединительных линий должно быть минимальным.
Стрелки нужны только как признак цикла Стрелка. Стрелки, показывающие направление потока управления, следует удалить.
Дракон-схемы созданы на основе блок-схем с целью их совершенствования. Дракон-схемы — это упорядоченные блок-схемы.
Сравнение со стандартом ГОСТ 19.701-90
В блок-схемах алгоритмов по ГОСТ 19.701-90 формализованы только фигуры. За пределами формализации остаются:
— правила присоединения отростков линий к фигурам;
— точки размещения фигур, или точки ввода фигур;
— связи между фигурами.
В отличие от блок-схем, в дракон-схемах проведена полная формализация. Строго определены не только иконы, но их отростки, а также соединительные линии и точки ввода фигур. Формализацию соединительных линий обеспечивают формальные отростки икон, формальные валентные точки и макроиконы.
Правила работы с отростками, валентными точками и макроиконами описаны в работе .
Теория отростков
Назначение теории отростков — устранить неоднозначность присоединения отростков к графическим фигурам.
В языке ДРАКОН формализация отростков выполнена так:
— иконы заданы не отдельно, а вместе с отростками (рис. 11, 12);
— число отростков, тип и направление каждого отростка строго определены.
Рис. 11. Иконы языка ДРАКОН
Рис. 12. Иконы языка ДРАКОН. Окончание
Существуют три типа отростков:
— входной,
— выходной,
— нейтральный.
Входной и выходной отростки направлены сверху вниз и лежат на одной вертикали, причем входной отросток входит в икону сверху, а выходной — исходит из нее снизу. Икона Вопрос имеет не один, а два выхода; второй выходной отросток направлен по горизонтали вправо. Все отростки ориентированы к центру иконы.
На рис. 13 показаны примеры входных и выходных отростков. Нейтральный отросток приведен на рис. 12, пункт 21. Это горизонтальный отросток, соединяющий икону Синхронизатор с иконой-хозяином.
Перечисленные правила задают однозначную привязку отростков к иконам, являясь средством формализации.
Рис. 13. Язык ДРАКОН предлагает однозначный (единственный) вариант присоединения отростков к иконам. Икона Действие имеет два отростка: входной (сверху) и выходной (снизу). Икона Вопрос имеет три отростка: входной (сверху) и два выходных (внизу и справа)
Сравниваем со стандартом ГОСТ 19.701-90
Иконам Действие и Вопрос в стандарте ГОСТ 19.701-90 соответствуют блоки Процесс и Решение (рис. 14).
Рис. 14. ГОСТ 19.701—90 разрешает присоединять линии к блокам Процесс и Решение четырьмя разными способами, т. е. неоднозначно. Язык ДРАКОН устраняет недостаток и предлагает однозначный (единственный) вариант
Легко видеть, что формализация отростков в ГОСТе отсутствует. Действительно, в стандарте для блока Процесс (рис. 14) предусмотрены четыре варианта. Больше того, число вариантов может возрасти вдвое, если учесть, что стандарт ГОСТ 19.701—90 разрешает выполнять чертежи как со стрелками, так и без них:
«При необходимости или для повышения удобочитаемости могут быть добавлены стрелки-указатели».
Для сравнения: в языке ДРАКОН для иконы Действие (рис. 13) предусмотрен всего один чертеж, что исключает путаницу и предотвращает ошибки.
Далее. Для блока Решение (рис. 14) ГОСТ разрешает четыре варианта (или даже восемь — с использованием стрелок и без них).
Сравним с языком ДРАКОН и иконой Вопрос (рис. 13). Для нее задан один-единственный чертеж, что обеспечивает строгую формализацию.
Неоднозначность графики стандарта является прямым следствием указания ГОСТа 19.701—90: «Символы могут быть вычерчены в любой ориентации».
Наличие в стандарте разных способов подключения отростков к блокам говорит об отсутствии формализации соединительных линий в блок-схемах, что является недостатком стандарта ГОСТ 19.701-90.
Теория валентных точек
Валентные точки можно рассматривать как точки размещения икон, или точки ввода икон. Расположение валентных точек на чертеже дракон-алгоритма строго определено. Иконы можно вставлять только в валентных точках, и больше нигде. На рис. 15 белыми кружками показаны валентные точки, находящиеся на отростках икон Действие и Вопрос. Для каждой точки определено, какие иконы и макроиконы можно вводить в данную точку.
Рис. 15. Икона Действие имеет две валентные точки, а икона Вопрос — три
На чертеже дракон-алгоритма валентные точки не изображаются, но подразумеваются. Они визуализируются (на короткое время) только в процессе построения дракон-схемы — при работе инструментальной программы ДРАКОН-конструктор.
Динамика валентных точек
Чертеж дракон-алгоритма формируется методом логического вывода из визуальных аксиом. На каждом шаге построения происходит размножение валентных точек. Процесс размножения можно рассматривать как динамический процесс преобразования валентных точек.
Рассмотрим построение дракон-схемы силуэт (рис. 16).
Рис. 16. Размножение валентных точек (кружки) при проектировании дракон-схемы силуэт
В аксиоме-силуэт (рис. 16, слева) всего 3 валентных точки. После добавления к аксиоме ветки силуэта (рис. 16, в центре) получается уже 5 точек. А после вставки иконы Действие (рис. 16, справа) число точек увеличивается до 6. Дальнейший процесс построения силуэта приводит к монотонному росту числа валентных точек.
Это значит, что иконы (или макроиконы) можно вставлять не куда угодно, а только в строго определенные места (валентнын точки). Ввод производится так. Сначала происходит разрыв соединительной линии в выбранной пользователем валентной точке. Затем в место разрыва вставляется нужна фигура.
Все списки (списки валентных точек и списки разрешенных икон и макроикон) хранятся в памяти программы ДРАКОН-конструктор, который осуществляет визуальный логический вывод. Таким образом, описанная операция строго формализована и защищена от многих ошибок.
Пользователю запрещено рисовать соединительные линии
Во избежание ошибок разработчику алгоритма запрещено рисовать какие-либо линии на чертеже алгоритма.
Все линии автоматически рисует программа ДРАКОН-конструктор. Пользователь лишь управляет этим процессом, выбирая из меню нужные иконы (и макроиконы) и указывая на чертеже валентные точки, куда их нужно вставить.
ДРАКОН-конструктор, подчиняясь разумным указаниям пользователя (и отклоняя неразумные) автоматически применяет правила визуального логического вывода.
Тщательно разработанные и теоретически обоснованные правила построения дракон-алгоритма, учитывающие особенности зрительного восприятия, позволяют облегчить и ускорить понимание алгоритма.
Благодаря правилам сложный и запутанный алгоритм можно преобразовать и представить в виде комплекта ясных, доходчивых и дружелюбных (people-friendly) дракон-схем.
Попробуйте ДРАКОН-конструктор DrakonHub. Вы убедитесь, что все соединительные линии он выполняет автоматически, причем без пересечений.
Теория макроикон
Некоторые сочетания икон и соединительных линий повторяются чаще других; их целесообразно выделить и стандартизовать. Такие сочетания называются макроиконами. Макроиконы служат для предотвращения ошибок при проведении соединительных линий.
Рис. 17. Макроиконы языка ДРАКОН
Рис. 18. Макроиконы языка ДРАКОН. Окончание
Макроиконы Развилка и цикл Стрелка
Проведем анализ двух макроикон: Развилка и цикл Стрелка. Обе они содержат только одну икону — икону Вопрос, а также соединительные линии и валентные точки (рис. 19).
Рис. 19. Две макроиконы: Развилка и цикл Стрелка
Цикл Стрелка — пустой оператор, он служит заготовкой для построения реальных циклов с условием. Если заполнить верхнюю валентную точку, получим цикл ДО (do while). Если нижнюю — цикл ПОКА (while). Если обе — цикл do while do.
Макроикона Развилка — тоже пустой оператор. Если заполнить левую валентную точку, получим оператор ЕСЛИ (if). Если обе — оператор ЕСЛИ ТО (if else).
Теория макроикон позволяет различать опасное и безопасное использование макроикон. Чтобы безопасно построить цикл с условием, следует использовать макроикону цикл Стрелка, но не Развилку.
Недопустимые действия
Опасность появляется тогда, когда пользователь пытается нарушить правила и переделать макроикону Развилка, превратив ее в цикл. Это можно сделать с помощью операции «Пересадка лианы» — нужно оторвать правый выход иконы Вопрос в валентной точке и пересадить его наверх в нужную точку, превратив в стрелку цикла. Однако в языке ДРАКОН так поступать запрещено, так как возникает опасность допустить ошибку.
Почему? Потому что речь идет об образовании нового цикла, аналогичного оператору goto, который реализует переход на оператор, расположенный выше (раньше) на чертеже ДРАКОН-алгоритма. Подобная операция в языке ДРАКОН считается небезопасной и недопустимой. Специалист по надежности программного обеспечения Гленфорд Майерс предостерегает:
«Наихудшим применением оператора goto считается переход на оператор, расположенный выше (раньше) в тексте программы».
Запрет на образование нового цикла вызван тем, что переход на оператор, расположенный выше, является самым плохим (и недопустимым) использованием оператора перехода.
Как избежать ошибки. В меню программы «ДРАКОН-конструктор» предусмотрена макроикона цикл Стрелка, предназначенная для безопасного создания циклов с условием. При этом угроза ошибок снимается.
Сравниваем со стандартом ГОСТ 19.701-90
Формализация макроикон и валентных точек в ГОСТе не предусмотрена. Трудности понимания сложных блок-схем алгоритмов, выполненных по ГОСТ 19.701-90, связаны с тем, что в них отсутствует должный порядок — правила разработки схем не формализованы, не эргономичны и разрешают совершать недопустимые действия. Эксперты отмечают:
«Основной недостаток блок-схем заключается в том, что они не приучают к аккуратности при разработке алгоритма. Ромб можно поставить в любом месте блок-схемы, а от него повести выходы на какие угодно участки. Так можно быстро превратить программу в запутанный лабиринт, разобраться в котором через некоторое время не сможет даже сам ее автор».
В отличие от ГОСТа, в языке ДРАКОН икону Вопрос можно вставить не «в любом месте» чертежа, а только в валентных точках. И повести выходы не на «какие угодно участки», а только и исключительно в те места, которые разрешены согласно формальным правилам языка ДРАКОН.
Некорректное использование термина "алгоритм" в стандарте ГОСТ 19.701–90
Межгосударственный стандарт ГОСТ 19.701—90 (редакция 2010 года) получен методом прямого применения из международного стандарта ISO 5807:1985.
Но вот что удивительно. В оригинале ISO 5807:1985 термин algorithm отсутствует:
«Information processing — Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts»
А при локализации на русском языке термин алгоритм внезапно появляется:
СХЕМЫ АЛГОРИТМОВ, ПРОГРАММ, ДАННЫХ И СИСТЕМ
Обозначения условные и правила выполнения
При этом возникает некорректность (противоречие), так как в тексте стандарта ГОСТ 19.701—90 сказано:
1.3. В настоящем стандарте определены символы, предназначенные для использования в документации по обработке данных, и приведено руководство по условным обозначениям для применения их в:
1) схемах данных;
2) схемах программ;
3) схемах работы системы:
4) схемах взаимодействия программ;
5) схемах ресурсов системы
Противоречие заключается в том, что в этом списке из пяти пунктов (и в дальнейшем тексте) отсутствует упоминание о схемах алгоритмов.
В оргинале противоречия нет, так как пункт 1.3 соответствует английскому тексту международного стандарта ISO 5807:85:
1 Scope and field of application
This International Standard specifies symbols to be used in information processing documentation and gives guidance on conventions for their use to:
a) data flowcharts,
b) program flowcharts,
c) system flowcharts,
d) program network charts,
e) system resources charts.
Алгоритмы — чрезвычайно важный термин и понятие. По моему мнению, необходимо выпустить отдельный самостоятельный стандарт на алгоритмы и убрать упоминание об алгоритмах из ГОСТ 19.701—90.
Каким должен быть стандарт на алгоритмы
Проблема стандартизации представления алгоритмов
Стандарт графического представления алгоритмов (далее стандарт алгоритмов) есть единая система обозначений (единая нотация) для записи алгоритмов. В настоящее время проблема стандартизации алгоритмов не решена. На практике для записи алгоритмов применяются разнообразные средства: псевдокоды, блок-схемы (flowcharts), схемы деятельности (activity diagrams) языка UML, дракон-схемы (drakon-charts).
В программировании (с появлением структурного программирования) подробные блок-схемы алгоритмов стали ненужными; вместо них используются псевдокоды, как правило, не подлежащие стандартизации.
При выпуске документации на алгоритмы действует межгосударственный стандарт ГОСТ 19.701—90, полученный методом прямого применения из международного стандарта ISO 5807:1985. Проблема в том, что стандарты ГОСТ 19.701—90 и ISO 5807:1985 обладают существенными недостатками; они не удовлетворяют требованиям для записи алгоритмов.
Требования к стандарту алгоритмов
Существующие нотации и алгоритмические языки не предотвращают алгоритмические ошибки, а наоборот, содействуют их появлению, являясь своеобразным катализатором ошибок. Новая нотация должна в максимальной степени содействовать сокращению числа ошибок в алгоритмах.
Проблема ошибок является чрезвычайно важной и актуальной; поэтому предотвращение ошибок должно быть предусмотрено на уровне стандарта для записи алгоритмов.
Что лучше для российского образования: дракон-схемы или блок-схемы по ГОСТ 19.701—90?
Многие авторы высказываются в поддержку языка ДРАКОН.
«Визуальный язык ДРАКОН образует наглядную среду для первоначального обучения программированию и мог бы быть весьма полезен при организации школьных курсов информатики» [85].
«Блок-схемы, нарисованные по правилам языка ДРАКОН, отличаются поразительной четкостью, наглядностью и прозрачностью структуры. А наглядность и доходчивость алгоритмов — это именно то, чего так остро недостает школьным учебникам» [86].
«ДРАКОН — это … эргономичный стандарт для графического представления учебной информации… Язык ДРАКОН учит нас, методистов и учителей правильному составлению блок-схем… Насколько я знаю, нет другой литературы, где тому же самому можно научиться настолько просто и даже увлекательно» [87].
«Язык усовершенствованных графических схем ДРАКОН обеспечивает разработку сложных алгоритмов с сохранением наглядности даже для многостраничных схем» [88].
«Алгоритмический язык ДРАКОН … используется в технике, биологии, медицине и образовании. Преимуществом этого языка является то, что схемы легко рисовать и понимать, они очень наглядны» [89].
«Язык ДРАКОН — удобный инструмент для записи и структурирования деятельности в виде алгоритмов…, дает глубокое понимание сложных проблем, позволяет проектировать сложную деятельность, бизнес-процессы, формализовать свои профессиональные знания» [90].
«Использование языка ДРАКОН и гибридных языков может позволить полностью отказаться от традиционного подхода к разработке ПО РК (программного обеспечения робототехнических комплексов — Авт.), снижая интеллектуальную нагрузку на разработчика алгоритма, исключая ошибки толкования исходных данных программистом … Но самое главное — это позволит резко сократить затраты на разработку ПО РК, что сделает роботов более доступными для потребителей самого разного уровня» [91].
Приведем также отзыв рядового пользователя, размещенный в сети Интернет участником с ником dvuugl:
«Если нужно рисовать алгоритм, теперь только и только на Драконе. Считаю, что он должен стать государственным стандартом для блок-схем вместо существующего. Удивительно, что авторы книг продолжают использовать прежние схемы, на которые после Дракона без ужаса смотреть невозможно».
В то же время, несмотря на явное преимущество дракон-схем, в большинстве российских школ и вузов язык ДРАКОН не изучают, предпочитая устаревшие блок-схемы. Причина проста: блок-схемы опираются на авторитет стандартов ГОСТ 19.701—90 и ISO 5807:1985, а дракон-схемы такой поддержки не имеют. Многие преподаватели вузов и учителя школ продолжают знакомить студентов и школьников с неэргономичными блок-схемами, оправдывая свои действия необходимостью соблюдать требования стандарта ГОСТ 19.701—90.
Стандарты, которые отстали от жизни
Проведенный анализ позволяет сделать вывод, что морально устаревший стандарт ISO 5807:1985 (и его калька ГОСТ 19.701—90) препятствуют распространению новых, более удобных и эффективных форм представления визуальных алгоритмов. Указанные стандарты оказывают негативное воздействие на систему среднего и высшего образования России.
Таким образом, налицо парадоксальная ситуация. Система образования должна распространять лучшее, а не худшее. Однако на деле происходит обратное. Российским преподавателям, учащимся и специалистам навязан устаревший и не имеющий научного обоснования стандарт только потому, что он скопирован с международного стандарта. Возникло противоречие между устаревшим стандартом и новой практикой.
Это противоречие следует устранить. Учитывая изложенное выше, необходимо при записи алгоритмов отказаться от некачественных стандартов ISO 5807:1985 и ГОСТ 19.701—90 и в качестве государственного стандарта разработать стандарт, основанный на языке ДРАКОН. Как отмечает профессор Я. В. Безель в журнале «Вестник Российской академии наук»:
«при разработке единого стандарта, снабженного компьютерной поддержкой и рассчитанного на постепенное внедрение во всех отраслях и предметных областях, целесообразно взять за основу язык ДРАКОН» [92].
Язык ДРАКОН устраняет недостатки блок-схем
ДРАКОН упорядочивает блок-схемы за счет формализации, эргономизации и неклассической структуризации [39, 93]. С появлением дракон-схем (drakon-charts) блок-схемы алгоритмов по ГОСТ 19.701—90 полностью потеряли свое значение, так как они во всех отношениях уступают дракон-схемам [39, с. 32—36, 242—254].
Государственный комитет РФ по высшему образованию в 1996 г. по решению Президиума научно-методического совета по информатике под председательством академика РАН Ю. И. Журавлева включил изучение языка ДРАКОН в Примерную программу дисциплины «Информатика» для бакалавров для направлений:
510000 — Естественные науки и математика;
540000 — Образование;
550000 — Технические науки;
560000 — Сельскохозяйственные науки [38].
А. Н. Степанов в «Курсе информатики для студентов информационно-математических специальностей» (2018) отмечает:
«Существуют близкие к блок-схемам языки визуального программирования, такие как… язык программирования и моделирования ДРАКОН. В этом языке используются графические элементы, аналогичные стандартным элементам блок-схем… Но для обеспечения возможности автоматического преобразования графической программы в машинный язык введены строгие правила задания графических и текстовых элементов такой программы» [37, с. 190].
Далее Степанов излагает концепцию языка ДРАКОН и указывает его преимущества:
«В рамках этого подхода основные управляющие конструкции следования, ветвления и цикла, которые в обычных алгоритмических языках задаются с помощью служебных слов, таких как begin, end, if, then, else, while, do и т. д., заменяются управляющей графикой, похожей на стандартные элементы блок-схем… Язык двумерного структурного программирования ДРАКОН является полным по Тьюрингу и относится к универсальным языкам программирования… Использование гибридных языков позволяет отказаться от текстовых управляющих структур, используемых в обычных языках, и заменить их управляющей графикой языка ДРАКОН. Написание программы становится более понятным и удобным для человека, повышается производительность труда программистов» [37, с. 1017—1019].
Следует различать алгоритмы и программы
В литературе термины «алгоритм» и «программа» иногда используются как синонимы. Однако при создании стандарта это недопустимо; их необходимо строго различать.
Стандарт ГОСТ 19.701—90 нарушает это правило; он называется «Схемы алгоритмов, программ, данных и систем» и не проводит границы между алгоритмами и программами.
Тезис академика Дородницына
Академик А. А. Дородницын четко проводит указанную границу, подчеркивая, что «без алгоритмов предмета информатики не существует» [94]. Более того, он предлагает выделить «алгоритмические средства» как отдельную, самостоятельную сущность:
«…состав информатики — это три неразрывно и существенно связанные части: технические средства, программные средства и алгоритмические средства. Если о первых двух частях никогда не забывают — … они получили специальные термины “hardware” и “software”, — то алгоритмическая часть информатики остается почему-то в тени… об этой важнейшей части информатики просто забывают» [94].
Таким образом, согласно Дородницыну, алгоритмические средства должны составлять третью, самоценную часть информатики, наряду с программными средствами (software) и техническими средствами (hardware) [94].
Чтобы в полной мере реализовать идею Дородницына, нужно иметь отдельный стандарт, посвященный алгоритмам, содержащий эргономичную нотацию для записи алгоритмов, пригодную для подавления ошибок.
Выводы
1. Схемы алгоритмов (flowcharts), описанные в ГОСТ 19.701—90 и международном стандарте ISO 5807:1985, обладают серьезными дефектами. Пользоваться ими недопустимо.
2. Вместо блок-схем для записи алгоритмов следует использовать дракон-схемы (drakon-charts).
3. Необходимо разработать и выпустить отдельный стандарт, посвященный алгоритмам, на основе языка ДРАКОН.
4. Государственный комитет РФ по высшему образованию в 1996 г. по решению Президиума научно-методического совета по информатике включил изучение языка ДРАКОН в программу курса «Информатика».
5. Тем не менее, преподаватели вузов и учителя школ продолжают знакомить студентов и школьников с морально устаревшими блок-схемами, обосновывая такую практику необходимостью ориентироваться на действующий стандарт ГОСТ 19.701—90.
6. Преподавателям и учителям можно рекомендовать ознакомиться с языком ДРАКОН, убедиться в его преимуществах и организовать изучение языка ДРАКОН на лекциях, уроках, практических занятиях, курсовых и дипломных работах.
Литература
1. (1995) Паронджанов В. Д. Графический синтаксис языка ДРАКОН // Программирование. 1995, №3. С. 45-62.
2. (1998) Паронджанов В. Д. Как улучшить работу ума. (Новые средства для образного представления знаний, развития интеллекта и взаимопонимания). — М.: Радио и связь, 1998, 1999. — 352 с.
3. (2001) Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто. — М.: Дело, 2001. — 360 с.
4. (2009 (Паронджанов В. Д. Язык Дракон. Краткое описание. — М., 2009. — 124 с.
5. (2010) Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. Как улучшить работу ума без лишних хлопот. — М.: ДМК-пресс, 2010, 2014, 2016. — 464 с.
6. (2012) Ефанов С. Д. Программирование микроконтроллеров на ДРАКОНе. — Сайт Сообщество EasyElectronics.ru
7. (2012) Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с.
8. (2016) Паронджанов В.Д. Визуальный алгоритмический язык ДРАКОН в ракетной технике и медицине // Современные автоматизированные системы управления реального времени как прикладное развитие научных достижений кибернетики» (К 100-летию со дня рождения И.А. Полетаева). Материалы межведомственной конференции 24 марта 2016 г. — ФГБУ «3 ЦНИИ» Министерства обороны РФ, 2016. — 218 с. — С. 57-78.
9. (2017) Паронджанов В. Д. Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН. — М.: ИСП РАН, 2017. — Доклад на семинаре в институте системного программирования РАН 19 мая 2017 г.
10. (2017) Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины. Клиническое мышление высокой точности и безопасность пациентов. / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.
11. (2017) Митькин С.Б. Визуальное программирование на языке ДРАКОН. — Хабр, 2017 ( @rykkinn )
12. (2019) Митькин С. Б. Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019.
13. (2019) Паронджанов В. Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М.: Препринт, 2019. — 374 с.
14. (2020) Паронджанов В. Д. Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов? — М.: Обращение к Президенту РФ, 2020. — 70 с.
14а. (2021) Паронджанов В. Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН. — Хабр, 2021.
15. (2021) Паронджанов В. Д. Алгоритмические языки и программирование: ДРАКОН : учебное пособие для вузов. — Москва : Издательство Юрайт, 2021. — 436 с. — (Высшее образование).
Литература на тему «Медицинский алгоритмический язык ДРАКОН»
17. (2014) Aiste Vileikyte, Ruta Jolanta Nadisauskiene, Vladimiras Parandzanovas, Paulius Dobozinskas, Algirdas Karalius, Ausrele Kudreviciene. Algoritmines „Drakon“ kalbos pritaikymas medicinoje (на литовском языке). —
18. (2016) Паронджанов В.Д. Можно ли улучшить медицинский язык? // Человек. 2016. №1. — С. 105-122.
20. (2017) Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины. Клиническое мышление высокой точности и безопасность пациентов. / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.
22. (2019) Паронджанов В.Д. Перспективы развития медицинской науки и алгоритмическая клиническая медицина Рукопись.
23. (2020). Сморкалов А.Ю., Чистяков С.И., Горох О.В., Певнев А.А. Особенности реализации программы дополнительной подготовки врачей по специальности «Анестезиология-реаниматология», «Интенсивная терапия осложненных форм новой коронавирусной инфекции» // Виртуальные технологии в медицине. № 2 (24). 2020. — С. 42-47.
24. (2021) Митькин С.Б., Паронджанов В. Д. Инструкция. Как нарисовать клинический алгоритм (алгоритм действий врача) с помощью онлайн-редактора DrakonHub. — 2021.
Литература, указанная в ссылках
37. Степанов, А. Н. Курс информатики для студентов информационно-математических специальностей. (Серия «Учебник для вузов») / А. Н. Степанов. — Санкт-Петербург : Питер, 2018.
38. Примерная программа дисциплины «Информатика». Издание официальное. — Москва : Госкомвуз, 1996. — С. 3, 4, 15, 16. — URL: https://drakon.su/_media/biblioteka/progr_drakon.pdf.
39. Паронджанов, В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации / В. Д. Паронджанов. — Москва: ДМК Пресс, 2012, 2014, 2016.
85. Пышкин, Е. В. Структурное проектирование: основание и раз- витие методов. С примерами на языке C++ : учебное пособие / Е. В. Пышкин. — Санкт-Петербург : Политехнический ун-т, 2005. С. 283. — URL: http://kspt.icc.spbstu.ru/media/files/people/pyshkin/books/StructDesign-Excerpt.pdf.
86. Окулова, Л. П. Проектирование образовательного процес- са в соответствии с требованиями педагогической эргономики / Л. П. Окулова // Вестник Наука и практика (29 мая 2012 — 31 мая материалы конференции «Инновации и научные исследования, а также их примен. на практике». — Варшава. — URL: http:// xne1aajfpcds8ay4h.com.ua/pages/view/730.
87. Беляков, Е. Новый алгоритм: раздевайся и быстро ложись спать. Диалог на языке «Дракона» / Е. Беляков // Учительская газета. — № 10. — С. 16.
88. Фокин, Ю. Г. Теория и технология обучения: деятельност- ный подход : учебное пособие для студентов высших учебных за- ведений / Ю. Г. Фокин. — 3-е изд., испр. — Москва : Издательский центр «Академия», 2008. — С. 233.
89. Новый вектор в преподавании фтизиатрии студентам-педиатрам / М. Э. Лозовская [и др.] // Туберкулез и болезни легких. — Т. 97. — № 5. — С. 73, 74.
90. Косова, А. Е. Язык ДРАКОН как средство повышения качества профессиональной компетентности / А. Е. Косова // Современное образование: повышение профессиональной компетентности пре- подавателей вуза — гарантия обеспечения качества образования: научно-методическая конференция 1—2 февраля 2018. — Томск : Изд-во Томск. ун-та сист. упр. и радиоэлектрон., 2018. — С. 89—91.
91. Пичкалев, А. В. Разработка программного обеспечения робототехнических комплексов с использованием графического язы- ка ДРАКОН / А. В. Пичкалев // Робототехника и искусственный интеллект : материалы VII Всероссийской научно-технической конференции (г. Железногорск, 11 декабря 2015) / под научной редакцией В. А. Углева. — Красноярск : Сибирский федер. ун-т, — С. 90—94.
92. Безель, Я. Б. Можно ли улучшить работу ума? Новый взгляд на проблему / Я. Б. Безель // Вестник РАН. — 2003. — Т. 73. — № 4. — С. 364—365.
93. Паронджанов, В. Д. Графический синтаксис языка ДРАКОН / В. Д. Паронджанов // Программирование. — 1995. — Т. 3. — С. 45. — URL: http://drakon.su/_media/video_i_prezentacii/graphical_ syntax_.pdf.
94. Дородницын, А. А. Информатика: предмет и задачи / А. А. Дородницын // Вестник Академии наук СССР. — 1985. — № 2. — С. 85—89.
Теги: Стандарт представления алгоритмов; Критика стандарта ГОСТ 19.701—90; Стандарт алгоритмов на основе языка ДРАКОН; Визуальный язык ДРАКОН; Эргономичный алгоритмический язык ДРАКОН; Программа ДРАКОН-конструктор; ДРАКОН-алгоритм; Аксиома-силуэт; Визуальный логический вывод; DRAKON visual language;
Стандарт представления алгоритмов
Критика стандарта ГОСТ 19.701—90
Стандарт алгоритмов на основе языка ДРАКОН
Эргономичный алгоритмический язык ДРАКОН
Программа ДРАКОН-конструктор
Визуальный логический вывод
Полученный результат (почти безошибочное автоматическое проектирование графики дракон-схем) является значимым достижением.
;
mickvav
Вот к чему приводит безоглядочное копание своей грядки, горячо любимое советской профессурой. Автор, это-вот-все было осмысленно году в 85-м, примерно. С того момента человечество внезапно сделало много разного, и поняло много разного. Выползайте уже из пещеры и оглянитесь. И визуальных и читаемых языков придуман вагон, scratch для детей и тот читаемее, чем это чудо-юдо. Русский язык в программировании тоже попробовали уже (1С, чур-меня) — очень нишевая штука.
Удивительное рядом, но похоже что взлетают языки с очень компактным базовым синтаксисом и документацией, написанной на английском так, чтобы автоматические переводчики не шибко врали при переводе на другие языки.
Плюс стало понятно, что для разработки надежных больших систем куда важнее даже не сам язык как таковой, а культура вокруг — количество кода на функцию, покрытие тестами, скорость получения ответа на тупой вопрос «проходят ли все тесты», сложность графа зависимостей компонентов. А для поддержания визуальной читаемости на должном уровне линтеры и считалки цикломатической сложности — прямо песня. Когда пытаешься запилить функцию в 300 строк а оно тебе (само, железко) — «чувак, тут слишком много кода в одной функции, распилил бы ты ее...» или «ой, чой-то ты вот это ветвление тестом не покрыл» — это прям радость, правда.
Parondzhanov Автор
Стандарт ГОСТ 19.701—90 — это действующий стандарт.
Он используется при выпуске документации прежде всего. Речь идет о схемах алгоритмов. Этот стандарт задает графику схем алгоитмов. Но не коды. Коды здесь вообще ни при чем.
Вы, по-видимому, не используете стандарт ГОСТ 19.701—90.
Но другие разработчики вынуждены им пользоваться.
К сожалению, ваш комментарий не относится к теме статьи.
mickvav
Как же я счастлив, что мне не приходится дублировать код документацией на детали реализации алгоритма. Ровно потому, что это очень сложно поддерживать в актуальном состоянии — мне бы пришлось написать транспайлер с питона на дракон, чтобы не писать один и тот же код дважды. И сам факт, что вы тратите время и энергию на систему, усложняющую жизнь другим людям, вызывает естественный вопрос — зачем? Может, стоит сосредоточить усилия на отказе от ГОСТ 19.701-90 и закопать уже стюардессу?
Документация — она же вроде всегда должна писаться для чтения людьми, правда? Люди, занимающиеся реализацией, способны читать хорошо написанный код, это не сложнее чем визуальная схема алгоритма. Тогда схема не нужна. Ненужное нужно выкинуть.
Если документация пишется для чтения людьми на более высоком уровне иерархии — то на кой черт им детали реализации? Им нужен результат — что на входе, что на выходе, какая должна случиться польза. Ну, может, сколько это все будет стоить времени/денег/каких-нибудь ресурсов. И с какой вероятностью сломается. Для описания этих вещей никакой дракон не нужен, это описывается простым человеческим языком — русским, английским, суахили — каким нужно.
starosta6123
Просто не оцениваете значимости блок-схем для понимания, а что же там происходит?
Прежде всего это учит логическому мышлению.
Блок-схемы когда-то учили в школе на информатике, сейчас этого нет.
А стандарт существует и будет существовать, даже если он устарел.
Так вот когда сталкиваешься со стандартами для документации, то получается что-то очень сложное и непонятное и не удобное.
В общем, это попытка улучшить документацию, и в серьезных разработках без нее никуда. Это все равно, что собирать плату сразу без схемы.
Scrach прекрасен, но он не подходит для документирования и цели его другие.
В общем, это попытка сделать удобной и полезной документацию, на которую плюются из-за ГОСТа.
У каждого стандарта и документации есть своя область применения.
Конечно нет смысла рисовать блок-схему на очередной сайт, но для построения более-менее промышленного сложного устройства придется.
mickvav
Внезапно, «очередной сайт» может под капотом оказаться весьма сложной штукой, с заковыристой системой взаимодействий — все зависит от задач и масштаба. Но внезапно, строить их по заранее прибитой гвоздями блок-схеме перестали уже лет несколько назад. Ровно потому, что много чего заранее не известно.
Обратите внимание — весь мир живет без ГОСТ-а (в буквальном понимании) и отлично себя чувствует, хотя это не значит что в широком смысле нет аналогичных/близких систем визуализации — они есть, и таки да, помогают логическому мышлению.
Другой разговор, что 25 лет попыток насаждения авторского видения более широкому сообществу выглядят, мягко говоря, странно.
darii
Тут дело имхо в другом. В том, что проектировать все равно приходится, а существующие инструменты по-прежнему неидеальны, хоть и стали лучше, чем 35 лет назад. За последние 2 месяца я отсобеседовал не меньше десятка корпоративных архитекторов, и к моему удивлению, каждый из них признавался, что разочарован в существующих нотациях, а в идеале хотел бы работать без строгого соответствия архитектурным языкам и фреймворкам.
Их можно понять. Любой более-менее опытный проектировщик (будь то архитектор решений, бизнес- или системный аналитик) неминуемо сталкивался с родовой травмой всех формальных нотаций. Начиная с определенного уровня сложности, бизнес-процессы уже невозможно описать так, чтобы одновременно было:
Пару-тройку лет назад я открыл для себя нотацию Archimate, которую использую до сих пор в качестве базового инструмента проектирования. В моем случае, основная ее ценность — помогать мне стряпать старые добрые UML-диаграммы проще и читаемее, чем без нее. Но серебряных пуль не бывает, и у моей любимой Archimate тоже есть много бесящих повседневных моментов.
Как я понял, Parondzhanov очередной раз выносит на суд публики свою старую разработку, у которой одна из ценностей тоже заключается в том, чтобы сделать диаграммы более читаемыми, чем раньше.
Вряд ли я когда-нибудь сойду с ума настолько, чтобы всерьез использовать этот дракон как low coding platform, помогающую доменному эксперту писать код на Java/Scala/Coq/etc. Но сегодня утром открыл эту статью, посмеялся над «принципом шампура», дал почитать нескольким знакомым аналитикам и получив от них позитивную обратную связь, решил попробовать эти самые шампуры в своей рутине. Мне как раз нужно подготовить очередной ненужный занудный архитектурный документ (из тех, что никто не читает), в котором 5-6 иллюстраций с вырвиглазными BPMN и UML. Почти уверен, что внедрение принципа шампура сделает эти иллюстрации если не читаемее, то по крайней мере, компактнее. А это значит, Parondzhanov не зря затеял эту свою статью.
P.S. Владимир Данилович, а есть ли возможность фигуры из вашей нотации (те, что на иллюстрациях) выложить в любом векторном формате, а еще лучше — в виде библиотеки для Figma, по аналогии с ArchiMate_Shapes.fig? Так будет проще подсадить на вашу нотацию некоторых молодых специалистов. Тем более, что drakonhub.com стилизует фигуры явно по-другому, не столь этетично, как в этой статье.
Parondzhanov Автор
darii
Вся информация в моих книгах и статьях полностью открыта. Вы можете использовать ее по своему усмотрению полностью или частично.Но. Фигуры — только часть дела. Чрезвычайно важно, чтобы были правильные связи между иконами, то есть соединительные линии, причем без пересечений и внутренних соединителей.
В ДРАКОНе связи строго формализованы с помощью визуального аксиоматического метода (метод визуального логического исчисления). Благодаря логико-математической формализации достигается защита от многих (но не всех) ошибок. Защита от ошибок — важная часть идеологии ДРАКОНа.
Используя только фигуры и отбрасывая защищенные связи между фигурами, вы выбрасываете автоматическую защиту от ошибок, которую реализует правильно построенный ДРАКОН-конструктор.
Отзыв индивидуального предпринимателя Сергея Ефанова о языке ДРАКОН
zartarn
Это всего лишь ваша субъективная проф деформация. Носителям английского языка как то не мешает синтаксис на их родном языке))
mickvav
Несомненно. Я вполне осознанно деформируюсь в сторону «generalist-a» — при выборе между узкоспециальным языком применимым внутри одной индустрии в одном экономическом подпространстве и заточенным под конкретные задачи этой индустрии и универсальным языком я выберу универсальный, если выбор возможен. Поэтому и «меня» — у вас может быть другая траектория и я ни разу не агитирую за то, что моя — единственно правильная (это не так) ;)
TMTH
А жизнь в собственном информационном пузыре приводит к вот таким комментариям. Потому как за пределами вашего пузыря, кроме алгоритмов, которые выполняет компьютер, существуют алгоритмы, которые выполняют люди и, иногда, целые организации. И тут проблемы визуализации и стандартизации алгоритмов встают во весь рост. Дракон, как мне кажется, стоит рассматривать не как графический язык программирования, а как что-то в ряду блок-схем ГОСТ-а, IDEF3, BPMN и т.п.
mickvav
Увы и ах, но таки да, когнитивные способности ограниченны, и мы вынуждены жить в пузырях — все знать невозможно.
Да, люди выполняют алгоритмы, но если для объяснения алгоритма действий человеку приходится вводить новый язык со сложными конструкциями — неплохо строить такой язык в рамках конкретной культуры на основе обратной связи от тех, кто этот язык будет читать, а не пытаться насадить мастерским произволом как универсальный ГОСТ. Я вполне допускаю, что в какой-то индустрии и наборе организаций это чудо прижилось, но попытка безапелляционного обобщения на всех читателей выглядит глупо. С другой стороны — UML вот тоже пытались продать как универсальную штуку для всего, теперь потихоньку хоронят (https://simpleprogrammer.com/unified-modeling-language-age-of-agile/) :)