Re[9]: Текст и схемы как эквиваленты записи
От: PSV100  
Дата: 10.08.12 15:39
Оценка:
Здравствуйте, VladZharinov, Вы писали:

PSV>Спасибо за "матподготовку".


VZ>Пожалуйста. На самом деле по математике-то схем почти ничего не было сказано. Вообще-то главное [...]


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

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

Под впечатлением от Amber была попытка рисования схем по мотивам, указанным мною в соседнем посте
Автор: PSV100
Дата: 20.07.12
. Сразу же вылезли неприятные моменты:

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

— Наличие разных "ромбиков" — маленьких и ромба с текстом (вопрос) — вводит неоднозначность в стиль языка. Необходимо отказаться от усеченного ромба с текстом, но в большинстве случаев (для развилок "да/нет") тогда требуется больше места по вертикали;

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

— "Ромбики" и "квадратики" выглядят как-то "не к месту" в таких "тяжёлых" случаях, как этот:



Рисунок не очень-то нагляден, здесь суть в том, что если использовать наклонные линии, то они должны быть под 45 гр., тогда они более приятны глазу при входе/выходе в/из ромбик/квадратик, а это требует больше места по вертикали. В таких случаях чёрточки UML приятнее, да и нет разделения на разные элементы соединения/слияния:



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



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

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

А попытка использовать Amber-мотивы себя не оправдала. "Ромбики" с "квадратиками" выкинули и в очередной раз поигрались с чёрточкой из UML внутри ДРАКОНа:



Здесь есть и "мульти-шампура", и "множественный выбор" (в ветке "С"). Недостаток этих чёрточек. Во-первых, нужны какие-то формальные ограничивающие правила для составителя по поводу использования наклонных линий при соединении/разделении. Если использовать строгие драконовские маршруты, которые часто в таких случаях окажутся "шибко ломаными" — будет ещё хуже. Во-вторых, в сложных случаях соединения "леса" не избежать, и этот лес также требует приличного места по вертикали, к тому же иногда чёрточки из "леса" лучше убрать: будет даже проще, если линии работают "без посредников", т.е. от квадратика к квадратику.

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



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



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

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

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



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



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

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



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

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

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