Quali metodologie, processi e strumenti sono disponibili per la progettazione e la modellazione di applicazioni non orientate agli oggetti?

Question

Conosco abbastanza bene UML per la modellazione di applicazioni orientate agli oggetti. Tuttavia, non ho familiarità con nulla di specificamente progettato per progettare e / o modellare procedurali, funzionali o qualsiasi altro paradigma. Come progettate o modellizzate applicazioni scritte in un linguaggio non orientato agli oggetti?

Answer 1

Oh goloso, c'è un tuffo nel passato.

Usavamo diagrammi di flusso , pseudocode , diagrammi di flusso di dati , grafici della struttura , Hierarchy-IPO , " diagrammi appendiabiti " (che in realtà sono una variante dei diagrammi di flusso), diagrammi di Nassi-Schneiderman . Tra gli altri.

Oh, SADT è un altro.

Answer 2

SSADM - Penso di avere ancora la mia certificazione in una scatola da qualche parte .. .

Answer 3

UML può essere utilizzato anche per la modellazione di linguaggi non OO. Uso UML per modellare praticamente qualsiasi cosa. Ad essere onesti, il nucleo di UML è focalizzato sull'OO, ma gran parte del comportamento, a livello di istanza e tipi strutturali meno comuni funzionano per linguaggi non OO. Tuttavia, UML è per la progettazione in OO e non per l'implementazione, i tuoi blocchi / oggetti sono solo diversi, moduli o quant'altro.

Molti dei tipi di diagramma menzionati da Charlie Martin hanno rappresentazioni UML analoghe. Ancora meglio è un modello non solo un diagramma / vista.

Esempio: LISP non è basato su OO. Quindi crea una parola chiave o un tipo stereo per le classi che sono funzioni. Gli attributi sono gli argomenti in quanto non ha stato. Questo non è perfetto, ma è il più accessibile.

Esempio: COBOL / JCL non è basato su OO. Ogni pacchetto PACBASE deve essere un componente e avere componenti strutturali come COBOL. Gli artefatti possono essere il tuo JCL.

Lascia che il fatto che UML sia ampio e vagamente definito a tuo vantaggio e riutilizzi le parti UML. Puoi sempre formalizzarlo con un profilo UML. Dove lavoro questo è stato un punto di discussione per qualche tempo. I programmatori di mainframe non vedono la progettazione di OO e OO-UML come pertinenti, ma è solo parzialmente vero in quanto il nucleo o quanto la maggior parte della gente va con esso è solo per le cose di classe / strutturali e casi d'uso, che è focalizzato su OO.