UML-Diagramm für AVR-Programm

Jo klar gibbet die. Aber sicher, dass du UML meinst? UML ist eine 
Beschreibungssprache für Objekte, C ist aber nicht objektorientiert...

Oder meintest du etwa Programmablaufpläne (PAP)?

Also ich hab in meinem Projekt mehrere C-Files. In jedem dieser C-files 
sind Funktionen enthalten. Ich möchte einfach graphisch darstellen, 
welche Funktionen in den Files enthalten sind und wie sie untereinander 
zusammenhängen.

Ich habe immer mit Poseidon und auch Netbeans gearbeitet und finde es OK 
(kostenfrei). Mittlerweile denke ich man kann mit UML nur Deppen oder 
Uniheinis beeindrucken, das Programm wird davon nicht besser. 
Sarkastisch: Ich glaube nur triviale Software lohnt sich auf UML hin 
umstrukturiert zu werden. Ansonsten: Schnittstellen im Team absprechen 
und individuell verständlich schriftlich fixieren, das isses meiner 
Ansicht nach. UML bringt keinen echten Gewinn ist mithin noch nicht 
praxistauglich.

Also UML (Unifined Modeling Language) ist eine allgemeine 
Beschreibungssprache.
Es sollte schon bei der Planung klar sein ob so etwas angestrebt wird 
oder nicht.
Denn üblicherweise modelliert man das Problem via UML und läßt dann 
daraus einen objektorientierten Ansatz generieren.
C kann die Kapselungen nicht darstellen, daher ist es sinnfrei UML für 
ein vorhandenes Programm einzusetzen, welches keinerlei 
Objektorientiertheit hat.
Siehe z.B.: http://de.wikipedia.org/wiki/UML
Für ein strukturiertes Programm mit Prozeduren würde ich eher wie schon 
erwähnt einen Programmablaufplan pro Prozedur erstellen.
Siehe http://de.wikipedia.org/wiki/Programmablaufplan
Oder optional:
http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm
Es gibt so etwas ähnliches wie JAVA-Doc für C:
http://www.stack.nl/~dimitri/doxygen/
Nur kenne ich kein Tool, das aus einem bestehenden Programm UML/PAP/NSD 
erzeugt.
Wirst also doch einfach selbst malen müssen.

UMLer wrote:
> Also UML (Unifined Modeling Language) ist eine allgemeine
> Beschreibungssprache.
> Es sollte schon bei der Planung klar sein ob so etwas angestrebt wird
> oder nicht.
> Denn üblicherweise modelliert man das Problem via UML und läßt dann
> daraus einen objektorientierten Ansatz generieren.
> C kann die Kapselungen nicht darstellen, daher ist es sinnfrei UML für
> ein vorhandenes Programm einzusetzen, welches keinerlei
> Objektorientiertheit hat.

Ich hab schon mehrmals versucht, sowas zu "Modellieren", aber wirklich 
genutzt hats dann nachher trotzdem nix. Ständig wird hier und da mal 
wieder was abgeändert, dann ist ne Schnittstelle nicht ausreichend und 
wird flux umgestrickt und und und.
Also bisher fand ich nen Header mit Doxygen-Tags drinne immer 
brauchbarer.

@ Sven Pauli:
Das Problem liegt darin, das UML eine allgemeine Beschreibungssprache 
werden sollte, mit der graphisch einfach und ohne detaillierte 
OO-Kenntnisse komplexe Dinge modelliert werden können sollen (oder so 
ähnlich).
Zwischen Version 1 und 2 gibt es einige größere Umbauten/Erweiterungen.
UML steht oberhalb irgendwelcher Programmiersprachen und OO-Konzepte.
Es ist wie der Name schon sagt zur Modellbildung gedacht und nicht zur 
Programmierung.
Das es bei echten Projekten meist mehr Arbeit als Unterstützung bedeutet 
liegt auf der Hand, da in einem echten Projekt niemals ein 100% Lasten- 
und Pflichtenheft erstellt wird.
Ist leider so vor allem im IT Bereich.
Doxygen wendet sich wie JAVA-Doc an den Maintainer der Software, so das 
eine schnelle und übersichtliche Dokumentation der einzelnen Funktionen, 
Parameter usw. erstellt werden kann.
Das nützt aber einem Projektmanager, der das Produkt beschreiben soll 
und dann z.B. einen Flyer für PR/Messe erstellen rein gar nichts.
Damit wären wir dann wieder bei der Grundsatzdiskussion über Projekte 
und deren Management, was im IT-Bereich meiner Erfahrung nach nicht 
wirklich existent ist.
Leider :-(