Примеры хорошо разработанных диаграмм архитектуры программного обеспечения

Я трачу довольно много времени на рисование диаграмм архитектуры программного обеспечения, которые обычно состоят из вариантов блоков, связанных стрелками. Хотя эти диаграммы передают соответствующую информацию, они часто оставляют желать лучшего с точки зрения эстетики.

Некоторые примеры диаграмм архитектуры программного обеспечения, которые демонстрируют это:

• http://applicationarchitecture.files.wordpress.com/2011/06/f0039-component-diagram-complete-component-model.png
• http://applicationarchitecture.files.wordpress.com/2010/03/f0022-sample-network-diagram.png

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

Один (не программный) пример, который я нашел ( http://visual.ly/house-democrats-health-plan-flow-chart ), страдает (возможно, намеренно для демонстрации сложности) от множества тех же проблем, что и выше ...

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

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

Затем мы рассмотрим некоторые примеры конструкций, которые имеют дело с аналогичными проблемами.

Это тип блок-схемы / диаграммы процесса с акцентом на категории элемента / узла. Это, в свою очередь, является типом сетевой диаграммы узла с добавленной направленностью: по существу, узлами, которые могут иметь категории, и соединениями, которые могут иметь направление.

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

Итак, сложные блок-схемы и сетевые диаграммы с акцентом на направление / поток и категории узла / элемента. Первые основные принципы:

• Сделайте каждый узел / элемент простым
• Сделайте различия между типами элементов ясными и простыми с четкой иерархией между ними
• Сделайте поток и связность как можно больше фонового элемента

Подумайте об отношении сигнал / шум (иногда называемом соотношением «чернила данных» в контексте информационной графики): соединения являются визуальными ориентирами, а не данными, поэтому сделайте их как можно более тонкими, не делая их менее простыми для отслеживания. Также подумайте о фигуре : данные должны быть предметом, который рассматривается на переднем плане, визуальные подсказки, показывающие поток и категорию, должны быть фоном, который люди знают, но не отвлекают.

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

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

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

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

Очень много видов пива

Большая работа, проделанная PopChartLab , актуальна. Они специализируются на больших плакатах, показывающих множество взаимосвязанных вещей, и иногда они описывают свой процесс. Вот их описание проекта, в котором они действительно боролись с тем количеством вещей, которые хотели показать . Лично мне не очень нравится конечный результат (они усердно работали, чтобы приручить шарик для волос, но конечный результат все еще остается шариком волос), но читать то, что они пытались и что работало, а что не могло помочь.

Вот пример, который аккуратно использует размещение на странице, чтобы показать категории и порядок в потоке. Он не нуждается в яркой яркой цветовой гамме (которая является ссылкой на предмет, старый логотип Apple цвета радуги). Использование оси x и y страницы таким образом означает, что она может сохранить соединительные линии для других типов информации.

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

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

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

Хотите красивые диаграммы архитектуры программного обеспечения? Посмотрите на проекты с открытым исходным кодом, такие как Eclipse, Aptana, Magento, Android, Fedora и т. Д.

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

Такие компании, как Apple (например, документация для разработчиков для iOS и OS X), Google (документация для App Engine и Android), IBM, Oracle и даже производители аппаратного обеспечения, такие как Intel и Nvidia, должны иметь хорошие диаграммы архитектуры программного обеспечения или системы, которые можно почерпнуть из вдохновения. ,

Веб-платформы, особенно PaaS-провайдеры, такие как Heroku, AWS, EngineYard, OpenShift (Redhat), Cloudbees и т. Д., Также могли бы стать хорошими источниками для действительно хороших архитектурных диаграмм, поскольку их частично выполняют маркетинговую функцию.

Интересная статья об использовании диаграмм для архитектуры программного обеспечения - « Простые наброски для построения диаграмм архитектуры программного обеспечения» от Саймона Брауна.

Есть другие примеры отличных диаграмм от Lucid Chart по адресу https://www.lucidchart.com/pages/examples/network_diagram_software