c Bibliothek mit strukuren in uml darstellen

[UMLenker (Gast)]

Hi habe eine recht unübersichtliche Bibliothek mit vielen Strukturen.
Ich habe in powerpoint meine erste Darstellung davon erstellt.
Allerdings möchte ich das etwas professioneller machen.
Vlt. Gibt es uml Standards dafür?
Jemand ne Idee?

[Klaus W. (mfgkw)]

Ich verstehe die Frage nicht ganz.
Suchst du jetzt die Darstellung, oder ein Tool dafür?

Vielleicht eine Antwort auf beides: es gibt plantuml, und in der Doku 
dazu sind viele Beispiele.

https://plantuml.com/de/

[MikeH (Gast)]

Installier dir Doxygen und dot. Da kannst du alle Abhängigkeiten in 
UML-Style generieren. UML ist aber für objektorientierte Programmierung 
gedacht. Es gibt zwar auch Krücken dafür in C, ist aber imho sinnfrei.

[UMLenker (Gast)]

Ich frage mich ob man die c bibliothek als uml darstellen kann.

Sie hat als Grundlage unmengen an Strukturen.
Ich will die Abhängigkeit darstellen
Doxygen kapier ich noch nicht

[Nano (Gast)]

UMLenker schrieb:
> Hi habe eine recht unübersichtliche Bibliothek mit vielen
> Strukturen.
> Ich habe in powerpoint meine erste Darstellung davon erstellt.
> Allerdings möchte ich das etwas professioneller machen.
> Vlt. Gibt es uml Standards dafür?
> Jemand ne Idee?

Violet UML Editor

https://sourceforge.net/projects/violet/

Grundsätzlich sollte man erst einmal Zeit investieren um die richtigen 
Tools zu finden und kennenzulernen.

Dazu schaue:

https://www.youtube.com/watch?v=22FU31ZUgNA

Regel Nr. 4:

"4. Great tools help make great g̶a̶m̶e̶s̶ software . Spend as much 
time on tools as possible."

[rbx (Gast)]

Standards gibt es wohl nicht, die gibt es eher für Java oder C++ (+ 
viele ganz gute Bücher mit Beispielen). Zumindest gibt es noch 
Objective-C (zur Orientierung) ( 
https://de.wikipedia.org/wiki/Objective-C ) - aber 
Übersetzen/Konvertieren muss man wohl doch noch selber.

[A. S. (Gast)]

UML ist (wie C) eine Programmiersprache.

Wenn Du sie "sprichst" (kennst), dann kennst Du auch Tools dazu und hast 
damit Erfahrung.

Wenn Du sie nicht sprichst und nur mit dessen Elementen Strukturen und 
Beziehungen darstellen möchtest, entsteht schnell Pseudocode, bei dem 
Elemente nach optischen Gesichtspunkten gewählt werden.

Das verwirrt mehr als es nützt, so als wenn man in Pseudo-C die 
verschiedenen Klammern ([{}]) rein nach Gefühl mixt.

Als Übersetzer sollte man beide Sprachen gut sprechen. Sonst lieber bei 
der einen Sprache bleiben und z.b. doxygen oder einfache 
Strukturdiagramme malen.

[Lotta . (mercedes)]

Ein gutes UML-System , das reverse engineering kann,
ist das Tool für Dich, zumindest in C++, C mußt Du
ausprobieren.
Stellvertretend etwa ist Sparx Enterprise
oder OEW (Objekt Workbench), das als Sonderzugabe
mal bei den Borland c-Compilern (BorlandC 4 oder 5) dabei war.

Wenn Dir auch nassi shneiderman reicht käme
auch ein altes Tool von Siemens "Easycode"
oder "Easycase" in Frage, das aus Struktogrammen
c oder C++ code macht und umgekehrt.

Ist aber alles leider nicht opensorce.


mfg

[Ein T. (ein_typ)]

UMLenker schrieb:
> Hi habe eine recht unübersichtliche Bibliothek mit vielen Strukturen.
> Ich habe in powerpoint meine erste Darstellung davon erstellt.
> Allerdings möchte ich das etwas professioneller machen.
> Vlt. Gibt es uml Standards dafür?
> Jemand ne Idee?

Für die Erzeugung von Diagrammen verwende ich gerne das Programm dia 
[1]. Das kann nicht nur UML, sondern auch verschiedene andere 
Diagrammtypen, ist IMHO einfach zu bedienen und für Windows, MacOS und 
Linux verfügbar. Zudem gibt es diverse Skripte zum Export der damit 
erzeugten Diagramme, so können beispielsweise mit "tedia2sql" damit aus 
UML-Klassendiagrammen CREATE-Skripte für SQL-Datenbanken erzeugt werden.

Das Dateiformat von dia sind gzip-komprimierte XML-Dateien, so daß sich 
auch eigene Skripte zum Export in eigene Dateiformate und 
Programmiersprachen schreiben lassen, andererseits unterstützt dia 
breits eine Vielzahl von Exportformaten, und kann mit verschiedenen 
Plugins nochmals erweitert werden.

[1] http://dia-installer.de/

[Nano (Gast)]

Ein T. schrieb:
> UMLenker schrieb:
>> Hi habe eine recht unübersichtliche Bibliothek mit vielen Strukturen.
>> Ich habe in powerpoint meine erste Darstellung davon erstellt.
>> Allerdings möchte ich das etwas professioneller machen.
>> Vlt. Gibt es uml Standards dafür?
>> Jemand ne Idee?
>
> Für die Erzeugung von Diagrammen verwende ich gerne das Programm dia
> [1]. Das kann nicht nur UML, sondern auch verschiedene andere
> Diagrammtypen,

Und das ist das Problem. Es ist eine Wollmilchsau vergleichbar mit 
Microsoft Visio und somit kein auf UML spezialisiertes Programm, sondern 
ein Programm
das für alles da sein soll, aber nichts wirklich gut macht.

Das ist in etwa so, als würde man zum Zeichnen von Schaltplänen Inkscape 
anstatt KiCad verwenden.

Deswegen sollte man das eher nicht benutzen.
Oben habe ich ein richtiges UML Programm empfohlen, dass auf UML 
spezialisiert ist und wenn er sucht, dann wird er auch noch ein paar 
weitere Open Source UML Programme finden.
Die Wikipedia ist zur Suche eine brauchbare Hilfe.

Lediglich UML Diagramme aus dem C oder C++ Quellcode erzeugen, das 
scheinen
noch keine Open Source UML Programme zu können, da braucht er dann schon
etwas professionelles.

[Nano (Gast)]

Noch eine Ergänzung.

Das Problem von so einer Wollmilchsau, also Dia oder Visio ist vor allem 
auch, dass man doppelt oder dreimal so lange braucht, wie mit einem 
richtigen UML Programm.
Es ist also auch Zeitverschwendung.

Daher nochmal ganz oben mein erstes Posting.
Lerne die Tools und wende Zeit auf die richtigen zu finden.

[Ein T. (ein_typ)]

Nano schrieb:
> Ein T. schrieb:
>> Für die Erzeugung von Diagrammen verwende ich gerne das Programm dia
>> [1]. Das kann nicht nur UML, sondern auch verschiedene andere
>> Diagrammtypen,
>
> Und das ist das Problem. Es ist eine Wollmilchsau vergleichbar mit
> Microsoft Visio und somit kein auf UML spezialisiertes Programm, sondern
> ein Programm das für alles da sein soll, aber nichts wirklich gut macht.

Also, trotz meiner grundsätzlichen Skepsis gegenüber Java-Software habe 
ich mir den von Dir empfohlene VioletUMLEditor jetzt einmal angeschaut. 
Es war mir bereits ein wenig suspekt, daß sich der Quellcode nicht 
kompilieren ließ, weil ein Test einen Fehler geworfen hat, aber ich hab' 
ja Linux und mir dann einfach mal das Debian-Package dieser Software 
installiert, weil ich es ja restlos entfernen kann.

Sicherlich habe ich das Werkzeug nicht intensiv und vollständig 
ausgetestet, denn leider ist mir völlig verborgen geblieben, welche 
Funktionen oder anderweitigen Vorzüge das Programm gegenüber Dia haben 
soll. Im Gegenteil scheint es mir so, als habe Dia nicht nur erheblich 
mehr Funktionen, sondern auch eine wesentlich größere verfügbare 
Infrastruktur wie das bereits erwähnte tedia2sql, oder dia2code [2] und 
das unten genannte cpp2dia [3], um einige Beispiele zu nennen.

Als jemand, der seit vielen Jahren erfolgreich Dia nutzt, muß ich leider 
sagen, daß ich vom VioletUMLEditor bisher ziemlich enttäuscht bin. Da Du 
den VioletUMLEditor jedoch besser zu kennen scheinst, würde ich mich 
über einen oder mehrere Hinweise von Deiner Seite sehr freuen, was 
dieses Programm denn besser können soll als dia. Herzlichen Dank für 
Deine Mühen.

Nebenbei bemerkt fand ich es jetzt auch nicht unbedingt 
vertrauenerweckend, daß das Programm beim Starten (Kubuntu 20.04) 
erstmal eine Fehlermeldung anzeigt.

> Das ist in etwa so, als würde man zum Zeichnen von Schaltplänen Inkscape
> anstatt KiCad verwenden.

Ach, weißt Du, mein Emacs -- und wie ich von Kollegen weiß, auch deren 
vim -- können etliche Sprachen, von C über C++ über LaTeX und HTML, CSS 
und ECMA-/Javascript, der Emacs kann obendrein als Mailprogramm und als 
Webbrowser und vieles Weiteres genutzt werden. Möchtest Du deswegen 
behaupten, daß es sinnvoller sei, sich für jede Sprache eine andere IDE 
zu installieren und zu erlernen?

Außerdem erscheint es mir -- okay, natürlich liegt das an mir -- schon 
ein bisschen seltsam, daß Du diese Angelegenheit sehr emotional zu sehen 
scheinst. Bist Du an dem VioletUMLEditor-Projekt vielleicht beteiligt 
oder was ist der Grund? Am Ende geht es hier doch nur um Editoren für 
Diagramme, oder nicht?

> Deswegen sollte man das eher nicht benutzen.
> Oben habe ich ein richtiges UML Programm empfohlen, dass auf UML
> spezialisiert ist und wenn er sucht, dann wird er auch noch ein paar
> weitere Open Source UML Programme finden.
> Die Wikipedia ist zur Suche eine brauchbare Hilfe.

Also auf der englischsprachigen Wikipediaseite dazu ist Dia gelistet 
[1]. Also ich scheine nicht der einzige Mensch auf der Welt zu sein, der 
Dia für einen durchaus brauchbaren UML-Editor hält, denn dieser Eintrag 
stammt nicht von mir.

> Lediglich UML Diagramme aus dem C oder C++ Quellcode erzeugen, das
> scheinen
> noch keine Open Source UML Programme zu können, da braucht er dann schon
> etwas professionelles.

Also für C++ und Dia gibt es jedenfalls cpp2dia [3].

[1] 
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
[2] http://dia2code.sourceforge.net/
[3] http://cpp2dia.sourceforge.net/

[Ein T. (ein_typ)]

Nano schrieb:
> Das Problem von so einer Wollmilchsau, also Dia oder Visio ist vor allem
> auch, dass man doppelt oder dreimal so lange braucht, wie mit einem
> richtigen UML Programm.
> Es ist also auch Zeitverschwendung.

Es tut mir leid, aber auch in dieser Hinsicht konnte ich beim von Dir 
empfohlenen Programm keinerlei Vorteile gegenüber Dia erkennen. Aber das 
hängt vermutlich auch immer davon ab, wie geübt man mit dem jeweiligen 
Werkzeug ist.

> Daher nochmal ganz oben mein erstes Posting.
> Lerne die Tools und wende Zeit auf die richtigen zu finden.

Du wirst lachen, aber genau das habe ich getan -- und dabei eben Dia 
gefunden. Daß dieses kein auf einen spezialisierten Einsatzzweck 
zugeschnittenes Werkzeug ist, sondern ein Allrounder, scheint mir 
allerdings keineswegs als Nach-, sondern im Gegenteil als enormer 
Vorteil. Dia kann nämlich eine Sache ausgesprochen gut, und zwar, 
hübsche Diagramme zu malen und in allerlei Formate zu exportieren. 
Weitere Werkzeuge aus dem Dia-Universum können die Dateien mit Dias 
Diagrammen dann in eine Vielzahl von anderen Formaten überführen, etwa 
C++, Java, PHP oder SQL, um einige Beispiele zu nennen. IMHO entspricht 
das auch der UNIX-Philosophie, derzufolge ein Werkzeug genau eine 
Aufgabe erfüllen soll, diese aber richtig gut.

Ein anderer Aspekt, den ich als ausgesprochen positiv empfinde, ist die 
Tatsache, daß ich nicht für jede Kleinigkeit ein neues Werkzeug brauche, 
das installiert, gepflegt, dessen Bedienung erlernt und in Erinnerung 
bleiben muß. Gerade deshalb tendiere ich immer sehr gern dazu, Software 
zu benutzen, die dasselbe (Diagramme editieren, Code schreiben) für 
verschiedene Anwendungsbereiche beherrschen. Daher erscheint mir Deine 
anscheinend tief verwurzelte Abneigung gegenüber derartigen Werkzeugen 
durchaus ein wenig merkwürdig.

[Ein T. (ein_typ)]

Ein T. schrieb:
> Nano schrieb:
>> Und das ist das Problem. Es ist eine Wollmilchsau vergleichbar mit
>> Microsoft Visio und somit kein auf UML spezialisiertes Programm, sondern
>> ein Programm das für alles da sein soll, aber nichts wirklich gut macht.
>
> Als jemand, der seit vielen Jahren erfolgreich Dia nutzt, muß ich leider
> sagen, daß ich vom VioletUMLEditor bisher ziemlich enttäuscht bin. Da Du
> den VioletUMLEditor jedoch besser zu kennen scheinst, würde ich mich
> über einen oder mehrere Hinweise von Deiner Seite sehr freuen, was
> dieses Programm denn besser können soll als dia. Herzlichen Dank für
> Deine Mühen.

Sehr schade, ich hatte auf eine Antwort gehofft... :-(

[Nano (Gast)]

Ein T. schrieb:>
> Als jemand, der seit vielen Jahren erfolgreich Dia nutzt, muß ich leider
> sagen, daß ich vom VioletUMLEditor bisher ziemlich enttäuscht bin. Da Du
> den VioletUMLEditor jedoch besser zu kennen scheinst, würde ich mich
> über einen oder mehrere Hinweise von Deiner Seite sehr freuen, was
> dieses Programm denn besser können soll als dia. Herzlichen Dank für
> Deine Mühen.

Es geht im wesentlichen um die Usability und Effizienz.
Der Bau eines UML Diagramms geht damit schneller von der Hand, weil es 
darauf optimiert ist.

Darin unterscheiden sich übrigens viele UML Programme.

Eine Klasse willst du bspw. ja nicht nur einfach als Vektorgrafik 
einfügen, sondern du willst auch jedes Attribut und jede Methode 
benennen und darauf sind gute UML Programme optimiert, dass das gut und 
effizient geht.
Und wenn du das ganze UML Diagramm umbauen musst, dann bleiben bei einem 
guten Programm die Beziehungen untereinander bestehen, wenn du die 
Klassen per Drag & Drop hin und herziehst.
Das Eintragen der Beziehungen geht übrigens mit guten UML Programmen 
auch schneller.

Normale Vektorprogramme sind darauf nicht optimiert, da kann es also 
sein, dass beim Verschieben einer Klasse die Beziehung aufbricht.
DIA ist so ein Zwischending zwischen beidem und muss daher als 
Wollmilchsau beide Welten bedienen und das führt zwangsläufig zu 
Kompromissen.

Zugegeben, ich habe DIA schon lange nicht mehr benutzt, aber als ich es 
das letzte mal benutzt habe, war das Zeichen von UML Diagrammen damit 
eine sehr aufwendige, ineffiziente und langsame Tortur.


Wenn man bei DIA aus dem UML Diagramm inzwischen Code generieren kann, 
dann ist das ja durchaus eine große Verbesserung, damals konnte es das 
noch nicht.



>> Das ist in etwa so, als würde man zum Zeichnen von Schaltplänen Inkscape
>> anstatt KiCad verwenden.
>
> Ach, weißt Du, mein Emacs -- und wie ich von Kollegen weiß, auch deren
> vim -- können etliche Sprachen, von C über C++ über LaTeX und HTML, CSS
> und ECMA-/Javascript, der Emacs kann obendrein als Mailprogramm und als
> Webbrowser und vieles Weiteres genutzt werden. Möchtest Du deswegen
> behaupten, daß es sinnvoller sei, sich für jede Sprache eine andere IDE
> zu installieren und zu erlernen?

Der Vergleich hinkt.

Wenn du eine UML Klasse in Inkskape erstellst, dann wirst du für jedes 
Klassenattribut höchstwahrscheinlich ein eigenes Textfeld händisch 
einfügen müssen.
Das ist viel zu umständlich.

> Außerdem erscheint es mir -- okay, natürlich liegt das an mir -- schon
> ein bisschen seltsam, daß Du diese Angelegenheit sehr emotional zu sehen
> scheinst. Bist Du an dem VioletUMLEditor-Projekt vielleicht beteiligt
> oder was ist der Grund?

Nein, bin ich nicht, aber alle Jahre mal, wenn ich UML Diagramme 
brauche, guck ich mir an, was es so gibt und wie die weiterentwickelt 
wurden.

Und das letzte mal, als ich UML Diagramme zeichnen musste, war halt eben 
VioletUMLEditor am weitesten fortgeschritten. Davor habe ich bspw. noch 
StarUML verwendet.
StarUML war auch gut, wird aber nicht mehr weiterentwickelt, vermutlich 
weil es in Delphi geschrieben wurde.
Es gibt von dem einen Fork namens WhiteStarUML, aber den habe ich noch 
nicht ausprobiert:
https://sourceforge.net/projects/whitestaruml/


>  Am Ende geht es hier doch nur um Editoren für
> Diagramme, oder nicht?

Es geht um die Nutzung des besten Programms für die Aufgabenstellung.
Und das bedeutet eben das effizienteste mit dem die Arbeit möglicht 
schnell und effizient von der Hand geht.

>> Deswegen sollte man das eher nicht benutzen.
>> Oben habe ich ein richtiges UML Programm empfohlen, dass auf UML
>> spezialisiert ist und wenn er sucht, dann wird er auch noch ein paar
>> weitere Open Source UML Programme finden.
>> Die Wikipedia ist zur Suche eine brauchbare Hilfe.
>
> Also auf der englischsprachigen Wikipediaseite dazu ist Dia gelistet
> [1]. Also ich scheine nicht der einzige Mensch auf der Welt zu sein, der
> Dia für einen durchaus brauchbaren UML-Editor hält, denn dieser Eintrag
> stammt nicht von mir.

In der Wikipedia kann jeder sein Zeug eintragen, das bedeutet aber 
nicht, dass dies DIA zu einem guten UML Editor macht.
Ich habe auch nicht behauptet, dass die Wikipedia ein Qualitätsbeleg 
wäre, sondern ich erwähnte sie, weil die bekannteren Open Source UML 
Programme über kurz oder lang alle in den Listen und Kategorien alle in 
der Wikipedia landen und dann die Suche, welche UML Programme man alle 
ausprobieren kann, recht einfach ist.

Und wie schon gesagt, es gibt auch Leute die benutzen Inkscape zum 
Zeichnen von Schaltplänen, das sagt aber nichts über die Sinnhaftigkeit 
aus, es so zu machen:
https://www.youtube.com/watch?v=I-6ljbgstl8


>> Lediglich UML Diagramme aus dem C oder C++ Quellcode erzeugen, das
>> scheinen
>> noch keine Open Source UML Programme zu können, da braucht er dann schon
>> etwas professionelles.
>
> Also für C++ und Dia gibt es jedenfalls cpp2dia [3].

Du kannst dir alle anderen Open Source UML Programme ja mal ansehen, ob 
die das inzwischen auch für C und C++ Code können.

[Nano (Gast)]

Ein T. schrieb:
> Nano schrieb:
>> Das Problem von so einer Wollmilchsau, also Dia oder Visio ist vor allem
>> auch, dass man doppelt oder dreimal so lange braucht, wie mit einem
>> richtigen UML Programm.
>> Es ist also auch Zeitverschwendung.
>
> Es tut mir leid, aber auch in dieser Hinsicht konnte ich beim von Dir
> empfohlenen Programm keinerlei Vorteile gegenüber Dia erkennen.

Ich weiß ja nicht ob du auf die Kriterien Effizienz geachtet hast.
Siehe oben, da habe ich ja schon durchscheinen lassen, worauf ich achten 
würde.

> Aber das
> hängt vermutlich auch immer davon ab, wie geübt man mit dem jeweiligen
> Werkzeug ist.

Das kommt noch dazu.

> Dia kann nämlich eine Sache ausgesprochen gut, und zwar,
> hübsche Diagramme zu malen und in allerlei Formate zu exportieren.

Ist es auch gut dafür geeignet, die Diagramme mit Daten füttern?
Bei meinem letzten Test war das nämlich nicht so. Der ist aber zugegeben 
schon sehr lange her.

> Weitere Werkzeuge aus dem Dia-Universum können die Dateien mit Dias
> Diagrammen dann in eine Vielzahl von anderen Formaten überführen, etwa
> C++, Java, PHP oder SQL, um einige Beispiele zu nennen. IMHO entspricht
> das auch der UNIX-Philosophie, derzufolge ein Werkzeug genau eine
> Aufgabe erfüllen soll, diese aber richtig gut.

Die meisten Open Source UML Programme können die Diagramme nach SVG 
exportieren. Also kann man die beliebig weiterbearbeiten und 
verarbeiten, wenn man das braucht.


> Daher erscheint mir Deine
> anscheinend tief verwurzelte Abneigung gegenüber derartigen Werkzeugen
> durchaus ein wenig merkwürdig.

Vielleicht liegt es daran, weil du nicht weiß, worauf ich achte wenn es 
um die Frage geht, ob man mit einem Programm effizient arbeiten kann.

[Nano (Gast)]

Ein T. schrieb:
> Ein T. schrieb:
>> Nano schrieb:
>>> Und das ist das Problem. Es ist eine Wollmilchsau vergleichbar mit
>>> Microsoft Visio und somit kein auf UML spezialisiertes Programm, sondern
>>> ein Programm das für alles da sein soll, aber nichts wirklich gut macht.
>>
>> Als jemand, der seit vielen Jahren erfolgreich Dia nutzt, muß ich leider
>> sagen, daß ich vom VioletUMLEditor bisher ziemlich enttäuscht bin. Da Du
>> den VioletUMLEditor jedoch besser zu kennen scheinst, würde ich mich
>> über einen oder mehrere Hinweise von Deiner Seite sehr freuen, was
>> dieses Programm denn besser können soll als dia. Herzlichen Dank für
>> Deine Mühen.
>
> Sehr schade, ich hatte auf eine Antwort gehofft... :-(

Du hast keine Geduld.

[Ein T. (ein_typ)]

Nano schrieb:
> Ein T. schrieb:
>> Sehr schade, ich hatte auf eine Antwort gehofft... :-(
>
> Du hast keine Geduld.

Jedenfalls nicht übermäßig viel davon, da könntest Du Recht haben. ;-)

Nano schrieb:
> Es geht im wesentlichen um die Usability und Effizienz.

Ja, und nein, insbesondere hinsichtlich der Effizienz. Da ist es nämlich 
auch eine Frage, wie oft mir der betreffende Anwendungsfall begegnet. 
Ich für meinen Teil würde sagen, daß ich so ein- bis zweimal im Monat 
ein Diagramm zeichne -- das kann mal ein UML-Klassendiagramm sein, oder 
ein Flußdiagramm, ein Netzwerkdiagramm oder ein BPML-Diagramm. All das 
-- und noch viel mehr -- kann Dia. Und für jeden dieser durchaus 
unterschiedlichen Diagrammtypen wird es immer gleich bedient. Die 
gleiche Bedienung ist ein riesiger Vorteil, gerade und vor allem bei der 
Effizienz.

> Der Bau eines UML Diagramms geht damit schneller von der Hand, weil es
> darauf optimiert ist.

Als ich den Violetumleditor gerade noch einmal ausprobiert habe, um den 
anhängenden Screenshot zu erstellen, wollte ich zuerst eine kleine 
Vererbungshierarchie hinein bauen. Davon bin ich aber wieder 
abgegekommen, weil der Vererbungspfeil in Violet ausgesprochen hakelig 
war und kaum anständig positioniert und am Element verankert werden 
konnte. Bei Dia sind die Verbindungspunkte als kleine blaue X 
eingezeichnet und in der Standardeinstellung schnappt der 
Vererbungspfeil präzise dort ein, wie bei anderen Diagrammtypen. Ein 
Verschieben des Vererbungspfeils in VioletUMLEditor führte leider 
außerdem dazu, daß der ganze Pfeil irgendwie... kaputt ging. Das gibt es 
bei Dia so auch nicht, da kann ich den Verbindungspfeil auswählen, 
problemlos weitere Elemente hinzufügen oder entfernen, ganz nach Lust 
und Notwendigkeit. In diesem meinem -- zugegeben: oberflächlichen -- 
Test war die Usability von Dia viel besser als die von VioletUMLEditor, 
und nein: das lag leider nicht daran, daß ich Dia bereits seit vielen 
langen Jahren sehr gut kenne, sondern daran, daß Violet einige Dinge nur 
sehr rudimentär umsetzt (mehr dazu unten) und sich bei meinen Versuchen 
als zumindest hakelig, wenn nicht gar als fehlerhaft erwiesen hat.

> Darin unterscheiden sich übrigens viele UML Programme.
>
> Eine Klasse willst du bspw. ja nicht nur einfach als Vektorgrafik
> einfügen, sondern du willst auch jedes Attribut und jede Methode
> benennen und darauf sind gute UML Programme optimiert, dass das gut und
> effizient geht.

Bitte betrachte den angehängten Screenshot und siehe, daß Dia diesen 
Punkt viel besser umgesetzt hat als das Spezialwerkzeug VioletUMLEditor.

> Und wenn du das ganze UML Diagramm umbauen musst, dann bleiben bei einem
> guten Programm die Beziehungen untereinander bestehen, wenn du die
> Klassen per Drag & Drop hin und herziehst.

Ja, genau -- und deswegen macht Dia das auch so, und zwar nicht nur für 
UML. Wenn ich ein Objekt verschiebe, bleiben die Verbindungen erhalten 
und werden, sofern notwendig, sogar automatisch neu geroutet.

> Das Eintragen der Beziehungen geht übrigens mit guten UML Programmen
> auch schneller.

Wie bereits oben gesagt, hat sich das bei mir als ausgesprochen hakelige 
und nicht sonderlich gut funktionierende Angelegenheit dargestellt. Im 
Gegensatz zu Dia habe ich in VioletUMLEditor auch keine Möglichkeit 
gefunden, die Objekte zu selektieren und mithilfe der Maustasten präzise 
feinzupositionieren und auszurichten.

> Normale Vektorprogramme sind darauf nicht optimiert, da kann es also
> sein, dass beim Verschieben einer Klasse die Beziehung aufbricht.
> DIA ist so ein Zwischending zwischen beidem und muss daher als
> Wollmilchsau beide Welten bedienen und das führt zwangsläufig zu
> Kompromissen.

Dia ist ja auch gar kein "normales Vektorprogramm" wie Inkscape oder LO 
Draw. Wie gesagt, Dia behält die Verbindungen beim Verschieben von 
Objekten, und routet sie notwendigenfalls sogar automatisch neu.

> Zugegeben, ich habe DIA schon lange nicht mehr benutzt, aber als ich es
> das letzte mal benutzt habe, war das Zeichen von UML Diagrammen damit
> eine sehr aufwendige, ineffiziente und langsame Tortur.

Das muß sehr, sehr lange her sein, denn ich kenne und nutze Dia jetzt 
seit deutlich über achtzehn Jahren, und seitdem ich es benutze, 
funktioniert es genau so, wie ich es weiter oben beschrieben habe -- und 
zwar, ja, auch inklusive UML.

> Wenn man bei DIA aus dem UML Diagramm inzwischen Code generieren kann,
> dann ist das ja durchaus eine große Verbesserung, damals konnte es das
> noch nicht.

Auch dieses Feature habe ich schon vor ca. vierzehn Jahren mit einer 
gepatchten Version von tedia2sql genutzt, um ein Webframework zu bauen, 
dessen Datenbank mithilfe von Dias UML-Diagrammen entworfen wurde. 
Danach wurden aus der Datei mithilfe tedia2sql nicht nur der Code zum 
Erzeugen des Datenbankschemas und erste Einträge in die 
Credentials-Tabellen, sondern -- das war mein Patch -- auch gleich 
fertiger Code für das Webframework zum Editieren der Tabellen generiert.

> Wenn du eine UML Klasse in Inkskape erstellst, dann wirst du für jedes
> Klassenattribut höchstwahrscheinlich ein eigenes Textfeld händisch
> einfügen müssen.
> Das ist viel zu umständlich.

Ich erstelle meine UML-Diagramme aber nicht mit Inkscape, sondern mit 
Dia. Woher immer wieder Dein Verweis auf Inkscape kommt, erschließt sich 
mir nicht. Inkscape ist eine völlig andere Software für völlig andere 
Anwendungsfälle, und die einzige Gemeinsamkeit von Dia und Inkscape ist, 
daß beide mit Vektorgrafiken arbeiten.

> Nein, bin ich nicht, aber alle Jahre mal, wenn ich UML Diagramme
> brauche, guck ich mir an, was es so gibt und wie die weiterentwickelt
> wurden.

Dann solltest Du Dir Dia vielleicht noch einmal anschauen, damit wir 
wenigstens von derselben Software reden (können) und Du mir nicht 
ständig mit Inkscape kommst.

> Es geht um die Nutzung des besten Programms für die Aufgabenstellung.
> Und das bedeutet eben das effizienteste mit dem die Arbeit möglicht
> schnell und effizient von der Hand geht.

Puh, das sind große Worte... Aber wie oben schon erwähnt: alleine die 
deutlich hakeligere Bedienung von VioletUMLeditor im Vergleich zu Dia 
macht Dia für mich zu einem  besseren und effizienteren Werkzeug, und 
mehr Funktionalität bietet Dia auch für UML-Diagramme. Und sicherlich 
auch deswegen, weil ich Dia häufiger benutze und daran gewöhnt bin, bin 
ich damit auch viel schneller, als wenn ich mir für jeden der oben 
genannten Diagrammtypen eine eigene Software installieren, pflegen, 
warten, und mir die Bedienung dieser Software merken müßte. Vielleicht, 
ich schließe das nicht aus, gibt es für jeden der genannten 
Diagrammtypen eine Software, womöglich sogar OpenSource, mit der sich 
noch effizienter arbeiten ließe, allerdings fiele es mir schwer, die 
Eigenheiten der Bedienung aller dieser Programme zu behalten, um sie 
effizient nutzen zu können, zumal wenn ich sie dann lediglich alle paar 
Monate mal für wenige Stunden nutze. Und deswegen ist Dia in diesem 
Punkt, zumindest für mich, ganz eindeutig im Vorteil und die wesentlich 
effizientere Wahl.

> Ich habe auch nicht behauptet, dass die Wikipedia ein Qualitätsbeleg
> wäre, sondern ich erwähnte sie, weil die bekannteren Open Source UML
> Programme über kurz oder lang alle in den Listen und Kategorien alle in
> der Wikipedia landen und dann die Suche, welche UML Programme man alle
> ausprobieren kann, recht einfach ist.

Und dieses Ausprobieren, um das_ _perfekte Werkzeug zu finden, dauert 
dann wie lange? Bleibt da nicht die von Dir beschworene Effizienz auf 
der Strecke?

>>> Lediglich UML Diagramme aus dem C oder C++ Quellcode erzeugen, das
>>> scheinen
>>> noch keine Open Source UML Programme zu können, da braucht er dann schon
>>> etwas professionelles.
>>
>> Also für C++ und Dia gibt es jedenfalls cpp2dia [3].
>
> Du kannst dir alle anderen Open Source UML Programme ja mal ansehen, ob
> die das inzwischen auch für C und C++ Code können.

Das kann ich ganz bestimmt, aber ich für mich habe einen wundervollen 
UML-Editor namens Dia. Den kenne ich, den beherrsche ich, er 
funktioniert wunderbar und hat, sicherlich auch weil es ihn schon seit 
über zwanzig Jahren gibt, eine sehr gute, breitgefächerte Infrastruktur.

Nano schrieb:
> Ein T. schrieb:
> Ich weiß ja nicht ob du auf die Kriterien Effizienz geachtet hast.
> Siehe oben, da habe ich ja schon durchscheinen lassen, worauf ich achten
> würde.

Ja, tatsächlich habe ich auf Effizienz geachtet, und bevorzuge deswegen 
immer noch Dia.

>> Dia kann nämlich eine Sache ausgesprochen gut, und zwar,
>> hübsche Diagramme zu malen und in allerlei Formate zu exportieren.
>
> Ist es auch gut dafür geeignet, die Diagramme mit Daten füttern?
> Bei meinem letzten Test war das nämlich nicht so. Der ist aber zugegeben
> schon sehr lange her.

Was genau meinst Du mit "mit Daten zu füttern"? Für das oben erwähnte 
Framework wurden initiale Konfigurations- und Login-Daten ins erzeugte 
SQL aufgenommen, meinst
Du sowas?

Oder meinst Du die Beschriftung von Objekten, etwa die von Klassen mit 
ihrem Namen, ihren Eigenschaften und ihren Methoden? Wie das bei 
UML-Klassen von VioletUMLEditor und Dia funktioniert, kannst Du dem 
anhängenden Screenshot entnehmen: während der VioletUMLEditor da den 
einfachsten -- um nicht zu sagen: primitivsten -- Weg geht, für 
Klassenname, -Eigenschaften und -Methoden einfach nur jeweils ein 
vollkommen unstruturiertes mehrzeiliges Textfeld vorsieht, hat Dia auf 
der rechten Seite für jede einzelne Eigenschaft und Methode ein schickes 
Formular, in das ich den Namen, Typ, sowie eventuelle Defaultwerte 
sauber angeben kann. Aber das ist nur der Anfang, denn diese Dinge 
werden natürlich auch sauber strukturiert in den mit Dia erzeugten 
Dateien gespeichert, von wo ich sie dann wiederum zum Beispiel mit einem 
Skript auslesen kann. Wenn ich hingegen die Dateien von VioletUMLEditor 
weiterverarbeiten wollte, müßte ich mir für die Daten aus den erwähnten 
Multiline-Feldern stattdessen sogar einen eigenen Parser schreiben. Ob 
das effizient(er) wäre, bezweifle ich.

Alleine der angehängte Screenshot beider Programme zeigt nach meinem 
Dafürhalten ziemlich deutlich, wie viel besser und effizienter 
UML-Klassendiagramme mit Dia erstellt, editiert, und weiterverarbeitet 
werden können. Alleine die Eingabe der Methodensignaturen, die im 
Screenshot gezeigt wird, ist offensichtlich sehr viel besser 
strukturiert und deren Darstellung und Speicherung ist standardisiert. 
Da hätte ich von einem spezialisierten Werkzeug wie VioletUMLEditor mehr 
erwartet, allerdings werden meine Erwartungen leider nicht erfüllt.

> Die meisten Open Source UML Programme können die Diagramme nach SVG
> exportieren. Also kann man die beliebig weiterbearbeiten und
> verarbeiten, wenn man das braucht.

Dia kann seine Diagramme selbstverständlich auch nach SVG exportieren. 
Oder nach PNG, PostScript, LaTeX, und etliche weitere Formate.

> Vielleicht liegt es daran, weil du nicht weiß, worauf ich achte wenn es
> um die Frage geht, ob man mit einem Programm effizient arbeiten kann.

Das kann natürlich sein, oder vielleicht haben wir auch andere Ansichten 
in Bezug darauf, was Effizienz ist und welche Merkmale dafür relevant 
sind. Auch nach einem erneuten Versuch mit VioletUMLEditor bleibt Dia 
für mich in jeder Hinsicht der klare und eindeutige Gewinner -- nicht 
nur bezüglich der Funktionalität, sondern gerade und besonders auch mit 
Blick auf die Effizienz.

[Nano (Gast)]

Ein T. schrieb:
>> Eine Klasse willst du bspw. ja nicht nur einfach als Vektorgrafik
>> einfügen, sondern du willst auch jedes Attribut und jede Methode
>> benennen und darauf sind gute UML Programme optimiert, dass das gut und
>> effizient geht.
>
> Bitte betrachte den angehängten Screenshot und siehe, daß Dia diesen
> Punkt viel besser umgesetzt hat als das Spezialwerkzeug VioletUMLEditor.

Nachdem Screenshot zu urteilen, scheint das genau NICHT so.

In DIA muss man, wenn man das nicht alles auf einmal in einer Textbox 
eingeben kann, ein paar Dutzend Textboxen anspringen (Tab oder Maus?) 
und wechseln um dann alles reinzuschreiben. Also bspw. Name, Typ, 
Sichtbarkeit, Parameterwert, Datentyp usw..
Also n mal Tab Taste drücken oder schlimmer, n mal Maus schubsten, 
zielen und klicken.

Genau das ist das, was ich mit ineffizient meinte.

Beim Violet UML Editor ist es für Name, die Attribute und die Methoden 
jeweils ein Textfeld und das eingeben pro Textfeld, in dem dann bspw. 
ALLE Attribute eingegeben werden können ist nicht viel anders als das 
Eingeben von Quellcode in einem Editor oder einer IDE.
Das ist Dutzende mal schneller als dieses ewige Geklicke, wie es dem 
Screenshot zu urteilen bei Dia zu sein scheint.

Und jetzt stell dir mal vor, du müsstest ein größeres Klassendiagram 
zeichnen. Da potentiert sich der Aufwand mit dem vielen umständlichen 
geklicke dann ganz schnell. Im Violet UML Editor gibt man einfach ein 
und sagt dem Editor was man braucht und fertig.

Für mich wäre das schon ein Ausschlusskriterium von Dia. Und das meine 
ich ernst, ich sage das jetzt nicht um da jetzt irgendein einfach 
dagegen zu sein.


>> Und wenn du das ganze UML Diagramm umbauen musst, dann bleiben bei einem
>> guten Programm die Beziehungen untereinander bestehen, wenn du die
>> Klassen per Drag & Drop hin und herziehst.
>
> Ja, genau -- und deswegen macht Dia das auch so, und zwar nicht nur für
> UML. Wenn ich ein Objekt verschiebe, bleiben die Verbindungen erhalten
> und werden, sofern notwendig, sogar automatisch neu geroutet.

Na immerhin hat sich dann da etwas verbessert. Damals war das noch nicht 
so.



>> Das Eintragen der Beziehungen geht übrigens mit guten UML Programmen
>> auch schneller.
>
> Wie bereits oben gesagt, hat sich das bei mir als ausgesprochen hakelige
> und nicht sonderlich gut funktionierende Angelegenheit dargestellt. Im
> Gegensatz zu Dia habe ich in VioletUMLEditor auch keine Möglichkeit
> gefunden, die Objekte zu selektieren und mithilfe der Maustasten präzise
> feinzupositionieren und auszurichten.

Feinarbeiten und millimetergenaues Positionieren muss vielleicht ein 
Programm wie Visio oder die Kopie davon DIA können, damit Zeichnungen 
aller Art "Eye Candy" genug aussehen, aber beim Erstellen eines UML 
Klassendiagramms geht es nicht um so etwas, sondern da geht es um eine 
funktionale Darstellung der Klassen im Bezug zueinander um eine bessere 
Übersicht zu haben oder Fehler zu erkennen und dann um das ganze dann 
ganz schnell wieder umzubauen, wenn es eine bessere Lösung gibt. Da 
verschwendet man also nicht seine Zeit mit millimetergenauem 
positionieren, das ist NICHT der Sinn von UML.
Eine einfache snap to Grid Funktion ist also völlig ausreichend.

Ich tippe mal darauf, dass du Dokumente lieber in MS Word schreibst, 
anstatt in LaTeX. Da kann man nämlich auch ganz viel Zeit für das 
WYSIWYG verschwenden, anstatt sich auf den Text zu konzentrieren, wie es 
in LaTeX möglich ist.



>> Wenn du eine UML Klasse in Inkskape erstellst, dann wirst du für jedes
>> Klassenattribut höchstwahrscheinlich ein eigenes Textfeld händisch
>> einfügen müssen.
>> Das ist viel zu umständlich.
>
> Ich erstelle meine UML-Diagramme aber nicht mit Inkscape, sondern mit
> Dia. Woher immer wieder Dein Verweis auf Inkscape kommt, erschließt sich
> mir nicht.

Inkscape wird neben Dia auch als Alternativen zu Visio in dem WP Artikel 
zu Visio aufgeführt.




> Vielleicht,
> ich schließe das nicht aus, gibt es für jeden der genannten
> Diagrammtypen eine Software, womöglich sogar OpenSource, mit der sich
> noch effizienter arbeiten ließe,

Selbstverständlich. Schaltpläne lassen sich auch in Dia erstellen, aber 
klüger wäre es dafür KiCad zu verwenden.

http://dia-installer.de/shapes/Electric/index.html.en


> Und dieses Ausprobieren, um das_ _perfekte Werkzeug zu finden, dauert
> dann wie lange? Bleibt da nicht die von Dir beschworene Effizienz auf
> der Strecke?

Nein. Denn die Zeit holt man später wieder rein.
Vor allem gilt das, wenn man beabsichtigt das Programm länger zu nutzen.



> Das kann ich ganz bestimmt, aber ich für mich habe einen wundervollen
> UML-Editor namens Dia.

Wie schon gesagt, das viele Durchklicken durch die Textfelder solltest 
du dir nochmal überdenken, ob das wirklich effizient ist und ob du hier 
wirklich nach den richtigen Kriterien geachtet hast um das richtige, 
also effizienteste Programm zu finden.

Bei Quellcode ist es auch nicht anders, die schnellste Art Quellcode 
umzusetzen ist ihn einfach als Text niederzuschreiben.
Grafische Programmiersprachen haben sich nie durchgesetzt, Versuche gab 
es einige.

> Den kenne ich, den beherrsche ich, er
> funktioniert wunderbar und hat, sicherlich auch weil es ihn schon seit
> über zwanzig Jahren gibt, eine sehr gute, breitgefächerte Infrastruktur.

Ich bestreite nicht, dass Dia als Visio Klon eine große Verbreitung und 
somit Entwicklergemeinde hat, aber das führt eben nicht, siehe mein 
Kritikpunkt oben, zum effizientesten Workflow.

Ein Attribut wie:

+get_eins():int

habe ich mit Textvervollständigung, die so ein Textfeld ja haben darf, 
schneller per Tastatur eingetippt, also du dich durch jedes einzelne 
Textfeld durchgeklickt hast.

Und das ist der Punkt, nachdem ich hier die Effizienz eines UML 
Programms unter anderem bspw. bemessen würde.

> Nano schrieb:
>> Ein T. schrieb:
>> Ich weiß ja nicht ob du auf die Kriterien Effizienz geachtet hast.
>> Siehe oben, da habe ich ja schon durchscheinen lassen, worauf ich achten
>> würde.
>
> Ja, tatsächlich habe ich auf Effizienz geachtet, und bevorzuge deswegen
> immer noch Dia.

Oder du siehst den Wald vor lauter Bäumen nicht.

Will heißen, dir ist es noch nicht aufgefallen, dass das durchhangeln 
durch eine Vielzahl von Textboxen ineffizienter ist, anstatt einfach den 
Code in eine Textbox einfach reinzuschreiben.


> Was genau meinst Du mit "mit Daten zu füttern"?

Das was ich hier gerade geschrieben habe.
Die Attribute und Methoden einzutragen.


> Für das oben erwähnte
> Framework wurden initiale Konfigurations- und Login-Daten ins erzeugte
> SQL aufgenommen, meinst
> Du sowas?

Nein.


>
> Oder meinst Du die Beschriftung von Objekten, etwa die von Klassen mit
> ihrem Namen, ihren Eigenschaften und ihren Methoden? Wie das bei
> UML-Klassen von VioletUMLEditor und Dia funktioniert, kannst Du dem
> anhängenden Screenshot entnehmen: während der VioletUMLEditor da den
> einfachsten -- um nicht zu sagen: primitivsten -- Weg geht, für
> Klassenname, -Eigenschaften und -Methoden einfach nur jeweils ein
> vollkommen unstruturiertes mehrzeiliges Textfeld vorsieht,

Das ist nicht unstrukturiert. Das ist wie Quellcode strukturiert und hat 
die Struktur, wenn man richtig schreibt, somit schon inhärent 
eingebettet.
Was brauchst du da noch zusätzliches Metageklatsche?



> Aber das ist nur der Anfang, denn diese Dinge
> werden natürlich auch sauber strukturiert in den mit Dia erzeugten
> Dateien gespeichert, von wo ich sie dann wiederum zum Beispiel mit einem
> Skript auslesen kann. Wenn ich hingegen die Dateien von VioletUMLEditor
> weiterverarbeiten wollte, müßte ich mir für die Daten aus den erwähnten
> Multiline-Feldern stattdessen sogar einen eigenen Parser schreiben. Ob
> das effizient(er) wäre, bezweifle ich.

Selbst wenn du das müsstest, so einen Parser schreibst du einmal.
Du dagegen klickst dich immer noch hunderte mal durch die einzelnen 
Textfelder um sie auszufüllen und verlierst mit jeder weiteren Klasse 
jede Menge Zeit.

> Alleine der angehängte Screenshot beider Programme zeigt nach meinem
> Dafürhalten ziemlich deutlich, wie viel besser und effizienter
> UML-Klassendiagramme mit Dia erstellt, editiert, und weiterverarbeitet
> werden können.

Was du da als besser betrachtet, ist aber nicht besser, weil das viel 
langsamer beim Eintippen ist.

Du musst bspw. bei der Sichtbarkeit für ein Attribut oder Methode zur 
Maus greifen um das Pulldown Menu zu benutzen oder du nimmst die 
Cursortasten, sofern du dich zum Pulldownmenü tabben kannst, was aber 
auch nicht schneller geht.

Ich dagegen setze nur ein + oder entsprechend anderes Zeichen vor den 
Namen und fertig.
Und jetzt erzählt du mir nochmal, dass deine Methode effizienter und 
schneller ginge.

> Alleine die Eingabe der Methodensignaturen, die im
> Screenshot gezeigt wird, ist offensichtlich sehr viel besser
> strukturiert

Nein, eben nicht.
So wie es in Dia ist, ist es gerade schlechter. Siehe oben. Da habe ich 
aufgeführt, worauf man hier achten sollte.

> und deren Darstellung und Speicherung ist standardisiert.

In Dia ist es zusätzlichen Metageklatsche, das hier aber unnötig ist, da 
es sich bei UML Attributen oder Methoden bereits per Definition um 
strukturierten Text handelt.

> Da hätte ich von einem spezialisierten Werkzeug wie VioletUMLEditor mehr
> erwartet,

Es ist genau so gemacht worden, damit das schnell und effizient von der 
Hand geht, ohne viel rumgeklicke und rumgetabbe, und das erfüllt der 
VioletUMLEditor bestens.

>> Die meisten Open Source UML Programme können die Diagramme nach SVG
>> exportieren. Also kann man die beliebig weiterbearbeiten und
>> verarbeiten, wenn man das braucht.
>
> Dia kann seine Diagramme selbstverständlich auch nach SVG exportieren.
> Oder nach PNG, PostScript, LaTeX, und etliche weitere Formate.

Das habe ich nicht bestritten.


>> Vielleicht liegt es daran, weil du nicht weiß, worauf ich achte wenn es
>> um die Frage geht, ob man mit einem Programm effizient arbeiten kann.
>
> Das kann natürlich sein,

Dem Screenshot zu urteilen und deiner Äußerung zu deinem Vergleich ist 
es wohl so.


> oder vielleicht haben wir auch andere Ansichten
> in Bezug darauf, was Effizienz ist und welche Merkmale dafür relevant
> sind.

Manchmal hilft es, einfach die eigene Perspektive zu verlassen um von 
außen eine andere Sichtweise zu bekommen.

Bei normalem Quellcode bist du es ja bspw. gewohnt, dass du deinen 
Quellcode einfach in einen Texteditor oder Editorfeld einer IDE 
reinschreibst.
So, und jetzt stell dir mal vor, du müßtest per Drag and Drop jedes 
Schlüsselwort der Sprache aus einem Auswahlfenster an Schlüsselwörtern 
in dein Textfeld ziehen. Dann hättest du etwas, was mit Dia bei UML 
vergleichbar wäre. Also umständlich.
Und ja, auf so eine Idee könnte man durchaus kommen.

Ne While Schleife per Drag and Drop ziehen und schon hätte man die ganze 
Schleife mit Rumpf und müsste sie dann im Textfeld noch ergänzen. Da 
entspricht dem, was dein Dia bei UML macht, in dem Fall also der Umweg 
über viele kleine Textboxen, nur damit das für dich den Schein von 
Struktur ergibt und dabei ist das simple runtertippen, also selber 
schreiben, einer Schleife viel schneller.
Und letzteres entspricht dann dem, was du auch im Violet UML Editor bei 
den Attributen und Methoden machst.

[Ein T. (ein_typ)]

Nano schrieb:
> Visio oder die Kopie davon DIA
> Visio Klon
> Metageklatsche
> Metageklatsche

Du wirst ja schon wieder unsachlich... Meine Güte, muß das denn immer 
sein? Kannst oder willst Du nicht sachlich bleiben? Es fällt mir daher 
schwer, Dir abzunehmen, daß Du nicht nur deshalb dagegen bist, weil Du 
dagegen sein willst.

Dia ist im Übrigen gar kein Klon von Microsoft Visio, sondern wurde von 
The GIMP inspiriert, was man seinem User Interface auch hie und da 
ansieht. Und Dia gab es schon, als es bei Microsoft noch gar kein Visio 
gegeben hat... Das nur vorweg.

Daß Dir meine Kriterien nicht gefallen oder Du sie nicht verstehst, ist, 
Pardon, jetzt wirklich nicht mein Problem. Ich kann nur sagen, daß ich 
schon einige zum Teil sogar ausgesprochen teure UML-Werkzeuge gesehen 
habe, nicht zuletzt auch den alten Platzhirsch in diesem Bereich, 
Rational Rose. Die meisten dieser Werkzeuge haben für das Editieren von 
Klassennamen, -Attributen und -Methoden ziemlich ähnliche Dialoge wie 
Dia, und zwar aus guten Gründen: weil es nämlich einfach sinnvoll ist, 
solche Daten strukturiert zu erfassen und zu speichern. Der große 
Vorteil ist, daß die so eingegebenen Daten automatisiert 
weiterverarbeitet werden können. Kann ja sein, daß das für Dich nicht 
wichtig ist, aber für viele andere Nutzer solcher Software, wie für 
mich, ist es das sehr wohl.

Wenn Dir das nicht gefällt, kannst Du Dir ja einen eigenen Objektbogen 
bauen -- ja, sowas geht -- der dann auch nur so eine, sagen wir mal 
freundlich: "rudimentäre" Eingabemöglichkeit hat wie Dein 
VioletUMLEditor. Dia hat ein sehr leistungsfähiges Plugin-System und 
solche einfachen Shapes sind nur ein bisschen XML. Wenn Du das nicht 
willst, dann nimm' halt weiterhin Dein Tool.

Ich meine, es ist doch schön, daß Du etwas gefunden hast, mit dem Du 
umgehen und arbeiten kannst. Aber versuch nicht, mir zu verklickern, 
meine Kriterien bei der Evaluation und Auswahl meiner Software oder 
diese Software seien doof, ineffizient, unproduktiv oder sonst 
irgendeinen Schwachsinn. Ich weiß ja nicht, was Du da mit Deinem 
Eingabefuror machst, aber bei mir (und, nebenbei, auch meinen Kollegen) 
ist das mit Abstand wichtigste Werkzeug bei der Erstellung von 
UML-Diagrammen nicht unsere Tastaturen, sondern unsere Gehirne.

Und was das präzise Positionieren und Ausrichten angeht, so ist ein 
UML-Editor ja nicht nur ein Entwurfs-, sondern auch ein Kommunikations- 
und Dokumentationstool, und zumindest im professionellen Bereich kommt 
es dann nun einmal auch auf eine halbwegs ansprechende Gestaltung an, 
welche im Übrigen auch der Übersichtlichkeit der so erzeugten Diagramme 
ausgesprochen zuträglich ist. Daß diese Diagramme in der Regel 
wesentlich häufiger gelesen als geschrieben werden, macht diesen Punkt 
sogar ganz besonders wichtig und effizient.

Auch die vielen Ausgabe- und Exportformate von Dia sind eine feine 
Sache, denn dadurch kann ich meine Diagramme in alles Mögliche umwandeln 
-- in Code, in eine HTML-Website für unser internes Confluence, als 
Postscript- oder PDF-Datei in die mit LaTeX erstellte Dokumentation. 
Auch das ist für den Kommunikationsaspekt, den gute UML-Werkzeuge 
erfüllen müssen, überaus sinnvoll.

Nebenbei ist mir heute mittag etwas aufgefallen, das mich wieder daran 
erinnert hat, weswegen ich so eine Skepsis gegenüber Java-Software habe: 
das Ding frißt um den Faktor 35 bis 56 mehr Arbeitsspeicher als Dia. Ich 
möchte gar nicht wissen, was für eine Maschine ich bräuchte, um das 
Klassendiagramm unserer Serversoftware mit ~ 350 Klassen laden und 
darstellen zu können -- und versuchen kann ich es ja leider auch nicht, 
weil VioletUMLEditor nur sein eigenes Dateiformat mit in HTML 
eingebetteten XML und PNG beherrscht, und sonst leider nichts. Nicht 
eben beeindruckend sind auch die unglaublich vielen Formate, in die 
VioletUMLEditor exportieren kann -- nämlich als Grafik oder in die 
Zwischenablage. Aber ich kann mir ja Konverter schreiben... janeeisklar, 
natürlich kann ich, aber warum sollte ich, wenn ich dasselbe bereits 
fertig, stabil, getestet und reproduzierbar bei Dia habe?

Unterm Strich, sei mir nicht böse, sieht VioletUMLEditor für mich aus 
wie eine Hobbyarbeit von einem Studenten, der im dritten Semester etwas 
über Java und UML gelernt hat und das jetzt mal ausprobieren wollte. 
Keine Importformate, nur ein ausgesprochen merkwürdiges Speicherformat 
(wie gesagt: HTML mit XML und PNG drin) und Exportformate, die sich 
ebenfalls mit keinem Werkzeug dieser Welt sinnvoll weiterverarbeiten 
lassen, dann diese verkrüppelte Eingabe mit Multilinefeldern... 
irgendwie wirkt das von hinten bis vorne nicht ausgereift, sondern 
hingerotzt, und für mein Team und mich wäre diese Software leider 
vollkommen unbrauchbar.

Aber wenn es Dir gefällt und für Deine Bedürfnisse ausreicht, warum 
nicht? Ich meine, ich bin hier ja nicht der... Mensch, der anderen 
erzählen will, welche Software effizient sei und welche Software sie 
empfehlen oder gar nutzen dürften. Wie gesagt: ich freu' mich ja, daß Du 
mit dieser Software glücklich bist -- denn benutz' die doch und hab' 
viel Spaß damit. Aber bitte lerne zu akzeptieren, daß meine 
Anforderungen offenbar andere sind als Deine, und ich deswegen eine 
andere Software benutze und empfehle. Viel Glück und Erfolg!

[Nano (Gast)]

Ein T. schrieb:
> Nano schrieb:
>> Visio oder die Kopie davon DIA
>> Visio Klon
>> Metageklatsche
>> Metageklatsche
>
> Du wirst ja schon wieder unsachlich...

Was ist daran Unsachlich?

DIA war schon immer als Visio Ersatz gedacht.
Die Zeilgruppe und Zielfunktion ist identisch.

Es ist quasi das Pendant zu Visio, so wie LibreOffice das Pendant zu MS 
Office ist.

Und sag du doch ein besseres Wort für Metageklatsche. Hätte ich 
Metaballast sagen sollen?
Geklatsche fand ich passend, da es sich um Metadaten handelt, die 
dazugeklatscht wurden, aber unnötig sind.


> Dia ist im Übrigen gar kein Klon von Microsoft Visio, sondern wurde von
> The GIMP inspiriert, was man seinem User Interface auch hie und da
> ansieht.

Diese Argumentation ist Unsinn. Dia verwendet lediglich GTK, deswegen 
sieht das Gimp ähnlich, so wie übrigens alle GTK Programme. Das ändert 
aber nichts daran, dass es ein Pendant zu Visio in der Open Source Welt 
sein soll.

> Und Dia gab es schon, als es bei Microsoft noch gar kein Visio
> gegeben hat... Das nur vorweg.

Vielleicht informierst du dich mal richtig.
Visio gibt es seit 1992. Dia erst seit 1998.


>
> Daß Dir meine Kriterien nicht gefallen oder Du sie nicht verstehst, ist,
> Pardon, jetzt wirklich nicht mein Problem.

Ist das alles?
Ich habe es dir wenigstens argumentativ belegt, dass Dia ineffizienter 
ist.

Zähl doch mal dir Schritte um 1 Klasse mit 5 Attributen und 3 Methoden, 
und eine weitere Klasse mit 7 Attributen und 5 Methoden zu bauen und 
dann dann verknüpft das.
Die Liste wird bei Dia viel länger.


> Ich kann nur sagen, daß ich
> schon einige zum Teil sogar ausgesprochen teure UML-Werkzeuge gesehen
> habe, nicht zuletzt auch den alten Platzhirsch in diesem Bereich,
> Rational Rose. Die meisten dieser Werkzeuge haben für das Editieren von
> Klassennamen, -Attributen und -Methoden ziemlich ähnliche Dialoge wie
> Dia, und zwar aus guten Gründen: weil es nämlich einfach sinnvoll ist,
> solche Daten strukturiert zu erfassen und zu speichern. Der große
> Vorteil ist, daß die so eingegebenen Daten automatisiert
> weiterverarbeitet werden können.

Du hast leider immer noch nicht verstanden, dass die Daten bereits 
strukturiert sind.
Und wie man diese strukturierten Daten dann intern abspeichert, ist noch 
eine ganz andere Geschichte. Auch das wäre möglich.


>
> Ich meine, es ist doch schön, daß Du etwas gefunden hast, mit dem Du
> umgehen und arbeiten kannst. Aber versuch nicht, mir zu verklickern,
> meine Kriterien bei der Evaluation und Auswahl meiner Software oder
> diese Software seien doof, ineffizient, unproduktiv oder sonst
> irgendeinen Schwachsinn.

Siehe oben, mach einen Schritt für Schritt Vergleich, dann siehst du es 
selber.


> Ich weiß ja nicht, was Du da mit Deinem
> Eingabefuror machst, aber bei mir (und, nebenbei, auch meinen Kollegen)
> ist das mit Abstand wichtigste Werkzeug bei der Erstellung von
> UML-Diagrammen nicht unsere Tastaturen, sondern unsere Gehirne.

Offenbar machst du dir keine Gedanken darüber, wie man ein 
Klassendiagramm schnell und effizient umsetzt.


> Und was das präzise Positionieren und Ausrichten angeht, so ist ein
> UML-Editor ja nicht nur ein Entwurfs-, sondern auch ein Kommunikations-
> und Dokumentationstool, und zumindest im professionellen Bereich kommt
> es dann nun einmal auch auf eine halbwegs ansprechende Gestaltung an,
> welche im Übrigen auch der Übersichtlichkeit der so erzeugten Diagramme
> ausgesprochen zuträglich ist.

Das ist Unsinn!
Der Endkunde sieht so eine Art der Dokumentation nicht.
Sie ist für die Entwickler gedacht, damit die einen groben Überblick 
über den Aufbau der Software bekommen und da ist es völlig egal, ob die 
Klassendiagramme jetzt auf den mm genau positioniert werden, wichtig ist 
nur, dass sie halbwegs übersichtlich gestaltet sind.

Und wenn du mal in die Situation kommen solltest, dass das wirklich 
sauber aussehen muss. Also wenn du über UML ein Buch schreibst, dann 
kannst du das ganze Klassendiagramm per SVG exportieren und dann in der 
DTP Software nochmal geraderücken lassen.



> Auch die vielen Ausgabe- und Exportformate von Dia sind eine feine
> Sache, denn dadurch kann ich meine Diagramme in alles Mögliche umwandeln
> -- in Code, in eine HTML-Website für unser internes Confluence, als
> Postscript- oder PDF-Datei in die mit LaTeX erstellte Dokumentation.
> Auch das ist für den Kommunikationsaspekt, den gute UML-Werkzeuge
> erfüllen müssen, überaus sinnvoll.

Es gibt genug Tools dir dir SVG in PS, PDF oder LaTeX oder MS Office Doc 
usw. packen können.



> Nebenbei ist mir heute mittag etwas aufgefallen, das mich wieder daran
> erinnert hat, weswegen ich so eine Skepsis gegenüber Java-Software habe:
> das Ding frißt um den Faktor 35 bis 56 mehr Arbeitsspeicher als Dia.

Null Argumentation.
Guck mal an, wieviel RAM du inzwischen im Rechner hast.
Wir haben nicht mehr das Jahr 1997.

> Ich
> möchte gar nicht wissen, was für eine Maschine ich bräuchte, um das
> Klassendiagramm unserer Serversoftware mit ~ 350 Klassen laden und
> darstellen zu können

Und wieder eine Null Argumenation.
Die Klassendaten sind Nutzerdaten und haben mit Java somit erstmal 
ziemlich wenig zu tun.
Als Programmierer solltest du das eigentlich wissen.


> -- und versuchen kann ich es ja leider auch nicht,
> weil VioletUMLEditor nur sein eigenes Dateiformat mit in HTML
> eingebetteten XML und PNG beherrscht, und sonst leider nichts. Nicht
> eben beeindruckend sind auch die unglaublich vielen Formate, in die
> VioletUMLEditor exportieren kann -- nämlich als Grafik oder in die
> Zwischenablage. Aber ich kann mir ja Konverter schreiben... janeeisklar,
> natürlich kann ich, aber warum sollte ich, wenn ich dasselbe bereits
> fertig, stabil, getestet und reproduzierbar bei Dia habe?

Weil Dia ineffizient ist. Oben habe ich es erklärt warum.
Zähl die Schritte, dann sollt dir das auffallen.


> Unterm Strich, sei mir nicht böse, sieht VioletUMLEditor für mich aus
> wie eine Hobbyarbeit von einem Studenten, der im dritten Semester etwas
> über Java und UML gelernt hat und das jetzt mal ausprobieren wollte.

Jedes Open Source Projekt hat mal klein angefangen, auch Dia.
Und das UML Projekte nicht so viel Entwicklerzulauf bekommen liegt 
schlichtweg daran, weil UML heutzutage gar nicht in dem Umfang 
eingesetzt wird, wie man sich das ursprünglich mal gedacht hatte.


> dann diese verkrüppelte Eingabe mit Multilinefeldern...

Genau die ist ein Vorteil.
Oben habe ich es erklärt.
Für ein weiteres Attribut musst du nämlich nur die Entertaste drücken 
und dann dein Attribut eingeben.
Bei Dia musst du dich stattdessen durch nen Wolf klicken.



> Aber wenn es Dir gefällt und für Deine Bedürfnisse ausreicht, warum
> nicht? Ich meine, ich bin hier ja nicht der... Mensch, der anderen
> erzählen will, welche Software effizient sei und welche Software sie
> empfehlen oder gar nutzen dürften.

Du bist der Mensch hier, der Violet kritisiert hat und Dia als das beste 
von allem hingestellt hast, was es bei genauerem Blick nicht ist.
Ich habe Violett lediglich empfohlen.

[UMLenker (Gast)]

Nano schrieb:
> Violet UML Editor
>
> https://sourceforge.net/projects/violet/

Weiß nicht wie ich dort meine C Strukturen korrekt darstellen soll

Habe jetzt auch das Programm Dia Diagramm geht das etwas damit?

A. S. schrieb:
> . Sonst lieber bei
> der einen Sprache bleiben und z.b. doxygen oder einfache
> Strukturdiagramme malen.

Ja einfache Strukturdiagramme z.B gibts da irgendwelche 
vorgaben/Beispiele?


* Also das Tool wäre nicht so wichtig
* Es geht mir nur um die Darstellung von Strukturen in C.
* Soll ich das einfach so mahen wie bei Klassendiagrammen in C++?
* Es muss doch eine art UML-Software-Engineering Lösung für C Programme 
geben?!

[A. S. (Gast)]

UMLenker schrieb:
> * Es geht mir nur um die Darstellung von Strukturen in C.

wofür, bzw. für wen? Ein Kästchen um die Strukur herum wird nur dann 
optisch sinnvoll, wenn es auf ein Dutzend Elemente beschränkt bliebt.

Versuch doch einfach mal Doxygen oder irgendein C++-Tool. Oder schreib 
mal, was Dir so vorschwebt, wenn Du eine (verschachtelte) Struktur hast

struct sFoo1{
   int a;
   int b;
   void (*func)(void);
}

struct sFoo{

   struct sFoo1 pFoo1;
   int d;
   void (*func)(struct sFoo1 *pFoo);
}

[Fred (Gast)]

Wenn ich versuche, mir die Mitgliedsvariablen einer Klasse, dargestellt 
in UML visuell vorzustellen, dann sehe ich in der Tat eine Liste in 
einem Kasten.

Im wesentlichen ist der Satz von Mitgliedsvariablen des Individuums 
einer Klasse mit einer Variablen vom Strukturtyp nicht verschieden; man 
könnte sagen sie sind gleich, denn es handelt sich um eine Folge von 
Variablen.

Die Ausgangsfrage ist daher einfach mit ja zu beantworten.

[Klaus W. (mfgkw)]

UML ist ja eher für objektorientierte Umgebungen gedacht.

Nichtsdestotrotz kann man plattes C auch damit beschreiben.

Fred schrieb:
> Im wesentlichen ist der Satz von Mitgliedsvariablen des Individuums
> einer Klasse mit einer Variablen vom Strukturtyp nicht verschieden; man
> könnte sagen sie sind gleich, denn es handelt sich um eine Folge von
> Variablen.

Genau, das kann man auch für C-structs verwenden. Was in UML eine Klasse 
ist, ist dann halt in C die struct.

Aggregation geht natürlich (struct in einer anderen).

Was zwangslöufig eher mager ist in C, sind Ableitungen.
Eine struct sock_addr_in könnte man sich als Ableitung von einer struct 
sock_addr vorstellen, dann hört es aber auch schnell wieder auf.

Zumindest Daten kann man damit beschreiben. Ob der TO mehr will, weiß 
ich nicht so recht. LEtztlich könnte man in UML wesentlich mehr 
ausdrücken als in C.

[Nano (Gast)]

UMLenker schrieb:
> Weiß nicht wie ich dort meine C Strukturen korrekt darstellen soll

Bei C würde ich mir gar nicht die Mühe machen es in UML zu quetschen,
sondern einfach beim reinen C Quellcode bleiben und es dabei belassen.
Geübte Programmierer brauchen nicht mehr als das, um sich im Quellcode 
zurechtzufinden.

Wenn es aber unbedingt sein muss:

C Structs entsprechen im Prinzip den Attributen im UML Klassendiagram.
Den Namen des Structs kannst du im UML Klassendiagramm als Klassenname 
missbrauchen.

Da an die C Structs keine Funktionen gebunden sind, wie es bspw. bei 
Objektorientierten Programmiersprachen mit Klassen und ihren Methoden 
der Fall wäre und die in C somit frei "herum hängen", brauchst du da 
schon etwas Selbstdisziplin. Du findest im Internet genug Informationen, 
wie du mit C objekt orientiert programmierst und wenn du dich strikt an 
die dort entsprechenden Regeln hältst, kannst du die C Funktionen in die 
Methoden des UML Klassendiagramms packen


Wenn es dir jetzt aber nicht um eine visuelle Darstellung der Daten, 
sondern nur um den Programmablauf geht, gäbe es noch die Möglichkeit es 
so wie früher mit einem Programmablaufplan (PAP) oder Struktogramm zu 
machen. Beides ist aber nicht mehr zeitgemäß und im Prinzip hast du das 
alles ja schon im Quellcode. Solltest du das aber dennoch wollen, dann 
ist der PAP dem Struktogramm klar vorzuziehen.
https://de.wikipedia.org/wiki/Programmablaufplan
https://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm

[Ein T. (ein_typ)]

UMLenker schrieb:
> Habe jetzt auch das Programm Dia Diagramm geht das etwas damit?

Nicht mit dem Programm alleine, nein. Aber ich habe das jetzt mal 
ausprobiert und dazu das Programm cpp2dia [1] installiert und 
konfiguriert. Das wiederum hängt vom Programm "Exuberant Ctags" [2] ab, 
das ich heruntergeladen, konfiguriert und übersetzt ("./configure && 
make") habe, eine Installation ("sudo make install") war nicht notwendig 
-- aber dafür mußte ich den korrekten Pfad in der ~/.cpp2diarc 
eintragen, die beim ersten Aufruf von cpp2dia.tclsh angelegt wurde. Bei 
den anderen Abhängigkeiten von cpp2dia (tcl, graphviz, dia) haben die 
Versionen, die mein Kubuntu 20.04 mitgebracht hat, völlig ausgereicht.

Danach habe ich mir die Quellen des in C geschriebenen LDAP-Browsers 
"gq" geschnappt. Im Verzeichnis mit den Sourcen mußte ich die Dateien 
von ".c" in ".cpp" umbenennen und im Code den String "struct" in "class" 
umbenennen, danach habe ich cpp2dia.tclsh im Verzeichnis mit dem 
Quellcode von "gq" aufgerufen, und heraus kam eine Dia-Datei, die ich 
dann mit Dia in das im Anhang befindliche PNG exportiert habe. Für rund 
eine halbe Stunde Arbeit finde ich das Ergebnis schon ganz brauchbar, 
wenngleich cpp2dia allerdings keine Kompositionen (eine Struktur ist ein 
Element einer anderen) finden konnte. Keine Ahnung, ob das eventuell 
auch möglich wäre, zur Not könnte man das ja -- je nachdem, wieviel es 
ist -- auch noch manuell machen. Im Falle von "gq" mit etwa 25k LOC und, 
wenn ich mich nicht verzählt habe, 62 "Klassen" würde ich schätzen, daß 
das in ein bis zwei Stündchen gemacht sein könnte, aber das hängt 
natürlich davon ab, wie umfangreich Dein Code ist. Es kann auch sein, 
daß Du etwas andere Vorarbeiten leisten müßtest als ich, insofern: HTH, 
YMMV.

Hinsichtlich anderer Einblicke möchte auch ich das hier bereits mehrmals 
empfohlene Programm doxygen empfehlen. Das kostet ein bisschen 
Einarbeitungszeit, erzeugt dann aber eine übersichtliche, durchklickbare 
Dokumentation, inklusive Aufrufgraphen und so weiter. Wenn Du Dich 
häufiger durch fremden Code fräsen oder Deinen eigenen sauber 
dokumentieren mußt, lohnt sich eine gründliche Einarbeitung in doxygen 
in jedem Fall für Dich! ;-)


[1] http://cpp2dia.sourceforge.net/
[2] http://ctags.sourceforge.net/

[UMLenker (Gast)]

Ein T. schrieb:
> Wenn Du Dich
> häufiger durch fremden Code fräsen oder Deinen eigenen sauber
> dokumentieren mußt, lohnt sich eine gründliche Einarbeitung in doxygen

haha sieht wohl so aus

Ein T. schrieb:
> cpp2dia

ah ok . das Ding ist ich kann das auch selber zeichnen. Das muss das 
Tool nicht unbedingt machen.
Am Ende muss ich ja eh wissen ob es richtig gezeichnet wurde.
Also so oder so.
Ob es jetzt automatisch gemacht wurde, oder ob ich es selber zeichne.
Das ist der wesentliche Punkt den ich noch klären will.

Nano schrieb:
> Wenn es aber unbedingt sein muss:
>
> C Structs entsprechen im Prinzip den Attributen im UML Klassendiagram.

genau in diese Richtung möchte ich gehen.
:D

Klaus W. schrieb:
> Was in UML eine Klasse
> ist, ist dann halt in C die struct.

A. S. schrieb:
> Versuch doch einfach mal Doxygen oder irgendein C++-Tool. Oder schreib
> mal, was Dir so vorschwebt, wenn Du eine (verschachtelte) Struktur hast

Mach ich.

Fred schrieb:
> Die Ausgangsfrage ist daher einfach mit ja zu beantworten.
juhey

Ein T. schrieb:
> Es kann auch sein,
> daß Du etwas andere Vorarbeiten leisten müßtest als ich, insofern: HTH,
> YMMV.
Was bedeutet HTH und YMMV?

[Klaus W. (mfgkw)]

UMLenker schrieb:
> Was bedeutet HTH und YMMV?

Falls google mal ausfällt:

HTH = "Hope this helps" (Ich hoffe, die geholfen zu haben)
YMMV = "your mileage may vary (Bei meinem Auto ist die Reichweite..., 
bei dir kann es anders sein wenn du anders fährst oder deine Beifahrer 
mehr/weniger wiegen)"

HTH

[Ein T. (ein_typ)]

Nano schrieb:
> Ein T. schrieb:
>> Aber wenn es Dir gefällt und für Deine Bedürfnisse ausreicht, warum
>> nicht? Ich meine, ich bin hier ja nicht der... Mensch, der anderen
>> erzählen will, welche Software effizient sei und welche Software sie
>> empfehlen oder gar nutzen dürften.
>
> Du bist der Mensch hier, der Violet kritisiert hat und Dia als das beste
> von allem hingestellt hast, was es bei genauerem Blick nicht ist.
> Ich habe Violett lediglich empfohlen.

Immer schön bei der Wahrheit bleiben, ja? Ich habe Dia in meinem Beitrag 
Nr. 7013123 vom 24.03.2022 12:09 [1] empfohlen, Du hattest dann in 
Deinem Beitrag Nr. 7013152 um 12:38 Uhr des Tages geant^W dagegen 
geschimpft und gegen meine Empfehlung gerantet. Dabei hatte ich 
VioletUMLEditor in meinem ersten Beitrag gar nicht einmal erwähnt, 
geschweige denn, es zu kritisieren -- wie auch, ich kannte das Programm 
damals noch gar nicht. Ich habe Dia auch nicht, wie Du leider falsch 
behauptest, als "das beste von allem hingestellt", sondern hatte 
geschieben: "Für die Erzeugung von Diagrammen verwende ich gerne das 
Programm dia  [1]. Das kann nicht nur UML, sondern auch verschiedene 
andere Diagrammtypen, ist IMHO einfach zu bedienen und für Windows, 
MacOS und Linux verfügbar", siehe unter [1]. Das liest sich allerdings 
vollkommen anders, als Du es jetzt behauptest, findest Du nicht auch?

Schau, ich weiß ja, daß Du mich nicht ausstehen kannst und in Deinem 
Furor leider auch manchmal dazu tendierst, es mit Wahrheit, Sachlichkeit 
und Höflichkeit nicht sonderlich genau zu nehmen. Aber können wir uns 
bitte darauf einigen, daß Du meine Beiträge nur noch dann beantwortest, 
wenn Du ernsthaft was substanziell Sinnvolles und Sachliches dazu 
beitragen kannst? Das würde ich nicht nur Dir und mir, sondern auch 
unseren Lesern und den jeweiligen TOs gegenüber nett finden, vielen 
Dank.

Aber genug der Metadiskussion, kommen wir zum Thema zurück.

Schau, es ist nicht schlimm, daß wir diese Werkzeuge eben 
unterschiedlich nutzen und  unterschiedliche Anforderungen an solche 
Werkzeuge haben. Während es Dir ausreicht, beim Entwurf ein mehr oder 
weniger sauberes Diagramm zu skizzieren und dann anhand Deines Diagramms 
manuell Deinen Code zu schreiben, dienen solche Diagramme bei mir, wie 
erwähnt, nicht nur Entwurfs- sondern auch noch gänzlich anderen Zwecken, 
etwa Kommunikations- und Dokumentationszwecken, und eben auch zur 
Erzeugung von Code. Wir haben dabei also offensichtlich unterschiedliche 
Anwendungsfälle und deswegen auch zwangsläufig verschiedene 
Anforderungen an derartige Werkzeuge.

Anstatt diese simple Tatsache zu akzeptieren, erklärst Du meine 
Anwendungsfälle aber einfach mal für unsinnig und stellst Deinen als die 
Einzig Wahre Wahrheit (tm) dar. Mein Anwendungsfall scheint aber nicht 
so völlig ungewöhnlich zu sein, dünkt mich, denn zum Beispiel die 
Wikipedia-Übersicht zu den Features solcher Werkzeuge [3] hat sogar 
eigene Spalten dafür, ob und welche Sprachen die jeweiligen Tools 
generieren und / oder einlesen können. Und zumindest die mir bekannten 
Werkzeuge, die aus den Diagrammen Code generieren können -- neben Dia 
wären das zum Beispiel auch Umbrello und Rational Rose -- händeln die 
Eingabe von Attributen und Methoden ganz ähnlich wie auch Dia das macht. 
Warum nur? Weil Unternehmen, die mehrere tausend Euro für ein 
UML-Modellierungswerkzeug ausgeben, sich dann auch noch Ineffizienz bei 
deren Benutzung leisten können? Oder vielleicht doch, weil eine 
strukturierte Eingabe mit säuberlich getrennten Datenfeldern hier schon 
mindestens dann die sinnvollste und effizienteste Idee ist, wenn man 
brauchbaren Code daraus erzeugen will?

Es erscheint mir auch einigermaßen anachronistisch, fehlerträchtig und 
ineffizient, erst ein UML-Diagramm hinzuschmieren und danach alles, was 
man darin doch bereits eingegeben hat, manuell noch einmal abzutippen. 
Spätestens an dieser Stelle wird höchstwahrscheinlich jeder Vorteil 
einer effizienteren Dateneingabe wieder völlig zunichte gemacht, würde 
ich mal vermuten, auch wenn Du mir darin sicherlich gleich wieder auf 
das Vehementeste widersprechen wirst.

Ich sehe die strukturierte Dateneingabe aber auch nicht als ineffizient 
an; sowohl ich als auch alle meiner Kollegen, die ich diesbezüglich 
gefragt habe, verwenden in der Arbeit mit UML-Modellierungswerkzeugen 
höchstens zehn Prozent unserer Zeit für die eigentliche Dateneingabe 
(zehn Prozent war der höchste erfragte Wert, andere Kollegen sprachen 
sogar von höchstens einem Prozent) und die übrige Zeit darauf, unsere 
Softwarearchitektur zu entwerfen, was weniger Tipp- als Denkarbeit ist. 
Wenn nun aber höchstens ein bis zehn Prozent der Arbeitszeit bei der 
Nutzung derartiger Werkzeuge auf die Dateneingabe entfällt, dann spielt 
deren Effizienz natürlich bei Weiten keine so große Rolle mehr, wie Du 
uns aufdrängen möchtest. Dieser Aspekt ist obendrein auch noch lediglich 
auf die Eingabe beschränkt, aber derartige Diagramme werden natürlich 
viel häufiger gelesen als editiert -- weswegen sich alle weiteren 
Erwägungen hinsichtlich der Effizienz natürlich zwangsläufig auch auf 
eine sauber strukturierte, übersichtliche und ansprechende Darstellung 
erstrecken müssen.

Zudem erstellen wir unsere UML-Diagramme nicht nur mit offensichtlich 
vollkommen anderen Zielen, sondern auch für gänzlich andere Zielgruppen. 
Während bei Dir nur allein der Entwickler im Vordergrund steht, um ihm 
einen schnellen Überblick über die Softwarearchitektur zu geben, muß ich 
auch noch andere Zielgruppen als die Entwickler bedienen, zum Beispiel 
Kunden, Auditoren, die Fachleute vom Software Escrow, und nicht zuletzt 
auch das eigene Management. Wir haben dabei nämlich oft verschiedene 
Regularien und Richtlinien zu beachten, wie die Normen ISO 9k und 27k, 
Gesetze und Verordnungen wie HIPAA und die der BaFin, zivilrechtliche 
Vertragswerke wie PCI-DSS sowie, natürlich, Security Audits. In vielen 
dieser Fäll ist es zu Dokumentations- und Kommunikationszwecken 
sinnvoll, ansprechende und übersichtliche UML-Diagramme vorlegen zu 
können. Deswegen haben im Gegensatz zu VioletUMLEditor die meisten für 
den professionellen Bereich gedachten Werkzeuge auch eigens Funktionen, 
um die Objekte im Diagramm ordentlich auszurichten und ihr Aussehen 
anzupassen.

Demgegenüber kann das Pogramm, welches Du so... nachdrücklich 
empfiehlst, seine Objekte noch nicht einmal einfärben, um logische und 
thematische Zusammenhänge übersichtlich darzustellen! Ich finde das 
Fehlen eines so eklatant wichtigen Features erschütternd -- bei 
Diagrammen mit mehr als zwanzig bis dreißig Klassen könnte ich ohne 
farbliche Zuordnungen kaum noch die Zusammenhänge übersehen, und schon 
gleich gar nicht auf den ersten Blick.

Zuletzt möchte ich darauf hinweisen, daß ich es im Gegensatz zu Dir 
geschafft habe, die Frage des TO zu beantworten und ihm eine nicht 
unbedingt elegante, dennoch aber vorhandene Möglichkeit aufgezeigt habe, 
seinen C-Code in ein Diagramm zu überführen. Alles, was Du bisher dazu 
beigetragen hast, waren die Empfehlung eines Programms, dem sinnvolle 
Funktionen fehlen, sowie Dein großzügiger Hinweis, daß ein geübter 
Entwickler sich ohnehin besser im Quellcode zurecht finden würde. 
Verzeihung, aber der TO hat seine Frage mutmaßlich gerade deswegen 
gestellt, weil er das offenbar nicht so gut kann wie Du und deswegen 
etwas Übersichtlicheres sucht...


[1] Beitrag "Re: c Bibliothek mit strukuren in uml darstellen"
[2] Beitrag "Re: c Bibliothek mit strukuren in uml darstellen"
[3] 
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools