Warum ist es unangemessen, UML-Diagramme zu verwenden, um zu planen, wie Ihr Code organisiert wird?

Ja, Diagramme können manchmal unangemessen sein. Wann sind sie unangemessen? Wenn Sie sie ohne Code erstellen, um sie zu validieren, und dann beabsichtigen, ihnen zu folgen. Es ist nichts Falsches daran, ein Diagramm zu zeichnen, um eine Idee zu untersuchen.

_{Agile Softwareentwicklung: Prinzipien, Muster und Praktiken - Robert C. Martin}

Was genau meint er damit? Ist UML nicht dazu gedacht, die Struktur Ihres Codes vor dem "Eintauchen" zu planen ? Was bringt es, wenn Sie den erstellten Diagrammen nicht folgen?

Kontext: In diesem Kapitel erstellt Onkel Bob ein UML-Diagramm für den Score Keeper eines Bowling-Spiels. Anschließend entwickelt er das Programm testgetrieben, ohne das UML-Diagramm zu konsultieren. Das resultierende Programm ist nichts anderes als das UML-Diagramm, und Onkel Bob kommt zu dem oben zitierten Schluss.

— q126y
quelle

Onkel Bob meint, dass die Architektur, die aus der testgetriebenen Entwicklung hervorgeht, sich radikal vom UML-Diagramm unterscheiden kann.

— Robert Harvey

Lesen Sie auch, ist Design tot? Von Martin Fowler für eine ausgewogene Diskussion über dieses Thema und die agile Bewegung

— Eliezer Steinbock

Abstimmung dieser Frage als Antwort auf das schlechte Urteilsvermögen von @RobertHarvey et al. Bei der Abstimmung, um eine wichtige und nützliche Frage abzuschließen.

— David Arno

@DavidArno Wenn Sie eine starke Meinung dazu haben, was geschlossen werden soll oder nicht, würde ich Sie nachdrücklich ermutigen, sich an den Diskussionen auf unserer Metaseite zu beteiligen. Jeder, der derzeit dort postet (einschließlich mir), fällt wahrscheinlich unter "@RobertHarvey et al.", Mit Ausnahme einiger SE-Mitarbeiter, und wir waren besorgt, dass ein anderer Standpunkt nicht vertreten ist, aber bisher ist noch niemand aufgetaucht, um ihn zu vertreten .

— Ixrec

@Ixrec, ich habe mich noch nie zuvor mit Metadiskussionen befasst, außer einmal, um zu überprüfen, ob ich in Antworten auf meine eigenen Open-Source-Bibliotheken verweisen kann (die Antwort darauf war, dass ich es könnte). Vielleicht sollte ich Ihren Rat annehmen und mich stärker engagieren. Danke für den Vorschlag.

— David Arno

Antworten:

Um dies richtig zu erklären, brauchen wir eine kurze Geschichtsstunde. In den frühen Tagen des Software-Engineerings war es eine häufig verwendete Analogie, ein Haus zu bauen. Ein Architekt und Bauingenieur bespricht Pläne mit einem Kunden und entwirft einen Entwurf. Die Bauherren folgen dann diesem Entwurf, um das eigentliche Haus zu bauen. Das Schreiben von Code wurde als das Äquivalent zum Bau des eigentlichen Hauses angesehen. Daher bestand ein wahrgenommener Bedarf an Vorabentwurf, bevor dieser Bau stattfinden konnte. Es wurden verschiedene grafische Entwurfswerkzeuge erstellt, darunter auch UML.

Die ursprüngliche Idee bei UML war, ein System vollständig mit UML zu entwerfen und es dann den Codierern zu übergeben, um dieses Design in Code zu übersetzen. In Wirklichkeit funktioniert dies einfach nicht und führte dazu, dass Programmierer jahrelang als "Implementierer" und nicht als "Designer" angesehen wurden, Projekte verspätet waren, die Designs sich ständig ändern mussten, nachdem sie abgeschlossen sein sollten usw.

Der Grund ist einfach. Codierung ist Design . Bei der Hausanalogie ist der Code die Zeichnung des Architekten. Der Compiler ist der Builder, der diese Entwürfe nimmt und daraus ein Programm erstellt. Diese Erkenntnis führte dann dazu, dass agile Techniken, TDD usw. geboren wurden: Tools zur Verbesserung der Qualität dieses Code-Designs.

So wie ein Architekt möglicherweise vorläufige Skizzen erstellt, um sie und ihr Team bei der Visualisierung des Gesamtdesigns zu unterstützen, kann ein Entwickler UML oder andere Tools verwenden, um das benötigte Design zu visualisieren. So wie diese Skizzen nicht blind befolgt werden, sollte die UML nicht blind befolgt werden. Das Code-Design sollte sich aus agilen Iterationen und der Verwendung von TDD entwickeln. Ebenso wie ein Architekt ein Modell des Hauses erstellen könnte, um sie und ihr Team bei der Visualisierung der Zeichnungen zu unterstützen, kann UML zur Visualisierung der Codestruktur verwendet werden.

Wie Onkel Bob sagt, können Sie die UML nicht validieren, sondern nur den Code. Daher ist der Code die primäre Konstruktionsdokumentation, und UML ist, falls verwendet, nur eine sekundäre Dokumentation.

— David Arno
quelle

Ich hatte Anfang dieses Jahres einen Teil des Daches meines Hauses angehoben und es war ziemlich lehrreich. Der Architekt hat wirklich nicht mehr gezeichnet, wie das Endprodukt aussehen sollte. Er übergab die harten Berechnungen und die Tragwerksplanung einem Bauingenieur. Die Bauherren mussten dann die theoretischen Entwürfe an die Aktualität des Hauses anpassen (sobald die Gipskartonplatte entfernt war, befanden sich die Balken an leicht unterschiedlichen Stellen), sodass die Planung bei jedem Schritt erfolgte.

— Jaydee

Dies ist eine nützliche Antwort, vereinfacht jedoch einige Aspekte zu stark. Einer der Hauptgründe, warum UML als "High-Level-Design-Notation" nicht gut funktioniert, ist meiner Meinung nach, dass ihre Erfinder zu hartnäckig waren, um ein Datenflussdiagramm hinzuzufügen. Dies ist die einzige mir bekannte Notation, die für das Top-Town-Design geeignet ist, um Abstraktionen für Komponenten und Schnittstellen zwischen ihnen in unterschiedlichem Maßstab auszudrücken, und die auch eine genau definierte Zuordnung zum Code aufweisen kann. Stattdessen enthält UML viel Unsinn, den niemand wirklich braucht.

— Doc Brown

Ich denke, dass nicht jede Programmiersprache (oder jedes Design oder jeder Code) in UML passt (was ich zugeben muss, dass ich nicht gut weiß - lese nur ein paar Bücher darüber -, ich habe es nie benutzt und ich mag es wahrscheinlich nicht).

Einfacher C-Code (z. B. der Quellcode des Linux-Kernels) wird von UML möglicherweise nicht genau modelliert.

Ocaml-Code (mit seinen Modulen und Funktoren) oder sogar C ++ 11-Code (mit Lambdas und Vorlagen) passen möglicherweise nicht in UML.

Mehrstufige Programmierung à la MetaOcaml passt wahrscheinlich nicht in UML.

Prolog-Code oder Common Lisp-Code passen wahrscheinlich nicht in UML.

Siehe auch diese Antwort und diese Frage von mir.

Lesen Sie Scotts Programmiersprache Pragmatik und Van Roys Konzepte, Techniken und Modelle der Computerprogrammierung und fragen Sie sich, ob jedes Programmiermodell dort in UML passt.

Siehe auch Martin Fowlers Ist Design tot? Blog.

— Basile Starynkevitch
quelle