Progettazione software mediante pseudocodifica?

Conosci un buon modo per progettare (ovvero scrivere) software con un metodo basato su pseudocodice?

Sono nuovo di progettazione software e leggere alcune informazioni su UML. Le mie umili gerarchie di classi sono buone finora, tuttavia, dopo che è diventato complesso, noto che "vedendo l'intera immagine" avrei potuto usare una struttura diversa per una maggiore estendibilità futura. Dato che Python è bravo con la prototipazione, sto quasi iniziando a scrivere, ma non del tutto.

Quindi ho provato i diagrammi di classe UML, ma non sembrano aiutarmi molto. I problemi che risolvo lì posso banalmente fare nella mia testa. Ma noto ulteriori requisiti di progettazione quando inizio a pseudocodificare i metodi effettivi.

Quindi, se volessi progettare con pseudocodice, come lo faresti? Credo che per me un metodo che sia approssimativamente 1 a 1 con il codice funzioni meglio. Ma la maggior parte dei software UML non mostra nemmeno il codice del metodo (al contrario delle immagini in es. GoF).

Qualcuno ha affermato che UML è solo per la documentazione e la presentazione e non eccezionale per il design? Ho anche quella sensazione. Pensavo che UML puro e alcuni schizzi di lavagna semplicistici fossero il modo di progettare software fino a quando ho cercato su Google ho trovato Envision APDT.

Quindi lo sviluppo agile è qualcosa che dovrei cercare o lo chiamano casualmente quell'agile - pensavo che l'agile riguardasse solo la pianificazione? O sto progettando in modo errato (con UML) - qualcuno progetta con pseudocodice? Come posso trovare un buon strumento per questo?

 I thought agile is about schedule only?

Non è solo una pianificazione. Lo sviluppo di software agile si basa principalmente sull'essere uno sviluppo evolutivo e una consegna iterativa a tempo con una pianificazione adattiva che incoraggia la risposta flessibile alle modifiche richieste dal proprietario del prodotto.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Nella mia esperienza, i grafici sono molto più facili da capire dal punto di vista del cliente. Sono visivamente accattivanti e molte volte molto colorati e facili da seguire. Tuttavia, è molto difficile mantenere i grafici a causa della natura della disconnessione con il codice dell'applicazione reale. Ogni volta che viene apportata una modifica nell'applicazione, lo sviluppatore deve impiegare del tempo per aggiornare tutta la documentazione, inclusi i grafici. Tuttavia, questo problema può essere facilmente eliminato una volta che c'è un BA nel team o nell'azienda, che comprende bene i processi aziendali dei clienti e può gestire i diagrammi UML.

Strumenti come UML possono semplificare questo processo ma funzionano bene solo con la programmazione orientata agli oggetti. Lo pseudo codice è molto più semplice per i team tecnici. Il processo di creazione di questo codice aumenta notevolmente la velocità dell'attuale fase di sviluppo del linguaggio di programmazione.

Ci sono alcune altre alternative che potresti anche guardare:

• Diagrammi del flusso di dati
• Diagrammi di stato
• Diagrammi di flusso del processo

Buoni riferimenti da guardare: Tutorial di progettazione software . Inoltre, consiglierei personalmente di leggere un buon blog su Pseudocodice o Codice? pubblicato da Coding Horror - il mio blog preferito da leggere :)

Tutto sommato, ci sono alcuni compromessi che è necessario considerare.

Quando si programma in linguaggio assembly, scrivere pseudo-codice ha molto senso. L'algoritmo potrebbe essere verificato prima di spendere lo sforzo di tradurlo manualmente in linguaggio assembly e quindi eseguire il debug della traduzione. Aveva ancora un senso per i linguaggi compilati di prima generazione come FORTRAN IV, dove l'unico costrutto di controllo era GOTO, tutte le variabili (eccetto gli argomenti formali) erano globali e i nomi delle variabili erano limitati a sei caratteri.

Oggi facciamo pochissima programmazione nel linguaggio assembly e vedo poco valore nella scrittura di pseudo-codice invece che nella semplice scrittura di codice. In un linguaggio decente, il codice reale seguirà lo pseudo-codice quasi parola per parola, e lo pseudo-codice è solo una perdita di tempo.

Tuttavia, non inizio a programmare in fondo. Seguo TDD e inizio con un test. Quindi comincio a programmare in alto e gradualmente mi muovo verso il basso in base alle necessità per far passare i test.

L'alternativa allo pseudo-codice non sta scrivendo 1000 righe di classi di basso livello. Inizia invece dall'alto, chiamando l'API ideale ma inesistente per il tuo dominio. Quindi crea l'API.

Trovo che i diagrammi di classe valgano a malapena lo sforzo, anche quando salti l'elenco di tutti i metodi e mostri semplicemente la gerarchia dell'ereditarietà. I diagrammi di sequenza sono buoni, ma mi sento imbarazzato quando li disegno (probabilmente solo io).

Trovo che i diagrammi di flusso di dati e i diagrammi di struttura siano più utili (anche se i diagrammi di struttura sono comunemente associati a BDUF e al momento non sono pertanto favorevoli). I DFD sono particolarmente utili per la decomposizione funzionale. Ogni "bolla" in un DFD può essere suddivisa nel proprio DFD fino a raggiungere il livello di dettaglio desiderato.

Penso che gli strumenti grafici siano migliori della pseudocodifica, ma UML è semplicemente così complicato da combinare il male in quei metodi :-)

Per essere un po 'più chiari: penso che la programmazione sia principalmente un modo per analizzare un certo problema, separandolo da componenti più piccoli e dalla loro interazione. Questo è "un viaggio, non una destinazione", migliora costantemente la tua conoscenza del problema, quindi il grafico dei componenti sta cambiando: i livelli appaiono e svaniscono, le funzioni e gli elementi di dati si spostano su e giù, ecc.

Lo strumento naturale per seguire questo processo è uno sketchboard, il più semplice possibile, ma abbastanza complesso per aiutare la comprensione rapida (stessi colori, forme, frecce per lo stesso significato logico). Non ho trovato il proiettile d'argento, e forse un giorno scriverò il mio, ma ora uso gliffy ; combinato con la funzione di zoom di prezi sarebbe quasi perfetto.

Perché non pseudocodificare? Lo pseudocodifica è un passo avanti verso l'implementazione, una "forma serializzata del grafico componente", quando ancora modellate le vostre idee. Non va bene, limita la testa. Nella mia esperienza ho scoperto che più tardi comincio a scrivere codice, meno codice devo buttare via ...

Ma forse è perché ho scritto tutti quei codici buttati fuori, quindi non devo scriverli ora, l'esperienza che ho acquisito è con me durante la progettazione del sistema? Bene, devo modificare l'affermazione.

Se ti perdi con il tuo grafico e vedi molte possibili soluzioni equivalenti, vai su pseudocodice o addirittura scrivi quel codice con oggetti finti - in Java, questa è quasi nessuna differenza. Vedi il codice, senti la struttura e l'usabilità di quei componenti, ti aiuterà a sistemare il tuo grafico e prendere decisioni. Questo funziona SOLO se sei pronto a buttare via quel codice se ritieni che sia un male. Penso che questo sia il vantaggio dello pseudocodice: minore è la tentazione di mantenerlo quando funziona, ma è sbagliato nella struttura (e come sempre, non hai abbastanza tempo). :-)