I have seen people using "mind-mapping" applications to capture their thoughts. I found this to be very limiting; one could only split into finer details, thus implying only a single direction and not capturing any interactions across branches. My mind does not map this way. I started using an Excel add-in called NodeXL (nodexl.codeplex.com). This tool was made for originally for mapping social networks like Twitter and Facebook. I found it very useful for mapping out interactions and relationships.
NodeXL image by Xiu Guo (www.xiudesign.com)
Beyond general mind-mapping, thinking in terms of components (NodeXL calls this a vetex, but it can be objects, blocks, element, etc.) and connections (edges or joints, links, interactions, interfaces, etc.) has many applications. A model of a system or process has a topology that can be described in a block diagram. Here are some examples:
- For CAD models Parts and Assemblies are the components and the Parent/Child relationships are the connections (the connections can be feature dependency, assembly constraints/mates, or context)
- For MBD models the Bodies are the components and Joints are the connections
- For a System Model the connections between the components could represent a signal, a flow (fluid, electrical), power, torque, etc.
- Using the block diagram similar to a flow chart, the component blocks are deliverables or decisions and the connections represent tasks or activities
- Use of a network diagram for the relationships between project stake-holders - the links can have properties such as the strength of the relationship
While simply having a diagram of the system is valuable, if the graphical depiction is static and/or non-associative it is likely to have little utility for me. I don't see the value of developing a schematic of a hydraulic or electrical system, for example, if I can't also use it to represent the simulated performance of the system. The components and connections need to be represented for for both a visual-only schematic and a system model, so why not develop the system as an executable model so that dynamic simulation can be used to drive design?
For CAD and CAE applications, the block diagram view can be incredibly important. A graphical view of component geometry is obviously useful for building models and reviewing simulation results (especially animations of moving components) but when the model's construction topology needs to be reviewed, working only the through the geometry-based graphical interface can be inefficient and error-prone. Many CAD & CAE applications have a viewer for depicting the model topology, but I have not seen them widely utilized.
Image courtesy of The MathWorks, Inc. (www.mathworks.com)
There are many specialized and general purpose software packages that utilize the block diagram as the basis of Model-Based Systems Engineering (MBSE) approach. Although the block diagram is an abstract view of the system, there is so much information that can be extracted. For example when a mechanical system is modeled as over- or under-constrained and all that is available is the graphical depiction, finding the issue may be quite difficult. With the block diagram available all connections and properties are easily located. The system topology and properties can be defined more precisely with a block diagram modeling tool and many packages offer the ability to build or modify the system programmatically.
I'm in no way diminishing the value offered by graphical depictions of systems, especially for viewing results (post-processing). Graphical output helps tremendously in communicating results to a broad audience. For building, debugging, and refining models, the block diagram is a indispensable tool.