Very few software engineers use UML symbols to design software, but electrical engineers regularly use circuit symbols to design electronics:
I think the big difference is that, even though circuit diagrams are idealisations, they’re still an accurate and complete representation what goes on the PCB at the end of the day: they’re visual source code. Give the circuit diagram to any two electronic engineers, and they’ll come up with more-or-less the same board.
The analogy just doesn’t cut it.
they’re still an accurate and complete representation what goes on the PCB at the end of the day: they’re visual source code
I think UML aspires to be a circuit diagram, but point taken. So they’re more analogous to purely visual programming environments.
That’s fine, since in my previous post, I maintained that “code is a perfectly reasonable place to model”. Even if it’s all text.
I can’t think of any purely visual programming environments at the moment, but I’m sure there are some out there.
Since when are circuit board designs “idealized” concepts? There is a 1:1 representaion between circuit and glyph. The glyph may represent something made of many pieces or a sub component of a bigger piece (such as a transformer or an IC), but it still represents a discrete part that physically exists in 1:1 relation. You want an not gate? One wire in, one wire out, not gate in between.
Electronics are hard, physical things, they definitely exist.
Programs are made out of thoughts and concepts, and have about the same physical reality as pixie dust, and work basically the same way (think happy thoughts!)
No, I’m not kidding. You try holding a sort routine in your hand! Never happen, the best you can ever do is hold a representation of a sort routine in your hands, be it on paper, or arranged in magnetic bits on a platter, its still not the actual sort routine. The sort routine exists effermerally in the flow of electrons that blast through the cpu (which is made of those very real physical circuits we discussed earlier).
Programs, even when they are coded into a computer have as much physical substance as the original idea that spawned them.
I’ve never lost my original sense of wonder that what we are doing is closer to magic than science is so many ways.
As such, how do you diagram an idea? Can you draw a conclusion? Draw happy? Draw a stubbed toe!
It doesn’t work. Restricting the ideas to computers makes the problem harder, not easier. How abstract should your diagram be? Do you draw boxes for the applications? For the methods? THe variables? Is a sort routine an funnel instead of a box? Maybe a robot shuffling blocks? How much detail do you use? How much do you need?
No diagraming concept ever works for everyone, because thought is a personal experience and you can only diagram a thought like everyone else if you think exactly like them.
Worse, a style for drawing batch process doesn’t work for state transitions, but state transitions include tiny batches.
UML diagramming for everything is an attempt to catch the wind, and equally doomed.
Ultimately, the diagram IS the code. The code really just represents the idea with more detail. UML is just a doodle along the way.
It’s because, IMHO, that UML isn’t freaking obvious. It’s obtuse. What’s the open arrow, open circle mean again?
(Great post, BTW)
But there are physical laws to software development. Laws that my clients are always trying to break.
For example, the law of time, cost, bugginess, pick any two to reduce. Yet here are my clients asking me to reduce all three. God* bless them.
UML is not a circuit diagram. There is no direct mapping of LOCs to Use Case Stories, or Interaction Diagrams or even Class diagrams. UML is in the realm of vague description. That makes it a lot to describe the whole system, but doesn’t really tell you anything about the actual implementation.
Circuit Diagrams give you a one-to-one mapping of symbols to components. They exist in the ‘realm of Lego’; that is to say, physical that actually connect together.
If you want to describe software in the ‘realm of Lego’, you’re going to find yourself using State Diagrams and Flow Charts, not UML. Flow charts can be mapped directly onto LOCs. But even then there is some vagueness: does the implementation have structured constructs (if…then…else, etc) or is it all gotos?, does shared data have to be globals or can we encapsulate it into an object? These are higher-level question that flow charts don’t really address. In much the same way as the final board layout, with grounding planes and external power supplies, is not well represented in a circuit diagram.
I suppose in the end it comes down to automation. You can give a computer documents from the Lego realm and have actual physical constructs (completed boards, program binaries) come out the other end. Hand a computer a document from the realm of vague description and the best it can do is redraw your class diagram without overlapping lines.
D-E-I-T-Y, Jeff. Deus, dei, deo, deum, deo.
Otherwise, Scott is right. Circuit diagrams are much lower level than most UML constructs – they’re really pseudocode. The EE equivalent of UML would be a CPU diagram where a box just says “Arithmetic-Logical Unit”. Like UML, those diagrams are useful as an overview but cannot be used to immediately construct the CPU.
Drawing UML :
drawing a class…
1 box : 4 lines
class name : avg. 1-3 lines pr. letter.
property seperator : 1 line
properties : avg. 1-3 lines pr. letter.
method seperator : 1 line
methods : avg. 1-3 lines pr. letter.
drawing a database:
1 box : 5 lines
database name : avg. 1-3 lines pr. letter.
relation : 1 line + avg. 1-3 lines pr. letter.
…yep UML is faster 
Your analogy is WRONG that is why it does not work or make sense to you!!!
Electronic engineers also have conceptual diagramming aids that assist in the design process e.g. black box, ladder diagrams, state transition tables, state machine diagrams, sequence diagrams, etc. Now you know where the inspiration for a good deal of the UML diagrams came from!
A circuit diagram is a VERY weak analogy to UML! It is more like source code. The circuit diagram is used to provide the manufacturing process with a design phase logical output that assist in the implementation in real hardware and component. Similarly, source code is used by the interpreter/compiler to manufacture a piece of functioning software. I think that is a slightly better analogy.
You should maybe have asked someone who knew about both hardware and software design before making such a flawed posting! Sad that is spoiling an otherwise spot on blog.
Regards
John
Exactly my feeling too Scott (Hanselman)!
The UML symbols aren’t great. Compared to the beautiful electronic circuit symbols they are nothing IMHO.
Let’s go back and try to invent a better UML shall we? (I’m serious)
Let’s go back and try to invent a better
UML shall we? (I’m serious)
A few years ago Kent Beck had a birds of a feather session at UML World (I think in 2001.) Some time during that session he came up with the idea of a “Galactic Modeling Language” (or something like that) and start making fun of UML and its complexity. To make things simpler he was suggesting a modeling language with a single element: the line A box was just 4 lines, an arrow was just 3 lines, and so on and so forth.
(tongue-in-cheek) I don’t think his modeling idea caught up momentum officially but to be honest it’s the most common type of modeling that see in use at companies’ whiteboards.
I’m with the guys who don’t think a circuit diagram is an accurate representation of anything. In that sense it’s like UML - it’s just a conceptual step. Circuit diagrams are full of approximations and assumptions, and leave a lot of stuff out. I do like the way you used a valve amp circuit as your example, though. very cool!
Circuit diagrams also have a variety of purposes, from early design descriptions to post facto maintenance aids. Again, like UML. It can be a lot of work to understand an actaul circuit board from a diagram, and even more to build a working circuit board from one. usually requires a computer for anything non-trivial… hey, just like UML!
“I can’t think of any purely visual programming environments at the moment, but I’m sure there are some out there.”
There was a very simple one for VB called LiveWire I believe. Labview comes to mind also. Of the two, Labview appears to be more usefull. Then there is the promise of the draw-able workflow in Biztalk.next() (where Biztalk.EOF never == true). (that’s right, I went old-school ADO, I went there). But at some point, with any visual programming tool, you have to get your hands dirty if you keep adding features. You’ll always hit a wall.
Why are UML diagrams less than useful, yet ERDs are very useful? The physical representation of something? It’s got to be more than that. Eventually, your UML class is represented by lines of code the same as your ERDs are represented by lines of DDL. I think it’s the simplicity, once you jettison all the complicated UML symbols and simplify the diagrams, it’s easier to understand.
Capacitator? Capacitor, surely.
Of course! We create stuff out of thin air, and love it. Though programming is still riddled with limitations.
(But the spelling is “deity”).
Geesh, I misspell one word, and I get such grief! 
Fixed.
Your analogy is WRONG that is why it does not work or make sense to you!!!
It’s not meant to be a perfect analogy. It’s meant to show the difference between diagrams used to model the physical world, and diagrams used to model the virtual world.
And no matter how perfect your circuit diagram is (and it will be far more perfect than any UML can ever be for software), you have a lot of physical problems to contend with when printing up a 5 or 6 layer PCB!
The connections on the PCB should be identical to the circuit diagram, but while the circuit diagram is arranged to be readable, the PCB layout is arranged to be functional, so there is rarely any visible correlation between the circuit and the layout.
So the pure high-level logic of circuit diagram itself is not enough – we require even more, different diagrams when transitioning from logical to physical.
Why are all the images "WTF"s?
a href="http://www.codinghorror.com/blog/archives/000561.html"http://www.codinghorror.com/blog/archives/000561.html/a - Explination on the “WTF” images.
I can’t think of any purely visual programming environments at the moment, but I’m sure there are some out there.
Well, LabView is one.