Как организована структурная схема?

Question

Я хотел бы понять точную иерархию блок-схемы.

Если блок A находится поверх блока B, означает ли это, что A каким-то абстрактным образом строится с использованием B?

Конкретный вопрос:

У меня есть компонент C, который вызывает компоненты D, E для достижения своей цели. Находится ли C поверх D, E (поскольку он их использует) или это разные несвязанные блоки? Когда будет каждый случай? aD, E - это не платформа, на которой построен C, а всего лишь то, что он использует.

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

Answer 1

Если вы имеете в виду диаграммы архитектуры, как на общей картине кодовой базы большого размера, то стандарта как такового не существует. Например, в вашем примере, если D и E находятся на одном уровне, могут ли они использовать друг друга - вы увидите, что оба использовались. Structure101 использует соглашение о том, что ячейки должны использовать только ячейки под ними - любые восходящие зависимости в реальном коде помечаются на диаграмме (и в IDE) как «нарушения».

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

Answer 2

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

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

Я бы настоятельно рекомендовал изучить диаграммы компонентов UML, диаграммы классов, а затем перейти к другим стилям, которые вы найдете полезными, включая: диаграммы состояний, диаграммы последовательности и диаграммы вариантов использования. Самое замечательное то, что большинство разработчиков видели это или работали с ними раньше.

Answer 3

Есть хитрость для блок-схем.

Они просто продают.

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

Если у вас есть «пирамида», и вы не хотите показывать ее, тогда ваши блоки нижнего уровня слишком мелкозернистые.

Объедините детализированные блоки нижнего уровня в больший каркасный блок. Тогда у вас может быть меньше больших блоков внизу.