Про диаграммы для @squadette

Published by @9000 on 2017-05-12

Disclaimer: Диаграммы мне нужны редко; > 95% моих задач решают тексты. Хорошо структурированный текст (см. напр. Org mode) заменяет схемы во многих случаях.

Это ответ на вот этот пост @squadette.

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

Схема (и другая любая картинка) полезна тогда, когда она передаёт какой-то существенный аспект лучше, чем текст. Обычно так бывает, когда число взаимосвязей между некоторыми сущностями становится существенно больше 1. Текст хорошо передаёт линейно связанные структуры, деревья с небольшой степенью ветвления (мало больших веток, ветки в основном мелкие, на 1-2 предложения). Более сложные структуры обычно легче воспринимать в виде планарного графа.

Как вы понимаете, сколько схем должно появиться в процессе разработки?

Никак :) Но обычно их появляется мало. Основное их назначение — показать важные взаимосвязи между блоками, которые потом описываются в основном текстом (например, кодом). Такие сильно связанные, существенно нелинейные места обычно составляют малую долю описаний.

Как вы оцениваете сложность схемы?

По числу объектов и числу связей. Дополнительную сложность придают трудно планаризуемые схемы, с пересечениями линий, линиями между далёкими объектами, с большим числом линий у некоторых объектов, etc. Обычно это повод снизить детализацию и провести декомпозицию.

Вообще, иерархичность / фрактальность рулит.

Хорошая схема относительно легко разбивается на подсхемы, и обычно древообразна, с небольшим числом связей существенно поперёк иерархии. Очень часто “сложная и запутанная” схема разбивается на несколько параллельных деревьев с рядом общих узлов; в таком виде их можно и рассматривать.

Может ли быть полезной схема на которой три объекта? Два объекта? 200 объектов?

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

200 объектов осмысленны в двух случаях.

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

В древности, конечно, бывали огромные принципиальные электрические схемы с таким числом элементов (например, цветной телевизор). Разбираться в них было довольно болезненно, но поблочная разметка помогала сузить область поиска. Более крупные принципиальные схемы, например, ЭВМ СМ-4, были неизбежно разбиты на блоки, просто затем, чтобы помещаться на бумаге; помню смутно, на на среднем листе было, кмк, сильно менее 100 элементов.

Когда я активно проектировал БД, я много рисовал ER-схем. Их достаточно часто приходилось резать на подсхемы по разным соображениям. Типа, у нас есть БД магазина; можно отдельно посмотреть на подмножество таблиц, нужных для работы с каталогом, отдельно — для работы с заказами, отдельно — таблицы про движение денег, отдельно — grand scheme of things, со всеми таблицами, крома аудита, но от таблиц оставлены только имена, etc.

Разумеется, множества объектов на этих суб-диаграммиах пересекаются и берутся из общего для всей схемы набора. Кмк, это не спецфично для схем БД; такое должен уметь каждый серьёзный редактор диаграмм, так же, как каждый серьёзный текстовый редактор должен уметь folding / outline mode.

Как вы решаете вопрос с количеством связей между объектами и какие графические виды связей вы используете?

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

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

Используете ли вы цвета при рисовании схем?

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

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

Легко и надёжно разичимых цветов мало, особенно на светлом фоне: менее десятка для заливок, 3-5 для стрелок. Обычно я применяю 2-4 цвета; больше уже начинает напрягать.

Какие виды графических схем вы используете?

  • Схемы “общего вида”, графы из прямоугольников и стрелочек. Они обычно показывают движение информации и какие-то свойства узлов обработки информации. Такие диаграммы я рисую чаще всего, и они нередко есть начальная фаза для более специальных типов диаграмм.
  • ER diagrams полезны для проектирования и документирования БД (но требуют вложений, чтобы быть полезными).
  • Для описания протоколов с несколькими участниками, особенно близких к железу, хорошо подходят “sequence diagrams”.
  • State machine diagrams бывали полезны иногда.
  • Определённую пользу могут приносить IDEF0 и подобные схемы описани процессов, и даже use case diagrams (но последние по моему опыту осмысленны только в начале проекта и достаточно эфемерны, чтобы рисовать их только на бумаге или доске).

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

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

  • Большая часть UML, особенно диаграммы классов.
  • Все схемы, где за связями невозможно легко проследить, особенно если связей много и они иногда проходят “под” другими элементами.
  • Схемы, на которых невозможно разорбать надписи, одновременно окидывая взглядом схему целиком. Особенно грустно, когда на схеме при этом полно пустого места.

В целом, бесполезны схемы, нарисованные “для красоты”, а не для удобства пользования.

Как вы воспринимаете взаимосвязи между разными схемами, присутствующими в проекте?

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

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

Да и не встречал я проектов, где так уж много важных схем; не помню ни одного, где их было бы более десятка, а чаще их от 0 до 3.

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

Каковы ваши критерии оценки “эстетичности”(?) схемы?

“Некрасивый самолёт летать не будет” (ц)

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

Если схема хорошо выглядит как абстрактная картина, но неудобна прагамтически, то это абстрактная картина, но не схема. (Такое нередко случается с “инфографикой”, где “инфо-“ оттесняется на задний план.)

[П]редставьте себе, что одну из схем, которые вы нарисовали, будет рисовать каллиграф тушью на рисовой бумаге.

Пусь рисует; наверное он знает, что делает. Мне же наверняка придётся эту схему ещё раз 10 подправлять, поэтому в самом гламурном случае она будет напечатана на цветом принтере для висения на стене и черкания заметок поверх, а в 99% случаев останется только на экране.

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

Задумался. Наверное, нет. Традиционный инструментарий и так очень богат.

Какие быстрые критерии вы используете для быстрой валидации графической части проекта?

  • Нет объектов без связей.
  • Нет обхектов без подписи / названия или их внятного графического эквивалента.
  • Все связи можно проследить.
  • Схема односвязна; если нет, то это несколько схем на одном листе, они должны быть явно разделены.
  • Нет объектов, куда входит и откуда выходит слишком много стрелок; если есть, то это проблема с уровнем детализации, надо либо показать структуру мега-объекта, либо снизить детализацию вокруг него.
  • Нет нескольких в точности одинаковых достаточно сложных фрагментов (copy-pasted). Если есть, то это тоже проблема детализации, такой фрагмент надо вынести в отдельную схему. Можно стерпеть два одинаковых сложныж фрагмента, но тогда их одинаковость надо визуально подчеркнуть, обвести границы фрагментов, etc. Если есть небольшое различие между в остальном одинаковыми фрагментами, его тоже надо визаульно подчеркнуть.
  • Указано направление всех связей; ненаправленные связи не нужны почти никогда.
  • Если это схема данных (напр. БД), показана cardinality для всех связей (“куриные лапки”, цифры, “многослойность” объекта, etc).
  • Про объекты с только входящими и только выходящими стрелками понятно, почему они такие, т.е. их надо найти и пристально рассмотреть.

Как-то так.


2015-2017 Mokum.place