Perché non possiamo catturare la progettazione del software in modo più efficace? [chiuso]

Come ingegneri, tutti "progettiamo" artefatti (edifici, programmi, circuiti, molecole ...). Questa è un'attività (design-the-verb) che produce un qualche tipo di risultato (design-the-noun).

Penso che siamo tutti d'accordo sul fatto che progettare il nome sia un'entità diversa rispetto al manufatto stesso.

Un'attività chiave nel settore del software (in effetti, in qualsiasi attività in cui l'artefatto del prodotto risultante deve essere migliorato) è comprendere il "design (il-sostantivo)". Eppure, come comunità, sembriamo essere praticamente dei fallimenti completi nel registrarla, come evidenziato dalla quantità di sforzo che le persone fanno per riscoprire fatti sulla loro base di codice. Chiedi a qualcuno di mostrarti il ​​design del suo codice e vedere cosa ottieni.

Penso a un design per software che abbia:

• Una specifica esplicita per ciò che il software dovrebbe fare e quanto bene lo fa
• Una versione esplicita del codice (questa parte è semplice, tutti ce l'hanno)
• Una spiegazione di come ciascuna parte del codice serve a raggiungere la specifica (ad es. Una relazione tra frammenti di specifica e frammenti di codice)
• Una logica del perché il codice è così com'è (ad esempio, perché una scelta particolare piuttosto che un'altra)

Ciò che NON è un design è una prospettiva particolare sul codice. Ad esempio [non scegliere specificamente] i diagrammi UML non sono progetti. Piuttosto, sono proprietà che puoi derivare dal codice o, probabilmente, proprietà che desideri derivino dal codice. Ma come regola generale, non è possibile derivare il codice da UML.

Perché dopo oltre 50 anni di sviluppo di software, perché non abbiamo modi regolari per esprimerlo? (Sentiti libero di contraddirmi con esempi espliciti!)

Anche se lo facciamo, la maggior parte della comunità sembra così concentrata sull'ottenere "codice" che il design-the-noun si perde comunque. (IMHO, fino a quando il design non diventerà lo scopo dell'ingegneria, con l'artefatto estratto dal design, non riusciremo ad aggirare questo).

Cosa hai visto come mezzo per la registrazione di progetti (nel senso che l'ho descritto)? I riferimenti espliciti ai documenti sarebbero buoni. Perché pensi che i mezzi specifici e generali non abbiano avuto successo? Come possiamo cambiarlo?

[Ho le mie idee che rafforzano il punto di vista puntato sopra, ma sono interessato alle risposte degli altri ... ed è difficile implementare il mio schema [[e forse questo è il vero problema: -]]]

EDIT 2011/1/3: Uno dei thread di risposta suggerisce che la "documentazione" (presumibilmente testuale, in particolare non formale) potrebbe essere adeguata. Immagino che dovrei chiarire che non ci credo. Gli strumenti CASE sono apparsi sulla scena a partire dagli anni '80, ma i primi strumenti hanno catturato principalmente pixel per i diagrammi di qualsiasi cosa tu abbia disegnato; mentre gli strumenti avevano probabilmente un successo commerciale, in realtà non erano molto utili. Un'intuizione chiave è stata che se gli artefatti di "progettazione" aggiuntivi non sono formalmente interpretabili, non è possibile ottenere alcun aiuto serio da parte degli strumenti. Credo che la stessa intuizione si applichi a qualsiasi forma utile a lungo termine di acquisizione del design: se non ha una struttura formale, non sarà di alcun utilità. I documenti di testo praticamente non superano questo test.

Penso che ci siano diverse ragioni per cui non siamo ancora bravi in ​​questo.

1. La gente per molto tempo, sebbene il software fosse come una casa, usasse processi e idee dalla costruzione. "Software Architect" era un titolo desiderato da tutti i programmatori. Negli ultimi dieci anni l'architetto del software si è quasi estinto. L'idea di processi a cascata in cui prima hai un architetto che dice come il software dovrebbe funzionare e apparire, e quindi indurre le persone a fare diagrammi su come dovrebbe essere costruito e, infine, hanno scimmia codice che implementa questi bei flussi di lavoro / diagrammi UML su specifica, questa idea è ora ampiamente deriso. Quindi, in effetti, l'intera industria ha imboccato la strada sbagliata per 40 anni.

2. Gli strumenti che utilizziamo cambiano e migliorano costantemente. La programmazione è un enigma logico, e troviamo idee e tecniche migliori per astrarre quell'enigma e renderlo comprensibile. Il modo in cui lo modelliamo deve evolversi alla stessa velocità, ma è in ritardo. Le tecniche migliorate per astrarre l'enigma della programmazione significa anche che possiamo aumentare la complessità. E così facciamo. La programmazione è sempre ai margini della complessità che come programmatori siamo in grado di gestire.

3. Creare modi per descrivere il programma è una sorta di astrazione. Se riusciamo a trovare un buon modo di astrarre il software, possiamo anche mettere quell'astrazione direttamente negli strumenti di sviluppo e quindi aggiungere un'altra astrazione / semplificazione alla programmazione. Questo è successo molte volte. Esempi di tali astrazioni sono funzioni, classi e librerie.

4. Perciò; Se si dispone di un modello di software accurato e di successo , tale modello sarà equivalente al software. Quale tipo rende inutile l'intero sforzo, il che a sua volta conferma il punto 1 sopra: Modellare il software è molto meno utile di quanto si pensasse in precedenza. È invece meglio estrarre i dati sul software dal codice. La creazione di un modello UML dall'aspetto del codice è molto più illuminante della creazione di un modello UML e del tentativo di implementare quel modello teorico.

Potresti essere interessato a rivedere la documentazione sulla tracciabilità del software. Senza un ordine particolare:

• CUBRANIC, D., MURPHY, GC, SINGER, J., E BOOTH KELLOGG, S. Hipikat: una memoria di progetto per lo sviluppo del software. Transactions on Software Engineering 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I., E HAN, J. Un'indagine sull'uso e la documentazione della logica di progettazione dell'architettura. In Proc della 5a Conferenza di lavoro IEEE / IFIP sull'architettura del software (2005).
• RAMESH, B., POWERS, T., STUBBS, C., EDWARDS, M. Tracciabilità dei requisiti di attuazione: un caso di studio. In Proc of the Int'l Symp on Requirements Engineering (York, 1995).
• HORNER, J. E ATWOOD, ME Motivazioni del design: la logica e le barriere. In Proc della 4a Conferenza nordica sull'interazione uomo-computer: ruoli che cambiano (Oslo, Norvegia, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., E CLARK, S. Best practice per la tracciabilità automatizzata. Computer 40, 6 (giugno 2007), 27–35.
• ASUNCION, H., FRANÇOIS, F., E TAYLOR, RN Uno strumento di tracciabilità del software industriale end-to-end. In Proc della 6a riunione congiunta di European Software Eng Conf e ACM SIGSOFT Int'l Symp on the Foundations of Software Engineering (ESEC / FSE) (Dubrovnik, 2007).

Nota che questa è solo la punta dell'iceberg e sono sicuro di aver lasciato fuori alcuni documenti chiave.

In una nota a parte, il mio lavoro su Arcum è stato un mezzo per i programmatori per esprimere all'IDE l'uso di modi di dire trasversali. Una volta espressi, i programmatori potrebbero quindi trasformare il loro codice sorgente per utilizzare implementazioni alternative:

• Macneil Shonle, William G. Griswold e Sorin Lerner. Oltre il refactoring: un framework per la manutenzione modulare degli idiomi progettuali trasversali . In seguito alla 6a riunione congiunta della conferenza europea sull'ingegneria del software e al simposio ACM SIGSOFT sulle basi dell'ingegneria del software (ESEC-FSE '07; 3-7 settembre 2007). 175-184.

Per inciso, Arcum è anche legato al tuo lavoro DMS.

UML è per un programma quali sono i piani per un edificio nella mia visione umana. I piani da soli non sono un progetto fuori rotta, sono necessarie specifiche dei materiali (strumenti di codice utilizzati), una visione generale dell'edificio (una rappresentazione schematica dell'intero software, compresi i progetti della GUI), come l'edificio è piantato nell'ambiente circostante (uno schema chiaro di come il software interagisce con gli altri / è installato all'interno del sistema operativo), come resiste al clima e al suolo (interazione con l'hardware), ... Molti libri sul design provano a definirlo, ma allo stesso modo molte cose nella scienza, ogni scienziato ha un po 'la sua definizione.

Ora, anche io non sono d'accordo con la tua osservazione sul fatto che non puoi derivare il codice da UML. Puoi, se hai le informazioni aggiuntive menzionate. Ma il vero codice non è più il design, questo è l'artefatto. Non puoi nemmeno estrarre le pietre e il cemento reali da un piano, ma hai bisogno del piano per mettere le pietre e il cemento reali nella forma corretta e nel posto giusto.

Alla luce di ciò, ho trovato interessante l' articolo che segue (l'ho incontrato in un contesto diverso quando stavo cercando un software grafico, ma comunque ...). L'approccio grafico per descrivere un design aveva senso per me, anche se, di nuovo, questo è solo una parte del design secondo me. La cosa interessante è che questo approccio fornisce un framework per comprendere e riformattare i progetti (invece di refactor il software), come indicato nei seguenti documenti:

• Wermelinger e Fiadeiro

• Tsantalis et al

Ci sono molti altri approcci per descrivere (parte di) il design, come il design strutturato (grafici HIPO) o il design del programma integrato , i modelli di design , ...

Tuttavia, fintanto che non sono previsti standard di settore, è improbabile trovare un modo "regolare" per esprimerlo. Anche dopo oltre 50 anni. E ad essere sincero, se la tua azienda trova un buon modo per esprimere un design, lo condivideresti con il mondo?

Dalla mia esperienza personale, direi che siamo bravi a catturare il design del software. Abbiamo un database di requisiti e documenti di progettazione per ogni singola caratteristica che abbiamo mai implementato sulla nostra piattaforma. Suppongo che la mia circostanza sia forse unica. Ecco alcune cose a cui pensare però.

Ogni singola persona nel mio team ha una laurea in ingegneria ... principalmente EE o CE. L'ingegneria ti insegna a progettare come parte del curriculum.

Penso che ci siano molti cosiddetti ingegneri del software che provengono da sfondi CS. La progettazione del software non è parte integrante della maggior parte dei programmi CS. Non sto dicendo che tutte le major CS siano cattive nella progettazione, ma scommetterei che la maggior parte non ha un'istruzione formale che le abbia insegnate. Penso che molte persone credano che se puoi programmare puoi progettare software, il che non è vero. Dato che molti programmatori non hanno una formazione ingegneristica, non è davvero sorprendente che molti progetti software non abbiano un team che sia bravo a catturare il design.

Vedo due problemi.

Il primo è che è difficile mantenere sincronizzati codice e documentazione. Se sono separati, divergeranno e la documentazione diventerà inutile. I programmatori hanno provato a usare gli strumenti per fare il loro lavoro per mantenerli sincronizzati (come gli strumenti CASE), ma questi strumenti sono stati intercettati tra i programmatori e il loro codice, il che ha causato più danni che benefici. Una delle intuizioni chiave del design guidato dal dominio (Evans, 2004) è che un buon design è davvero difficile, quindi per ottenere qualcosa da esso, devi:

• scegli la più piccola area possibile del tuo programma in cui un buon design produrrà grandi benefici, il cosiddetto dominio principale
• lavorare sodo per ottenere un buon design sotto forma di un linguaggio onnipresente che tutti i membri del team usano continuamente
• per quanto possibile, rendere la progettazione parte del codice

L'altro grosso problema con il modo in cui progettiamo è che i nostri metodi di progettazione non sono abbastanza matematici. Le astrazioni che perdono non si prestano a trarne solide conclusioni, e il mondo della logica rigorosamente applicata e della chiara verità è chiamato matematica, da cui i programmatori per lo più evitano.

I pochi strumenti matematici che abbiamo, come i metodi formali, sono molto ingombranti.

Map-ridurre è un bell'esempio di matematica nella programmazione. L'idea di base è questa: quando si dispone di un'operazione binaria associativa, è possibile distribuirne l'esecuzione molto facilmente. Un'operazione binaria è una funzione con due parametri, l'associatività implica che (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 è

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) dove As, Bs e C possono essere aggiunti banalmente in posizioni diverse, i loro risultati raccolti e riassunto in pochissimo tempo.

Ridurre la mappa è un'idea ridicolmente semplice. Può essere descritto su un pezzo di carta. Se puoi presumere che il lettore abbia una solida conoscenza del concetto di associatività, se si adatta a un pezzo di carta abbastanza piccolo. Ora prova a spiegare la riduzione della mappa a qualcuno senza usare il termine associatività o indirizzandolo indirettamente. Ti sfido.

La progettazione del software senza astrazioni matematiche è come provare a fare architettura senza mai preoccuparsi di imparare la geometria.

Forse Haskell può risolvere questo problema nel tempo. L'uso dei concetti della teoria delle categorie per descrivere i programmi mi sembra promettente. La teoria delle categorie è così astratta che persino i matematici ne hanno fatto poco uso, ma apparentemente le categorie, che sono astratte al di là del riconoscimento, sembrano essere abbastanza astratte da descrivere la struttura del software. Lo scopriremo. Lentamente.