Rules

UML, Circuit Diagrams, and God's Rules

Very few software engineers use UML symbols to design software, but electrical engineers regularly use circuit symbols to design electronics:

Circuit symbols are constructed into circuit diagrams-- the the visual language of electricity:

If circuit diagrams are a standard, universally understood way to talk about electronics, why doesn't UML enjoy the same currency for software development?

Well, one obvious difference is that software, unlike electricity, isn't subject to God's laws.* And God didn't invent x86. Software development is far less amenable to formal diagrams because, well, it's something we just made up. And we keep changing the rules all the time. As Brooks points out in The Mythical Man-Month, software developers are essentially playing the role of God:

Why is programming fun? What delights may its practioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctiveness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this tractability has its own problems.)

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

Software developers do not have a monopoly on creativity. A clever circuit is no less imaginative than a clever algorithm. But software development is a "tractable medium." If we decide the speed of light is not to our liking, we just change it. Imagine the difficulty an electrical engineer would have working on your circuit diagram if, on that diagram, you had changed something fundamental, like the conductivity of copper.

But even with the helpful constraint of God's rules, circuit diagrams are still idealized representations of the final product. You need a printed circuit board to implement the circuit diagram-- and the translation from circuit digram into PCB typically invoves a lot of real-world compromises.

This is not to say that formal software diagramming systems like UML aren't useful in software engineering. They can be. But they'll never be as useful as circuit diagrams are to electrical engineers.

Circuit Diagrams

Next Page: Circuit Symbols
Also see: Block Diagrams

Circuit diagrams show how electronic components are connected together. Each component is represented by a symbol and a few are shown here, for other symbols please see the Circuit Symbols page.

Circuit diagrams and component layouts

Circuit diagrams show the connections as clearly as possible with all wires drawn neatly as straight lines. The actual layout of the components is usually quite different from the circuit diagram and this can be confusing for the beginner. The secret is to concentrate on the connections, not the actual positions of components.

The circuit diagram and stripboard layout for the Adjustable Timer project are shown here so you can see the difference.

A circuit diagram is useful when testing a circuit and for understanding how it works. This is why the instructions for projects include a circuit diagram as well as the stripboard or printed circuit board layout which you need to build the circuit.

Drawing circuit diagrams

Drawing circuit diagrams is not difficult but it takes a little practice to draw neat, clear diagrams. This is a useful skill for science as well as for electronics. You will certainly need to draw circuit diagrams if you design your own circuits.

Follow these tips for best results:

• Make sure you use the correct symbol for each component.
• Draw connecting wires as straight lines (use a ruler).
• Put a 'blob' () at each junction between wires.
• Label components such as resistors and capacitors with their values.
• The positive (+) supply should be at the top and the negative (-) supply at the bottom. The negative supply is usually labelled 0V, zero volts.
  If you are drawing the circuit diagram for science please see the section about drawing diagrams the 'electronics way'.

If the circuit is complex:

• Try to arrange the diagram so that signals flow from left to right: inputs and controls should be on the left, outputs on the right.
• You may omit the battery or power supply symbols, but you must include (and label) the supply lines at the top and bottom.

Drawing circuit diagrams the 'electronics way'

Circuit diagrams for electronics are drawn with the positive (+) supply at the top and the negative (-) supply at the bottom. This can be helpful in understanding the operation of the circuit because the voltage decreases as you move down the circuit diagram.

Circuit diagrams for science are traditionally drawn with the battery or power supply at the top. This is not wrong, but there is usually no advantage in drawing them this way and I think it is less helpful for understanding the circuit.

I suggest that you always draw your circuit diagrams the 'electronics way', even for science!

[I hope your science teacher won't mind too much!]

Note that the negative supply is usually called 0V (zero volts).
This is explained on the Voltage and Current page.

UML, Circuit Diagrams, and God's Rules

UML, Circuit Diagrams, and God's Rules

Very few software engineers use UML symbols to design software, but electrical engineers regularly use circuit symbols to design electronics:

Circuit symbols are constructed into circuit diagrams-- the the visual language of electricity:

If circuit diagrams are a standard, universally understood way to talk about electronics, why doesn't UML enjoy the same currency for software development?

Well, one obvious difference is that software, unlike electricity, isn't subject to God's laws.* And God didn't invent x86. Software development is far less amenable to formal diagrams because, well, it's something we just made up. And we keep changing the rules all the time. As Brooks points out in The Mythical Man-Month, software developers are essentially playing the role of God:

Why is programming fun? What delights may its practioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctiveness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this tractability has its own problems.)

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

Software developers do not have a monopoly on creativity. A clever circuit is no less imaginative than a clever algorithm. But software development is a "tractable medium." If we decide the speed of light is not to our liking, we just change it. Imagine the difficulty an electrical engineer would have working on your circuit diagram if, on that diagram, you had changed something fundamental, like the conductivity of copper.

But even with the helpful constraint of God's rules, circuit diagrams are still idealized representations of the final product. You need a printed circuit board to implement the circuit diagram-- and the translation from circuit digram into PCB typically invoves a lot of real-world compromises.

This is not to say that formal software diagramming systems like UML aren't useful in software engineering. They can be. But they'll never be as useful as circuit diagrams are to electrical engineers.

* Or the deity of your choice.