Was sind die Vorteile der Modellierung von Softwaresystemen im Vergleich zu Code?

Die meisten, wenn nicht alle mir bekannten IT-Mitarbeiter glauben, dass es von Vorteil ist, Software vor dem Codieren mit UML oder anderen Diagrammtypen zu modellieren. (Meine Frage bezieht sich nicht speziell auf UML, sondern kann eine grafische oder textuelle Beschreibung des Softwaredesigns sein.)

Da bin ich mir nicht so sicher. Der Hauptgrund ist: Code lügt nicht. Sie wird vom Compiler oder Interpreter geprüft. Es hat hoffentlich automatisierte Tests und muss die statische Code-Analyse bestehen. Wenn ein Modul nicht korrekt mit einem anderen Modul verbunden ist, ist dies normalerweise im Code offensichtlich, da eine Fehlermeldung angezeigt wird.

All dies kann nicht mit Diagrammen und anderen Dokumenten durchgeführt werden. Ja, es gibt Tools, die UML überprüfen, aber alles, was ich bisher gesehen habe, ist sehr begrenzt. Daher sind diese Dokumente in der Regel unvollständig, inkonsistent oder einfach falsch.

Selbst wenn die Diagramme selbst konsistent sind, können Sie nicht sicher sein, dass der Code sie tatsächlich implementiert. Ja, es gibt Codegeneratoren, die jedoch niemals den gesamten Code generieren.

Ich habe manchmal das Gefühl, dass die Besessenheit mit der Modellierung auf der Annahme beruht, dass Code unweigerlich ein unverständliches Durcheinander sein muss, mit dem sich Architekten, Designer oder andere gut bezahlte Leute, die sich einen Überblick verschaffen, nicht befassen sollten. Sonst würde es viel zu teuer werden. Daher sollten alle Entwurfsentscheidungen vom Code wegbewegt werden. Code selbst sollte Spezialisten (Code-Affen) überlassen werden, die in der Lage sind, ihn zu schreiben (und möglicherweise zu lesen), sich aber mit nichts anderem befassen müssen. Dies hat wahrscheinlich Sinn gemacht, als Assembler die einzige Option war, aber moderne Sprachen ermöglichen es Ihnen, auf einer sehr hohen Abstraktionsebene zu programmieren. Aus diesem Grund sehe ich keine Notwendigkeit mehr zum Modellieren.

Welche Argumente für die Modellierung von Softwaresystemen fehlen mir?

Übrigens glaube ich, dass Diagramme eine großartige Möglichkeit sind, bestimmte Aspekte des Software-Designs zu dokumentieren und zu kommunizieren, aber das bedeutet nicht, dass wir das Software-Design darauf aufbauen sollten .

Klärung:

Die Frage wurde als unklar zurückgestellt. Lassen Sie mich deshalb eine Erklärung hinzufügen:

Ich frage, ob es sinnvoll ist, Dokumente (ohne Code) zu verwenden, die die Software als primäre Quelle der Wahrheit über Software-Design modellieren. Ich denke nicht daran, dass ein erheblicher Teil des Codes automatisch aus diesen Dokumenten generiert wird. In diesem Fall würde ich die Dokumente selbst als Quellcode und nicht als Modell betrachten.

Ich habe einige Nachteile dieser Prozedur aufgelistet, die mich wundern lassen, warum so viele Leute (meiner Erfahrung nach) dies als die bevorzugte Methode für das Softwaredesign betrachten.

Der Vorteil der Modellierung von Softwaresystemen im Vergleich zum gesamten Code ist: Ich kann das Modell auf ein Whiteboard passen.

Ich glaube fest an die Magie, auf einem Blatt Papier zu kommunizieren. Wenn ich versucht habe, Code auf das Whiteboard zu schreiben, als ich unserem System neue Codierer beibrachte, gibt es einfach keinen Code auf der erforderlichen Abstraktionsebene, der auf ein Whiteboard passt.

Ich kenne die Besessenheit mit dem Modellieren, auf die Sie sich beziehen. Menschen, die Dinge tun, weil sie es schon einmal getan haben, ohne darüber nachzudenken, warum sie es tun. Ich bin gekommen, um es Formalismus zu nennen. Ich arbeite lieber informell, weil es schwieriger ist, die Albernheit hinter der Tradition zu verbergen.

Das heißt nicht, dass ich ab und zu keine UML-Skizze herauspeitsche. Aber ich werde niemals der Typ sein, der verlangt, dass Sie ein UML-Dokument einreichen, bevor Sie programmieren können. Ich könnte verlangen, dass Sie sich 5 Minuten Zeit nehmen und einen Weg finden, um zu erklären, was Sie tun, weil ich die Existenz von Code, den nur eine Person versteht, nicht ausstehen kann.

Fowler identifizierte verschiedene Arten, wie Menschen UML verwenden, die er UML-Modi nannte . Das Gefährliche an allen ist, dass sie dazu benutzt werden können, sich vor nützlicher Arbeit zu verstecken. Wenn Sie es tun, um mit der Maus zu codieren, habe ich schon viele Versuche gesehen. Ich habe noch niemanden gesehen, der dafür gesorgt hat, dass das wirklich funktioniert. Wenn Sie dies tun, um zu kommunizieren, sollten Sie sicherstellen, dass andere Sie verstehen. Wenn Sie es tun, um zu entwerfen, ist es verdammt gut, Probleme zu finden und zu beheben, während Sie arbeiten. Wenn alles reibungslos läuft und Sie die meiste Zeit damit verbringen, die Pfeile schön aussehen zu lassen, können Sie sie abbrechen und wieder arbeiten.

Erstellen Sie vor allem keine Diagramme, von denen Sie erwarten, dass sie länger als einen Tag gültig sind. Wenn Sie es irgendwie können, sind Sie gescheitert. Weil Software weich sein soll. Verbringen Sie keine Wochen damit, die Diagramme genau richtig zu machen. Sag mir einfach, was los ist. Wenn Sie müssen, verwenden Sie eine Serviette.

Trotzdem bevorzuge ich Programmierer, die ihre UML und ihre Entwurfsmuster kennen. Sie sind einfacher zu kommunizieren. Solange sie wissen, dass das Erstellen von Diagrammen keine Vollzeitbeschäftigung ist.

Ich frage, ob es sinnvoll ist, Dokumente (ohne Code) zu verwenden, die die Software als Hauptwahrheitsquelle für das Softwaredesign modellieren

Nein, das ergibt nie Sinn. Ihr Code ist Ihr primäres Designdokument, dh "die primäre Quelle der Wahrheit über das Softwaredesign". Nur der Code beschreibt genau, was die Anwendung tut, wenn der Compiler dieses Design übernimmt und die Anwendung daraus erstellt.

Verwenden Sie Diagramme auf jeden Fall als ergänzende Designdokumente. Wenn sie jedoch nicht automatisch aus dem Code generiert werden, müssen Sie darauf achten, dass sie dem tatsächlichen Design eine andere Geschichte erzählen. Wenn UML Ihr Boot schwimmt, verwenden Sie das. Wenn nicht, benutze etwas anderes.

Einige Leute finden es nützlich, ihr Denken in Diagrammform zu skizzieren, bevor sie anfangen, Code zu schreiben. Aber denken Sie daran, was Onkel Bob dazu gesagt hat:

" Also, 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. "

Wenn Sie ein Design mit UML untersuchen, werfen Sie es beim Codieren weg. Schreiben Sie einen Test, und schreiben Sie dann Code, damit er erfolgreich ist. Wiederholen. Auf diese Weise erhalten Sie ein validiertes Design. UML kann Ihnen niemals die gleiche Validierungsstufe für Ihr Design anbieten.

Die meisten, wenn nicht alle mir bekannten IT-Mitarbeiter glauben, dass es von Vorteil ist, Software vor dem Codieren mit UML oder anderen Diagrammtypen zu modellieren.

Ich bin nicht anderer Meinung, dass alle Leute, die Sie kennen, das glauben, aber ich denke nicht, dass es auf der ganzen Linie üblich ist. Im Jahr 1970 wusste Winston Royce, dass die Softwareentwicklung einen gewissen Grad an Iteration zwischen Design- und Code-Aktivitäten aufwies. 1992 schrieb Jack Reeves, dass Codierung die eigentliche Design-Aktivität sei (auch im C2-Wiki beschrieben ).

Dies bedeutet nicht, dass versucht wurde, modellgetriebene Entwicklungswerkzeuge zu entwickeln. Es gibt Tools, die versuchen, Code aus UML-Modellen zu generieren (und nicht nur Klassendiagramme, sondern auch verschiedene Diagrammtypen miteinander zu verknüpfen und Code daraus zu generieren). Aber das sind, zumindest was ich gesehen habe, keine weit verbreiteten Werkzeuge.

Dies bedeutet auch nicht, dass Sie direkt von den Anforderungen zum Schreiben von Code übergehen sollten. Es gibt bestimmte Entwurfsentscheidungen, die wichtig sind, um frühzeitig richtig zu sein, und ein gewisses Maß an Modellierung kann nützlich sein, um sicherzustellen, dass jeder die Optionen, ihre Auswirkungen versteht und kommunizieren kann. Einige Leute (einschließlich ich) nennen dies die "Softwarearchitektur" .

Code lügt nicht. Sie wird vom Compiler oder Interpreter geprüft. Es hat hoffentlich automatisierte Tests und muss die statische Code-Analyse bestehen. Wenn ein Modul nicht korrekt mit einem anderen Modul verbunden ist, ist dies normalerweise im Code offensichtlich, da eine Fehlermeldung angezeigt wird.

Dies ist wirklich das Herzstück einiger Aspekte der agilen Modellierung, insbesondere der ausführbaren Spezifikationen und der einzelnen Informationsquelle . Ich bin nicht unbedingt mit TDD einverstanden, aber die Idee, Ihren Code und die zugehörigen Tests (vom Gerät bis zu den Akzeptanztests, die vorzugsweise als automatisierte Tests erfasst werden) als einzige Quelle der Wahrheit zu betrachten, ist eine gute Idee.

Selbst wenn die Diagramme selbst konsistent sind, können Sie nicht sicher sein, dass der Code sie tatsächlich implementiert. Ja, es gibt Codegeneratoren, die jedoch niemals den gesamten Code generieren.

Ich denke, in der Regel ist es falsch, vom Modell-> Code auszugehen. Stattdessen sollte der Code Modelle generieren. Das heißt, Tools sollten in der Lage sein, Code zu untersuchen und grafische und tabellarische Darstellungen zu generieren, die weiter verbessert werden können, wenn Ingenieure Text um sie herum schreiben. Und diese Modellgeneration aus Code sollte nahtloser Bestandteil eines Build- und Release-Prozesses sein.

Es gibt Tools, die dies in unterschiedlichem Maße für verschiedene Sprachen unterstützen. Angesichts der Natur von Sprachen und Paradigmen ist es für einige einfacher als für andere.

Ich habe einige Nachteile dieser Prozedur aufgelistet, die mich wundern lassen, warum so viele Leute (meiner Erfahrung nach) dies als die bevorzugte Methode für das Softwaredesign betrachten.

Ich glaube nicht, dass diese Leute unbedingt Software-Engineering und Software-Design verstehen. Ich denke, diese Leute schauen sich an, was andere Ingenieursdisziplinen tun, und ordnen es den Dingen zu, von denen sie denken, dass sie Software-Ingenieure tun sollten. Aber sie ignorieren einen großen Unterschied. Andere technische Disziplinen erstellen zunächst Modelle und Simulationen, da die Erstellung des eigentlichen Produkts extrem teuer und zeitaufwendig ist. In der Softwareentwicklung können wir Teile unseres Designs nehmen und in sehr kurzer Zeit und mit sehr geringen Kosten etwas produzieren, das in einer realen Umgebung getestet werden kann. Die Wirtschaft ist sehr unterschiedlich.

Was sind die Vorteile der Modellierung von Softwaresystemen im Vergleich zu Code?

Wenn Sie ein extrem komplexes Softwaresystem haben, bedeutet Modelle etwas zu haben, das leichter zu verstehen ist. Es ist eine andere Abstraktionsebene, die den Menschen hilft, die verschiedenen Facetten Ihres Systems zu verstehen. Dies ist einer der Gründe, warum es in jeder Modellierungssprache oder -notation so viele verschiedene Modellierungssprachen und -typen gibt, dass unterschiedliche Interessengruppen das Softwaresystem konzeptionell schnell und einfach verstehen können.

Ich frage, ob es sinnvoll ist, Dokumente (ohne Code) zu verwenden, die die Software als primäre Quelle der Wahrheit über Software-Design modellieren. Ich denke nicht daran, dass ein erheblicher Teil des Codes automatisch aus diesen Dokumenten generiert wird. In diesem Fall würde ich die Dokumente selbst als Quellcode und nicht als Modell betrachten.

Viele Nicht-Code-Dokumente sind als Blaupausen nützlich . Das heißt, die "Wahrheit" des Entwurfs sollte dieser Richtung folgen. Auf diese Weise können Sie Elemente modellieren, die ein Design erfüllen muss. Man könnte sie Anforderungsdokumente nennen, aber das ist in all den Beispielen, die ich geben könnte, vielleicht zu stark. Ich habe PlantUML über PlantText.com verwendet , um diese zu produzieren.

• Anwendungsfalldiagramme können die beabsichtigten Funktionen und Interaktionen mit Benutzern oder externen Systemen darstellen.

• Aktivitätsdiagramme können Geschäftsprozesse darstellen, die von einer Software unterstützt werden müssen.

• Zustandsdiagramme können die beabsichtigte Dynamik auf einer Website anzeigen:

• Gang of Four-Entwurfsmuster werden als statische und dynamische Modelle dargestellt. Zum Beispiel Memento:
  
  

Ich habe einige Nachteile dieser Prozedur aufgelistet, die mich wundern lassen, warum so viele Leute (meiner Erfahrung nach) dies als die bevorzugte Methode für das Softwaredesign betrachten.

Wenn Sie an echten Informationen über die Verwendung von UML außerhalb Ihrer Erfahrung interessiert sind, wurden einige Studien durchgeführt (ich habe versucht, Links zu Artikeln zu finden, die nicht von Paywall stammen):

• Petre, Marian (2013). UML in der Praxis . In: 35. Internationale Konferenz für Softwaretechnik (ICSE 2013), 18.-26. Mai 2013, San Francisco, CA, USA, S. 722–731.
• N. Mangano, TD LaToza, M. Petre und A. van der Hoek (2015). Wie Software-Designer mit Skizzen am Whiteboard interagieren . In: IEEE Transactions on Software Engineering, vol. 41, nein. 2, S. 135-156.
• Andrew Forward und Timothy C. Lethbridge. 2008. Probleme und Möglichkeiten für modellorientierte versus codeorientierte Softwareentwicklung: eine Umfrage unter Softwareprofis . In Proceedings des internationalen Workshops 2008 über Modelle in der Softwareentwicklung (MiSE '08). ACM, New York, NY, USA, 27-32.

Wir Entwickler lieben es, Bilder zu verwenden, um unsere Welt zu erklären.

• Das Auto ist das Ergebnis der Produktionskette, genau wie der Code (natürlich den Bereitstellungsprozess hinzufügen).
• Das Designdokument des Fahrzeugs ist dasselbe wie das Designdokument der Software.

In unseren Welten ist es häufig so, dass diejenigen, die das Designdokument konzipieren und erstellen, mit denen identisch sind, die den Code erstellen. Dies gilt nicht für die anderen Bereiche. Dies bedeutet jedoch nicht, dass Sie wirklich das gleiche Qualitätsniveau erzielen können, wenn Sie sie alle zusammen ausführen.

Indem Sie diese Dokumente zuerst ohne Codierung erstellen (ohne einen Proof-of-Concept für Fasability, ...):

• Sie werden es sich sicher überlegen, bevor Sie es tun. Sobald Sie wissen, was Sie tun müssen, ist das Codieren EINFACH.
• Sie können erfahrene Personen auf den schwierigsten Teil Ihrer Software konzentrieren: Design, Algorithmus / Mathematik sind alle außer für ganz bestimmte Zwecke (eingebettet, Echtzeit, Assemblierung).
• Sie können einen Großteil des Codierungsprozesses an weniger erfahrene Personen delegieren, während sich die erfahreneren Personen nur auf den kritischsten Teil konzentrieren, der das Niveau ihrer Fähigkeiten erfordert. Die weniger erfahrenen Leute werden viel darüber lernen.
• Sie können mit Nicht-IT-Mitarbeitern über das Image Ihres Designdokuments diskutieren. Wenn Sie nur Code hätten, müssten Sie ein Image dessen extrahieren, was Sie getan haben, mit dem Risiko, etwas zu vergessen (ein vergessener Zuhörer irgendwo ...). Weitere Informationen zur Kommunikation finden Sie in der Antwort von CandiedOrange.
• Wenn Sie Ihre Software weiterentwickeln müssen, können Sie besser vorhersagen, welche Auswirkungen dies haben wird.
• Mit Design können Sie problemlos Teile Ihrer Software abschneiden und gleichzeitig Teile Ihrer Software entwickeln.
• Schreiben Sie diese verdammt reberbativen Unit-Tests ist viel einfacher, wenn Sie keine Kopfschmerzen haben müssen, wenn Sie alle Fälle während der Codierung abdecken wollen, in einem TDD-Ansatz, der den Test codiert, bevor der Code einfach ist.
• ...

Hinweis: Diese Behauptungen gehen davon aus, dass der Code tatsächlich das Design widerspiegelt und beide auf dem neuesten Stand sind ...