Slashdot Mirror

← Back to Stories (view on slashdot.org)

Software Diagramming In Embedded Systems?

Posted by timothy on from the can't-be-completely-obscure dept.

afd100 writes "I work for a medium-sized company building embedded systems using C. As of yet, we do not have a great design methodology, but it is something we're working on. For the last 7 years now, we've been documenting our embedded software in an IEEE'esque Software Detailed Design, and using a very cryptic block diagram to explain our software. What does the embedded software community at large currently use to graphical represent their software or do they even try this? Since the programming is functionally decomposed, is UML the right way to go?"

1 of 52 comments (clear)

  1. Re:Ditch diagrams. I'm serious. by Evanisincontrol · · Score: 1, Redundant

    2) Unnecessary cruft which no one uses.

    I disagree completely. If you have ever walked blindly into a system with nothing but code and diagrams to help you through, you'd know that those diagrams are invaluable. Unless you want to waste man power by having another architect hand-hold your way through the system for hours/days/weeks until you've got a firm grasp on it, there's just no substitute for well-made design docs.

    I think the notion of "diagrams are useless" spawns from system architects who don't have the foresight to realize that diagrams aren't meant for themselves, but rather everyone else who has to deal with the system thereafter.