Sollten Sie vor oder nach der Implementierung Klassendiagramme erstellen?

So wie ich es sehe, wenn Sie eine erstellen, bevor Sie den Vorteil haben:

• Vorausplanen
• Überblick über das Projekt

aber du verlierst:

• Zeit (bei der Arbeit wiederholen Sie sich wahrscheinlich beim Schreiben von Code)

Auf der anderen Seite könnte ich sie alle nach dem Schreiben meines Codes erstellen, um ihn als Referenz für zukünftige Entwickler zu behalten.

Welches dient dem Zweck von Klassendiagrammen und welches ist vorteilhafter?

Wenn Sie sie zuvor erstellt haben, sind sie Teil der Entwurfsphase.

Wenn Sie sie später erstellen, können Sie sie nur zur Dokumentation verwenden. Die Dokumentation ist jedoch besser und schneller, wenn Sie dies während des Entwurfs und der Codierung tun.

Übrigens verlieren Sie beim Design keine Zeit! Der Codierungsteil wird schneller sein. Und besser.

Denken Sie schließlich, dass das Entwerfen eines Wolkenkratzers oder einer Brücke ein Zeitverlust ist, anstatt nur mit dem Bau zu beginnen?

Ein Kompromiss besteht darin, während der Entwurfsphase mit der Erstellung von Dummy-Code zu beginnen (nur Prototypen von Klassen / Funktionen) und dieses Codeskelett zum Erstellen der Klassendiagramme zu verwenden.

Wenn ich sie vor dem Codieren erstellt habe, betrachten wir sie als "temporäre" Dokumente. Das heißt, wir erstellen die Diagramme und bringen unsere Gedanken auf Papier. Wir beginnen mit der Codierung anhand dieser Klassendiagramme. Wir werfen sie dann raus. Es lohnt sich nicht, die Zeit für die Wartung zu verwenden, sobald die Codierung begonnen hat. Wenn Sie aktuelle Klassenmodelle wünschen, verwenden Sie ein Tool, um sie aus dem Code zu erstellen.

In beiden Fällen bleiben sie als Teil der Dokumentation erhalten. Niemand wird sie aktualisieren, wenn Änderungen an der Implementierung vorgenommen werden. Die Diagramme enthalten keine Datumsangaben, sodass Sie nicht einmal wissen, auf welche Version des Codes sie sich beziehen. Wenn eine neue Person zum Projekt hinzugefügt wird, geben Sie ihr die Diagramme mit der Aufschrift "Hier sind einige Diagramme, die zu einem bestimmten Zeitpunkt während des Entwurfs oder der Implementierung erstellt wurden. Wir wissen nicht, wie aktuell sie sind."

Dies ist Teil des Designs und sollte daher vor der Implementierung erstellt werden. Dies bedeutet nicht, dass sie während / nach der Implementierung nicht verfeinert werden können, um den aktuellen Implementierungsstatus widerzuspiegeln.

Das Bereitstellen eines Designs nach der Implementierung ist das, was ich als "Cowboy-Codierung" bezeichnen würde, und Sie können sicher im wilden Westen gedeihen, aber denken Sie daran, dass Cowboys normalerweise irgendwann tot enden.

Dies hängt von der Tiefe des Designs ab. Einige Leute bestehen darauf, Klassendiagramme auch für die trivialsten Klassen zu schreiben, weil "es eine gute Praxis ist". Ich denke, es ist Zeitverschwendung, etwas zu zeichnen, wenn Sie bereits genau wissen, wie es implementiert wird. Wenn Sie ein neues Design erstellen , das nicht bekannt ist, ist es auf jeden Fall nützlich, zuerst einige Diagramme zu zeichnen.

Ich verwende jedoch nie UML-Tools, da sich das Design während der Implementierung normalerweise so stark ändert, dass ich das Diagramm neu zeichnen muss. Ich nehme an, ein gutes Zwei-Wege-Tool würde diese Änderungen bewältigen, aber ich habe noch nie ein gutes verwendet (ich habe jedoch nur kostenlose verwendet). Stattdessen zeichne ich auf Papier oder auf ein Whiteboard, um das Design zu sortieren. Nachdem ich es implementiert habe und ziemlich sicher bin, dass es einwandfrei ist, werde ich ein formelleres Diagramm erstellen.

Vergessen wir auch nicht die anderen Diagrammtypen. Ich habe immer festgestellt, dass Sequenzdiagramme zu den nützlichsten gehören, und ich verwende sie häufig, wenn zwischen den Komponenten viel Kommunikation besteht.

Vor der Implementierung. Wie einer meiner ehemaligen Mitarbeiter einmal sagte: "Ich programmiere gerne so viel wie möglich, bevor ich mit dem Codieren beginne", und ich denke, das ist ein guter Ansatz.

Ich finde, dass das Zeichnen eines Diagramms mich normalerweise auf fehlende Informationen hinweist. Dies passiert auch, wenn ich nur einen Code-Editor eingebe, ohne das Diagramm gezeichnet zu haben, die Instanzen jedoch weiter voneinander entfernt sind (weil ich Zeit damit verbringe, Algorithmen, Berechnungen und Tests usw. zu schreiben), und ich daher möglicherweise mehr Zeit dafür habe Gehen Sie vorbei, bevor Sie meine fehlenden Informationen erhalten.

Auch wenn sich das Design, das Sie vage in Ihrem Kopf haben, als Mist herausstellt, werden Sie dies schneller bemerken, wenn Sie es zuerst grafisch darstellen. Deshalb zeichne ich zumindest etwas schnelles und informelles. Ob daraus ein elektronisches Diagramm wird, das andere als Referenz verwenden können, hängt vom Projekt ab.

Die Erstellung von Klassendiagrammen sollte während und nach der Erstellung erfolgen, da das Modell mit den Änderungen des Codes und der Anforderungen interaktiv sein sollte. Zuerst müssen Sie ein Klassendiagramm erstellen, um Ihr Projekt zu starten. Es wäre hilfreich, Ihre Objekte auf einer höheren Abstraktionsebene zu visualisieren. Sie können eine stabile und intelligente Softwarearchitektur erstellen. Dann müssen Sie codieren und manchmal werden Sie feststellen, dass die Architektur, die in UML gut zu sein scheint, im Code nicht wirklich möglich ist. Anschließend ändern Sie Ihren Code und Ihre Architektur. Schließlich aktualisieren Sie Ihr Modell durch Codeänderung und generieren Dokumentation.

In meinem letzten Projekt haben Entscheidungsträger meine Anforderungen im letzten Jahr über 50 Mal geändert. Es ist wirklich schmerzhaft und UML hilft mir, die Rückverfolgbarkeit von Änderungen zu gewährleisten und warum. UML sollte das Zusammenführen von Modell und Code jederzeit iterativ ermöglichen (z. B. von Code zu Modell, von Modell zu Code, von beiden, von Code nach dem Refactoring usw.). Ich verwende Omondo EclipseUML für Helios und bin sehr zufrieden damit dieses Werkzeug. Meine Lieblingsfunktion ist die Modellzusammenführung, mit der ich mein Modell jederzeit aktualisieren kann, ohne Modellinformationen zu verlieren. Ich mag es auch, wenn Entitäten direkt im Klassendiagramm modelliert werden und die Datenbank mithilfe von Stereotypen und Ruhezustand erstellt wird. Wirklich mächtig und vollständig vom Objekt zur Datenbank !!

Vorher : Es wird Ihnen helfen, Ihre Gedanken zu organisieren und Ihre Absichten zu kommunizieren. Gehen Sie hier nicht auf Details ein.

Nach : es aus dem Code als Teil des Build - Prozesses automatisch generiert wird , offensichtlich (hoffen , sind auch Sie nicht zu uml angebracht)

Beide sind nützlich, aber die vor Sachen weg so schnell geworfen werden können , wie es implementiert ist ... es ist schon veraltet sowieso an dieser Stelle.

Mit Topcased erstelle ich meine Klassendiagramme während der Entwurfsphase. Dann klicke ich auf die Schaltfläche "Code generieren", um eine Zeichenfläche meiner Implementierung zu erstellen. Dann fülle ich die Platzhalter mit Code aus.

Ich werde für die Antwort stimmen (C) Mach dir keine Sorgen.

Sie sind weitgehend unnötig. Persönlich mache ich mir nie die Mühe, sie anzusehen, wenn sie zur Verfügung gestellt werden.

Sie sind vor der Entwicklung nicht erforderlich, da sich das Design ohnehin ändern wird. Und wenn Sie nicht glauben, dass sich das Design Ihrer Klassen ändern wird, legen Sie sich bereits Handschellen an und verhindern, dass Ihr zukünftiges Selbst das Problem richtig lösen kann. Wenn Sie der Meinung sind, dass Sie sich an bereits vorhandene Klassendiagramme halten müssen, arbeiten Sie entweder für die NASA oder Sie schießen sich in den Fuß.

Danach sind sie unnötige Dokumentation. Wenn Sie mit einer kleinen Code-Inspektion nicht herausfinden können, was die Klassen tun oder wie sie miteinander in Beziehung stehen, haben Sie eine Lücke in Ihren Fähigkeiten als Softwareentwickler.

Natürlich klingt diese Antwort wirklich arrogant und eigensinnig; Naja.

Bei Eiffel und den zugehörigen Tools ist dies nur ein Unterschied in der Sichtweise, die alle auf dieselben zugrunde liegenden Dateien verweisen.