Operazione: Progettazione operazione
In questa attività si perfezionano i risultati dell'Analisi di operazione in dettagliate Realizzazioni di operazione.
Scopo
  • Perfezionare le interazioni preliminari di sottosistema in Realizzazioni di operazioni nel modello di progettazione.
  • Perfezionare e specificare le Operazioni di sottosistema.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo:
  • Nessuno
Esterno:
  • Nessuno
Output
Passi
Creare le realizzazioni di operazione

Nella Attività: Analisi di operazione, il progettista ha creato le interazioni del sottosistema (con pochi dettagli) nel modello di analisi. Richiamare la granularità di queste interazioni, così come sono state raggruppate per operazione di sistema, cioè le interazioni acquisite che realizzano ogni operazione di sistema. A questo punto, lavorando con le descrizioni ampliate del caso d'uso di sistema (white-box,) i dettagli dei messaggi, le entità cambiate, l'ordine, il flusso di controllo e i dati associati vengono aggiunti al modello di progettazione insieme alle realizzazioni di operazione risultanti e acquisite. Non appena questi dettagli vengono aggiunti, il progettista valuta la qualità delle collaborazioni emergenti, cercando le opportunità per eseguire il refactoring della progettazione. Prendere nota delle realizzazioni di operazione con le descrizioni di cosa fa il sottosistema quando elabora un messaggio (delineata dalla descrizione di fase white-box e migliorata se necessario). Tali descrizioni sono di aiuto nella fase successiva, per lo sviluppo di specifiche per ogni operazione di Sottosistema.

Aggregare le fasi white-box di sottosistema simili e specificare le operazioni di sottosistema

Il progettista ha prodotto il segnalibro iniziale dello studio di operazione di sistema durante l'attività di analisi di operazione. La tabella dello studio mostra anche (con uno sfondo grigio) la tracciabilità delle fasi black box del caso d'uso di sistema, indicando (nella tabella) che le fasi black box del caso d'uso di sistema <id 1> e <id 2> vengono entrambe eseguite tramite chiamata del <nome di operazione di sistema 1>.

<Nome> del sottosistema
Operazione di sistema Identificatore di fase black box di caso d'uso di sistema Località Processo Risorsa lavorativa Descrizione di fase white-box di sottosistema Operazione di sottosistema

<operazione di sistema nome1>

<id 1> Identificatore di località Identificatore di processo Identificatore di organizzazione o di risorsa lavorativa di sistema (identificatore di fase white-box): descrizione di un'azione eseguita da un sottosistema (che esegue parte della fase black-box) nella forma di input, elaborazione, output (identificatore di operazione di sistema): nome dell'operazione del sottosistema che viene richiamata per questa fase, ad esempio "«operazione di sottosistema» Avviare un elenco di vendite" (per sottosistema elaborazione ordine)
... ...   (identificatore di fase white-box):...  
... ...   ...  
<id 2> ... ...   ...  
<nome2 di operazione di sistema> <id 3> ... ...   ...  
<id 4> ... ...   ...  
... ... ... ...   ...  

Esempio di studio di operazione di sottosistema.

Lavorando dalle fasi white-box e dalle realizzazioni di operazione, vengono identificate le operazioni di sottosistema e specificato il loro comportamento. Con l'identificazione delle operazioni di sistema, potrebbe non esserci un'operazione univoca per ogni fase white-box; cioè, quando si esamina l'insieme di fasi white-box e i relativi messaggi di scambio associati, le entità di input-output e così via, ci si potrebbe trovare nella condizione che è possibile definire un insieme più piccolo delle operazioni di sottosistema che soddisfa le esigenze.

Si noti che la tabella di studio può anche essere ordinata per località o per processo, mostrando in tal modo l'associazione di un insieme di operazioni di sottosistema con ogni località o con ogni processo . L'ordinamento per località offre un'indicazione sul carico di elaborazione in una località (utile per ragionare sulla capacità dei componenti visivi che supportano la località. In questa forma, lo studio ordinato per località diventa una proprietà del modello di distribuzione.

Quando un'operazione di sottosistema viene ospitata in più località, allora almeno una parte del sottosistema è replicata. Non c'è alcuna implicazione che tali parti replicate condividano necessariamente dati o che siano in sincronizzazione. Queste sono scelte di progettazione che dipendono dall'applicazione e dal motivo della replica; ad esempio, l'elaborazione richiesta potrebbe essere identica, ma verificarsi per un differente segmento di business. In modo estremo, tutte le operazioni di sottosistema possono essere ospitata in più località, la cui cosa significa che il sottosistema stesso è replicato. La necessità di identificare le istanze replicate in modo univoco dipende dai motivi della replica.

L'ordinamento del processo consente al progettista di ragionare sui problemi di concorrenza: se si considera un operazione di sottosistema come una parte discreta di funzionalità disponibile per gli attori, allora come prima approssimazione le operazioni associate allo stesso processo non possono esse eseguite in parallelo. Ciò potrebbe portare il progettista a riconsiderare la collocazione del processo o a considerare la replica del processo oppure a esaminare il problema della latenza percepita a un livello inferiore di dettagli, ad esempio, attraverso l'esame delle opzioni suddivise per tempo e la condivisione del processo quando un'operazione si blocca (per produrre input-output, ad esempio). Tali tecniche offrono una reattività accettabile, mentre un ritardo nell'avvio di un'operazione (operazioni di serializzazione rigorosa) potrebbe essere intollerabile. In questa forma, lo studio ordinato per processo diventa una proprietà del modello di distribuzione.

Nota a piè pagina - Cosa è stato raggiunto

Per ogni sottosistema si sono:

  • definite le sue operazioni
  • definite le interfacce che si attendono supportate dal sottosistema
  • descritto come il sottosistema collabora con altri sottosistemi per realizzare i casi d'uso di sistema
  • definito il contesto del sottosistema: i suoi attori, le interfacce e le entità di I/O

A questo punto si è nella posizione giusta per riuscire a consegnare questo insieme di lavoro di prodotti allo sviluppo indipendente, se si desidera, oppure di richiamare le attività di RUP nella disciplina dei requisiti, per eseguire ulteriore decomposizione in un modo ricursivo.

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