Creazione di porte e bind per i protocolli
Considerare le responsabilità della capsula, creando un insieme iniziale di classi di porta. Tali classi rappresentano
le interfacce per la capsula. Le classi di porta rappresentano la realizzazione di un Prodotto di lavoro: Protocollo, che alternativamente rappresenta un
insieme di segnali in e out utilizzati per comunicare con le capsule.
Durante la creazione delle porte, considerare l'Elenco di controllo:
Protocollo per determinare se il protocollo è appropriato. La porta dovrebbe riflettere un singolare insieme
di responsabilità correlate; avendo un protocollo con uno scopo simile, consente il proprio riutilizzo attraverso un
numero di capsule. Dopo aver selezionato il protocollo appropriato, collegare la porta al protocollo adeguato.
|
Convalida delle interazioni della capsula
Dopo aver collegato le porte ai protocolli, è necessario valutare e convalidare il comportamento esterno della capsula.
Utilizzando tecniche ripetitive manuali o tool di simulazione automatizzati, verificare il comportamento della capsula
simulando gli eventi che determineranno tale comportamento. La convalida considererà anche le capsule che interagiscono
con le capsule in fase di progettazione. Utilizzando i tool automatizzati, scrivere del codice stub all'interno della
capsula per consentire la verifica delle porte. Quando vengono rilevati errori nel protocollo, nella definizione di
porta o nelle responsabilità della capsula, eseguire le appropriate modifiche alle definizioni di capsula, porta e
protocollo.
|
Definizione di una macchina a stati capsule
Dopo aver convalidato le porte e i protocolli della capsula, definirne il comportamento interno. Il comportamento della
capsula viene definito utilizzando un diagramma di sequenza. Riferimento: Linea guida:
Diagramma di sequenza . È possibile ottenere altre informazioni generali sulla capsula dallaLinea guida: Capsula , elenco di controllo:
Capsula.
Come prima cosa, identificare gli stati in cui la capsula può esistere. Gli stati devono essere univoci (una capsula
non può essere in due stati contemporaneamente) e descrittivi. Consultare le linee di guida appropriate e i punti di
verifica per ulteriori informazioni.
Dopo aver definito gli stati, prendere in considerazione le transizione tra stati. Il codice di transizione deve essere
letto come pseudocodice di applicazione di livello elevato e deve consistere principalmente di chiamate di servizio del
sistema operativo in tempo reale, ad es. servizi frame, servizi di orario, operazioni di porta, operazioni di capsula e
operazioni passive di classe.
Quando si aggiunge il codice di dettaglio a una transizione di capsula:
-
Se il codice può essere utile in altre transizioni, prendere in considerazione la possibilità di delegarlo a
un'operazione di capsula.
-
Considerare se il codice implementa funzionalità che si uniformano alle responsabilità della capsula.
Quando si definisce un'operazione di capsula:
-
Considerare se la funzione deve essere utilizzabile in qualsiasi momento da qualsiasi transizione nella capsula e
se qualsiasi lavoro eseguito potrà mai essere utile in qualche parte del sistema. In caso affermativo, considerare
di delegarlo a una funzione di classe passiva.
-
Se il codice è troppo specifico per l'applicazione per essere memorizzato in una classe di dati, considerare la
creazione di una classe di dati aggiuntiva come un'astrazione per quel codice.
-
Se il codice tratta l'alterazione della struttura di dati (ad es., manutenzione degli elenchi), o esegue calcoli
complessi (più di una riga) allora dovrebbe essere introdotto in una classe di dati.
|
Definizione dei requisiti sulle classi passive
In base alle macchine a stati capsule, esaminare le classi passive riferite dalla capsula. Se sono presenti nuovi
requisiti su quelle classi, occorre generare le richieste di modifica per eseguire le modifiche richieste. Se le nuove
classi sono state identificate, è necessario riunire insieme i loro requisiti (più specificatamente le operazioni
richieste su di esse) e creare le classi. Queste classi verranno ulteriormente descritte nell'Attività: Progettazione della classe.
|
Introduzione all'eredità della capsula
L'eredità della capsula viene utilizzata per implementare generalizzazione-specializzazione, per consentire l'utilizzo
del polimorfismo, per riutilizzare l'implementazione. La parola fondamentale è "implementazione": si tratta di una
tecnica che viene utilizzata principalmente per riutilizzare la struttura interna delle capsule e non il relativo
comportamento esterno.
L'eredità viene spesso utilizzata in modo non idoneo per ottenere qualcosa ottenibile più facilmente utilizzando
tecniche di progettazione più semplici.
Utilizzo dell'eredità per la generalizzazione-specializzazione
Esistono tre tipi di eredità. Elencate da quella meno complessa (più ricercata) a quella più complessa (meno
ricercata), sono:
-
Eredità di interfaccia: eredità soltanto le porte e i protocolli ed è il tipo di eredità maggiormente
ricercato
-
Eredità strutturale: eredita l'interfaccia più le gerarchie di contenimento strutturale (utile per i
framework)
-
Eredità di comportamento: oltre all'eredita dell'interfaccia e della struttura, riutilizza anche il codice
comportamentale e le macchine a stati
L'eredità comportamentale e strutturale pone alcuni problemi:
-
Il forte livello di accoppiamento fornito dall'eredità provoca le modifiche a cascata alle sottoclassi quando
vengono eseguite per le superclassi.
-
La necessità di escludere ed eliminare il comportamento e la struttura delle superclassi nelle sottoclassi, indica
l'utilizzo inappropriato dell'eredità (solitamente per il riutilizzo tattico del codice). Il refactoring delle
classi e delle capsule e l'utilizzo appropriato della delega è una strategia più idonea.
-
Ereditare significa spostare decisioni di progettazione per la gerarchia delle classi, provocando dipendenze di
progettazione e compilazione sgradite.
Di seguito, altri problemi:
-
Le decisioni non possono essere appropriate in tutte le situazioni di utilizzo.
-
L'introduzione dell'eredità rende attualmente il riutilizzo più difficoltoso, poiché gli elementi di progettazione
sono accoppiati in modo più saldo.
-
La progettazione diventa molto più fragile poiché qualsiasi nuovo requisito che invalida la decisione provoca
grandi problemi.
-
La progettazione deve essere estremamente flessibile per compensare ciò che è spesso difficile. Ciò rende la
progettazione di framework riutilizzabili come uno sforzo!
Tutte le progettazioni contenenti struttura/comportamento hanno decisioni e presupposizioni integrate (sia esplicite
che implicite). La domanda critica da porsi è se si ha la certezza che il rapporto decisione/presupposizione sarà
sempre valido. Se la risposta è negativa, in che modo è possibile rimuoverlo o modificarlo?
|
Convalida del comportamento della capsula
Come fase finale, il comportamento della capsula deve essere valutato e convalidato. Utilizzando tecniche ripetitive
manuali o tool di simulazione automatizzati, il comportamento della capsula dovrebbe essere verificato simulando gli
eventi che lo determinano. In aggiunta, deve essere convalidata la struttura interna della capsula, per assicurare che
oltre a quella esterna venga convalidata anche l'implementazione del comportamento interno. Utilizzando i tool
automatizzati, è possibile scrivere del codice stub per simulare l'implementazione di classi di dati passive e le
capsule esterne con cui la capsula interagisce. Occorre documentare i difetti rilevati ed eseguire le appropriate
modifiche alle definizioni della capsula.
|
|