Was bringt ModelMaker?

[oki]

:( Hallo alle zusammen!

Ich suche gerade eine Möglichkeit mehr Ordnung und Übersichtlichkeit in meine Projekte und dessen Code zu bekommen. Jedes einzelne ist in der Regel sehr groß, komplex und über längere Zeiträume entstanden.
Oft sehe ich bei meinem eigenen code nicht mehr so richtig durch, oder schreibe Sachen versehentlich doppelt. Da würde sicher eine gute Doku helfen, aber bis heute habe ich es nicht geschafft zu meinen Programmen, Komponenten, Klassen und Objekten etwas durchgängig anständiges auf die Beine zu stellen.

Letztens hat mir ein Bekannter erzählt, dass er fast nur noch mit ModelMaker arbeitet. Das währe so toll.

Jetzt hab ich mir das Demo gedownloaded und mal rein geschaut. Hat mir so richtig nichts gebracht .

Kann mir mal jemand kurz beschreiben was mir ModelMaker bringt und ob eine Nutzung wirklich Sinn macht?


Par Tipps währen toll,


Gruß oki

[RavenIV]

Zitat:

Zitat von oki

Letztens hat mir ein Bekannter erzählt, dass er fast nur noch mit ModelMaker arbeitet. Das währe so toll.

Dann belästige doch Deinen Bekannten noch mal.
Wenn er es so tool findet, kann er Dir auch sicher was darüber erzählen...

[oki]

Hi RavenIV,

mein letzter Besuch hier ist leider schon etwas länger her. Hatte ne Menge um die Ohren.

Leider scheint der Ton hier etwas rauher geworden zu sein. Ich hatte eigentlich nicht erwartet, dass hier jemand der Meinung ist, Fragen sind unangebracht.

Egal, vielleicht gibt es hier noch andere.

Mich interessiert hier die Meinung anderer Leute. (an meinen Bekannten komme ich zur Zeit auch nicht ran.


o.k. vielleicht gibt's hier noch andere,


Gruß oki

[dataspider]

Hi Oki,

ich hatte mir vor ein paar Jahren ModelMaker und den ModelMaker CodeExplorer zugelegt.
Mittlerweile arbeite ich nur noch - aber mit Begeisterung - mit dem CodeExplorer.
Er vereinfacht das Coding ungemein.
An ModelMaker hat mich gestört, dass er nicht in die IDE integriert ist und man keine Codevervollständigung nutzen kann. Ab und zu mache ich mal noch ein Klassendiagramm.
Weiterhin kann man nicht so ohne Weiteres Formulardateien bearbeiten.
Es kann natürlich sein, dass ich mich nicht ausreichend mit ModelMaker beschäftigt habe.

Vielleicht fehlt dir eher ein gutes Dokumentationstool wie z.B. doc-o-matic von toolsfactory.
Es erstellt auch Klassendiagramme, nur nicht so gut wie in ModelMaker. Aber damit erhält man sehr gute Hilfe - Dateien. Die Hilfe in Delphi integriert - und schon hab ich dank F1 doch schon recht gute Übersicht über meinen Code. Man muss sich natürlich zwingen, auch mal erläuternden Text in die Doc zu schreiben.
Mit GExperts erstelle ich übrigens meine Unit- und Procedureheader. Die hab ich einmal an doc-o-matic angepasst - funktioniert super.

Cu, Frank

[oki]

Hi dataspider,

erst mal herzlichen Dank für deine Antwort. Hatte schon Sorge um die Kultur hier.

Du triffst so ziemlich den Nerv der Sache. Grundlätzlich geht es mir wirklich um genau zwei Themen, gute Dokumentation (techn.) und Strukturierung meiner Objekte. Nach doc-o.matic werd ich mal google'n.

Mit dem erläuternden Text hab ich kein Problem, ist eh schon massig in meinem Code. Aber das Ding mit GExperts sagt mir aktuell nichts. Kannst du mir dazu noch einige Infos geben?

Gruß oki

[dataspider]

Hi oki,

GExperts ist ein sehr guter Helfer. Einfach mal installieren und ausprobieren.

Zur Dokumentation benutze ich die Macro Templates von GExperts.
Menü: GExperts - Editor Experts - Expand Macro Templates (SHIFT - ALT - T)

So sieht z.B. das Template für einen Procedure Header aus:

Delphi-Quellcode:

{ ------------------------------------------------------------------------------
 Procedure: %PROCNAME%
 Author:    %USER%
 Date:      %DAY%-%MONTHSHORTNAME%-%YEAR%
 Description:

 See Also:

 Arguments:
   %ARGUMENTS%
 Return Value:
   %RESULT%
 Summary:
------------------------------------------------------------------------------ }

Die Schlüsselwörter wie Description, See Also, Summary etc. kennt doc-o-matic und verlinkt damit seine Informationen.
Dadurch erhält man eine saubere und gut strukturierte Hilfe.

Cu, Frank

[oki]

Hi dataspider,

doc-o-matic hab ich mir schon mal kurz angesehen. Sieht auf den ersten Blick sehr gut aus, hat aber auch einen stolzen Preis. Das für mich interessanteste daran war die Integration in die Delphi-Hilfe. Vielleicht gibt es ja sowas ähnliches auch noch für weniger Geld?

Jetzt schau ich mir noch GExperts an.

somit erst mal herzlichen Dank.

gruß oki

[dataspider]

Zitat:

Zitat von oki

Das für mich interessanteste daran war die Integration in die Delphi-Hilfe.

Das ist kein Feature von doc-o-matic. Das mache ich in Delphi über Hilfe - Anpassen ...

Na ja, und der Preis (499,- gegen 299,- für ModelMaker) ist schon hart.
Aber ich habe auch lange nach einer Alternative gesucht und leider nichts gefunden.

Cu, Frank

[HERMES]

Ich benutze auch ModellMaker, ich kann mich dazu nur der KRitik vom Dataspieder anschliessen. Wenn man allerdings ein neues Projekt aufbaut und MM von vorneherein benutzt, klappt es auch mit der Dokumentation ganz gut, wenn man allerdings schon ein großes Projekt hat wird es ziemlich aufwendig, das noch in MM nachzudokumentieren.

Für "kleinere" Sachen, verwende ich eine modifizierte Version von javadoc. Such mal nach javadoc und Delphi.

[oki]

Hi Hermes,

auch dir Dank für den Beitrag. Gerade jetzt poppt bei mir diese Frage hoch, weil ich ein recht umfangreiches Projekt zu laufen habe und so langsam der Überblick verloren geht.
da schein also MM nachträglich nichts zu sein.

Meine üblichen mehr oder weniger gepflegten Kommentare füge ich in der Regel mit /// oder {* *} ein.
vielleicht kennt jemand ja ein preiswertes oder freies Tool?

Gruß Oki

[stoxx]

Zitat:

weil ich ein recht umfangreiches Projekt zu laufen habe und so langsam der Überblick verloren geht.

was genau ist Dir zu unübersichtlich ?
Ich vertrete ja die Meinung, der Quelltext ist selbst die beste Dokumentation.
Wenn man JEDER kleinen Variable einen sinnvollen Namen gibt, dann kann man den Quelltext lesen wie ein Buch.

Die Namensfindung gestaltet sich allerdings manchmal wirklich schwierig und da zweifel ich manchmal an mir selber :-)

Ich schreibe auch zu jeder Klasse immer kurz was sie macht, welche Objecte sie benutzt und manchmal auch, von wem sie benutzt wird.
Ich persönlich bin mit GExperts und Strg+G hochzufrieden. Mehr benötigt man doch auch nicht, eine gute klare übersicht aller klassen (Objekte) und Funktionen in dieser Unit.
hmm ..

[oki]

Hi,

ich hab mich über's Wochenende mal n' bischen mit GExperts beschäftigt. Das ist eigentlich gar nicht so schlecht. Bevor ich weiter suche werd ich erst mal die Möglichkeiten von GExperts ausloten. Da scheint schon ne ganze Menge möglich zu sein.
Übrigens stoxx,

Zitat:

Die Namensfindung gestaltet sich allerdings manchmal wirklich schwierig und da zweifel ich manchmal an mir selber Smile

Da geht es den Menschen wie den Leuten.


Gruß Oki

[HERMES]

Zitat:

Zitat von stoxx

Ich vertrete ja die Meinung, der Quelltext ist selbst die beste Dokumentation.
Wenn man JEDER kleinen Variable einen sinnvollen Namen gibt, dann kann man den Quelltext lesen wie ein Buch.

Die Namensfindung gestaltet sich allerdings manchmal wirklich schwierig und da zweifel ich manchmal an mir selber :-)
hmm ..

Mit kleienere Progrämmchen klappt, das solange, wie sie kein anderer verstehen muss und man zumindest ungefähr weis, was wann wo und wie passiert. Aber wenn ein anderer kann sehr warscheinlich nicht viel mit deinen guten namen anfangen, denn er hat für sich andere gute namen.
Klar, man kann seine Zeit darauf verwenden die Programme so zuschreiben, dass man sie runterlesen kann wie einen Roman, aber mal erlich spätestens wenn komplexe Algogrithmen ins spiel kommen ists vorbei damit!

[3_of_8]

Was findest du eigentlich so schlimm an RavenIVs Antwort?

Er hat nicht gesagt, Fragen seien unangebracht. Aber dein Bekannter kann dir sicher gut helfen und das ganze auch besser erklären, da er nunmal vor Ort ist.

[oki]

Hi Leute,

erst mal möchte ich 3_of_8 antworten. Sicher könnte mir mein Bekannter eine Antwort geben. Jedoch interessiert mich hier die Meinung anderer. Das ich zusätzlich aktuell an den Bekannten nicht ran komme hatte ich auch schon gesagt. Der Hinweis auf meinen Bekannten sollte auch nur verdeutlichen, dass meine Info's somit recht mager und einseitig sind. Hätten sich hier zwanzig Leute gemeldet und alle behauptet MM ist das Beste, dann gäbe es wohl nicht viel zu diskutieren.
Gerade die hier abgegebenen Kommentare, dass man ein bestehendes Projekt schlecht mit MM weiter führt, hat mir eine Menge Zeit gespaart.
Und Sorry im Voraus, aber ich arbeite nach dem Motto: "Es gibt keine doofen Fragen, nur doofe Antworten!".

Jetzt zum Thema. Ich muß Hermes zustimmen, gerade bei umfangreichen Projekten die über eine längere Zeit laufen, am Besten auch mal ein halbes Jahr pausieren, lassen sich in Ihrem Zusammenhang auch bei gut kommentierten Code schlecht nachvollziehen. Und da rede ich über eigenen Code!!! Eine einfache und gute Doku über die Zusammenhänge der implementierten Klassen, Objecte, Methoden ... würde sicher helfen.

Gruß oki

[HERMES]

Oki hat davon gesprochen, dass er den überblick über seine Projekte verliert weil sie zu groß werden, es ist natürlich ansichtssache wie man ein großes Projekt definiert, aber letztendlich geht es darum, dass er seine bestehenden Projekte dokumentieren will. Daher vermute ich mal, dass er nicht alles nochmal neu schreiben will!
Ein Problem, das erst bei großen Projekten auftritt ist, dass man evntl. die Klassenhirachien, Objektbeziehungen, ... dokumentieren sollte, das geht nunmal Grafisch, per UML sehr gut - desshalb hat er auch anfangs nach ModellMaker gefragt.
Aber da Dokumentation nicht der Zeitverschwendung sondern dazu dient, dass man die Programme wieder versteht, wenn man mal nicht weis, was an eiener stelle geschieht, passiert in großen Projekten wirklich sehr schnell. Auch kann es vorkommen, dass mal ein Kollege an einem Programm weiterarbeitet oder er seine sachen als Open Source ins netz stellt, dann sollen auch andere die Möglichkeit haben das Programm in absehbarer Zeit verstehen zu können.

[oki]

Hi Hermes,

Zitat:

Ein Problem, das erst bei großen Projekten auftritt ist, dass man evntl. die Klassenhirachien, Objektbeziehungen, ... dokumentieren sollte, das geht nunmal Grafisch, per UML sehr gut - desshalb hat er auch anfangs nach ModellMaker gefragt.

genau so sieht es aus. Erschwerend kommt hinzu, dass meine Projekte eben nicht nur paar formulare und Unit's sind, sondern eben auch eigene spezielle Komponente. dort wird es dann richtig haarig. Diese tauchen in der Projektdoku nicht mit auf und müssen/sollten seperat dokumentiert werden. Ein geeignetes Tool für eine Beschreibung via UML ist da schon Gold wert.

Gruß oki

[stoxx]

Zitat:

Mit kleienere Progrämmchen klappt, das solange, wie sie kein anderer verstehen muss und man zumindest ungefähr weis, was wann wo und wie passiert. Aber wenn ein anderer kann sehr warscheinlich nicht viel mit deinen guten namen anfangen, denn er hat für sich andere gute namen.

hmm .. ja .. solche Diskussionen die unterschwellig darum gehen, "meiner ist größer" mag ich überhaupt nicht.
Also ich arbeite nicht an kleinen Projekten sondern seitdem ich angefangen habe zu Programmieren an einem einzigen großen Projekt.
Ätsch, meiner ist Größer :-D
Und ich sehe immer noch durch ! versprochen !

Das Buch "Code Complete" gibt sehr gute Hinweise zur Gestaltung von Quelltext.

Ich kann Dir nur sagen, dass ich, nachdem ich meinen Quellcode in UML angeschaut habe, überhaupt nix mehr verstanden habe ;-)
Vielleicht sollte man in Erwägung ziehen, dass es auch am Lerntyp liegen könnte ( auditiv, visuell, kommunikativ, motorisch)
Und deswegen von Mensch zu Mensch unterschiedlich.

http://www.philognosie.net/index.php...ticleview/163/

Teamerfahrungen hab ich keine, das ist wohl wahr. Aber darum ging es dem Hilfesuchenden ja auch gar nicht.
Ich kann Dir also nicht sagen, ob mit meinem Quelltext jemand anderes zurecht kommen würde ;-)
Ich denke dann sollte UML nur ein ZUSATZ sein. Wie eine Bedienungsanleitung. Seinen eigenen Quelltext sollte man auch ohne Bedienungsanleitung verstehen können !
Beim Autofahren macht sich das auch besser, wenn man alles ohne Bedienungsanleitung im Griff hat ;-)
Und wenn ich nach einem halben Jahr wirklich nicht mehr wußte, welcher Quelltext was genau macht, (vor allen Dingen welcher Teil macht das was ich suche und wo finde ich die Unit) habe ich in kurzer zeit durch aufrufe und "Deklaration suchen" zu meinem Ziel gefunden. Dafür braucht man natürlich eine IDE.

Zitat:

Eine einfache und gute Doku über die Zusammenhänge der implementierten Klassen, Objecte, Methoden ... würde sicher helfen.

ein sinngemäßes Zitat aus dem "Code Complete" Buch.
Dokumentiere nicht das WIE und WAS sondern das WARUM.
Warum Du etwas getan hast und wieso Du dieses oder jenes so gelöst hast und warum nicht anders.


Ich bin der Meinung, für Delphi mit seinem Interface und Implementation Konzept in Units braucht man nur bedingt ein kompliziertes UML Werk.
Der Interfaceteil ist ja schon eine gute Zusammenfassung der Klassen, properties und Methoden. Und wenn dort noch bischen Text steht sollte man alles verstehen.
In anderen Programmiersprachen gilt das natürlich nicht.
Eine grobe Skizze sollte in meinen Augen viel nützlicher sein als von einem Programm generiertes UML Diagramm. (Anders sieht es wahrscheinlich aus, wenn man zuerst das UML Diagramm als Architektur entwirft und danach ausprogrammiert)

Und was ich noch gemerkt habe. // Lieber mal eine Erklärung zu viel, als zu wenig..... schreiben, schreiben, schreiben