ДРАКОН — является лучшим из известных мне языков блок-схем, имеющим свою область применимости. Тем не менее, язык не лишён недостатков, как присущих всем блок-схемам, так и характерных для него самого. Некоторые недостатки являются продолжением преимуществ, а другие могут и не являться таковыми в ряде областей.
- Особенность языка подразумевает более сложные способы ввода, редактирования и передачи по сравнению как с плоским, так и, отчасти, насыщенным текстом. Для кода характерны необходимость вырезания, вставки, слияния, поиска и замены по шаблону, что трудно осуществлять с блок-схемами в прямом виде. Частично может быть решено введением текстового представления или гениальными разработками в области программ для работы со схемами.
- Недоопределённость как языка программирования. С одной стороны, это позволяет применять его более широко, с другой — не позволяет говорить о нём как о самодостаточном, полноценном инструменте разработки программ. При этом связь со многими языками нецелесообразна, так как подразумевает плохо совместимые подходы к программированию и только увеличивает скорбь в виде увеличения количества знаний, необходимых для создания кода. Может быть решено доопределением недостающей части языка и определения языка в модульном виде, позволяющим разным аудиториям учитывать только те части, которые им нужны.
- Недостаточность для оформления и неформальных алгоритмов, для которых сейчас он активно используется. Это обусловлено богатством человеческого языка, которое не вписывается в предложенные конструкции, что приводит к фактическим описаниям, которые используют его элементы либо не по назначению, либо переусложнённым образом, что ухудшает их понимание. Нередко можно наблюдать, как описанная простым текстом неформальная инструкция, которую и автору было проще формулировать, оказывается более понятной для читателей, чем блок-схема, составляемая с больши́м трудом.
- Вместимость полезной информации на единицу площади частично снижена(иногда наоборот), что приводит к ухудшенной возможности охвата кода и его понимания.
- Зашумленность кода. При небольшом изучении, особенно в ряде языков, поток выполнения кода становится очевидным, и его подчёркивание, что может быть и полезным в ряде случаях, здесь не только не вносит дополнительной ясности, но и, наоборот, отвлекает от основной сути кода. Есть неустранимое противоречие в представлении кода для разных применений и разных групп пользователей.
- Не всем людям представление кода в виде блок-схем, пусть и составленным по дополнительным эргономическим правилам, даёт преимущество в восприятии кода по сравнению с простым отформатированным текстом. Возможна и обратная зависимость. Многим людям для того, чтобы нарисовать блок-схему, сначала требуется написать код в качестве образца. Так было раньше [0], остаётся и сейчас. Несмотря на это некоторые по-прежнему считают аксиомой, что хорошие блок-схемы понятней людям. Недостаток может быть решён хорошим текстовым представлением, позволяющим бесшовное взаимодействие разных типов разработчиков.
-
Недостаточная структурность кода в языке, что не исправляется наглядностью неструктурных переходов. Это приводит к увеличению сцепки кода и усложняет разделение. Сильная декомпозиция, в свою очередь, обесценивает подчёркнутость переходов. То есть, недостаточная структурность ДРАКОН может приводить к тому, что правильное разбиение сначала будет сложней увидеть, а затем осуществить, и тем самым ДРАКОН повышает необходимость в подчёркивании переходов, порождая необходимость в самом себе, но не как лекарстве, а как наркотике.
Следует подчеркнуть, что это недостаток исключительно по сравнению с полностью структурными языками, такими как Оберон-07, но подавляющее большинство mainstream языков таковыми не являются. И, к примеру, для стиля обработки ошибок, характерных для С, визуализация в ДРАКОН была бы благом. Иными словами, с точки зрения многих программистов в ДРАКОН структурность почти такая, как надо. Тем не менее, даже для подчёркивания неструктурных конструкций ДРАКОН не всегда пригоден, например, не предусмотрена соответствующая запись для привычного для С подхода while + break/return; - Отсутствие адекватного представления для разновидности цикла c проверкой условия продолжения перед выполнением его тела (WHILE DO). В ДРАКОН необходимо либо удвоить проверку — в начале цикла и в конце каждой итерации, либо вынести тело цикла в побочную ветвь ветвления, нарушая правило самого ДРАКОН — «чем правее, тем реже». Эту оплошность можно охарактеризовать как провал, так как в ряде языков это самый часто используемая разновидность цикла. Можно решить изменением языка — осуществлять возврат назад линиями слева, оставив линия справа для переходов вперёд.
- Сосредоточенность на переходах может приводить к появлению излишнего ветвления там, где уместней работа на уровне логических значений или таблиц, не приводящих к переходам.
-
Повышенная сложность распознавания направленности ветвления. В ДРАКОН направление исполнения при истинности условия может меняться в зависимости от того, возле какой ветки был выставлено «Да». Это требует от читателя больше внимания в сравнении с постоянным направлением, используемым в большинстве языков. Фактически, в ДРАКОН «Да» и «Нет» — это не подсказки для незнакомых с блоком-вопросом, а составные части неявного сравнения логического значения. И если сравнение с «Да» — это тавтология, то сравнение с «Нет» — это аналог отрицания, что становится совсем очевидным, если сравнение провести в явном виде:
НЕ А, НЕТ = А
Получается, что стремясь избавиться от логического отрицания для выполнения правила «чем правее, тем реже», автор на самом деле возвёл в абсолют его использование, просто изменив форму выражения, но не улучшив, а ухудшив понятность схем.
Сноски:
[0]. Мифический человеко-месяц. Глава 15. Проклятье блок-схем.
На самом деле о блок-схемах больше говорят, чем пользуются. Я никогда не видел опытного программиста, который составлял бы подробные блок-схемы, прежде чем начинать писать программу. Там, где требуют стандарты организации, блок-схемы почти всегда делаются постфактум. Многие центры с гордостью используют машинные программы для генерирования этого «незаменимого инструмента разработки» из готового кода. Я думаю, что этот универсальный опыт не является постыдным и прискорбным отступлением от хорошей практики, признаваться в котором можно лишь с нервным смешком. Вместо этого он является применением здравого смысла и кое-чему учит нас о полезности блок-схем.цитата
Комментариев нет:
Отправить комментарий