Wie planen Sie die Architektur einer Anwendung, bevor Sie Code schreiben? [geschlossen]

Eine Sache, mit der ich zu kämpfen habe, ist die Planung der Architektur einer Anwendung, bevor Code geschrieben wird.

Ich meine nicht, Anforderungen zu sammeln, um einzugrenzen, was die Anwendung tun muss, sondern effektiv über einen guten Weg nachzudenken, um die Gesamtklasse, die Daten und die Flussstrukturen darzustellen und diese Gedanken zu wiederholen, damit ich einen glaubwürdigen Plan habe Denken Sie daran, bevor Sie die IDE öffnen. Im Moment ist es allzu einfach, die IDE zu öffnen, ein leeres Projekt zu erstellen, mit dem Schreiben von Kleinigkeiten zu beginnen und das Design von dort aus „herauswachsen“ zu lassen.

Ich nehme an, UML ist eine Möglichkeit, dies zu tun, aber ich habe keine Erfahrung damit, so dass es irgendwie nebulös erscheint.

Wie planen Sie die Architektur einer Anwendung, bevor Sie Code schreiben? Wenn UML der richtige Weg ist, können Sie einem Entwickler kleinerer Anwendungen eine kurze und praktische Einführung empfehlen?

Ich freue mich über Ihren Beitrag.

Ich finde es wirklich entscheidend, dass man zuerst auf Papier oder Whiteboard schreibt. Wechseln Sie dann zu UML, wenn Sie möchten, aber nichts geht über die Flexibilität, es zunächst nur von Hand zu zeichnen.

Ich betrachte Folgendes:

1. Was soll das System tun, das heißt, was ist das Problem, das das System zu lösen versucht
2. Wer ist der Kunde und was sind ihre Wünsche
3. womit sich das System integrieren muss
4. Gibt es irgendwelche Altaspekte, die berücksichtigt werden müssen?
5. Was sind die Benutzerinteraktionen?
6. etc...

Dann betrachte ich das System als Black Box und:

1. Welche Interaktionen müssen mit dieser Black Box stattfinden?
2. Was sind die Verhaltensweisen, die innerhalb der Black Box auftreten müssen, dh was muss mit diesen Interaktionen geschehen, damit die Black Box das gewünschte Verhalten auf einer höheren Ebene zeigt, z. B. eingehende Nachrichten von einem Reservierungssystem empfangen und verarbeiten, eine Datenbank aktualisieren usw. .

Dann erhalten Sie einen Überblick über das System, das aus verschiedenen internen Blackboxen besteht, von denen jede auf dieselbe Weise weiter unterteilt werden kann.

UML ist sehr gut, um ein solches Verhalten darzustellen. Sie können die meisten Systeme nur mit zwei der vielen Komponenten von UML beschreiben, nämlich:

• Klassendiagramme und
• Sequenzdiagramme.

Möglicherweise benötigen Sie auch Aktivitätsdiagramme, wenn das zu beschreibende Verhalten parallel ist.

Eine gute Quelle zum Erlernen von UML ist Martin Fowlers ausgezeichnetes Buch "UML Distilled" ( Amazon-Link) - bereinigt für das Skript Kiddie Link Nazis da draußen (- :)). Dieses Buch gibt Ihnen einen kurzen Überblick über die wesentlichen Teile der einzelnen Komponenten von UML.

Oh. Was ich beschrieben habe, ist so ziemlich Ivar Jacobsons Ansatz. Jacobson ist einer der drei Amigos von OO. Tatsächlich wurde UML ursprünglich von den beiden anderen Personen entwickelt, die die drei Amigos bilden, Grady Booch und Jim Rumbaugh

Sie sollten sich auf jeden Fall Steve McConnells Code Complete ansehen - und insbesondere sein Werbegeschenk-Kapitel "Design in Construction".

Sie können es von seiner Website herunterladen:

http://cc2e.com/File.ashx?cid=336

Wenn Sie für .NET entwickeln, hat Microsoft gerade (als kostenloses E-Book!) Das Application Architecture Guide 2.0b1 veröffentlicht . Es bietet viele wirklich gute Informationen zur Planung Ihrer Architektur, bevor Sie Code schreiben.

Wenn Sie verzweifelt wären, könnten Sie wahrscheinlich große Teile davon für nicht .NET-basierte Architekturen verwenden.

Ich werde dies vorwegnehmen, indem ich sage, dass ich hauptsächlich Webentwicklungen mache, bei denen ein Großteil der Architektur bereits im Voraus festgelegt wurde (WebForms, jetzt MVC) und die meisten meiner Projekte relativ kleine Einzelarbeiten sind, die weniger als ein Jahr dauern. Ich weiß auch, dass ich ein ORM und ein DAL haben werde, um mein Geschäftsobjekt bzw. meine Dateninteraktion zu verwalten. Vor kurzem habe ich dafür auf LINQ umgestellt, sodass ein Großteil des "Designs" über den DBML-Designer zum Datenbankdesign und zur Zuordnung wird.

Normalerweise arbeite ich auf TDD-Art (Test Driven Development). Ich verbringe nicht viel Zeit im Voraus damit, an architektonischen oder gestalterischen Details zu arbeiten. Ich sammle die gesamte Interaktion des Benutzers mit der Anwendung über Geschichten. Ich benutze die Geschichten, um das Interaktionsdesign zu erarbeiten und die Hauptkomponenten der Anwendung zu entdecken. Während dieses Prozesses mache ich viel Whiteboarding mit dem Kunden - manchmal erfassen wir Details mit einer Digitalkamera, wenn sie wichtig genug erscheinen, um in Diagrammform zu bleiben. Hauptsächlich werden meine Geschichten in Form von Geschichten in einem Wiki festgehalten. Schließlich werden die Geschichten in Veröffentlichungen und Iterationen organisiert.

Zu diesem Zeitpunkt habe ich normalerweise eine ziemlich gute Vorstellung von der Architektur. Wenn es kompliziert ist oder ungewöhnliche Dinge gibt - Dinge, die sich von meinen normalen Praktiken unterscheiden - oder ich mit jemand anderem zusammenarbeite (nicht typisch), werde ich die Dinge grafisch darstellen (wieder auf einem Whiteboard). Das Gleiche gilt für komplizierte Interaktionen. Ich kann das Seitenlayout und den Fluss auf einem Whiteboard entwerfen und es behalten (oder mit der Kamera aufnehmen), bis ich mit diesem Abschnitt fertig bin. Sobald ich eine allgemeine Vorstellung davon habe, wohin ich gehe und was zuerst getan werden muss, beginne ich, Tests für die ersten Geschichten zu schreiben. Normalerweise sieht das so aus: "Okay, dazu brauche ich diese Klassen. Ich fange mit dieser an und sie muss dies tun." Dann beginne ich fröhlich mit TDDing und die Architektur / das Design wächst aus den Anforderungen der Anwendung.

In regelmäßigen Abständen möchte ich einige Code-Teile noch einmal schreiben oder denken, "das riecht wirklich", und ich werde mein Design überarbeiten, um Doppelspurigkeiten zu entfernen oder die stinkenden Teile durch etwas Eleganteres zu ersetzen. Meistens geht es mir darum, die Funktionalität zu verbessern und dabei gute Designprinzipien zu befolgen. Ich finde, dass es ziemlich gut funktioniert, bekannte Muster zu verwenden und dabei auf gute Prinzipien zu achten.

http://dn.codegear.com/article/31863

Ich benutze UML und finde diese Anleitung ziemlich nützlich und leicht zu lesen. Lassen Sie mich wissen, wenn Sie etwas anderes brauchen.

UML ist eine Notation. Es ist eine Möglichkeit, Ihr Design aufzuzeichnen, aber (meiner Meinung nach) nicht, ein Design zu erstellen. Wenn Sie etwas aufschreiben müssen, würde ich UML jedoch empfehlen, nicht weil es das "Beste" ist, sondern weil es ein Standard ist, den andere wahrscheinlich bereits lesen können, und es besser ist, Ihren eigenen "Standard" zu erfinden.

Ich denke, die beste Einführung in UML ist immer noch UML Distilled von Martin Fowler, da es prägnant ist, praktische Anleitungen zur Verwendung gibt und klar macht, dass Sie sich nicht in die gesamte UML / RUP-Geschichte einkaufen müssen, um dies zu tun nützlich sein

Design zu machen ist schwierig. Es kann nicht wirklich in einer StackOverflow-Antwort erfasst werden. Leider haben sich meine Designfähigkeiten im Laufe der Jahre weiterentwickelt, so dass ich keine einzige Quelle habe, auf die ich Sie verweisen kann.

Ein Modell , das ich gefunden habe jedoch nützlich ist , Robustheit Analyse (Google für sie, aber es gibt ein Intro hier ). Wenn Sie Ihre Anwendungsfälle für das haben, was das System tun soll, ein Domänenmodell dessen, worum es geht, dann habe ich die Robustheitsanalyse als nützliches Werkzeug gefunden, um die beiden zu verbinden und herauszufinden, was die Schlüsselkomponenten des Systems sein müssen .

Aber der beste Rat ist, viel zu lesen, nachzudenken und zu üben. Es ist keine rein lehrbare Fähigkeit, man muss es tatsächlich tun.

Ich bin nicht klug genug, um mehr als ein bisschen vorauszuplanen. Wenn ich im Voraus plane, kommen meine Pläne immer falsch heraus, aber jetzt habe ich n Tage mit schlechten Plänen verbracht. Mein Limit scheint ungefähr 15 Minuten auf dem Whiteboard zu sein.

Grundsätzlich arbeite ich so wenig wie möglich, um herauszufinden, ob ich in die richtige Richtung gehe.

Ich betrachte mein Design auf kritische Fragen: Wenn A B bis C macht, ist es dann schnell genug für D? Wenn nicht, brauchen wir ein anderes Design. Jede dieser Fragen kann mit einem Spike beantwortet werden. Wenn die Spikes gut aussehen, haben wir das Design und es ist Zeit, es zu erweitern.

Ich codiere in die Richtung, um so schnell wie möglich einen echten Kundennutzen zu erzielen, damit ein Kunde mir sagen kann, wohin ich gehen soll.

Da ich immer etwas falsch mache, verlasse ich mich auf Refactoring, um es richtig zu machen. Refactoring ist riskant, daher muss ich unterwegs Unit-Tests schreiben. Das Schreiben von Komponententests nachträglich ist aufgrund der Kopplung schwierig, daher schreibe ich zuerst meine Tests. Es ist schwer, diszipliniert zu bleiben, und ein anderes Gehirn sieht die Dinge anders, deshalb habe ich gerne einen Kumpel dabei, der mit mir programmiert. Mein Coding-Kumpel hat eine Nase, deshalb dusche ich regelmäßig.

Nennen wir es "Extreme Programming".

"Whiteboards, Skizzen und Haftnotizen sind hervorragende Entwurfswerkzeuge. Komplizierte Modellierungswerkzeuge sind eher ablenkend als beleuchtend." Aus den Praktiken eines agilen Entwicklers von Venkat Subramaniam und Andy Hunt .

Ich bin nicht davon überzeugt, dass irgendetwas das kannvor der Implementierung im Voraus geplant werden. Ich habe 10 Jahre Erfahrung, aber das war nur bei 4 Unternehmen (einschließlich 2 Standorten bei einem Unternehmen, die fast gegensätzliche Gegensätze waren), und fast meine gesamte Erfahrung bestand darin, kolossale Cluster zu beobachten ****** ** s auftreten. Ich fange an zu denken, dass Dinge wie Refactoring wirklich der beste Weg sind, Dinge zu tun, aber gleichzeitig merke ich, dass meine Erfahrung begrenzt ist und ich möglicherweise nur auf das reagiere, was ich gesehen habe. Was ich wirklich gerne wissen würde, ist, wie ich die beste Erfahrung machen kann, damit ich zu richtigen Schlussfolgerungen komme, aber es scheint, als gäbe es keine Abkürzung und es erfordert nur viel Zeit, Leute zu sehen, die Dinge falsch machen :(. I. Ich würde wirklich gerne versuchen, in einem Unternehmen zu arbeiten, in dem die Leute die Dinge richtig machen (wie erfolgreiche Produktbereitstellungen belegen).

Ich möchte mich unterscheiden: UML kann für die Anwendungsarchitektur verwendet werden, wird jedoch häufiger für die technische Architektur verwendet (Frameworks, Klassen- oder Sequenzdiagramme, ...), da diese Diagramme hier am einfachsten mit der Entwicklung synchronisiert werden können .

Anwendungsarchitektur tritt auf, wenn Sie einige Funktionsspezifikationen (die die Art und den Ablauf von Vorgängen beschreiben, ohne Annahmen über eine zukünftige Implementierung zu treffen) und diese in technische Spezifikationen umwandeln.

Diese Spezifikationen stellen die Anwendungen dar, die Sie für die Implementierung benötigen einiger geschäftlicher und funktionaler Anforderungen benötigen.

Wenn Sie also mehrere große Finanzportfolios verarbeiten müssen (Funktionsspezifikation), müssen Sie möglicherweise festlegen, dass Sie diese große Spezifikation in folgende Bereiche unterteilen müssen:

• ein Dispatcher, der diese umfangreichen Berechnungen verschiedenen Servern zuweist
• Ein Launcher, um sicherzustellen, dass alle Berechnungsserver betriebsbereit sind, bevor Sie mit der Verarbeitung dieser Portfolios beginnen.
• eine GUI, um zeigen zu können, was los ist.
• eine "gemeinsame" Komponente zur Entwicklung der spezifischen Portfolio-Algorithmen, unabhängig vom Rest der Anwendungsarchitektur, um Unit-Tests, aber auch einige Funktions- und Regressionstests zu erleichtern.

Im Grunde genommen, um über die Anwendungsarchitektur nachzudenken , müssen Sie entscheiden, welche "Gruppe von Dateien" Sie auf kohärente Weise entwickeln müssen (Sie können nicht in derselben Gruppe von Dateien einen Launcher, eine GUI, einen Dispatcher usw. entwickeln würde sich nicht im gleichen Tempo entwickeln können)

Wenn eine Anwendungsarchitektur gut definiert ist, ist jede ihrer Komponenten normalerweise ein guter Kandidat für eine Konfigurationskomponente , dh eine Gruppe von Dateien, die als All in ein VCS (Version Control System) versioniert werden können, was bedeutet, dass alle Dateien vorhanden sind Jedes Mal, wenn Sie einen Schnappschuss dieser Anwendung aufzeichnen müssen, zusammen beschriftet (auch hier ist es schwierig, Ihr gesamtes System zu beschriften , da jede Anwendung nicht gleichzeitig in einem stabilen Zustand sein kann).

Ich mache seit einer Weile Architektur. Ich benutze BPML, um zuerst den Geschäftsprozess zu verfeinern und dann UML, um verschiedene Details zu erfassen! Der dritte Schritt ist im Allgemeinen ERD! Wenn Sie mit BPML und UML fertig sind, ist Ihre ERD ziemlich stabil! Kein Plan ist perfekt und keine Abstraktion wird 100% sein. Planen Sie ein Refactoring. Ziel ist es, das Refactoring so gering wie möglich zu halten!

Ich versuche, mein Denken in zwei Bereiche zu unterteilen: eine Darstellung der Dinge, die ich manipulieren möchte, und was ich damit vorhabe.

Wenn ich versuche, die Dinge zu modellieren, die ich manipulieren möchte, habe ich eine Reihe diskreter Artikeldefinitionen - eine E-Commerce-Website enthält eine SKU, ein Produkt, einen Kunden usw. Ich werde auch einige immaterielle Dinge haben, mit denen ich arbeite - eine Bestellung oder eine Kategorie. Sobald ich alle "Substantive" im System habe, erstelle ich ein Domänenmodell, das zeigt, wie diese Objekte miteinander in Beziehung stehen. Eine Bestellung hat einen Kunden und mehrere SKUs, viele Skus sind zu einem Produkt zusammengefasst und so weiter auf.

Diese Domänenmodelle können als UML-Domänenmodelle, Klassendiagramme und SQL-ERDs dargestellt werden.

Sobald ich die Substantive des Systems herausgefunden habe, gehe ich zu den Verben über, zum Beispiel zu den Operationen, die jedes dieser Elemente durchläuft, um eine Bestellung zu erstellen. Diese lassen sich normalerweise recht gut auf Anwendungsfälle aus meinen funktionalen Anforderungen abbilden. Der einfachste Weg, diese auszudrücken, sind UML-Sequenz-, Aktivitäts- oder Kollaborationsdiagramme oder Swimlane-Diagramme.

Es ist wichtig, dies als einen iterativen Prozess zu betrachten. Ich mache eine kleine Ecke der Domain, arbeite dann an den Aktionen und gehe dann zurück. Im Idealfall habe ich Zeit, Code zu schreiben, um Dinge auszuprobieren, während ich fortfahre. Sie möchten nie, dass das Design der Anwendung zu weit voraus ist. Dieser Prozess ist normalerweise schrecklich, wenn Sie denken, dass Sie die vollständige und endgültige Architektur für alles erstellen. Alles, was Sie versuchen, ist, die grundlegenden Grundlagen zu schaffen, die das Team im Verlauf der Entwicklung gemeinsam nutzen wird. Sie erstellen meistens ein gemeinsames Vokabular, das die Teammitglieder verwenden können, wenn sie das System beschreiben, und legen nicht das Gesetz fest, wie es gemacht werden muss.

Ich habe Probleme, ein System vollständig zu überdenken, bevor ich es codiere. Es ist einfach zu einfach, nur einen flüchtigen Blick auf einige Komponenten zu werfen, von denen Sie erst später feststellen, dass sie viel komplizierter sind, als Sie gedacht haben.

Eine Lösung besteht darin, sich wirklich anzustrengen. Schreibe UML überall. Gehen Sie durch jede Klasse. Überlegen Sie, wie es mit Ihren anderen Klassen interagieren wird. Das ist schwer zu machen.

Was ich gerne mache, ist zunächst einen allgemeinen Überblick zu geben. Ich mag UML nicht, aber ich mag es, Diagramme zu zeichnen, die den Punkt vermitteln. Dann beginne ich es umzusetzen. Selbst wenn ich die Klassenstruktur nur mit leeren Methoden schreibe, sehe ich oft Dinge, die ich früher übersehen habe, und aktualisiere dann mein Design. Beim Codieren wird mir klar, dass ich etwas anders machen muss, also werde ich mein Design aktualisieren. Es ist ein iterativer Prozess . Das Konzept "Alles zuerst entwerfen und dann alles implementieren" ist als Wasserfallmodell bekannt, und ich denke, andere haben gezeigt, dass es eine schlechte Art ist, Software zu erstellen.

Versuchen Sie es mit Archimate.