Esiste uno standard per documentare l'architettura di alto livello di un programma?


10

Sono uno sviluppatore dilettante e fino ad ora tutti i miei programmi erano abbastanza semplici da essere documentati nel codice. Durante la lettura del codice è stato chiaro cosa stavo facendo così e tale azione (il mio test standard era quello di guardare il codice 6 mesi dopo e capire tutto a prima lettura - e ho una breve durata della memoria).

Ora sto affrontando un programma che sta superando le mie capacità di ricordare le varie interazioni tra

  • il codice stesso
  • gli indici nel database
  • le interazioni tra i vari moduli (codice core "worker" e codice "library")

La mia attuale documentazione è una lavagna in cui ho tutti i tipi di caselle e frecce che puntano a codice, a indici di database, a azioni in esecuzione, a cambiamenti di stato, ecc. Solo per riferimento, un frammento del pasticcio:

inserisci qui la descrizione dell'immagine

La mia domanda è se esiste una serie standard o denominata di migliori pratiche (denominata nel senso che si tratta di una serie di pratiche raggruppate con un nome specifico) per la documentazione di prodotti più complessi.

Quali sono le parole chiave che dovrei cercare (tentativi generali di "documentare gli standard di architettura del software" e variazioni simili di solito hanno portato a software per flussi di lavoro o sistemi CAD di architettura di edifici).

Mi aspetto anche che non esistano buone pratiche generali per le descrizioni di alto livello e che ognuno costruisca la propria filosofia.


um UML e qualche semplice vecchio testo di solito
jk.

Se riesci a leggere il tedesco, dai un'occhiata a arc42.de/template/index.html Mostrano alcune linee guida per documentare l'architettura del software.
Bernhard Hiller,

8
"Non preoccuparsi di farlo" è probabilmente il più vicino a uno standard.
whatsisname

Risposte:


13

Non esiste uno standard a cui tutti aderiscono. I progetti software possono variare notevolmente (pensate a: helloworld.py rispetto al codice nello space shuttle).

Un metodo molto comune è utilizzare il modello 4 + 1 . Invece di provare a raggruppare tutto in un unico stile di documento, questa metodologia suddivide il progetto in cinque componenti:

  • La vista Sviluppo
  • Il Logical vista
  • La visione fisica
  • Il processo di visualizzazione
  • scenari

Le varie viste descrivono il prodotto da quattro diverse prospettive. Gli scenari sono dove vivono i casi d'uso e descrivono l'interazione delle altre viste.

Nota: questo è un modello concettuale e non è legato a nessuno strumento specifico.

Puoi leggere di più qui:

  1. 4 + 1 modello di vista architettonica (wikipedia)
  2. Progetti architettonici: il modello di architettura software “4 + 1” (documento IEEE - pdf)

Questo è un ottimo approccio, grazie. Facendo un passo indietro, si potrebbe pensare che sia abbastanza ovvio, ma aiuta molto a disconnettere i vari pezzi 4 + 1 che ho avuto tutti su un grafico.
WoJ,

4

IMHO UML non è uno strumento che funziona bene per documentare l'architettura del software del mondo reale. I diagrammi di classe sono utili, ma usano un livello di astrazione che è spesso troppo basso per questo scopo. I diagrammi dei casi d'uso sono in genere troppo "di alto livello" e mancano alcuni aspetti. Altri tipi di diagrammi UML hanno problemi simili (ad essere onesti, diagrammi di pacchetto, diagrammi di distribuzione, diagrammi di componenti possono documentare alcuni aspetti architetturali, ma personalmente non li ho mai trovati molto utili).

Se stai cercando un modo pratico e pragmatico di documentare architetture di alto livello, ti suggerisco di familiarizzare con i diagrammi di flusso dei dati . Questi sono facili da capire e hanno il vantaggio di poter scalare a diversi livelli di astrazioni. Li ho trovati più utili per documentare diversi tipi di sistemi. Peccato che non abbiano trovato la loro strada in UML, ma in fondo trovi molti strumenti - anche gratuiti come Dia o DrawIO - per realizzare questi diagrammi.

Come nota a margine, perché sono necessari "indici nel database" in una documentazione di alto livello? Penso che siano un dettaglio di implementazione del tuo modello di dati (relazionale?), E se li aggiungi o meno è - per la mia esperienza - più una questione di prestazioni e ottimizzazione.


Diagrammi del pacchetto? Diagrammi di distribuzione? Diagrammi dei componenti?
Nick Keighley,

3
Onestamente un gruppo di scatole con le frecce può fare miracoli per comunicare una serie di caratteristiche di design. Immagino che i diagrammi dei componenti rientrino in quella categoria, ma i miei clienti comprendono il flusso di dati con caselle che rappresentano i bit principali. Sono d'accordo con Doc Brown. La formalità di UML manca il segno con lo scopo previsto.
Berin Loritsch,

@NickKeighley: guarda la mia modifica.
Doc Brown,

@BerinLoritsch: IMHO "un gruppo di scatole con frecce" caratterizza i tipi di diagramma menzionati da Nick Keighley. I diagrammi del flusso di dati, tuttavia, fanno una chiara distinzione formale tra dati o gruppi / cluster di dati e processi o componenti che trasferiscono o trasformano questi dati. Questo non è niente che io possa esprimere facilmente con qualsiasi diagramma UML.
Doc Brown,

1
Devo ammettere che a volte ricorrere ai diagrammi del flusso di dati, in particolare quelli che consentono i negozi. In effetti il ​​diagramma di livello superiore che descrive il nostro sistema è essenzialmente un DFD. Trovo ancora utili i diagrammi di classe e il pacchetto in una certa misura. Non prendo molta attenzione alle parti "formali" di UML.
Nick Keighley,

0

Unified Modeling Language (UML) è un linguaggio di modellazione generale, evolutivo, nel campo dell'ingegneria del software, che ha lo scopo di fornire un modo standard per visualizzare la progettazione di un sistema.


Le specifiche formali sono disponibili su omg.org/spec/UML/2.5 ma ci sono molti tutorial più amichevoli sul web.
Simon B,

2
Questa risposta è solo una parte della domanda, UML è sicuramente lo strumento giusto per modellizzare, ma questo non costituisce da solo una documentazione completa
Walfrat,

3
Qualcuno usa UML molto spesso?
Panzercrisis,

scarabocchiare. ingegneria inversa.
Nick Keighley,

1
@Walfrat. è? Veramente? Ho i miei dubbi.
Doc Brown,

-3

Penso che avremmo fatto di meglio. UML sembrava buttare il bambino fuori con acqua da bagno. Nel fornire un linguaggio di modellazione unificato ha abolito la distinzione tra architettura e implementazione. O se non intendesse questo sembrava avere effetto.

Ho visto alcuni modelli UML mostruosi e francamente non fanno nulla per me che il codice non potrebbe fare, e lo fanno meglio.


3
non risponde alla domanda, probabilmente meglio come commento alla risposta di SuperGirl.
Newtopian,

1
Affronta la domanda. Sto sostenendo che la risposta alla domanda è più "No" di prima.
Nick Keighley,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.