> За три страницы обсуждения успели обсудить все — мою личность, мои стихи, мою компетенцию, нимб и самовлюбленность TAU, но примеры так и не появились. К чему бы это?
Возможно причина очень проста — вопреки привычным утверждениям, рисовать графические представления труднее, чем писать код программы. Писать мы можем от частного к общему, а рисовать — нет. При написании мы можем удерживать в голове только несколько строк алгоритма, остальное "за кадром", а при рисовании нужно удерживать в голове минимально лист схемы и всегда "ориентироваться на местности", как только какое-то пересечение, нужно проводить топологические изыскания.
Лучше приведи тут серию небольших статей, наглядно показывающих преимущества языка, хотя бы даже только в плане описания алгоритмов — и будет гораздо больше пользы.
Какие средства язык предоставляет для организации больших программ?
Я имею в виду средства абстракции и (де)композиции алгоритмов и данных.
И как это соотносится с тем, что проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.?
Дракон предназначен только для представления алгоритмов.
Всё остальное: модель данных, иерархия наследования, уровни абстракции — делается в обычном порядке средствами вашего любимого языка программирования.
Для проектирования статической структуры программы используются другие виды диаграмм: сущность-связь, диаграмма классов, диаграмма компонентов и прочая.
Что касается декомпозиции алгоритмов.
Дракон даёт дополнительный способ декомпозиции в дополнение к обычному вызову подпрограмм.
Это так называемый "силуэт". Он разбивает алгоритм на логические части, что позволяет избежать необходимости лишний раз создавать подпрограммы.
Я в глубоком детстве познакомился с так называемыми "блок схемами".
Что именно нового превносит дракон, кроме собственного синтаксиса?
Чем же именно он лучше для этих целей чем диаграммы поведения UML?
Дракон основан на блок-схемах, но отличается от них:
1. У Дракона есть конструкция "силуэт".
2. У Дракона есть дополнительные правила, цель которых — сделать диаграмму более предсказуемой и читаемой.
Каждое из этих правил имеет объективное обоснование.
Например, строгий запрет пересечения линий нужен, чтобы картинка не превратилась в кашу.
"Квадратики" соединяются простыми линиями, а не стрелками. Во-первых, это снижает графическую сложность диаграммы,
во-вторых, любая стрелка в Драконе (кроме силуэтной) означает цикл. Циклы сразу бросаются в глаза.
3. Дракон позволяет быстро выделить happy path и игнорировать код обработки ошибочных ситуаций.
Как насчёт взаимодействия сущностей (проектируем в рамках ООП, например) наподобие диаграмм последовательности?
Диаграмма последовательности описывает один use case и не содержит ветвления и циклов.
Самое главное в этом виде диаграмм — какие именно сущности взаимодействуют и в каком порядке.
Дракон же специализируется на ветвлении (if then else) и циклах.
Диаграмма последовательности — это детализация юз кейса с точки зрения его участников.
Дракон также взаимосвязан с юз кейсами: Дракон диаграмма — это компактное представление всех юз кейсов данного алгоритма.
Для случая, когда сущность имеет особое значение, в Драконе имеется особая икона "полка".
Есть и специальные иконы для приёма сообщений (или ввода) и посылки сообщений (или вывода).
Эргономичность состоит в том, что правила Дракона имеют объективные основания. Кратко приведу некоторые из них:
1) Пересечения линий запрещены.
(Думаю, объяснять не надо. Чтобы избежать аналогии диаграммы с макаронами или с мотком ниток.)
2) Следующая икона всегда строго внизу.
(Читатель диаграммы никогда не должен искать глазами следующий шаг алгоритма — он всегда внизу.
Почему именно движение вниз? Потому что движение вниз естественно при наличии гравитации, оно ассоциируется с расслаблением.)
3) Квадратики соединяются не стрелками, а прямыми линиями.
(Чтобы визуально не засорять диаграмму. Стрелки не нужны: линия всегда ведёт вниз.
Жирная стрелка в Драконе всегда означает цикл, поэтому циклы сразу видны. )
4) У иконы "развилка" (if) один выход всегда внизу, а другой — справа.
(Во-первых, этим достигается предсказуемость и единообразие. Человек концентрируется на идее, а не на способе её представления.
Кроме того, выполняется следующий закон: дальнейшее развитие алгоритма всегда идёт вниз,
а ветвление — вправо. Никогда влево. Это соответствует направлению чтения текста в европейских языках.)
5) Косые и кривые линии запрещены.
(Граф программы в Драконе не только плоский, но и прямоугольный. Он удобен для восприятия.
В городе с прямоугольной планировкой ориентироваться гораздо проще, чем с беспорядочной.)
6) Икона "развилка" (if) имеет форму не ромба, как в блок-схемах, а усечённого ромба.
(Это позволяет вместить в неё больше текста и делает диаграмму более компактной.)
Легкость то в чем. Я вот бегло пробежался по книге и пришел к выводу о огромных схемах. Текстовая форма более компактна.
1) Текстовая форма более компактна, но зато графическая — более наглядна.
Проблема в том, что для того, чтобы понять текстовое выражение хотя бы средней сложности, его приходится распаковывать в уме.
В случае с графической диаграммой вся сложность находится на поверхности и хорошо видна.
Мозговые усилия, требуемые на распаковку текстовой программы, можно использовать в мирных целях!
2) Наш зрительный анализатор оптимизирован под графику, а не под текст. Графике уже миллионы лет, а текст недавно появился.
3) В диаграмме на языке Дракон присутствует дополнительная информация, которая не является необходимой
для выполнения алгоритма компьютеровм, но считается важным для читателей и пользователей.
См. правило "чем правее, тем хуже" и "чем правее, тем больше".
Запостите лучше сюда алгоритм балансировки AVL-дерева, пожалуйста.
А то все эти "Обед в ресторане" и "Покрасить забор" как-то не тянут на типичные задачи
попрошу привести здесь алгоритм быстрой сортировки,
балансировки бинарного дерева и парсера текста. Чтоб их можно было реально выполнить.
V>Да и сейчас, если чувствую нутром во время ревью чужого кода, что "здесь что-то не то", беру блокнот и рисую квадратики и стрелочки и сразу вижу это "не то" или
что напрасно сомневался.
Прекрасно. А теперь то же самое попробуй на формальном ДРАКОНе.
Делаю это с удовольствием. Пример:
Недавно руководство поставило задачу: устранить ошибки и падения в одном из наших парсеров.
Взял исходники, нарисовал по ним диаграммки на Драконе и всё понял. По ходу выделил неявный конечный автомат, кстати.
Засунуть слова в прямоугольники и заменить операторы на стрелочки много ума не надо.
И эта махинация ухудшила восприятие.
Например, чтобы понять, что else-if может повторяться 0 или более раз нужно распутывать клубок стрелок.
1) В Драконе для обычных переходов не используются стрелки, только простые линии.
2) Клубков, комков и вермишени в Драконе не бывает, потому что пересечения линий запрещены.
3) Одна из сильных сторон Дракона: циклы сразу видны.
Дело в том, что ДРАКОН — это не язык разработки use-case'ов и для описания формальных требований он тоже не очень подходит.
Все-таки в RFC много отcебятины, воды и что самое досадное — недоговоренностей.
Юз кейсы и Дракон — это почти как Партия и Ленин. Говорим одно, подразумеваем другое.
Дракон-диаграмма представляет собой компактное представление всех юз кейсов данного компонента системы.
Каждый из юз кейсов легко получить из Дракон-диаграммы, если вести пальцем по линиям и квадратикам.
Выбор на развилках даёт разные юз кейсы.
Большой плюс Дракона в том, что удаётся увидеть юз кейсы, о которых заказчик/начальник/аналитег даже и не догадывался.
Дракон устраняет недоговорённости и неопределённости в проектировании.
Насчёт практического использования Дракона вне космоса.
Делаем систему контроля доступа. Есть разные виды ресурсов, над ними можно производить разные действия. В ресурсы также зашиты ограничения доступа.
А ещё есть пользователи со своими правами. Есть группы, у которых тоже есть права. Пользователь может быть в разных группах. И ещё кое-чего.
Всё это вместе даёт довольно сложную картину. Самое страшное в ней — это то, что НИКТО полностью не представляет, как это должно работать.
Есть несколько спецов, каждый из которых имеет МНЕНИЕ об одном виде ресурса, которые его касается.
Собрал всю информацию, нарисовал Дракон-схемы ("раздраконил" (с)). Сразу всё стало на свои места.
Что дальше? Надо утвердить с боем полученные спеки у аналитега, а он немец, понимаете? Я не говорю по-немецки, общаюсь с ним на адском местном суржике "Norglish".
Шансов объяснить ему это всё в течение суток нет. Даю ему Дракон-схемы и через 30 минут получаю "зачøт". Немец всё понял, а ведь он Дракона-то и не видел никогда.
После этого, водя пальцем по линиям и квадратиком, набросал юнит-тесты. И уже потом написал основной код и спокойно лёг спать.
Результат — всё работает.
Дополнительно пишутся тесты, где моделируются все возможные крайние случаи, и пытаются таким образом обнаружить ошибки. Это делать должен не инженер — у него намылен глаз, ему эту работу поручать нельзя (вернее он конечно сам то проверит 10 раз перед сдачей, но он вполне может ошибиться и что то пропустить, человеческий фактор!).
Инженер не может создать программу испытаний для программиста, программист в свою очередь не владеет темой в комплексе.
Кто ставит задачу, тот и определяет критерии приёмки. Если инженер/аналитег пишет требования, то он же и должен составить тестовые сценарии.
Низкоуровневые юнит-тесты должен, конечно, писать сам программист, но любая функциональность, которая видна пользователю, проверяется по сценариям инженера/аналитега.
То же самое касается исправлений ошибок. Сначала инженер/куэйщик говорит, как оно должно работать после исправления, потом программист исправляет.
Не важно, какой процесс в конторе — agile, waterfall или базар. Если программист кодит ДО того, как составлен сценарий тестирования, придёт беда и чума.
Плюс Дракона в том, что он наглядно показывает все необходимые тестовые сценарии для алгоритма на одной диаграмме.
В FBD может быть (и обычно бывает) несколько "путей исполнения", которые сливаются и раздваиваются, что вполне логично для функциональных схем, обрабатывающих реальные сигналы.
В ДРАКОНе такого нет, там есть обычный линейный поток управления.
Ибо текстом я сделаю гораздо быстрее и качественней.
Я тоже печатаю быстрее, чем рисую. Но программы редко пишут, да часто читают. Дракон облегчает именно чтение и понимание.
Рисовать сложнее хотя бы потому, что в Дракон-диаграмму надо закладывать дополнительную информацию, которая не является необходимой для выполнения.
Но зато эта информация очень помогает чтению, поэтому дополнительные усилия окупаются.
Прогрессивный мир нынче смотрит на: метапрограммирование, зависимые типы, typesets, proof-carrying code. Крайне интересны исследования в области total functional programming.
Многое из перечисленного выше отлично работает вместе с Драконом. То же функциональное программирование, отлично сочетается с Драконом (ДРАКОН-Эрланг например).
Re[2]: Язык ДРАКОН — новая идея в программировании
СМ>1) Текстовая форма более компактна, но зато графическая — более наглядна. СМ>Проблема в том, что для того, чтобы понять текстовое выражение хотя бы средней сложности, его приходится распаковывать в уме.
Для этого есть декомпозиция, очень способствует...
Для наглядности графического представления схемы даже небольшой программы нужно развесить на стене, для большой стены не хватит. Возможно в той отрасли откуда Дракон произошёл это не так и плохо, но для других задач может быть затруднительно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[2]: Язык ДРАКОН — новая идея в программировании
Модификация быстрой сортировки, использующая дополнительную память (т.е. не по месту), записывается на функциональном языке в 2-4 очень понятных строчки, которые не содержат явных циклов и ветвления.
Даже если из дракон-схемы выкинуть код для простых случаев, все равно она останется куда более громоздкой, чем код на ФЯ.
