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
Ruoli | Responsabile:
| Modificato da:
|
Input in | Obbligatorio:
| Facoltativo:
| Esterno:
|
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
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.
-
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.
-
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.
-
(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.
-
(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
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.
-
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.
-
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.
-
(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.
-
(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 |  |
Pianificato |  |
Personalizzazione
Opzioni di rappresentazione | Rappresentazione 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.
|
© Copyright IBM Corp. 1987, 2006. Tutti i diritti riservati.
|
|