How is a block diagram organized?

I would like to understand the exact hierarchy of a block diagram.

If a block A is on top of block B does it mean that A is in some abstract manner build using B?

A concrete question:

I have a component C that calls components D,E to achieve its goal. Is C on top of D,E (since it uses them) or are these different unrelated blocks? When would be each case? aD,E are not a platform that C is build on but just something it uses.

What disturbes me is that I usually see block diagrams with a big base block and many开发者_开发技巧 small "roof" blocks, e.g. a framework base and many features over it. However in my example if every component is build using 2 others I would end up with a base containing many blocks and one "roof". Alternatively I would end up with unrelated (non hierarchical) blocks which seems to miss the purpose of this diagram (or does it?).

Blocks and roof have actual names when you are using UML to design your view of the application. UML uses decorations on lines between classes to denote their relationship. Typically the relationship is either a 'is a' or 'has a' relationship. It derives from another class, or it has another class as a member variable.

In practical uses of diagrams, a large amount of classes are often left out of the picture in order to clearly communicate a given idea on a given diagram. I often leave out a class hierarchy when I'm making a class diagram concerning a particular focus. It usually takes a large number of diagrams to fully describe an application, and you can even exclude some classes completely and chalk it up to implementation details.

I would highly recommend looking into UML's component diagrams, class diagrams, and then continue on to other styles that you will find useful including: state diagrams, sequence diagrams, and use case diagrams. The great part is that most developers will have seen these, or worked with them before.

If you mean architecture diagrams as in the big picture of a large-ish code base, then there is no standard as such. For example in your example, if D and E are on the same level, can they use each other - you'll see both used. Structure101 uses the convention that cells should only use cells below them - any upward dependencies in the actual code are flagged on the diagram (and in the IDE) as "violations".

If by architecture you're thinking of the relationship between classes, then UML is what you want and the arrows between the boxes specifies what does/should use what and how...

There's a trick to block diagrams.

They're just marketing.

If you want precise semantics, you have to use UML, which doesn't use block diagrams with simple casual "on top of". The "on top of" is clearly too vague.

If you have a "pyramid", and you'd rather not show that, then your lower-level blocks are too fine-grained.

Lump the detailed lower-level blocks into a bigger framework block. Then you can have fewer big blocks on the bottom.