Operazione: Progettazione capsula
Questa attività descrive le caratteristiche della progettazione di capsula.
Scopo
  • Elaborazione e perfezionamento delle descrizioni di una capsula.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo: Esterno:
  • Nessuno
Output
Descrizione principale

Le capsule vengono utilizzate per definire i thread di esecuzione simultanei nel sistema. Le capsule possono essere nidificate a una profondità arbitraria così come essere associate a classi (passive) di progettazione. Questa attività viene eseguita una volta per ogni capsula, incluse le nuove capsule identificate all'interno dello scopo di questa attività.

 Rappresentazione UML 2.0

Si noti che la rappresentazione RUP corrente per le capsule Š basata sull'annotazione UML 1.5. Molte di queste possono essere rappresentate in UML 2.0 utilizzando Concetto: Classi strutturate.

Per ulteriori informazioni consultare Differenze fra UML 1.x e UML 2.0.

Passi
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.

Definizione di stati

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.

Definizione di transizioni di stati

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.

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni