Prodotto di lavoro: Architettura di riferimento
Questo prodotto di lavoro è, in sintesi, un pattern strutturale predefinito, o un insieme di pattern, probabilmente parzialmente o completamente istanziato, progettato e comprovato per essere utilizzato in particolari contesti tecnici e di business, con degli artefatti di supporto che ne abilitano l'uso.
Scopo

I prodotti di lavoro dell'architettura di riferimento fanno parte di una base di risorse riutilizzabili di un'organizzazione. Il loro scopo è di formare un punto di inizio per lo sviluppo strutturale. Possono variare da pattern strutturali, meccanismi strutturali e framework già pronti, a sistemi completi, con caratteristiche note, comprovate nell'utilizzo. Possono essere applicabili in generale o per un'ampia classe di sistemi che si espande nei domini, o con un ambito più ristretto, specifico per dominio.

L'utilizzo di architetture di riferimento testate è un metodo efficace per risolvere molti requisiti non funzionali, particolarmente i requisiti di qualità, selezionando le architetture di riferimento esistenti, di cui è noto, attraverso l'utilizzo, che soddisfano quei requisiti. Le architetture di riferimento possono esistere o essere utilizzate su diversi livelli di astrazione e da diversi punti di vista. Corrispondono alle viste 4+1 (consultare "Un tipico insieme di viste strutturali"). In questo modo, l'architetto di software può selezionare ciò che si adatta meglio (solo progettazione strutturale o progettazione ed implementazione, in vari gradi di completamento). 

Spesso un'architettura di riferimento viene definita in modo da non includere istanze dei componenti che verranno utilizzati per creare il sistema (se le include diviene un'architettura della linea di prodotti) ma non si tratta di una distinzione forte e rapida. In RUP (Rational Unified Process), la nozione di architettura di riferimento include riferimenti a componenti riutilizzabili esistenti (cioè le implementazioni).

Relazioni
RuoliResponsabile: Modificato da:
Input inObbligatorio:
  • Nessuno
Facoltativo: Esterno:
  • Nessuno
Output di
Descrizione
Breve profilo

Organizzazione delle risorse

L'organizzazione che detiene la proprietà delle risorse dell'architettura di riferimento deve decidere come devono essere classificate ed organizzate le risorse per un facile recupero da parte dell'architetto di software, soddisfando dei criteri di selezione del nuovo sistema. Anche se la creazione e la memorizzazione dell'architettura di riferimento al momento è esterna all'ambito di RUP, un suggerimento è di organizzare le architetture intorno all'idea di domini, dove per dominio si intende un'area di argomento che definisce i concetti di qualche aspetto di un sistema, o una famiglia di sistemi. Qui è consentito l'uso del termine 'dominio' ad un livello inferiore a quello dell'applicazione. Questo utilizzo differisce leggermente da alcune definizioni (ad esempio, quelle presentate in [HOF99]) ma si allineano bene con quelle in [LMFS96]:

"Dominio della linea di prodotti: un gruppo unito di capacità - attuali e/o future - definito per semplificare la comunicazione, l'analisi e la progettazione con l'obiettivo di identificare, progettare e gestire l'accomunanza di una linea di prodotti. Questi domini possono includere gruppi strettamente correlati di sistemi di utenti, funzioni comunemente utilizzate in più sistemi o raggruppamenti di servizi sottostanti largamente applicabili".

Questa definizione include la nozione che gli elementi utilizzati per comporre dei sistemi possono essi stessi appartenere ad un dominio che vale la pena di essere studiato di per sé. La figura riportata di seguito, proveniente da [LMFS96], illustra questo principio.

Domini orizzontali e verticali dell'esercito americano

Domini orizzontali e verticali dell'esercito americano

La figura mostra le principali famiglie di sistemi, sistemi di informazione, comando e controllo e sistemi di armamento, ognuno con dei domini verticali completamente indipendenti e domini orizzontali che li attraversano e che attraversano anche famiglie di sistemi. Quindi, i concetti di pianificazione in tempo reale sono applicabili al dominio tattico di Comando e controllo, e a tutti i domini dei sistemi di armamenti. Probabilmente quindi ha senso risolvere i problemi di pianificazione in tempo reale una sola volta per tutti i domini, e considerare come dominio separato la conoscenza e le risorse sviluppate, che avrà poi un'associazione a, per esempio, Electronic Warfare, ma non al sistema delle informazioni sul personale.

Contenuto

L'architettura di riferimento ha lo stesso formato del Prodotto di lavoro: Documento dell'architettura software e dei modelli associati, senza i riferimenti specifici del progetto, oppure con i riferimenti e le caratteristiche del progetto generalizzati, in modo che l'architettura di riferimento possa essere classificata in maniera appropriata nella base delle risorse. I tipici modelli associati al SAD (Software Architecture Document, Documento dell'architettura software) sono il Modello di casi d'uso, il Modello di progettazione, il Modello di implementazione ed il Modello di distribuzione.

L'accesso al SAD ed ai modelli associati fornisce diversi punti di ingresso all'architetto di software, che può scegliere di utilizzare solo le parti concettuali o logiche dell'architettura (se i criteri di riutilizzo dell'organizzazione lo consentono). All'altro estremo, l'architetto di software può prendere dalla base di risorse dei completi sottosistemi funzionanti ed un modello di distribuzione a livello fisico (vale a dire, un piano hardware e di rete completo).

Per rendere le risorse strutturali riutilizzabili sono necessari altri prodotti di lavoro di supporto.  

  1. Il modello di casi d'uso descrive il comportamento dell'architettura ma l'architetto di software deve anche conoscere le sue qualità non funzionali. Questi - il modello di casi d'uso e i requisiti non funzionali - potrebbero essere stati catturati in precedenza in una specifica di requisiti software. Da questo l'architetto di software sarà in grado di determinare in che misura l'architettura di riferimento soddisfa i requisiti correnti.

  2. L'utilizzo, e più particolarmente, la modifica dell'architettura necessita della stessa guida dello sviluppo originale. Ad esempio, l'architetto di software deve sapere quali regole sono state applicate durante la formazione dell'architettura di riferimento e quanto è difficile modificare le interfacce. L'accesso alle linee guida di progettazione associate all'architettura di riferimento può essere utile per fornire le risposte a queste domande.

  3. (Facoltativo) Anche visionare eventuali piani di test pertinenti esistenti può essere utile. I piani di test informeranno l'architetto sulle strategie di test e di valutazione precedentemente utilizzate per testare architetture simili, fornendo quindi una visione delle potenziali debolezze nell'architettura.

  4. (Facoltativo) Può essere utile visionare le eventuali pertinenti architetture di automazione di test e le specifiche di interfaccia esistenti. Questi prodotti di lavoro informano l'architetto sulle richieste che possono essere effettuate all'architettura per semplificare la fase di verifica.

Descrizione principale

Organizzazione delle risorse

L'organizzazione che detiene la proprietà delle risorse dell'architettura di riferimento deve decidere come devono essere classificate ed organizzate le risorse per un facile recupero da parte dell'architetto di software, soddisfando dei criteri di selezione del nuovo sistema. Anche se la creazione e la memorizzazione delle architetture di riferimento attualmente è esterna all'ambito RUP, un suggerimento è di organizzare le architetture intorno all'idea di Definizione del termine: dominio, dove un dominio è un'area di un argomento che definisce la conoscenza e i concetti di qualche aspetto di un sistema, o una famiglia di sistemi. Qui è consentito l'uso del termine 'dominio' ad un livello inferiore a quello dell'applicazione. Questo utilizzo differisce leggermente da alcune definizioni - ad esempio, quelle presentate in [HOF99] - ma si allinea bene con quelle presentate in [LMFS96]:

"Dominio della linea di prodotti: un gruppo unito di capacità - attuali e/o future - definito per semplificare la comunicazione, l'analisi e la progettazione con l'obiettivo di identificare, progettare e gestire l'accomunanza di una linea di prodotti. Questi domini possono includere gruppi strettamente correlati di sistemi di utenti, funzioni comunemente utilizzate in più sistemi o raggruppamenti di servizi sottostanti largamente applicabili".

Questa definizione include la nozione che gli elementi utilizzati per comporre dei sistemi possono essi stessi appartenere ad un dominio che vale la pena di essere studiato di per sé. La figura riportata di seguito, proveniente da [LMFS96], illustra questo principio.

Domini orizzontali e verticali dell'esercito americano

Domini orizzontali e verticali dell'esercito americano

La figura mostra le principali famiglie di sistemi, sistemi di informazione, comando e controllo e sistemi di armamento, ognuno con dei domini verticali completamente indipendenti e domini orizzontali che li attraversano e che attraversano anche famiglie di sistemi. Quindi, i concetti di pianificazione in tempo reale sono applicabili al dominio tattico di Comando e controllo, e a tutti i domini dei sistemi di armamenti. Probabilmente quindi ha senso risolvere i problemi di pianificazione in tempo reale una sola volta per tutti i domini, e considerare come dominio separato la conoscenza e le risorse sviluppate, che avrà poi un'associazione a, per esempio, Electronic Warfare, ma non al sistema delle informazioni sul personale.

Contenuto

L'architettura di riferimento ha lo stesso formato del Prodotto di lavoro: Documento dell'architettura software e dei modelli associati, senza i riferimenti specifici del progetto, oppure con i riferimenti e le caratteristiche del progetto generalizzati, in modo che l'architettura di riferimento possa essere classificata in maniera appropriata nella base delle risorse. I tipici modelli associati al SAD (Software Architecture Document, Documento dell'architettura software) sono il Modello di casi d'uso, il Modello di progettazione, il Modello di implementazione ed il Modello di distribuzione.

L'accesso al SAD ed ai modelli associati fornisce diversi punti di ingresso all'architetto di software, che può scegliere di utilizzare solo le parti concettuali o logiche dell'architettura (se i criteri di riutilizzo dell'organizzazione lo consentono). All'altro estremo, l'architetto di software può prendere dalla base di risorse dei completi sottosistemi funzionanti ed un modello di distribuzione a livello fisico (vale a dire, un piano hardware e di rete completo).

Per rendere le risorse strutturali riutilizzabili sono necessari altri artefatti di supporto.  

  1. Il modello di casi d'uso descrive il comportamento dell'architettura ma l'architetto di software deve anche conoscere le sue qualità non funzionali. Essi - il modello di casi d'uso e i requisiti non funzionali - potrebbero essere stati catturati in precedenza in una specifica di requisiti software. Da questo l'architetto di software sarà in grado di determinare in che misura l'architettura di riferimento soddisfa i requisiti correnti.

  2. L'utilizzo, e più particolarmente, la modifica dell'architettura necessita della stessa guida dello sviluppo originale. Ad esempio, l'architetto di software deve sapere quali regole sono state applicate durante la formazione dell'architettura di riferimento e quanto è difficile modificare le interfacce. L'accesso alle linee guida di progettazione associate all'architettura di riferimento può essere utile per fornire le risposte a queste domande.

  3. (Facoltativo) Anche visionare eventuali piani di test pertinenti esistenti può essere utile. I piani di test informeranno l'architetto sulle strategie di test e di valutazione precedentemente utilizzate per testare architetture simili, fornendo quindi una visione delle potenziali debolezze nell'architettura.

  4. (Facoltativo) Può essere utile visionare le eventuali pertinenti architetture di automazione di test e le specifiche di interfaccia esistenti. Questi artefatti informano l'architetto sulle richieste che possono essere effettuate all'architettura per semplificare la fase di verifica.

Proprietà
Facoltativo
PianificatoYes
Personalizzazione
Opzioni di rappresentazioneRappresentazione UML: diverse viste strutturali pertinenti: Caso d'uso, Logica, Processo, Distribuzione, Implementazione, Dati.

A meno che il sistema non sia del tutto senza precedenti, le architetture di riferimento devono essere esaminate per verificarne l'applicabilità (al dominio e al tipo di sviluppo), se esistono e sono accessibili all'organizzazione di sviluppo. La creazione di architetture di riferimento è una questione che deve essere affrontata a livello dell'organizzazione. E' certamente possibile ridurre l'elenco dei contenuti precedente ed ottenere comunque i vantaggi da un riutilizzo strutturale. Ad esempio, è possibile omettere il modello di test, anche se poi sarebbe necessario riscrivere i test nel caso in cui venisse modificata l'architettura. Ci si può aspettare almeno un modello di progettazione e qualche descrizione di comportamento associata (forse il modello di casi d'uso). In assenza anche di quello la risorsa difficilmente può essere denominata architettura di riferimento. Può tuttavia essere un valido pattern.