Reading and making systems diagrams
There are no universally accepted rules for the symbols used in systems modeling diagrams.
Some organizations use a standard set of rules. If your organization does this, then the rules and their definitions should be available in a handbook or user's guide.
The rules I will use here include a mixture of common symbols and meanings. Feel free to change them to fit your needs or preferences.
The Basic Flow
The purpose of the diagram is to show how the elements that you have included in your system model relate to one another and to elements in the environment of the system. Your goal is to understand the situation ... not to create a perfect diagram. This means that sometimes the diagram will have to sacrifice accuracy for understandability.
Sources initiate flows from the environment, and sinks terminate them. Boxes inside the system often show events or containers, although they also may show decisions, processes, and other things or actions.
Arrows indicate relationships, and these always require communications. However, the communications may be in the form of messages, substances, electronic signals and so on.
These diagrams are not meant to be logical tools ... like the flowcharts used to design computer software ... they are meant to summarize your thoughts about the model. They mean something to you, but they may not mean much to other people.
(I usually produce two diagrams for each model. The first diagram is somewhat messy. It includes extra elements that will later be deleted, and it also include notes to remind myself of what I was thinking. I make the second diagram after the model is complete. The second one is intended for other people to read and is as clear and concise as I can make it.)
Rainwater
This first example shows a flow of rainwater. The water is a substance that arrives in the system (my house, in this case) from a cloudy sky. The rainfall hits my roof, where it flows through the roof gutters down into a big barrel. Later, I use a hose to move the water from the barrel to my lawn.
The labels I've used here are very "loose". They describe what's going on, but they do not follow the rules very closely. The "rainfall" is definitely a flow of water, but "roof gutters" is a place where the water flows ... as is "hose." Similarly, while "barrel" is a container, "roof" is a surface.
I use this example to emphasize my point about models. My goal here is to paint a picture of what's happening. I could have made a more detailed diagram with more items in it that would be 100% accurate ... but that would have been more confusing to me than this diagram.
Your main goal is to understand the situation. The purpose of the diagram is to summarize your thoughts and describe the situation to yourself. Later, if you need to make a report or a public presentation of your results, you can create diagrams intended to communicate your findings to others.
Remote Control
The second example shows a common situation
... a signal that causes a change in an element. Here, a remote control device sends a signal to a television set and commands it to change the channel.
In this case the flow is an electronic signal that contains a coded message for the TV set. The set reads the signal and executes the command indicated by the message. The second arrow shows a flow of channel changes. This is not technically a communication - (technically, it would be called a "change of state") - but I want to show the change in the model, so I diagrammed it that way.
There are ways to do this that might be more clear. For example, I could expand the "television" box to show some of the inner workings.
For some purposes, this would be better. But for my purpose, which is to give a clear picture of what is happening with the TV, the first diagram is better because it is simple and understandable.
The first diagram may not be technically complete, but it conveys all the data it needs to convey for me, at this moment. If I later need to get more deeply involved in the inner workings of the television's channel changing circuitry, then I'll go ahead and produce the more detailed diagram.
Another Example
The first example problem in the first systems thinking tutorial produces a diagram that looks like this:
Notice that this does not use any of the symbols that I just described. You can read about this diagram in the tutorial itself; the point I want to make is that systems thinkers create whatever kinds of diagrams they need to describe the situation in a practical way.
Diagrams and Graphs
You will often encounter these two terms: system structure; system behavior.
Structure: the organization of a system ... the way something is built.
Behavior: the movement of a system ... what something does.
Diagrams illustrate the structure of a system. The elements and relationships show what the system looks like and how it hangs together. Graphs illustrate the behavior of a system. They show what the system produces as its outputs over time.
For example, the rainwater diagram shows what my house looks like. You can see how the elements of the system are organized.
But the diagram does not tell you anything about the amounts of water that end up in the barrel. For that you need a graph.
The vertical axis shows the inches of rain in the barrel. The horizontal axis shows days. So each bar shows the amount of rain in the barrel on that particular day. On day one there were 20" of rain in the barrel. On day two I watered my lawn, so the amount dropped until the barrel was almost empty. On day four it rained and the barrel filled up. There is an overflow hose on the barrel that dumps water once it reaches the top ... the diagram does not show this, but the graph shows that the barrel does not seem to hold more than 30" of water.
Diagrams and graphs show different aspects of a system, and both are used frequently in systems analysis. Many more examples are shown in the tutorials that follow.
Remember This
Systems diagrams use symbols to illustrate elements and the relationships among them. You use diagrams to help you think about the situation. Later you may want to make another set of diagrams to communicate your ideas to other people.
The following tutorials introduce basic diagraming techniques and show some of the common patterns that arise in systems modeling.