Warum können wir das Design von Software nicht effektiver erfassen? [geschlossen]

Als Ingenieure "entwerfen" wir alle Artefakte (Gebäude, Programme, Schaltkreise, Moleküle ...). Das ist eine Aktivität (design-the-verb), die zu einem Ergebnis führt (design-the-noun).

Ich denke, wir sind uns alle einig, dass design-the-noun eine andere Einheit als das Artefakt selbst ist.

Eine Schlüsselaktivität im Softwaregeschäft (in der Tat in jedem Geschäft, in dem das resultierende Produktartefakt verbessert werden muss) ist das Verstehen des "Designs (das-Nomen)". Dennoch scheinen wir als Community bei der Aufzeichnung so gut wie völlig versagt zu haben, was sich daran zeigt, wie viel Aufwand die Leute betreiben, um Fakten über ihre Codebasis wiederzuentdecken. Bitten Sie jemanden, Ihnen das Design seines Codes zu zeigen und zu sehen, was Sie erhalten.

Ich stelle mir ein Design für Software vor mit:

• Eine explizite Spezifikation, was die Software tun soll und wie gut sie es tut
• Eine explizite Version des Codes (dieser Teil ist einfach, jeder hat ihn)
• Eine Erklärung, wie jeder Teil des Codes dazu dient, die Spezifikation zu erreichen (z. B. eine Beziehung zwischen Spezifikationsfragmenten und Codefragmenten).
• Eine Begründung , warum der Code so ist, wie er ist (z. B. warum eine bestimmte Wahl statt einer anderen)

Was NICHT ein Design ist, ist eine bestimmte Perspektive auf den Code. Zum Beispiel sind UML-Diagramme keine Entwürfe. Es handelt sich vielmehr um Eigenschaften, die Sie aus dem Code ableiten können, oder möglicherweise um Eigenschaften, die Sie aus dem Code ableiten möchten. In der Regel können Sie den Code jedoch nicht aus UML ableiten.

Warum gibt es nach mehr als 50 Jahren Erfahrung mit der Erstellung von Software keine regelmäßigen Möglichkeiten, dies auszudrücken? (Zögern Sie nicht, mir mit expliziten Beispielen zu widersprechen!)

Selbst wenn wir das tun, scheint der Großteil der Community so darauf ausgerichtet zu sein, "Code" zu erhalten, dass Design-the-Nomen sowieso verloren geht. (IMHO, bis Design zum Zweck der Konstruktion wird und das Artefakt aus dem Design extrahiert wird, werden wir das nicht umgehen.)

Was haben Sie als Mittel zur Aufnahme von Designs gesehen (in dem Sinne, wie ich es beschrieben habe)? Explizite Verweise auf Papiere wären gut. Warum waren Ihrer Meinung nach bestimmte und allgemeine Mittel nicht erfolgreich? Wie können wir das ändern?

[Ich habe meine eigenen Ideen , die den oben genannten Standpunkt mit Aufzählungszeichen verdeutlichen, aber ich bin an den Antworten anderer interessiert ... und es ist schwierig, mein Schema umzusetzen. [[Und vielleicht ist das das eigentliche Problem: -]]

EDIT 2011/1/3: Einer der Antwort-Threads weist darauf hin, dass "Dokumentation" (vermutlich in Textform, insbesondere nicht formal) angemessen sein könnte. Ich sollte wohl klarstellen, dass ich das nicht glaube. CASE-Tools tauchten ab den 80er Jahren auf, aber die frühen Tools haben meist nur Pixel für die Diagramme von allem erfasst, was Sie gezeichnet haben. Die Tools waren zwar wohl kommerziell erfolgreich, aber nicht sehr hilfreich. Eine wichtige Erkenntnis war, dass wenn die zusätzlichen "Design" -Artefakte nicht formal interpretierbar sind, Sie keine ernsthafte Werkzeughilfe erhalten können. Ich glaube, die gleiche Erkenntnis gilt für jede langfristig nützliche Form der Design-Erfassung: Wenn sie keine formale Struktur aufweist, ist sie nicht wirklich nützlich. Textdokumente bestehen diesen Test so gut wie nicht.

Ich denke, es gibt mehrere Gründe, warum wir das immer noch nicht können.

1. Menschen waren lange Zeit, obwohl Software wie Häuser war, und verwendeten Prozesse und Ideen aus dem Bau. "Software Architect" war ein Titel, den alle Programmierer wollten. In den letzten zehn Jahren ist der Software-Architekt fast ausgestorben. Die Idee von Wasserfallprozessen, bei denen zuerst ein Architekt sagt, wie die Software funktionieren und aussehen soll, und dann die Leute dazu bringt, Diagramme darüber zu erstellen, wie sie erstellt werden sollen, und zuletzt Code Monkey diese netten Workflows / UML-Diagramme nach Vorgabe implementieren lässt, ist diese Idee jetzt weithin verspottet. Tatsächlich hat die gesamte Branche 40 Jahre lang den falschen Weg eingeschlagen.

2. Die Werkzeuge, die wir verwenden, ändern und verbessern sich ständig. Das Programmieren ist ein logisches Rätsel, und wir entwickeln bessere Ideen und Techniken, um dieses Rätsel zu abstrahieren und verständlich zu machen. Die Art und Weise, wie wir dies modellieren, muss sich mit der gleichen Geschwindigkeit entwickeln, bleibt jedoch zurück. Die verbesserten Techniken, um das Rätsel der Programmierung zu lösen, bedeuten auch, dass wir die Komplexität erhöhen können. Und so machen wir es. Programmierung liegt immer an den Rändern der Komplexität, mit der wir als Programmierer umgehen können.

3. Wege zur Beschreibung des Programms zu finden, ist eine Art Abstraktion. Wenn wir einen guten Weg finden, die Software zu abstrahieren, können wir diese Abstraktion auch direkt in die Entwicklungswerkzeuge einfügen und daher der Programmierung eine weitere Abstraktion / Vereinfachung hinzufügen. Das ist schon oft passiert. Beispiele für solche Abstraktionen sind Funktionen, Klassen und Bibliotheken.

4. Deshalb; Wenn Sie eine haben erfolgreiches und genaues Modell der Software, wird dieses Modell sein äquivalent zu der Software. Das macht die ganze Anstrengung irgendwie sinnlos, was wiederum Punkt 1 oben bestätigt: Die Modellierung der Software ist weitaus weniger nützlich als bisher angenommen. Es ist stattdessen besser, Daten über die Software aus dem Code zu extrahieren. Das Erstellen eines UML-Modells anhand des tatsächlichen Erscheinungsbilds des Codes ist weitaus aufschlussreicher als das Erstellen eines UML-Modells und der Versuch, dieses theoretische Modell zu implementieren.

Möglicherweise möchten Sie die Dokumentation zur Software-Rückverfolgbarkeit lesen. In keiner bestimmten Reihenfolge:

• CUBRANIC, D., MURPHY, GC, SINGER, J. UND BOOTH KELLOGG, S. Hipikat: Ein Projektgedächtnis für die Softwareentwicklung. Transactions on Software Engineering 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I. UND HAN, J. Ein Überblick über die Verwendung und Dokumentation von Architekturentwurfsgründen. In Proc der 5. Working IEEE / IFIP Konferenz über Softwarearchitektur (2005).
• RAMESH, B., POWERS, T., STUBBS, C. UND EDWARDS, M. Rückverfolgbarkeit der Anforderungen implementieren: Eine Fallstudie. In Proc des Internationalen Symposiums für Requirements Engineering (York, 1995).
• HORNER, J. UND ATWOOD, ICH Design-Begründung: die Begründung und die Barrieren. In Proc der 4. Nordischen Konferenz über Mensch-Computer-Interaktion: Rollenwechsel (Oslo, Norwegen, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B. UND CLARK, S. Best Practices für die automatisierte Rückverfolgbarkeit. Computer 40, 6 (Juni 2007), 27–35.
• ASUNCION, H., FRANÇOIS, F. UND TAYLOR, RN Ein umfassendes Tool für die Rückverfolgbarkeit von Industriesoftware. In Proc der 6. gemeinsamen Sitzung des European Software Eng Conf und des ACM SIGSOFT Int'l Symp über die Grundlagen des Software Engineerings (ESEC / FSE) (Dubrovnik, 2007).

Beachten Sie, dass dies nur die Spitze des Eisbergs ist, und ich bin sicher, dass ich einige Schlüsselpapiere ausgelassen habe.

In einer separaten Anmerkung war meine eigene Arbeit an Arcum ein Mittel für Programmierer, um der IDE die Verwendung von übergreifenden Design-Idiomen auszudrücken. Einmal ausgedrückt, könnten Programmierer ihren Quellcode transformieren, um alternative Implementierungen zu verwenden:

• Macneil Shonle, William G. Griswold und Sorin Lerner. Beyond Refactoring: Ein Framework für die modulare Pflege von übergreifenden Design-Idiomen . In Proceedings of the 6th Joint Meeting der European Software Engineering Conference und des ACM SIGSOFT Symposiums über die Grundlagen des Software Engineerings (ESEC-FSE '07; 3.-7. September 2007). 175-184.

Arcum hat übrigens auch etwas mit Ihrer DMS-Arbeit zu tun.

UML ist nach meiner bescheidenen Ansicht ein Programm, was die Pläne für ein Gebäude sind. Pläne alleine sind natürlich kein Entwurf, Sie benötigen dafür Materialspezifikationen (benutzte Code-Tools), eine allgemeine Ansicht des Gebäudes (eine schematische Darstellung der gesamten Software, einschließlich der GUI-Entwürfe), wie das Gebäude in der Umgebung bepflanzt ist (ein klares Schema, wie die Software mit anderen interagiert / innerhalb des Betriebssystems gepflanzt wird), wie sie dem Klima und dem Boden entspricht (Interaktion mit Hardware), ... Viele Bücher über Design versuchen, es zu definieren, aber so In vielen Bereichen der Wissenschaft hat jeder Wissenschaftler eine eigene Definition.

Jetzt stimme ich Ihrer Beobachtung auch nicht zu, dass Sie den Code nicht von UML ableiten können. Sie können, wenn Sie die genannten zusätzlichen Informationen haben. Aber der wahre Code ist nicht mehr das Design, sondern das Artefakt. Sie können die echten Steine ​​und den Beton auch nicht aus einem Plan extrahieren, aber Sie benötigen den Plan, um die echten Steine ​​und den Beton in die richtige Form und an die richtige Stelle zu bringen.

In diesem Licht fand ich den folgenden Artikel interessant (ich habe ihn in einem anderen Kontext kennengelernt, als ich nach Grafiksoftware suchte, aber trotzdem ...). Der grafische Ansatz zur Beschreibung eines Entwurfs ergab für mich Sinn, obwohl dies meiner Meinung nach nur ein Teil des Entwurfs ist. Das Interessante ist, dass dieser Ansatz einen Rahmen zum Verstehen und Umgestalten von Designs (im Gegensatz zum Umgestalten der Software) bietet, wie in den folgenden Abhandlungen angegeben:

• Wermelinger und Fiadeiro

• Tsantalis et al

Es gibt eine ganze Reihe anderer Ansätze, um das Design (teilweise) zu beschreiben, wie strukturiertes Design (HIPO-Charts) oder integriertes Programmdesign , Designmuster , ...

Solange es noch keinen Industriestandard gibt, ist es unwahrscheinlich, dass es eine "normale" Art gibt, dies auszudrücken. Auch nach über 50 Jahren. Und seien Sie ehrlich, wenn Ihr Unternehmen einen guten Weg findet, um ein Design auszudrücken, würden Sie es mit der Welt teilen?

Aus meiner persönlichen Erfahrung würde ich behaupten, dass wir das Design von Software gut erfassen können. Wir verfügen über eine Datenbank mit Anforderungs- und Designdokumenten für jedes einzelne Feature, das wir jemals auf unserer Plattform implementiert haben. Ich nehme an, mein Umstand ist vielleicht einzigartig. Hier sind einige Dinge, über die man nachdenken sollte.

Jede einzelne Person in meinem Team hat einen Ingenieurabschluss ... meistens EE oder CE. Das Ingenieurwesen lehrt Sie das Entwerfen als Teil des Lehrplans.

Ich denke, dass es eine Menge sogenannter Software-Ingenieure gibt, die CS-Hintergründe haben. Software-Design ist kein wesentlicher Bestandteil der meisten CS-Programme. Ich sage nicht, dass alle CS-Majors schlecht im Design sind, aber ich wette, dass die meisten keine formale Ausbildung haben, die es ihnen beigebracht hat. Ich denke, viele Leute gehen davon aus, dass wenn man programmieren kann, man Software entwerfen kann, was nicht stimmt. Angesichts der Tatsache, dass viele Programmierer keinen technischen Hintergrund haben, ist es nicht verwunderlich, dass viele Softwareprojekte kein Team haben, das gut darin ist, Design zu erfassen.

Ich sehe zwei Probleme.

Das erste ist, dass es verdammt schwierig ist, Code und Dokumentation synchron zu halten. Wenn sie getrennt sind, weichen sie voneinander ab und die Dokumentation wird unbrauchbar. Programmierer haben versucht, Tools zu verwenden, um sie synchron zu halten (wie z. B. CASE-Tools), aber diese Tools haben sich zwischen den Programmierern und ihrem Code bewegt, was mehr Schaden als Nutzen angerichtet hat. Eine der wichtigsten Erkenntnisse des domänengetriebenen Designs (Evans, 2004) ist, dass gutes Design wirklich schwierig ist. Um also etwas daraus zu machen, müssen Sie:

• Wählen Sie den kleinstmöglichen Bereich Ihres Programms, in dem gutes Design große Vorteile bringt, die sogenannte Kerndomäne
• arbeite wirklich hart, um ein gutes Design in Form einer allgegenwärtigen Sprache zu erhalten, die alle Teammitglieder ständig verwenden
• Machen Sie das Design so weit wie möglich zu einem Teil des Codes

Das andere große Problem bei der Art und Weise, wie wir entwerfen, ist, dass unsere Entwurfsmethoden nicht mathematisch genug sind. Undichte Abstraktionen sind nicht geeignet, solide Schlussfolgerungen daraus zu ziehen, und die Welt der streng angewandten Logik und der klaren Wahrheit wird als Mathematik bezeichnet, wovon Programmierer größtenteils zurückschrecken.

Die wenigen mathematischen Werkzeuge, die wir haben, wie formale Methoden, sind sehr unhandlich.

Map-Reduce ist ein schönes Beispiel für Mathematik in der Programmierung. Die Kernidee ist: Wenn Sie eine assoziative, binäre Operation haben, können Sie ihre Ausführung sehr einfach verteilen. Eine binäre Operation ist eine Funktion mit zwei Parametern. Assoziativität impliziert, dass (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 ist

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) wobei die As, Bs und Cs trivial an verschiedenen Orten hinzugefügt werden können, deren Ergebnisse gesammelt werden und in kürzester Zeit zusammengefasst.

Kartenreduzierung ist eine lächerlich einfache Idee. Es kann auf einem Blatt Papier beschrieben werden. Wenn Sie davon ausgehen können, dass der Leser das Konzept der Assoziativität fest im Griff hat, passt es auf ein recht kleines Stück Papier. Versuchen Sie nun, jemandem Map-Reduce zu erklären, ohne den Begriff Assoziativität zu verwenden oder sich indirekt darauf zu beziehen. Du traust dich ja nicht.

Software-Design ohne mathematische Abstraktionen ist wie der Versuch, Architektur zu machen, ohne sich jemals die Mühe zu machen, Geometrie zu lernen.

Vielleicht kann Haskell dies im Laufe der Zeit beheben. Die Verwendung von Konzepten aus der Kategorietheorie zur Beschreibung von Programmen erscheint mir vielversprechend. Die Kategorietheorie ist so abstrakt, dass selbst Mathematiker wenig damit anfangen konnten, aber anscheinend scheinen Kategorien, die bis zur Unkenntlichkeit abstrakt sind, abstrakt genug zu sein, um die Struktur von Software zu beschreiben. Wir werden es rausfinden. Langsam.