In questo momento, sto cercando di apprendere un'ingegneria del software ben documentata. Sapevo che se codifichiamo usando il concetto di Object Oriented, possiamo fare il concetto di design del software usando UML. Ma cosa succede se codifichiamo usando la programmazione procedurale, come facciamo la progettazione del software? per quanto ne so, UML è per OOP.
E hai qualche riferimento in internet? Si prega di consigli e correggere me se ho sbagliato su UML.
leggi codice completo, seconda edizione . Ha molti consigli sulla progettazione del software e quasi tutti sono molto, molto applicabili al codice procedurale. (L'edizione originale del libro è uscita prima che il codice OO fosse popolare.)
UML non è solo per OOP. La modularità e la separazione delle preoccupazioni entrano in gioco in qualsiasi sistema su larga scala e non importa se il tuo linguaggio rientra nel paradigma procedurale, funzionale, dichiarativo o orientato agli oggetti. Non c'è motivo per cui non puoi adattare i concetti e i diagrammi di UML per documentare il software che stai sviluppando.
Alcuni concetti come la generalizzazione e la realizzazione in un diagramma di classe potrebbero non avere senso, ma un modulo di "classe" potrebbe essere usato per rappresentare un'altra unità di compilazione. I diagrammi degli oggetti nel loro insieme potrebbero non avere senso. Ma i diagrammi di distribuzione, componente, attività, stato, caso d'uso, sequenza e temporizzazione avrebbero senso al di fuori di un ambiente orientato agli oggetti.
UML ti fornisce un linguaggio comune e una serie di simboli per la modellazione. Finché esiste una mappatura tra la lingua di destinazione e il set di simboli utilizzati, è possibile utilizzare UML e io lo supporterei poiché renderebbe molto più semplice la comunicazione del tuo progetto. Se un determinato concetto (e quindi un certo simbolo) non ha senso nella tua lingua, assicurati di non usarlo.
Non esiste una linea ben marcata tra OOP e procedurale. Solo dicendo, c'è un numero di persone (le API GTK abituate a IIRC) che mappano OOP su linguaggi procedurali .
E poi c'è una maggioranza silenziosa che si sviluppa in modo incrementale partendo da un main () , aggiungendo oggetti come sembrano adatti, usandoli come strumenti e non come Idee platoniche . Quando le cose diventano troppo grandi da gestire, scrivono classi e diagrammi come fanno tutti.
Inoltre, c'è ancora qualche grande design prima di finalizzare il contratto nell'ingegneria del software, quindi potresti chiederti come le prime aziende procedurali possano gestirlo. Prima di tutto ci sono non molte di quelle aziende, poiché è più difficile suddividere le attività senza oggetti.
Allora, sai, là dove molti. Hanno usato i diagrammi controllo flusso . Con diamanti e rettangoli e roba. Al giorno d'oggi potevano usare statecharts e, nelle interazioni di protocollo su rete o inter-processo, < strong> diagrammi di sequenza .
Leggi altre domande sui tag design object-oriented-design modeling