UML, Circuit Diagrams, and God's Rules

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 ?

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

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.

Well I find all of this way too simple on CREATELY - http://creately.com/