Perché non possiamo acquisire il design del software in modo più efficace? [chiuso]

Penso che ci siano diversi motivi per cui non siamo ancora bravi in questo.

1. Le persone per molto tempo sebbene il software fosse come le case e stessero usando processi e idee dalla costruzione. "Software architect" era un titolo che tutti i programmatori volevano. Negli ultimi dieci anni l'architetto del software si è quasi estinto. L'idea dei processi a cascata in cui per la prima volta hai un architetto che dice come dovrebbe funzionare il software e poi fare in modo che le persone realizzino diagrammi su come dovrebbe essere costruito e infine avere codice scimmia che implementa questi bei diagrammi di flusso di lavoro / UML alle specifiche, questa idea è ora ampiamente deriso. Quindi, in effetti, l'intera industria ha iniziato ad imboccare la strada sbagliata per 40 anni.

2. Gli strumenti che utilizziamo cambiano e migliorano costantemente. La programmazione è un enigma logico, e arriviamo a idee e tecniche migliori per astrarre quel puzzle e renderlo comprensibile. Il modo in cui modelliamo questo deve evolvere alla stessa velocità, ma resta indietro. Le tecniche migliorate per astrarre il puzzle della programmazione significano anche che possiamo aumentare la complessità. E così facciamo. La programmazione è sempre ai margini della complessità che noi programmatori possiamo 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. Di conseguenza; Se hai un modello di successo e preciso del software, quel modello sarà equivalente al software. tutto lo sforzo inutile, che a sua volta conferma il punto 1 sopra: la modellazione del 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 da come appare effettivamente il codice è molto più illuminante rispetto alla creazione di un modello UML e cercando di implementare quel modello teorico.

Potresti essere interessato a rivedere la letteratura sulla tracciabilità del software. In nessun ordine particolare:

• CUBRANICO, D., MURPHY, G. C., SINGER, J., E BOOTH KELLOGG, S. Hipikat: una memoria di progetto per lo sviluppo del software. Transazioni su Software Engineering 31, 6 (2005), 446-65.
• TANG, A., BABAR, M. A., GORTON, I., AND HAN, J. Un'indagine sull'uso e la documentazione del progetto di architettura. In Proc of the 5th Working IEEE / IFIP Conference on Software Architecture (2005).
• RAMESH, B., POTERI, T., STUBBI, C., ED EDITORI, M. Tracciabilità dei requisiti di implementazione: un caso di studio. In Proc of the Int'l Symp on Requirements Engineering (York, 1995).
• HORNER, J., AND ATWOOD, M. E. Motivo logico: la logica e le barriere. In Proc of the 4th Nordic Conference on Human-Computer Interaction: Changing Roles (Oslo, Norvegia, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., AND CLARK, S. Best practice per la tracciabilità automatica. Computer 40, 6 (giugno 2007), 27-35.
• ASUNCION, H., FRANÇOIS, F., AND TAYLOR, R. N. Uno strumento di tracciabilità del software industriale end-to-end. In Proc della sesta riunione congiunta dell'European Software Eng Conf e dell'ACM SIGSOFT Int'l Symp sui fondamenti dell'ingegneria del software (ESEC / FSE) (Dubrovnik, 2007).

Si noti che questa è solo la punta dell'iceberg, e sono sicuro di aver omesso alcuni documenti chiave.

In una nota a parte, il mio lavoro su Arcum era un mezzo per i programmatori di esprimere all'IDE l'uso di idiomi di design 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 di progettazione incrociati . In atti del sesto meeting congiunto della European Engineering Engineering Conference e dell'ACM SIGSOFT Symposium sui fondamenti dell'ingegneria del software (ESEC-FSE '07, 3-7 settembre 2007). 175-184.

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

UML è per un programma quali sono i piani per un edificio nella mia visione humbe. I piani da soli non sono un progetto fuori rotta, avete bisogno di specifiche materiali (strumenti di codice usati) per questo, una visione generale dell'edificio (alcune rappresentazioni schematiche dell'intero software, inclusi i progetti GUI), come l'edificio è piantato nei dintorni (un chiaro schema di come il software interagisce con gli altri / è inserito nel sistema operativo), come si rapporta al clima e al suolo (interazione con l'hardware), ... Un sacco di libri sul design cercano di definirlo, ma come con così 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 ricavare il codice da UML. Puoi, se hai le informazioni aggiuntive menzionate. Ma il vero codice non è più il disegno, questo è l'artefatto. Non puoi estrarre neanche 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.

In questa luce, ho trovato seguente articolo interessante (l'ho incontrato in un contesto diverso quando stavo cercando software grafico, ma comunque ...). L'approccio grafico per descrivere un progetto aveva senso per me, anche se - è vero - questa è solo una parte del design a mio parere. La cosa interessante è che questo approccio fornisce un quadro per comprendere e progettare i refactoring (al contrario del refactoring del software), come indicato nei seguenti documenti:

• Wermelinger and Fiadeiro

• Tsantalis et al

Esistono molti altri approcci per descrivere (parte) il design, come design strutturato ( HIPO Charts) o progettazione del programma integrata , disegni di design , ...

Tuttavia, fino a quando non è impostato uno standard di settore, è improbabile che abbia un modo "regolare" per esprimere ciò. Anche dopo oltre 50 anni. E sii onesto, se la tua azienda trova un buon modo per esprimere un design, lo condivideresti con il mondo?

Dalla mia esperienza personale, direi che siamo in grado di catturare il design del software. Abbiamo un database di requisiti e documenti di progettazione per ogni singola funzionalità 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 del mio team ha una laurea in ingegneria ... per lo più EE o CE. Ingegneria ti insegna a progettare come parte del curriculum.

Penso che ci siano molti cosiddetti software engineer che provengono da sfondi CS. La progettazione del software non è parte integrante della maggior parte dei programmi CS. Non sto dicendo che tutti i maggiori CS sono cattivi al design, ma scommetterei che la maggior parte non ha un'istruzione formale che li abbia insegnati. Penso che molte persone credano che se puoi programmare che puoi progettare software, il che non è vero. Dato che molti programmatori non hanno un background ingegneristico, non sorprende il fatto che molti progetti software non abbiano un team capace di catturare il design.

Vedo due problemi.

Il primo è che è maledettamente difficile mantenere il codice e la documentazione sincronizzati. Se sono separati, divergeranno e la documentazione diventerà inutile. I programmatori hanno provato a utilizzare gli strumenti per fare il lavoro di tenerli sincronizzati (come CASE-tools), ma questi strumenti si sono scambiati tra i programmatori e il loro codice, il che ha causato più danni che benefici. Una delle intuizioni chiave del design basato sul dominio (Evans, 2004) è che un buon design è davvero difficile, quindi per ottenere qualcosa da esso, è necessario:

• scegli l'area più piccola possibile del tuo programma in cui un buon design produrrà grandi benefici, il cosiddetto dominio principale
• lavorare davvero duramente per ottenere un buon design sotto forma di un linguaggio ubiquo che tutti i membri del team usano sempre
• per quanto possibile, crea la parte di design del codice

L'altro grosso problema con il nostro modo di progettare è che i nostri metodi di progettazione non sono abbastanza matematici. Le astrazioni che perdono non si prestano a trarre conclusioni solide da esse, e il mondo della logica strettamente applicata e della verità chiara è chiamato matematica, che i programmatori in genere evitano.

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

Map-reduce è un bell'esempio di matematica nella programmazione. L'idea centrale è questa: quando si dispone di un'operazione binaria associativa, è possibile distribuire 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 Cs possono essere aggiunti banalmente in luoghi diversi, i loro risultati raccolti e riassunti in pochissimo tempo.

Ridurre la mappa è un'idea ridicolmente semplice. Può essere descritto su un pezzo di carta. Se si può presumere che il lettore abbia una ferma comprensione del concetto di associatività, se si adatta su un pezzo di carta piuttosto piccolo. Ora prova a spiegare map-reduce a qualcuno senza usare il termine associatività o riferendoti indirettamente. Ti sfido.

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

Forse Haskell può sistemarlo nel tempo. L'uso di concetti dalla teoria delle categorie per descrivere i programmi mi sembra promettente. La teoria delle categorie è così astratta che persino i matematici hanno avuto poco a che fare con esso, ma apparentemente le categorie, che sono astratte oltre il riconoscimento, sembrano essere abbastanza astratte da descrivere la struttura del software. Lo scopriremo. Lentamente.