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.

"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.

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!

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!

https://www.airborn.com.au/method/layout.html
--
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.

PCB layout can be performed manually (using CAD) or in combination with an Autorouter. The best results are usually still achieved using atleast some manual routing - simply because the design engineer has a far better judgement of how to arrange circuitry. Surprisingly, many autorouted boards are often completely illogical in their track routing - the program has optimised the connections, and sacrificed any small amount of order that may have been put in place by manual routing. Generally autorouted boards are slightly harder for a technician to repair or debug, for this reason. Historically, PCBs used to be laid out by drawing or using stick on paper shapes on mylar film, - that really WAS manual routing!
--

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.

> 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.

Actually, schematics do not capture the nuance of all electronic circuit design, especially as the operating frequency becomes large and the physical realization is no longer electrically small.

Transmission lines and their effects are not captured on schematics at all, a real problem where I work. Schematics don't capture characteristic impedance or line length, both crucial design parameters in RF and microwave circuits.

An interesting side note is that the circuit diagram you chose breaks the rules - but is still understandable. The diagram you used does not have the "correct" representation of the resistors. But because the values are labled as ohms, we know what the diagram means. So, the analogy of circuit diagrams being like source code is not that close, either. Can you imagine what would happen if someone used 'while' instead of 'if' where they were supposed to?

How can we make constraints drive the execution ?

In physical systems god's rules or physical laws themselves govern the present and the future of the system's behavior. F=ma is a law and is also the dynamics, F=mdx^2/dt^2

In software models arbitrary OCL constraints for instance capture user requirements. These rules are declarative. Can we use these rules to drive the execution itself instead of doing a search in object interconnection space for constraint satisfaction ?

Why are all the images "WTF"s?

<a href="https://www.codinghorror.com/blog/archives/000561.html">https://www.codinghorror.com/blog/archives/000561.html</a>; - Explination on the "WTF" images.

I kind of a prove to your theory...
I started after my secondary school as an electronic technician... I use to developed circuits to control industrial components.
I got fascinated by the logic in the micro circuits and the into programming them... and then the micro processors and so on... today I am a system analyst. who knows...!?
Regards,
-Miguel

UML is too general purpose...

I think diagramming can be extremely useful and as useful as circuit diagrams! It will take something more like the current trend toward DSLs (domain-specific languages). Circuit diagrams, after all, are a domain-specific language for creating circuits. "Software" is a much broader subject with lots of areas that can benefit fromt their own (much smaller than UML) visual language.

One of the benefits of making a visual language small is that it's easier to learn and you can choose symbols that leverage "tacit" knowledge. That and the big one that it makes communication about a design easier (and in the case of, say, circuit diagrams... possible).

> I can't think of any purely visual programming environments at the moment, but I'm sure there are some out there.

A purely visual programming environment has existed since the early 80s. It is Prograph and a commercial IDE that supports it may be found at www.andescotia.com. Any program that can be written in C can be written in Prograph. In fact, the IDE is a multi-process, multi-threaded environment that is written in itself, a claim that LabView cannot make.

GOD WANTS TO JOIN THIS COVERSATION ABOUT SCHEMATICS

Just a thought, I haven't done any PCB work but when we code million gate ASICs we use Register-Transfer-Level languages like VHDL, Verilog and SystemVerilog that are at a much higher level than a circuit diagram / schematic and is more like traditional code. You code up the hardware and then you use synthesis tools on it afterwards to map it into gates.

Verilog itself looks like an awkward mash-up of C and Pascal, and SystemVerilog added constructs for object oriented programming. These languages have the concept of synthesizable (can be mapped to gates) and behavioural (simulation only) constructs. So you could use the object oriented constructs to test your design and but you couldn't use them to BUILD your design.

Anyhow, long story short, the circuit diagram representation is more analogous to programming in assembly. It's used for analog design a lot more than it would be for digital design where you would code at a higher level.

What difference is there between a processor executing a program and a dedicated circuit that does the exact same thing? Yes, there are countless variations in the designs of each hardware system but the functionality is the same in any case. A program is merely the virtual form of a dedicated circuit and, while a processor is running a program, it functions as a dedicated circuit. High level abstract programming constructs are useful for application developement, and they can be just as useful for circuit design too but, all that abstraction disappears at compile time when everything boils down to basic machine code which exists as electronic signals that DO follow God's law's.

Any method used to create hardware can be used to create software and visa versa. The APIs of operating systems and OOP language libraries can be implimented as virtual devices. Complex applications could be created using 2D or even 3D circuit diagrams with colorful textures, animations and special effects. Imagine the intense level of feedback you could get from an IDE like that. Much more fun than text, imo.

UML is too obtuse. I don't want to have to eat up memory (in my brain...which is limited) remembering what the bloody difference is between open arrow and closed arrow.

When I'm drawing classes or sequence diagrams or whatever, it's composed of squiggles, maybe some lines (mine definitely still look like squiggles), a few words, etc.

Or we'll just break out some index cards and make CRC cards, and line them up, point, etc, while talking about it.

I think the big difference is that the circuit boards are fixed, whereas code (nearly any code) is organic and changing.

A picture is worth a thousand words.

you need to add more pictures about work

I would like to hear from you in details by contact me direct on address bellow onikoyi p o box 91 igbajo 231009 osun statenigeria or slt lautech pmb 4000 ogbomoso oyo state nigeria e-mail. mosesinaction@yahoo.com call +2348038565396.
Am electrical electronics student/job so I need additional information about latest electronics development both solar and inverter circuits.
I like this site because they normally give me any informations I need with latest information.

thanks.

pls i need how to build a scrolling message display board

i want to know more about you

what is a circuit diagram?

stupid

ummmmmmmm.............. i still what to know what is a circuit diagram!

The trick is to make a connection, a correspondence, between the diagrams drawn and the functioning end product. That's pretty clear with a PCB... and there are scores (hundreds?) of people working on it for UML. Take a look at openarchitectureware, for instance. The real trick is that while a resistor is a resistor is a resistor, making for an easy correspondence between symbol and realization, the correspondence has to be defined for each UML symbol to some realization. And the DisneyWorld of things we've created (e.g. databases, blog posts, SMS messages, ip connections, spreadsheet cells) doesn't correspond so neatly to physical law, so it's harder.

I think it's worth following Martin Fowler's work/book on DSL's for a practical implementation of the 'correspondence' between a language convenient for thinking/working in and a suitable physical representation.

Will comment later! Sorry!!!