Wie spezifisch, um Design-Dokument zu bekommen?

Question

Ich erstelle ein Entwurfsdokument für ein Sicherheitssubsystem, das in C++ geschrieben werden soll. Ich habe ein Klassendiagramm und Sequenzdiagramme für die wichtigsten Anwendungsfälle erstellt. Ich habe auch die öffentlichen Attribute, Assoziationen und Methoden für jede der Klassen angegeben. Aber ich habe die Methodendefinitionen noch nicht auf die C++ - Ebene heruntergebohrt. Da ich neu in C++ bin, wie auch der andere Entwickler, frage ich mich, ob es nicht sinnvoll ist, weiter zu gehen und dieses Level anzugeben. Gedanken?

edit: Wow - ganz dagegen, einstimmig. Ich habe zum Beispiel über das ganze Geschäft nachgedacht über das Spezifizieren von const vs. nicht-const, das Übergeben von Verweisen, das Behandeln von Standardkonstruktor und Zuweisungen und usw.. Ich glaube, es war sehr hilfreich, dies bis jetzt auf diese Detailebene zu spezifizieren. Ich habe definitiv eine klarere Vorstellung davon bekommen, wie das System funktionieren wird. Vielleicht, wenn ich nur ein paar Methoden als Beispiel benutze, bevor ich in den Code eintauche?

Answer 1

Da Sie neu sind, macht es wahrscheinlich Sinn, nicht Drill-Down.

Grund: Sie finden immer noch die Sprache und wie die Dinge am besten strukturiert sind. Das bedeutet, dass Sie zunächst Fehler machen und diese korrigieren möchten, ohne die Dokumentation ständig zu aktualisieren.

Answer 2

Ich würde sagen, dass es überhaupt keinen Sinn ergibt, und dass Sie bereits zu weit gegangen sind. Wenn Sie neu in C++ sind, sind Sie nicht in der Lage, ein detailliertes Entwurfsdokument für ein C++ - Projekt zu schreiben. Ich würde dir empfehlen, zu versuchen, das zu implementieren, was du bereits in C++ hast, durch die unvermeidlichen Fehler zu lernen (wie öffentliche Attribute) und dann zurückzugehen und es zu überarbeiten.

Answer 3

Ich würde nicht empfehlen, auf dieses Niveau zu gehen, aber dann sind Sie schon wieder vorbei, wo ich in einer Design-Spezifikation gehen würde. Mein persönliches Gefühl ist, dass es sehr vergeudet sein wird, eine Menge Aufwand in die Detailplanung zu investieren, da Sie bei der Entwicklung von Code herausfinden, dass Ihre Annahmen, wie der Code funktioniert, falsch sind. Ich würde bei einem High-Level-Design bleiben und über die Verwendung von TDD (Test Driven Development) nachdenken, um das Low-Level-Design und die Implementierung zu leiten.

Answer 4

Der beste Weg, um anzugeben, wie der Code tatsächlich zusammenpassen sollte, ist in Code. Das Design-Dokument ist für andere Dinge gedacht, die nicht einfach in Code ausgedrückt werden können. Sie sollten es verwenden, um den tatsächlichen Bedarf des Programms zu beschreiben, wie es mit Benutzern interagiert, welche Einschränkungen in Bezug auf Hardware und Betriebssysteme bestehen. Beschreiben Sie sicherlich die Gesamtarchitektur Ihrer Anwendung in einem Designdokument, aber die API sollte beispielsweise in dem Code beschrieben werden, der die API verfügbar macht.

Answer 5

Sie sind mit dem Dokumentationsteil bereits weit genug gegangen. Wenn Sie als Anfänger in C++ die Sprache verstehen, möchten Sie vielleicht die Struktur Ihres Programms ändern. Dann müssten Sie Änderungen in der Dokumentation vornehmen. Ich würde vorschlagen, dass Sie mit der Dokumentation schon zu weit gegangen sind. Keine Notwendigkeit, mehr in es zu bohren

Answer 6

Es hängt wirklich davon ab, an wen das Design-Dokument gerichtet ist. Wenn es sich um einen Chef handelt, der nicht technisch ist, dann sind Sie gut mit dem, was Sie haben.

Wenn es für Sie selbst ist, dann verwenden Sie das Tool, um Ihnen zu helfen, damit Sie entscheiden. Ich erstelle Methodenlevel-Designdokumente, wenn ich ein Projekt erstelle, aber es ist auf einem hohen Niveau, so dass ich herausfinden kann, welche Eigenschaften die verschiedenen Klassen haben sollten. Ich habe festgestellt, dass die primären Funktionen einer Klasse in Bezug auf Sprachen wenig mit der Programmiersprache zu tun haben, in der wir arbeiten. Einige der erforderlichen internen Details und Funktionen sicherlich variieren aufgrund der gewählten Sprache, aber das sind Implementierungsdetails dass ich nicht mit während der Entwurfsphase stören.

Es hilft mir sicher zu wissen, dass zum Beispiel eine Autorisierungsklasse eine Authentifizierungsfunktion haben kann, die ein Benutzerobjekt als Parameter akzeptiert. Ich interessiere mich nicht wirklich während des Entwurfs, dass ich eine interne Schnur md5 Funktionsverpackung benötigen könnte, um ein bestimmtes Ziel zu erreichen. Das finde ich beim Codieren heraus.

Ziel des ersten Entwurfs ist es, sich so zu organisieren, dass Sie mit Klarheit und Voraussicht Fortschritte machen können, anstatt die gleiche Funktion vier Mal herauszureißen und neu zu implementieren, weil Sie ein Szenario vergessen haben, weil Sie nicht geplant haben.

EDIT: Ich arbeite in PHP sehr, und ich benutze tatsächlich PhpDoc, um einige der Design-Dokumente zu tun, indem Sie einfach die Methodensignatur ohne Implementierung schreiben und dann eine detaillierte Beschreibung dessen, was die Methode in der Methode tun sollte Kopfzeilen Kommentare. Dies hilft jedem, der meine Klasse in der Zukunft benutzt, weil das Design die Dokumentation ist. Ich kann die Dokumentation auch ändern, wenn ich beim Codieren einige Änderungen vornehmen muss.

Ich arbeite in PHP4 sehr, so dass ich keine Schnittstellen benutze. In php5 erstelle ich die Schnittstelle und implementiere sie dann woanders.

Answer 7

Wie alle anderen auch sagen, du bist weit hinter dir gegangen, wo du mit dem Design gehen musst. Haben Sie eine Reihe von Anforderungen an die einfache True/False-Anweisungsebene, von der Sie dieses Design abgeleitet haben? Sie können den ganzen Tag lang entwerfen, aber wenn Sie keine Anforderungen haben, die einfach sagen, was Sie tun werden, ist es egal, wie gut Ihr Design ist.