Scopo
|
Identificazione degli elementi di progettazione che formano i punti di giunzione nel sistema.
|
Le interfacce definiscono una serie di operazioni che vengono realizzate da alcuni programmi di classificazione. Nel
modello di progettazione le interfacce sono utilizzate principalmente per definire le interfacce per i sottosistemi.
Questo non significa che non possono essere utilizzate anche per le classi, ma per le classi singole è solitamente
sufficiente definire delle operazioni pubbliche sulla classe che definisce l'interfaccia. Le interfacce sono importanti
per i sottosistemi poiché consentono la separazione delle dichiarazioni di comportamento (l'interfaccia) dalla sua
realizzazione (le classi specifiche interne al sottosistema che realizzano l'interfaccia). Questa separazione consente
di incrementare l'indipendenza dei team di sviluppo che lavorano su parti diverse del sistema, mantenendo però
definizioni precise dei 'contratti' tra le diverse parti.
Per ciascun sottosistema identificare una serie di possibili interfacce. Utilizzando le collaborazioni
raggruppate create nel passo precedente, identificare la responsabilità che viene 'attivata' quando si avvia la
collaborazione. Questa viene quindi raffinata determinando quali informazioni devono essere fornite dal 'cliente' e
quali devono essere restituite al termine della collaborazione; questa serie di informazioni diventano il prototipo dei
parametri di input, output e dei valori restituiti per l'operazione che il sistema realizzerà. Definire il nome di
questa operazione, utilizzando le convenzioni di denominazione definite in Prodotto di lavoro: Linee guida specifiche del progetto. Ripetere
finché tutte le operazioni realizzate dal sottosistema non saranno definite.
Raggruppare poi tutte le operazioni sulla base delle loro responsabilità. Sono preferibili gruppi piccoli, siccome è
più probabile ottenere una serie aderente di responsabilità comuni se le operazioni nel gruppo sono minori. Tenere
sempre presente il riutilizzo - creare delle similitudini che possano rendere più semplice l'identificazione di
funzionalità riutilizzabili collegate tra loro. Allo stesso tempo, però, è bene non dedicare troppo tempo alla ricerca
del raggruppamento di responsabilità ideale; ricordarsi che si tratta di un primo raggruppamento e che il raffinamento
proseguirà in modo iterativo durante tutta la fase di elaborazione.
Ricerca delle similitudini tra le interfacce. Nell'insieme di interfacce candidate, cercare nomi simili,
responsabilità simili ed operazioni simili. Nel caso vi siano operazioni uguali in più interfacce, riorganizzarle,
estraendo le operazioni comuni ed inserendole in una nuova interfaccia. Considerare anche le interfacce esistenti,
riutilizzandole dove possibile. Lo scopo è quello di mantenere la coesione delle interfacce rimuovendo le operazioni
ridondanti. Ciò le renderà più semplici da comprendere e ne faciliterà l'evoluzione nel tempo.
Definizione delle dipendenze dell'interfaccia. I parametri ed i valori restituiti da ciascuna operazione
dell'interfaccia sono di diversi tipi: essi devono realizzare una particolare interfaccia, oppure devono essere istanze
di un semplice tipo di dati. Nel caso in cui i parametri siano oggetti che realizzano una determinata interfaccia, si
devono definire le relazioni di dipendenza tra di essa e l'interfaccia da cui essa dipende. La definizione delle
dipendenze fornisce delle informazioni utili per l'accoppiamento all'Architetto del software, siccome le dipendenze tra
le interfacce determinano le dipendenze primarie tra gli elementi del modello di progettazione.
Associazione delle interfacce ai sottosistemi. Una volta identificate le interfacce, creare delle associazioni
di realizzazione tra il sottosistema e l'interfaccia che esso realizza. Una realizzazione da un sottosistema ad
un interfaccia indica che esistono uno o più elementi all'interno del sottosistema che realizzano le operazioni
dell'interfaccia. Successivamente, quando il sottosistema verrà progettato, verrà raffinata la realizzazione
dell'interfaccia di sottosistema, il progettista del sottosistema definirà quali elementi specifici realizzeranno le
operazioni dell'interfaccia. Queste realizzazioni raffinate sono visibili solo al progettista del sottosistema; al
cliente del sottosistema saranno visibili unicamente le realizzazioni delle sue interfacce.
Definizione dei comportamenti specificati dalle interfacce. Le interfacce spesso definiscono una macchina a
stati implicita per gli elementi che le realizzano. Se le operazioni devono essere richiamate in un ordine specifico
(ad esempio, è necessario avviare una connessione al database prima di utilizzarlo), si deve definire una macchina a
stati che illustri gli stati visibili (o intuibili) pubblicamente che ciascun elemento di progettazione che realizza
l'interfaccia deve supportare. Questa macchina a stati aiuta l'utente di un interfaccia a comprenderla con più
semplicità, ed aiuterà il progettista degli elementi che realizzano l'interfaccia a fornire loro il comportamento
corretto.
Impacchettamento delle interfacce. Le interfacce sono in possesso dell'Architetto del software; la loro modifica
è sempre rilevante dal punto di vista architetturale. Per gestire questa eventualità, esse devono essere raggruppate in
uno o più pacchetti in possesso dell'Architetto del software. Se ciascuna interfaccia è realizzata da un singolo
sottosistema, la si può impacchettare assieme ad esso. Se invece è realizzata da più sottosistemi, deve essere
impacchettata in pacchetti separati in possesso dell'Architetto del software. Ciò consente di gestirla e controllarla
indipendentemente dal sottosistema.
Scopo
|
Identificazione degli elementi di progettazione che formano i punti di giunzione nel sistema (solo per
la progettazione del RT).
|
I protocolli sono simili alle interfacce nei sistemi basati sugli eventi: identificano il 'contratto' tra le capsule
definendo una serie corrispondente di segnali utilizzati per le comunicazioni tra thread di controllo indipendenti.
Mentre le interfacce sono utilizzate principalmente per la definizione di una messaggistica sincrona utilizzando un
modello di richiamo a chiamata di funzione, i protocolli sono utilizzati per la definizione di comunicazioni asincrone
utilizzando una messaggistica basata su segnali. Questi consentono una separazione tra la dichiarazione di
comportamento (l'insieme dei segnali) e la sua realizzazione (gli elementi del sottosistema che realizzano
l'interfaccia). Questa separazione consente di incrementare l'indipendenza dei team di sviluppo che lavorano su parti
diverse del sistema, mantenendo però definizioni precise dei 'contratti' tra le diverse parti.
Per ciascuna capsula identificare una serie di segnali in ingresso ed uscita. Utilizzando le collaborazioni
raggruppate create nei precedenti passi, identificare la responsabilità che viene 'attivata' quando si avvia la
collaborazione. Questa viene quindi raffinata determinando quali informazioni devono essere fornite dal 'cliente' e
quali devono essere restituite al termine della collaborazione; questa serie di informazioni diventano il prototipo dei
parametri di input per un segnale che la capsula realizzerà tramite una delle sue porte. Definire il nome di questo
segnale, utilizzando le convenzioni di denominazione definite in Prodotto di lavoro: Linee guida specifiche del progetto. Ripetere
finché tutti i segnali realizzati dalla capsula non saranno definiti.
Raggruppare poi tutti i segnali sulla base delle loro responsabilità. Sono preferibili gruppi piccoli, siccome è più
probabile ottenere una serie aderente di responsabilità comuni se i segnali nel gruppo sono minori. Tenere sempre
presente il riutilizzo - creare delle similitudini che possano rendere più semplice l'identificazione di funzionalità
riutilizzabili collegate tra loro. Allo stesso tempo, però, è bene non dedicare troppo tempo alla ricerca del
raggruppamento di responsabilità ideale; ricordarsi che si tratta di un primo raggruppamento e che il raffinamento
proseguirà in modo iterativo durante tutta la fase di elaborazione. Assegnare al protocollo un nome significativo che
descriva il suo ruolo nella collaborazione della capsula.
Ricerca delle similitudini tra i protocolli. Nell'insieme di protocolli candidati, cercare nomi simili,
responsabilità simili e segnali simili. Nel caso vi siano segnali uguali in più protocolli, riorganizzarli, estraendo i
segnali comuni ed inserendoli in una nuova interfaccia. Considerare anche i protocolli esistenti, riutilizzandoli dove
possibile. Lo scopo è quello di mantenere la coesione dei protocolli rimuovendo le operazioni ridondanti. Ciò li
renderà più semplici da comprendere e ne faciliterà l'evoluzione nel tempo.
Associazione dei protocolli alle capsule. Una volta identificati i protocolli, creare le porte sulle
capsule che li realizzano. Le porte delle capsule ne definiscono le 'interfacce', il comportamento che può essere
richiesto dalla capsula. Successivamente, una volta progettata la capsula, il comportamento specificato dalle porte
verrà descritto dalla sua macchina a stati.
Definizione dei comportamenti specificati dai protocolli. I protocolli spesso definiscono una macchina a stati
implicita per gli elementi che le realizzano. Se i segnali di input devono essere ricevuti in un ordine specifico (ad
esempio, un segnale 'sistema-pronto' deve essere ricevuto prima di un determinato segnale di errore), si deve definire
una macchina a stati che illustri gli stati visibili (o intuibili) pubblicamente che ciascun elemento di progettazione
che realizza il protocollo deve supportare. Questa macchina a stati aiuta l'utente della capsula che realizza il
protocollo a comprenderne meglio il comportamento, ed aiuterà il progettista delle capsule a fornire loro il
comportamento corretto.
Impacchettamento dei protocolli. I protocolli sono in possesso dell'Architetto del software; la loro modifica è
sempre rilevante dal punto di vista architetturale. Per gestire questa eventualità, essi devono essere raggruppati in
uno o più pacchetti in possesso dell'Architetto del software. In questo modo sarà possibile gestire e controllare i
protocolli indipendentemente dalle capsule che li realizzano.
|