Circuit board schematic and source code

[alex barylski]

Seems to be that source code is a far abstraction from actual circuitry(sp?) When building, or dealing with circuits you typically work with a schematic...my dad left one on the table for the daytime running lights or something (for the car) and while looking at it...I thought to myself... I wonder if anyone has successfully used a similar technique to describe a software architecture...up until now...I've seen only cheezy flowcharts or UML diagrams... Don't get me wrong. I like those, but neight does much for architecture...flowcharts are typically function specific (which is easy to figure out by just sifting through the code) and UML is great for showing me classes and the class hierarchy and API (which is usually easy to gain insight to as well) but architecturally...I've seen few examples... I wonder, if maybe it's because architeture is so difficult to explain...but perhaps using something of a circuit schematic would be justified??? Anyways, has anyone tried this? Seen something I could look at? Example architeture documents, etc??? Not sure what else to ask as I haven't thought about this much :) Cheers :)

It's frustrating being a genius and living the life of a moron!!!

[Chris Buckett]

Hockey wrote:

cheezy flowcharts or UML diagrams...

I remember that a book I read about uml a while back made the case that uml was designed to be the software engineers equivalent of an architects blueprint or an electricians schematic. There's more to uml than just class diagrams (9 types of diagram - use cases, activity diagrams, deployment diagrams, sequence ...) The thing is, that you you also need a good tool to create those diagrams - you don't get architects using and electricians using pencil and draught-board these days, they shell out for autocad and others. To create decent uml, you also need a decent tool Wikipedia[^] has a good list, but it'll probably take a couple of good books and sheer bloody mindedness to learn it thoroughly, as most of the books have mickey mouse examples. Also, the temptation to jump into code is just too great. Probably the best uml designers never go near the code, but just create the designs (much like a building architect wouldn't lay bricks). I don't like uml myself too much, either, but at present, it's the best tool for the job. And I am a long way from being an expert myself (I like coding too much. :)

ChrisB

[Garth J Lancaster]

Ive often described software (architecture) in terms of a 2d or 3d cube showing the components and how they relate/plug in to each other ... but beyond that Im not sure you can code from that sort of representation 'g'

[William Penington]

The Visual Programing Language in the MS Robotics Studio might be similar, but I'm don't think it works for anything other than robots.

[Joe Q]

VHDL is a "language" to program FPGAs, a hardware chip. It's fairly similar to a computer language with extensions for hardware operations. They have VHDL programs already made that put's a PowerPC chip onto the FPGA then hardware guys add the hardware conncetions they need around that, including defineing RAM and then a software guy comes along and programs it as if he has a PowerPC chip, DMA, and whatever else the hardware guys put on. Also, National Instruments uses a graphical language called LabVIEW to program FPGAs

[Dario Solera]

Joe Q wrote:

VHDL is a "language" to program FPGAs

Actually, VHDL is a language for describing any hardware component. There are two types of VHDL: functional and architectural. The first one describes the component's functions, the second one describes its architecture. You can use it to "generate" any hardware device, and also to program FPGAa and other programmable logic devices.

________________________________________________ Personal Blog [ITA] - Tech Blog [ENG] Developing ScrewTurn Wiki 2.0 (2.0 Alpha is out)

[Marc Clifton]

Hockey wrote:

my dad left one on the table for the daytime running lights or something

:laugh: That's not a circuit diagram, that's a wiring diagram. OK, so you see a switch and some fuses. Woohoo.

Hockey wrote:

flowcharts are typically function specific (which is easy to figure out by just sifting through the code)

Flowcharts aren't just for function specs, they're good for any level of abstraction. Like "Battery connects to switch, switch connects to light". :rolleyes:

Hockey wrote:

and UML is great for showing me classes and the class hierarchy and API

UML does a lot more than that. Packages, state and sequence diagrams, timing, use case, activity, etc. It's just that you don't see most people using UML for things other than classes, sometimes sequences, and rarely state or use cases or other things UML can do. If you look at a *real* circuit diagram, one thing you'll notice are these little black boxes called integrated circuits that themselves have extremely complicated circuits in them. It's like code. You have black boxes, like assemblies or COM or classes, depending on your level of detail, in an application as well. And like software, hardware schematics don't tell the whole story. Look at a spec for chip or component, and it'll include information on timing, state, tolerances (think of them as exceptions), etc. And even that is useless. You also need the physical information of the package or circuit board so you can figure out how to mount it on the PC board or create the write enclosure for it. There certainly are analogies one could make and commonality in how circuits and components are designed. I don't think you've looked enough at what UML and flowcharting is capable of doing though with regards to software. Marc

Thyme In The Country

People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith

[Christopher Duncan]

The problem is not that we lack the tools to do analogous in depth diagrams of software. From flowcharts to UML, there are many ways to document software, either before or after the fact. The difficulty lies in the fact that completely documenting software at the lowest level, as they attempt to do in the hardware world, would produce a printout which would probably collapse the table it was placed on. And that's for a small system. Add to this the shifty nature of the software development tools upon which we depend. With hardware, you can generally count on a resistor of a specific value to behave in a predictable manner. In the software world, however, we must work with an ever changing sea of interdependent APIs, often of dubious quality, resulting in a development environment which is simply not predictable. Consequently, in the real world, software is rarely specified in complete detail before being built, as a hardware component might be. The very nature of programming is by necessity one part design, one part experimentation, and one part burning incense and sacrificing chickens. It's almost impossible to completely specify software up front, and it's entirely too laborious to fully document it after the fact, since Marketing is already clamoring for the next version. We have the tools. It just doesn't make sense to use them in the same way as our hardware brethren.

Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com