2009-03-30 7 views
7

Sto creando un documento di progettazione per un sottosistema di sicurezza, da scrivere in C++. Ho creato un diagramma di classe e diagrammi di sequenza per i principali casi d'uso. Ho anche specificato gli attributi pubblici, le associazioni e i metodi per ciascuna delle classi. Ma, non ho ancora perforato le definizioni del metodo fino al livello C++. Dato che sono nuovo di C++, come lo è l'altro sviluppatore, mi chiedo se potrebbe non avere senso andare avanti e specificare a questo livello. Pensieri?Quanto è specifico per ottenere il documento di progettazione?

modifica: Wow - completamente contro, unanime. Stavo pensando, ad esempio, all'intero business riguardo alla specifica di const e non-const, passando i riferimenti, gestendo il costruttore e gli assegnamenti predefiniti e così via. Credo che sia stato abbastanza utile specularne fino a questo livello di dettaglio fino ad ora. Ho sicuramente avuto un'idea più chiara di come funzionerà il sistema. Forse se faccio solo alcuni metodi, ad esempio, prima di immergermi nel codice?

risposta

4

Dal momento che sei nuovo, probabilmente è consigliabile non eseguire il drill down.

Motivo: stai ancora cercando di capire la lingua e come le cose sono meglio strutturate. Ciò significa che inizialmente commetterai degli errori e vorresti correggerli senza aggiornare costantemente la documentazione.

+0

Ha accettato la risposta di Jason a causa del punto sul non dover tornare costantemente alla documentazione. –

5

Direi che non ha alcun senso e che sei già andato troppo lontano. Se sei nuovo in C++ non sei nella posizione di scrivere un documento di progettazione dettagliato per un progetto C++. Ti consiglierei di provare a implementare ciò che hai già in C++, imparare dagli errori inevitabili (come gli attributi pubblici) e poi tornare indietro e rivederlo.

5

Non consiglierei di andare a questo livello, ma poi di nuovo sei già passato dove andrei in una specifica di progettazione. La mia sensazione personale è che mettere molto impegno nel design dettagliato in anticipo andrà sprecato mentre scopri nello sviluppo di codice che le tue ipotesi su come funziona il codice sono sbagliate. Vorrei mantenere un design di alto livello e pensare all'utilizzo di TDD (sviluppo guidato dai test) per guidare la progettazione e l'implementazione a basso livello.

+0

+1 per TDD, soprattutto per una coppia di programmatori C++ inesperti. Ci saranno un sacco di errori e una rigorosa serie di test sarà la migliore difesa contro di loro. –

2

Il modo migliore per specificare in che modo il codice deve corrispondere effettivamente è nel codice. Il documento di progettazione è per altre cose che non sono facilmente espresse nel codice. Dovresti usarlo per descrivere l'effettiva necessità del programma, come interagisce con gli utenti, quali sono i vincoli in termini di hardware e sistemi operativi. Descrivere certamente l'architettura generale della propria applicazione in un documento di progettazione, ma, ad esempio, l'API dovrebbe essere effettivamente descritta nel codice che espone l'API.

0

Si è già andati abbastanza lontano con la parte di documentazione. Dato che sei ancora un principiante in C++, quando capirai la lingua, potresti voler cambiare la struttura del tuo programma. Quindi dovresti fare cambiamenti nella documentazione. Ti suggerirei di aver già esagerato con la documentazione. Non c'è bisogno di scavare di più in esso

3

Dipende davvero da chi è rivolto il documento di progettazione. Se è per un capo che non è tecnico, allora sei bravo con quello che hai.

Se è per te, allora stai usando lo strumento per aiutarti, quindi decidi tu. Quando creo un progetto, creo i documenti di progettazione a livello di metodo, ma è ad un livello elevato, così posso capire quali dovrebbero essere le caratteristiche delle varie classi. Ho trovato che attraverso le lingue, le funzionalità primarie di una classe hanno poco a che fare con il linguaggio di programmazione in cui stiamo lavorando. Alcuni dei dettagli interni e delle funzioni richieste certamente variano a seconda della lingua scelta, ma quelli sono dettagli di implementazione che I non si preoccupa di durante la fase di progettazione.

Mi aiuta sicuramente a sapere che, ad esempio, una classe di autorizzazione può avere una funzione di autenticazione che accetta un oggetto Utente come parametro. Non mi interessa davvero durante la progettazione che potrebbe essere necessario un wrapper di funzione md5 stringa interna per raggiungere un obiettivo specifico. Lo scopro mentre codifico.

L'obiettivo del design iniziale è quello di organizzarsi in modo da poter progredire con chiarezza e previdenza piuttosto che strappare e reimplementare la stessa funzione 4 volte perché si è dimenticato qualche scenario a causa della mancata pianificazione.

EDIT: io lavoro in PHP molto, e io in realtà uso PHPDoc per fare alcuni dei documenti di progettazione, semplicemente scrivendo la firma del metodo senza implementazione, poi mettere una descrizione dettagliata di ciò che il metodo deve fare nel metodo commenti di intestazione. Questo aiuta chiunque stia usando la mia classe in futuro, perché il design è la documentazione. Posso anche modificare la documentazione se devo apportare alcune modifiche durante la codifica.

Lavoro molto su php4, quindi non uso le interfacce. In php5, creo l'interfaccia, quindi la implemento altrove.

0

Come tutti gli altri dicono, sei andato oltre il punto in cui hai bisogno di andare con il design. Hai una buona serie di requisiti per il semplice livello di istruzione vero/falso da cui hai derivato il progetto? Puoi progettare tutto il giorno, ma se non hai requisiti che dicono semplicemente COSA hai intenzione di fare, non importa quanto sia buono il tuo design.

Problemi correlati