Wie spezifisch ist das Designdokument?

7

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?

    
Jack BeNimble 30.03.2009, 18:20
quelle

7 Antworten

4

Da Sie neu sind, macht es wahrscheinlich Sinn nicht , einen Drilldown durchzuführen.

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

    
Jason Cohen 30.03.2009, 18:25
quelle
5

Ich würde nicht empfehlen, zu diesem Niveau zu gehen, aber dann bist du schon wieder gegangen, 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.

    
tvanfosson 30.03.2009 18:25
quelle
5

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.

    
anon 30.03.2009 18:24
quelle
3

Es hängt wirklich davon ab, an wen das Designdokument gerichtet ist. Wenn es für einen Chef ist, 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 sich 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 Hauptfunktionalitäten 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 unterscheiden sich aufgrund der gewählten Sprache. Aber das sind Implementierungsdetails, mit denen ich mich in der Designphase nicht beschäftige.

Es hilft mir sicher zu wissen, dass zum Beispiel eine Autorisierungsklasse eine Authentifizierungsfunktion hat, 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.

Das Ziel des anfänglichen Designs besteht darin, sich so zu organisieren, dass Sie mit Klarheit und Voraussicht Fortschritte machen können, anstatt die gleiche Funktion viermal herauszureißen und neu zu implementieren, weil Sie ein Szenario vergessen haben, weil Sie nicht geplant haben.

BEARBEITEN: Ich arbeite viel in PHP, und ich benutze PhpDoc, um einige der Design-Dokumente zu erstellen, indem ich einfach die Methodensignatur ohne Implementierung schreibe und dann eine detaillierte Beschreibung über die Methode im Methodenkopf hinterlasse Bemerkungen. 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 viel in php4, also benutze ich keine Interfaces. In php5 erstelle ich die Schnittstelle und implementiere sie dann woanders.

    
Zak 30.03.2009 18:46
quelle
2

Am besten geben Sie an, wie der Code tatsächlich zusammenpassen soll: im 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. Natürlich beschreiben Sie die Gesamtarchitektur Ihrer Anwendung in einem Designdokument, aber zum Beispiel sollte die API tatsächlich in dem Code beschrieben werden, der die API verfügbar macht.

    
quelle
0

Sie sind bereits weit genug mit der Dokumentation 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 hinein zu bohren

    
stack programmer 30.03.2009 18:40
quelle
0

Wie jeder andere sagt, sind Sie weit darüber hinaus gegangen, wo Sie mit dem Design gehen müssen. 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.

    
Rob K 30.03.2009 23:58
quelle

Tags und Links