Come modellare i componenti di un sistema non informativo?

Quindi, perché non usi UML per costruire un diagramma di componenti o anche un diagramma di pacchetti? Se ho capito bene, vuoi una visione a volo d'uccello dell'intera architettura ed è per questo che non hai bisogno di un diagramma di classe, giusto?

Immagino che potresti anche guardare a SysML che può fornire un approccio più orientato ai sistemi.

Tutti i documenti che hai descritto funzioneranno per descrivere il tuo sistema dalle prospettive che catturano.

Un diagramma di classe serve per mostrare la struttura del tuo progetto senza che ha bisogno di vedere il codice, il fatto che il tuo codice sia molto strutturato è irrilevante.

Un DFD non ha bisogno di avere un archivio dati elencato, non tutti i sistemi memorizzano i dati, ma è comunque importante mappare come i dati fluiscono attraverso il sistema anche se i dati lasciano il sistema come condizione finale.

L'UML è probabilmente una delle poche lingue che supporta solo un paradigma: un paradigma OO; questo è il motivo per cui non puoi semplicemente esprimere qualcosa come interfacce, l'UML non può calcolare la tua richiesta.

Secondo me le radici di una buona documentazione su un progetto sono:

• un elenco di tutti i typedef utilizzati
• un elenco di tipi se la lingua è OO
• un elenco di tutte le interfacce
• un elenco di tutti i modelli, se necessario (se supportato dalla lingua)
• se il design è OO, l'UML può essere considerato ok solo per esprimere l'attività delle tue classi.

solo con interfacce e tipi / typedef puoi dire molto sul tuo progetto.

Un diagramma coinvolge anche i concetti di "relazione" e / o "flusso", il problema è che non sembra essere chiaro quale paradigma stai usando nella tua applicazione.

C ha lo scopo di supportare un paradigma di programmazione procedurale e strutturato, un diagramma non ha molto senso secondo me perché finirai con una serie di caselle e frecce uno dopo l'altro, in pratica dovrai riscrivere il codice in un diagramma di flusso senza descrivere alcuna logica e, la parte più importante, senza avere la possibilità di astrarre così tanto.

Come ha detto @Astyanax, i diagrammi di componenti e pacchetti UML sono generalmente utili anche in sistemi non OO. I diagrammi di transizione dello stato sono un'altra forma che sono comunemente visti a livello di sistema. Mi piace molto anche l'idea dei DFD, anche se non hai datastore: li ho sempre trovati abbastanza accessibili sia per gli utenti tecnici che per quelli non tecnici (non devi conoscere tutta la semantica di " riempito di diamanti "vs" diamanti non riempiti "ecc.)

Posso condividere la mia esperienza personale .

Ho progettato molti sistemi in diversi ambienti (il più grave è il framework di alcuni sistemi governativi di gestione dei dati agricoli), sia backend che frontend. Ho provato a utilizzare UML molte volte (Rose, Enterprise Architect e ArgoUML), ma non sono riuscito con la stessa ragione del tuo. La notazione UML è troppo limitante e invece di permettermi di esprimere e perfezionare le mie idee in un modo facile da condividere, ha cercato di forzare il mio pensiero nei suoi termini e ho trascorso tutto il mio tempo nella ricerca del miglior tipo di diagramma. E comunque, non solo avrei dovuto passare un sacco di tempo ad APPRENDERE quella roba, i risultati sarebbero leggibili solo per coloro che hanno imparato lo stesso ...

Quindi il mio risultato è: cestino UML e trovare un buon software per la creazione di grafici! I miei punti di attenzione nella selezione: prima di tutto: disegnare linee intelligenti, etichettate che seguono le forme, e dovrebbe anche consentire una facile riorganizzazione, colorazione, una biblioteca di belle forme. Anche il tuo pubblico lo amerà. In questo momento ho trovato gliffy.com, forse un po 'troppo semplice, ma "abbastanza buono" strumento per i miei bisogni attuali, e anche mio figlio può usarlo :-) Ma ce ne sono molti altri di questo genere.

Passa il tuo tempo prezioso a disegnare liberamente le tue idee e crea una notazione semplice e coerente (forma, colore, linea, codifica del testo) che puoi spiegare in un minuto - ed esprimi che NON è UML. Per me, funziona molto meglio del santo UML in realtà , almeno con i miei colleghi e il pubblico.

E hey, posso scrivere un codice migliore di quello che genera uno strumento UML, e NON userò MAI il codice generato e aggiornato in un sistema reale (solo se scrivo quello strumento, che è nel mio ambito a lungo termine :-) ).