Diagrammi UML per descrivere come una nuova funzionalità avrà un impatto / un impatto su un sistema esistente?

Il documento di ingegneria del software che descrive le modifiche necessarie per implementare la nuova funzionalità il concetto tecnico. Puoi trovare diversi modelli sulla rete. Uno di questi è il modello di arc42 . Se questo è troppo grande per te, contiene anche un (sotto) modello solo per concetti.

Non c'è uno schema UML speciale. Puoi usare uno qualsiasi dei Diagrammi esistenti e usare diverse rappresentazioni degli elementi come usare colori diversi per vecchi nuovi, modificati, nuovi componenti e / o comportamenti. Se questo non è abbastanza, puoi lavorare con diversi stereotipi o persino definire il tuo metamodello che è un argomento avanzato e forse eccessivo.

Non ci sono diagrammi UML focalizzati sulle modifiche: tutti i diversi diagrammi sono pensati per mostrare la situazione desiderata (o effettiva).

Tuttavia, anche se non disponi di modelli aggiornati, puoi iniziare a utilizzare UML per mostrare i punti salienti della modifica. Ad esempio:

• un schema dei casi d'uso : mostrerai un attore secondario coinvolto nell'uso dei login- caso (cioè il provider di identità openID). Potresti anche mostrare i casi d'uso ridondanti e fare un'anatazione per chiarire che saranno discussi.
• un diagramma di sequenza : questo ti aiuterà a rappresentare le interazioni con il provider di identità per le interazioni è coinvolto in
• a diagramma di classe : puoi limitare questo diagramma alle classi relative all'identità (modello di dominio) e le classi coinvolte nel processo di login (modello di progettazione).
• un'altra opzione meno utilizzata, ma potenzialmente molto utile qui, è un schema dei pacchetti . Il vantaggio consiste nel darti una panoramica delle dipendenze tra i pacchetti e quindi aiutarti ad analizzare come la modifica openId potrebbe propagarsi attraverso il sistema.

Questo reverse engineering limitato è ovviamente uno sforzo, ma può aiutare all'inizio del progetto ad analizzare ciò che è coinvolto, e quindi identificare e capire meglio il lavoro che dovrà essere fatto. Ma in quanto tale, UML non ti fornirà alcuna stima.

Come è stato menzionato nelle risposte precedenti, gli UML non sono particolarmente adatti a descrivere i cambiamenti. Potremmo proiettare il nuovo modello su quello attuale e prevedere l'impatto sulla base del codice, ma presumo che il risultato sarebbe una raccolta di diagrammi difficili da leggere da parte di persone che non hanno familiarità con la lingua.

Tuttavia, potrebbe interessarti un altro tipo di documentazione. Ad esempio, Matrice di tracciabilità .

Potremmo incrociare i requisiti effettivi (oi casi d'uso) con le nuove funzionalità e determinare l'impatto delle nuove funzionalità su quelle esistenti e il peso di ogni cambiamento.

In progetti di grandi dimensioni con innumerevoli casi d'uso e requisiti potrebbe essere difficile disegnare la matrice, ma possiamo restringere solo a quei "contesti limitati" del sistema che presumiamo siano direttamente coinvolti con le modifiche ed espandere la matrice come l'analisi avanza.

Ultimamente, quando la matrice è terminata, potremmo scegliere quelle modifiche che hanno avuto un impatto maggiore sul sistema e descrivere testualmente la natura delle modifiche.

Infine, se consideriamo che gli UML siano necessari, possiamo tradurre la letteratura precedente in diagrammi.

Potresti usare le nozioni di diff (colori) all'interno di diagrammi UML-as-a-sketch (forse alcuni strumenti lo supportano?). L'ho fatto con i diagrammi Use Case (il diagramma è in francese, ma il verde è nuovo una nuova funzione, il blu è cambiato, il giallo esiste):

Nelmioesempio(cheprovienedaun progetto GitHub ) non c'erano funzionalità rimosse (ridondanti), ma potevi fallo con strikethrough nel diagramma e / o con Use Cases di colore rosso.