Progettazione software per paradigmi non orientati agli oggetti

Anche per un sistema che non è progettato secondo il paradigma OO, puoi ancora utilizzare la notazione UML per documentare il sistema, eventualmente estesa con alcuni Diagrammi del flusso di dati (dato che non riesco a trovare immediatamente un diagramma corrispondente in UML). I diagrammi che vale la pena esaminare, anche per i sistemi non OO sono:

• Diagrammi di stato (transizione)
• Utilizza i diagrammi dei casi
• Diagrammi di sequenza

Quando modellizzi un sistema non OO, potresti dover essere un po 'flessibile rispetto a ciò che modesti come una "classe".

Ad esempio, se hai un file di intestazione stack.h come questo

struct stack;
struct stack* stack_create(void);
void stack_destroy(struct stack*);
void stack_push(struct stack*, void*);
void stack_pop(struct stack*);
void* stack_top(struct stack*);

con l'implementazione corrispondente, non c'è niente che ti impedisca di presentarlo come uno stack di classe nei tuoi modelli.

Puoi creare una progettazione orientata agli oggetti e implementarla in C, anche se C non supporta direttamente concetti orientati agli oggetti.

Vedi ad esempio Rumbaugh et al., "Modellazione e progettazione orientata agli oggetti", Capitolo 16, Prentice-Hall 1991, ISBN 0-13-629841-9.

Fai lo stesso design solo con moduli concettuali (come avresti dovuto fare in design OO) piuttosto che in classi esplicite. In C, quei moduli tendono ad essere funzioni, strutture o un insieme di funzioni, strutture o entrambi.