Was bringt ModelMaker?

[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 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
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