Prodotto di lavoro
|
Scopo
|
Personalizzazione (facoltativo, consigliata)
|
Modello di analisi (Classe di analisi)
|
Un modello di analisi consente di comprendere meglio i requisiti prima di decidere sul progetto. In
sistemi complessi può essere utilizzato per offrire una panoramica concettuale sul sistema stesso.
|
Facoltativo
Numerosi progetti si servono inizialmente di un Modello di progettazione invece di un Modello di
analisi.
I modelli di analisi che vengono creati in un progetto sono di solito artefatti temporanei, che
evolvono in modelli di progettazione.
|
Mappa di esplorazione, Prototipo dell'interfaccia utente
|
Progetti con interfacce utente grandi e complesse devono attuare la progettazione dell'interfaccia
utente.
|
Facoltativo
Progettazioni dell'interfaccia utente più informali possono bastare nel caso di uno sviluppo meno
impegnativo.
|
Modello di progettazione
|
La maggior parte dei sistemi, anche i più piccoli, devono essere progettati prima di essere
implementati per evitare rilavorazioni costose imputabili ad errori nel progetto. I modelli visivi
facilitano le comunicazioni sul progetto. I tool per il forward engineering e reverse engineering
possono garantire uniformità con il modello di implementazione e risparmiare impegno.
|
Consigliato per la maggior parte dei progetti.
In progetti di dimensioni ridotte, l'uso di tool automatizzati non è critico, anche se può offrire
vantaggi nella produttività a lungo termine.
|
Classe di progettazione; Pacchetto di progettazione
|
Le classi e i pacchetti sono componenti base per qualsiasi progetto orientato agli oggetti. La
progettazione orientata agli oggetti rappresenta l'approccio di progettazione standard, utilizzato
nella maggior parte dei progetti.
|
Consigliato per la maggior parte dei progetti.
Le problematiche principali per la personalizzazione vertono essenzialmente sulla decisione degli
stereotipi da utilizzare, che possono essere catturati nelle linee guida della progettazione.
|
Realizzazione di caso d'uso
|
Offrire un ponte per collegare casi d'uso e progetto.
|
Consigliato per la maggior parte dei progetti.
|
Interfaccia
|
Le interfacce sono utilizzate di solito per definire il comportamento indipendentemente dai componenti
a grana grossa che realizzano il comportamento stesso.
|
Consigliato per la maggior parte dei progetti.
La progettazione basata su componenti sta assumendo anch'essa il ruolo di progettazione standard.
|
Sottosistema di progettazione
|
I sottosistemi di progettazione consentono di incapsulare il comportamento in un componente che
fornisce le interfacce, a sua volta utilizzato per incapsulare le interazioni tra classi e/o altri
sottosistemi.
|
Consigliato per la maggior parte dei progetti.
I sottosistemi sono spesso utili per aumentare il livello di astrazione del progetto. Rendono i
sistemi più comprensibili.
|
Evento
|
Utile nei casi in cui i sistemi devono rispondere a molti eventi esterni.
|
Consigliata per i sistemi real-time.
|
Protocollo
|
Richiesto per i sistemi real-time.
|
Consigliata per i sistemi real-time.
|
Segnale
|
Utile nei casi in cui i sistemi richiedono simultaneità e sono basati su eventi.
Richiesto per i sistemi real-time.
|
Utile nei casi in cui i sistemi richiedono simultaneità e sono basati su eventi.
Consigliata per i sistemi real-time.
|
Capsula
|
Consigliata per i sistemi real-time, anche se può risultare utile nella modellazione e progettazione di
un qualsiasi sistema ad elevato grado di simultaneità.
|
Consigliata per i sistemi real-time.
|
Modello di dati
|
Utilizzato per descrivere la struttura logica e possibilmente fisica delle informazioni permanenti.
|
Consigliata per i progetti che utilizzano un database.
|
Modello di distribuzione
|
Mostra la configurazione dei nodi di elaborazione al run-time, i collegamenti tra gli stessi e le
istanze e gli oggetti del componente che in essi risiede.
|
Facoltativo.
Numerosi sistemi sono dotati di più nodi di elaborazione e pertanto devono utilizzare il Modello di
distribuzione, che può essere catturato, tuttavia, come una sezione del Documento dell'architettura
software e non esiste come artefatto identificato indipendentemente.
|
Proof of concept strutturale
|
Utilizzato per determinare se esiste una soluzione che soddisfa i requisiti significativi in termini
strutturali.
|
Consigliato per la maggior parte dei progetti.
Molti progetti usano Proof of concept strutturale per determinare la praticabilità dei requisiti.
Può assumere vari formati, ad esempio:
-
un elenco di tecnologie note che sembrano appropriate per la soluzione
-
uno sketch di un modello concettuale di una soluzione
-
una simulazione di una soluzione
-
un prototipo eseguibile.
|
Architettura di riferimento
|
L'architettura di riferimento accelera lo sviluppo e riduce i rischi riutilizzando soluzioni
comprovate.
|
Consigliato per la maggior parte dei progetti.
Se esiste materiale che si adatta all'architettura di riferimento, è possibile ridurre
drasticamente i tempi di sviluppo e i rischi.
|
Documento dell'architettura software (SAD)
|
Il Documento dell'architettura software ha l'intento di offrire una panoramica completa
dell'architettura del sistema. Questa panoramica è utile per comprendere il sistema e catturare le
decisioni chiave dell'architettura.
|
Consigliato per la maggior parte dei progetti.
Una panoramica ad alto livello dell'architettura software è utile per tutti i sistemi, tranne nei
casi di sistemi più piccoli. I sistemi complessi richiedono in genere un livello di dettaglio più
ampio e più viste rispetto ai progetti più piccoli.
|
Prototipo dell'interfaccia utente
|
Utilizzato per illustrare e verificare la funzionalità e utilizzabilità prima di avviare lo sviluppo
vero e proprio. È uno strumento efficace per convalidare il progetto prima di incorrere in lungaggini.
|
Consigliato per la maggior parte dei progetti.
|