mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UML-Diagramm für AVR-Programm


Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

In meinem AVR-Projekt ist es jetzt an der Zeit, um an die Dokumentation 
zu denken. Ich soll sowas wie ein UML-Diagramm für mein C-Programm 
erstellen. Gibt es dafür fertige Tool, die ihr empfehlen könnt? Ich habs 
mit MS Visio versucht, komme aber damit nicht klar. Könnt ihr mir 
helfen?

Gruss
Patrick

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: UMLer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: UMLer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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 :-(

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.