Wirklich nützliche UML-Diagramme

UML hat einen Dschungel von Diagrammen.
Profildiagramme, Klassendiagramme, Paketdiagramme ...

Allerdings (IMH-und-nicht-zu-erfahren-O) sehe ich ziemlich, dass es übertrieben ist, jedes einzelne Diagramm zu erstellen.

Welche UML-Diagramme eignen sich daher besser für einen Webkontext, genauer gesagt für ein Blog (wir möchten es von Grund auf neu erstellen).

_{Ich verstehe, dass nur weil ich UML-Diagramme verwendet habe, dies nicht bedeutet, dass unser Code großartig und brillant wäre ... aber es wäre sicherlich besser als nur nicht geplanter Code ...}

Als allgemeine Richtlinie:

• Ein Bereitstellungsdiagramm für einen Überblick über die Architektur (für jedes System geeignet)
• Ein Anwendungsfalldiagramm für eine Übersicht darüber, was Benutzer mit dem System tun werden (dito)
• Ein Klassendiagramm für das Datenmodell
• Aktivitätsdiagramme für den Ablauf einzelner Anwendungsfälle, wenn diese komplex sind
• Möglicherweise ein Zustandsmaschinendiagramm, wenn Sie einen Workflow zum Erstellen / Überprüfen / Veröffentlichen von Blogeinträgen haben

Einige Diagrammtypen (z. B. Zeitdiagramme) haben eher spezielle Verwendungszwecke, andere tendieren zu einer Detailebene, bei der der tatsächliche Code eine bessere Arbeit leistet (z. B. Sequenzdiagramme), und andere scheinen noch für gigantische Projekte gedacht zu sein, haben aber selbst dort einen fragwürdigen Nutzen ( Paketdiagramme? Jede IDE kann Ihnen Ihre Pakete anzeigen.

Das Diagramm ist weniger wichtig als die Gespräche, die Sie führen, wenn Sie Konzepte zwischen den verschiedenen Stakeholdern in einem Projekt kommunizieren. Nach Jahren der Softwareentwicklung habe ich in den letzten Jahren versucht, Informationen noch weniger schematisch zu erfassen als früher, als ich gerade anfing. Heutzutage kann ich bei der Erörterung von Konzepten einige einfache Anwendungsfälle auf einem Whiteboard erstellen, und ich werde häufig auf ein einfaches, aber klassisches Flussdiagramm zurückgreifen, wenn ich versuchen möchte, zu verstehen, wie ein Kunde möchte, dass ein System funktioniert. Wenn ich besonders besorgt bin, verwende ich die Kamera meines Telefons, um das Bild auf dem Whiteboard aufzunehmen und mich an bestimmte Dinge zu erinnern.

Stark dokumentiertes Design im Vorfeld ist nicht sehr schlank. Es entmutigt Veränderungen und fixiert Ihre Überlegungen zu einem einzigen Angriffsplan, der für das gesamte Projekt völlig falsch sein könnte. Sie möchten in der Lage sein, so viel von Ihrem Design wie möglich auf die letzte Minute zu verschieben, um die Wahrscheinlichkeit zu verringern, dass eine große Änderung Ihre Designs und Zeitpläne später durcheinander bringt. Dies bedeutet nicht, dass UML nicht verwendet werden sollte, sondern dass es sparsam verwendet werden sollte, um die Kommunikation von Konzepten zu verbessern, und nicht, um die Systeme zu definieren, die Sie erstellen möchten.

UML wurde als Kommunikationssprache zwischen Beteiligten konzipiert. (Programmierer-Programmierer, Programmierer-Geschäftsleute, Geschäftsleute-Benutzer) Menschen drücken ihre mentalen Modelle in einer einfachen, einheitlichen Sprache aus, die jeder versteht.

Sie müssen sich fragen, wie viel von dieser Kommunikation Sie benötigen.

• Handelt es sich um eine interne Software oder ein internes Produkt, das Sie zusammen mit der Dokumentation verkaufen möchten?
• Wie lange werden Sie die Software warten? Werden Sie einen Programmierer beauftragen, um es zu warten?
• Wie agil willst du sein? Sie könnten Zeit durch zu detaillierte Planung verschwenden.
• Wie seltsame Dinge möchten Sie tun? Normalerweise müssen Sie keine gängigen Muster wie den detaillierten Anwendungsfall der Registrierung oder die Gesamtarchitektur eines Blogs dokumentieren.

Als Faustregel gilt, dass Sie die Diagramme auf hoher Ebene erstellen, um sich einen Überblick zu verschaffen und Zeit mit komplizierten oder nicht so häufigen Dingen zu verbringen. Wenn Sie Ihr mentales Modell in UML schreiben / zeichnen, müssen Sie es vollständig verstehen und viele Fehler beheben, bevor Sie eine einzelne Codezeile schreiben.

Sie benötigen so viele wie erforderlich, um das System zu verstehen und zu kommunizieren. Für Blogging-Software würde ich nicht denken, dass Sie viele brauchen. Modellieren Sie so viel, wie Sie benötigen, um das System zu verstehen. Beenden Sie die Modellierung, wenn Sie Ihr Verständnis nicht mehr erweitern können.

Wenn Sie mit UML noch nicht vertraut sind, möchten Sie möglicherweise einige Diagramme im Detail erstellen, um das Verständnis der Diagramme zu verbessern. Sobald Sie einen Diagrammtyp gut genug verstanden haben, können Sie dies in Ihrem Kopf tun, und der Bedarf an tatsächlichen Diagrammen wird geringer.

Wenn Sie Ihre Diagrammversionen datieren, können Sie beurteilen, ob sie wahrscheinlich aktuell sind. Der Vergleich des aktuellen Entwurfs mit älteren Diagrammen kann hilfreich sein, um festzustellen, welche Bereiche des Projekts erheblich vom ursprünglichen Entwurf abweichen.

Wenn Sie keine Tools verwenden, die den Code aus Diagrammen generieren oder die Diagrammspezifikation in Code einbetten, ist es wahrscheinlich, dass sie nicht mit dem Code synchron sind. Detaillierte Diagramme werden mit der Zeit tendenziell wesentlich falscher. als Übersichtsdiagramm. Übersichtsdiagramme erfordern außerdem weniger Wartung, um sie auf dem neuesten Stand zu halten.

Es kann nützlich sein, Diagramme zu erstellen, die:

• Beschreiben Sie die Akteure und wie sie das System nutzen.
• Skizzieren Sie die Struktur von Paketen innerhalb des Systems. Beachten Sie, welche Pakete wiederverwendbare Komponenten enthalten.
• Modellieren Sie die Datenbankstruktur.
• Sequenzdiagramme sind nützlich, um Standardkomponenten zu entwerfen. Wenn Sie viele ähnliche Komponenten haben, modellieren Sie eine und verwenden Sie sie als Muster für die anderen. Erwägen Sie in solchen Fällen die Wiederverwendung von Code.

Generieren Sie Diagramme, die bei der Planung des Projekts hilfreich sind. Wenn ein Diagramm nicht erforderlich ist, um etwas über das Projekt zu verstehen und / oder zu kommunizieren, verschwenden Sie keine Zeit damit. Sie können auch ein Nicht-UML-Diagramm verwenden, wenn dies das Verständnis erleichtert. UML ist möglicherweise nicht der beste Weg, um die Datenbank zu modellieren.

Ich würde sagen, dass Sie UML-Diagramme an die Modellierungsebene aller Beteiligten und die Zeit anpassen müssen, die Sie für die Fertigstellung des Projekts benötigen.

Wenn das Team UML nicht kennt und keine Zeit hat, ist nur ein Klassendiagramm möglich, das aus umgekehrtem Code stammt. Jedes Mitglied kann seine Kommentare in das Klassendiagramm einfügen, was bereits eine gute Lösung für die Dokumentation darstellt. In diesem Fall ist das Modell nur eine grafische Ansicht des Codes. Dies würde bei sorgfältiger Durchführung fast 90% des Modellierungsbedarfs abdecken und dem Projekt keine zusätzliche Zeit hinzufügen.

Wenn Sie über fortgeschrittene Kenntnisse der Stakeholder verfügen, können alle Diagramme einen echten Mehrwert für das Projekt bringen, um den gesamten Bedarf an Modellierungsprojekten abzudecken. Dies könnte die Projektabwicklung erheblich verlängern, die Lieferqualität wird jedoch voraussichtlich besser sein.

UML ist cool, brillant und kann bei moderater Verwendung an jedes Projekt angepasst werden. Nicht gleichzeitig trinken und fahren :-)

Abgesehen von einigen großen Diagrammen, mit denen die Gesamtarchitektur Ihrer Anwendung in Bezug auf Server, Ebenen oder große Module kommuniziert wird, können Sie meines Erachtens nicht vorhersagen, welche Diagramme Sie im Voraus benötigen.

Warten Sie bis zum letzten verantwortlichen Moment. Sie werden sehen, wann Sie sie brauchen . Normalerweise ist es entweder

• während eines Gesprächs mit dem Kunden / Domain-Experten / Analysten, um einen Anwendungsfall zu klären
• oder kurz bevor Sie mit dem Code beginnen, um eine erste Version Ihres Designs zu erstellen.

Wie auch immer, Ihre Modelle werden wahrscheinlich veraltet sein, sobald Sie ein paar Codezeilen geschrieben oder ein erstes Kundenfeedback erhalten haben. Planen Sie also nicht alles im Voraus oder polieren Sie Ihre Diagramme so oft.