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

20

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.

Frank Puffer
quelle
5
Ich denke, es ist eine völlig berechtigte Frage. Wenn unser Modell einen Wert hat, muss er mit dem Code übereinstimmen. Warum also nicht das Modell in derselben Sprache entwerfen, mit der wir es später implementieren? Dann sind sie immer synchron. Und wenn Sie ausgefallene Grafiken bevorzugen, können diese aus Code generiert werden.
Ralf Kleberhoff
3
Dann sollten Sie mehr "IT" -Leute kennenlernen. Oder vielleicht sollte ich sagen, dass Sie sich mit mehr Gemeinschaften in diesem Dach vertraut machen sollten.
Derek Elkins
@DocBrown: Während die Antworten auf diese Frage und insbesondere die in Ihrem Kommentar verlinkten Artikel relevante Informationen liefern, ist die ursprüngliche Frage sehr unterschiedlich.
Frank Puffer
@FrankPuffer: Mir ist bewusst, dass ich für die Wiedereröffnung gestimmt habe. Dennoch denke ich, dass der Kern Ihrer Frage - "Was ist Software-Design" und "Die Rolle der Modellierung im Software-Design" - eine sehr weit gefasste Frage ist, die möglicherweise zu weit gefasst ist, um hier sinnvoll beantwortet zu werden.
Doc Brown

Antworten:

23

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.

kandierte_orange
quelle
2
"Es gibt einfach keinen Code auf dieser Abstraktionsebene, der auf ein Whiteboard passt." Das wirft eine interessante Frage auf. Warum nicht? Was müsste zutreffen, damit der Einstiegspunkt eines Systems auf sehr hoher Ebene erklärt, was es tut?
RubberDuck
2
Denn Code muss für alle Menschen (und mindestens einen Compiler) alles sein. Ein Model kann ein fokussiertes Publikum haben.
candied_orange
Ich finde es bedauerlich, das Wort "Formalismus" zu verwenden. Entweder wird das, was die "Modellbauer" tun, übermäßig aufgeblasen, oder es wird die tatsächliche formale Modellierung herabgesetzt . (Es scheint auch nicht wirklich Ihre Absicht zu erfassen, was ich hier sagen kann. Ihre Sorge scheint nicht darin zu liegen, das Modell selbst zu modellieren, sondern es als Tor oder aus bürokratischen Gründen zu verwenden, selbst wenn es keinen Mehrwert bietet.)
Derek Elkins
3
Mein Problem ist nicht das Modellieren. Es geht darum, formelle Zeremonien als Ersatz für kritisches Denken zu verwenden. Ich versuche zu sagen, dass ein Großteil des Modell-Bashings passiert, weil ein Großteil des Modellierens in diese Menge gefallen ist. Modellierung kann sehr gut sein. Aber es hat eine dunkle Seite.
candied_orange
1
"Ich kann das Modell auf ein Whiteboard montieren" ist eine sehr konkrete (exzellente!) Art zu sagen: "Ich kann eine Abstraktion von etwas machen, das komplizierter ist, um zu helfen, Aspekte zu verstehen oder zu kommunizieren, die ich für wichtig halte." Das ist es, was eine gute Modellierung im Allgemeinen bewirkt, ob es sich um Software oder etwas anderes Komplexes handelt.
Fuhrmanator
6

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.

David Arno
quelle
Ein Gegenbeispiel (?) :: Modellansichtstrennung (oder ein beliebiges GoF-Muster) kann leicht als beabsichtigte Wahrheit des von einem Architekten vorgeschlagenen Entwurfs (Blaupause) gezeichnet werden . Entwickler, die von dieser Absicht abweichen, machen das (beabsichtigte) Modell nicht unbrauchbar. Ja, der Code ist die "Wahrheit", aber nicht unbedingt das Design. Die Validierung muss bei UML oder einem Modell nicht automatisch erfolgen. Die Tatsache, dass dies nicht der Fall ist, macht ein Modell nicht für den Müll geeignet.
Fuhrmanator
Bei Tests bin ich mir nicht sicher, ob es sinnvoll ist, ein Design zu validieren. Können Sie Tests schreiben, die zeigen, dass sich die Domänenlogik nicht in der Präsentationsebene befindet (ein sehr häufiges Problem bei Implementierungen, die von einem beabsichtigten Entwurf abweichen)? Es actionPerformed()ist ein Schlüsselaspekt der Trennung , einem Entwickler ein Diagramm der Ebenen zu zeigen und zu erklären, dass sich eine Methode in der Präsentationsebene befindet und dass sie einfach die Kontrolle an die Domänenebene übergeben soll. (Ein einfaches Beispiel, aber es kann auf alle Arten von Entwurfsstrategien angewendet werden, die nicht einfach nur im Code darzustellen sind.)
Fuhrmanator
5

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.

Thomas Owens
quelle
5

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. Bildbeschreibung hier eingeben

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

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

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

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):

Fuhrmanator
quelle
0

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

Walfrat
quelle
Diese Antwort beschreibt ein nahezu bestmögliches Szenario. Sie erwähnen eine Einschränkung am Ende, die für sich genommen ziemlich groß ist. Es gibt viele andere. Sie können notwendige Aspekte leicht weglassen, unterschätzen die Komplexität eines Teils, nicht Faktor in den Zwängen der Bibliotheken / Frameworks Sie verhängen verwenden, nicht Faktor in Bugs in Abhängigkeiten, nicht Faktor in der Leistung oder anderen nicht-funktionalen Anforderungen, über Ingenieur, Änderungen nicht antizipieren oder einfach nicht so gut im Design sein. Es ist unwahrscheinlich, dass dieses Best-Case-Szenario auch im professionellen Kontext grob umgesetzt wird.
Derek Elkins
Wenn Sie anfangen, indem Sie nur jede Einschränkung von allem berücksichtigen, werden Sie nirgendwo hingehen. Welche Methode Sie auch verwenden. Und eine lange Liste von dem, was Sie gesagt haben, ist vollkommen gültig, wenn Sie nur Code machen.
Walfrat