Operazione: Definizione contesto del sistema
Questo compito descrive come creare un diagramma del contesto del sistema che mostri l'elevata qualità della collaborazione tra il sistema e gli attori.
Scopo
  • In base al modello di caso d'uso,  creare la collaborazione al massimo livello che mostra il sistema (modellato come sottosistema al massimo livello), le relative interfacce e le relative relazioni con i propri attori, incluse le entità di I/O esterne che circolano tra l'attore e il sistema.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo:
  • Nessuno
Esterno:
  • Nessuno
Output
Passi
Introduzione

Mentre il modello di caso d'uso mostra il contesto di comportamento per il sistema, in questa attività si crea un modello logico di sistema nel proprio ambiente, utilizzando il Prodotto di lavoro: Modello del caso d'uso e il Prodotto di lavoro: Specifiche supplementari per delineare, in un Diagramma di contesto:

  • Le interfacce che devono essere realizzate dal sistema (nei termini delle operazioni che il sistema fornisce, dei protocolli associati supportati, delle variabili di stato e archivi che il sistema realizza e degli attributi caratterizzati come misure di prestazioni tecniche).
  • Le entità di I/O che circolano tra il sistema e i relativi attori.
  • Le interfacce richieste dal sistema (da realizzare da parte degli attori che interagiscono con il sistema) per le prestazioni corrette. Spesso, se l'attore rappresenta un sistema esistente con cui il sistema deve comunicare, tali interfacce richieste riflettono semplicemente i vincoli imposti da qualche altro sistema.

Un diagramma di contesto mostra la collaborazione di alto livello tra il sistema e i relativi attori. È l'analogo strutturale al modello di caso d'uso per il sistema. Questa collaborazione viene creata nel modello di analisi.

Le entità di I/O (rappresentate per la modellazione come classi stereotipate di "I/O" con attributi ma prive di operazioni) descrivono le cose che circolano all'interno e all'esterno del sistema e possono, nel caso del sistema generale, includere dati, massa, energia o parti fisiche. Le entità di I/O vengono associate (durante la modellazione) a coppie attore-sistema indicanti che queste particolari entità di I/O circolano fra l'attore e il sistema. Possono facoltativamente essere mostrate sui diagrammi, associate all'attore e la direzione del flusso viene indicata da un "invia" o "ricevi" stereotipo sull'associazione, indicante la direzione relativa all'attore.

Un'operazione di sistema è un servizio che può essere richiesto da un oggetto per determinare il comportamento. Un'operazione specifica il nome, il tipo, i parametri ed i vincoli per richiamare un comportamento associato. Le operazioni vengono raggruppate intorno alle interfacce lungo le principali responsabilità del (sotto)sistema preso in considerazione. La chiamata di operazione di un sistema rappresenta un'interazione più fine-grained con il sistema che utilizza l'istanza caso d'uso e quest'ultima è una composizione di chiamate e risposte di operazione.

Le variabili di stato e gli archivi sono attribuiti definiti sulle interfacce realizzate dal sistema. Questi sono astratti e richiedono che il sistema mantenga le informazioni corrispondenti al tipo e molteplicità dell'attributo e permetta l'archiviazione, il recupero e la modifica di tali informazioni. Non c'è alcuna implicazione che un attributo nel sistema corrisponda direttamente all'attributo definito sull'interfaccia. La differenza tra le variabili di stato e gli archivi non è intrinseca, ma riflette solo il modo in cui gli attributi vengono utilizzati per controllare l'operazione della macchia a stati (astratta) del sistema. Un "stato" dura per un periodo di tempo, a differenza di un evento (come l'arrivo di un segnale) che accade in un punto nel tempo. Le macchine a stati menzionate qui sono macchine a stati finiti e la delineazione dello "stato" viene solitamente decisa dalle relativamente poche variabili; ad esempio, lo stato corrente potrebbe essere specificato dal valore di un singolo attributo di un tipo di enumerazione. La reazione del sistema a un evento, tuttavia, potrebbe non dipendere solo dalla natura dell'evento (e dell'informazione che trasporta, ad esempio nei parametri di operazione) e dallo stato corrente, ma anche dal valore di altri (forse molti) attributi.

Una TPM (Technical Performance Measure) è un attributo tecnico fondamentale selezionato dalle specifiche supplementari o dal modello di caso d'uso come indicatore critico dell'efficacia, che, se non realizzata, pone il sistema a rischio di costi eccessivi, pianificazione o vincoli di prestazione. I valori derivanti da questi attributi vengono tracciati per tutta la durata del progetto. Ad esempio, potrebbe essere importante che il peso trasportato di un sistema venga tenuto basso entro determinati limiti e il raggiungimento di questo obiettivo deve essere tracciato durante il progresso della progettazione e della costruzione. Il peso del sistema, quando trasportato, è ovviamente un attributo (percepibile in vari modi) di un'istanza del sistema e non è necessariamente lo stesso del peso obiettivo durante lo sviluppo (per un sistema da lanciare in orbita probabilmente si preferirebbe che fosse di meno). Un valore con tag UML può essere utilizzato per annotare un attributo TPM per indicare l'obiettivo delle prestazioni, ad esempio:

Peso "TPM" {massimo_peso = 1000 Kg}

Le misure di prestazioni tecniche (TPM) si possono applicare ad altre caratteristiche non strutturali come il tempo di risposta di operazione. I valori con tag possono essere applicati a operazioni di sistema o al sistema stesso per registrare le operazioni.

Creazione del diagramma di contesto iniziale

Le seguenti fasi mostrano i livelli di dettaglio in evoluzione del sistema nel contesto. L'esempio illustrato è quello di un sistema di sicurezza che protegge la proprietà da accessi non autorizzati e, in aggiunta all'emissione sonora, ha la capacità di segnalare le violazioni a un certo tipo di servizio di risposta. 

Nello stesso modo in cui si evolvono e si aggiungono ulteriori dettagli al modello di caso d'uso (scoprendo gli attori oppure, se il modello aziendale è stato eseguito e gli attori e forse le operazioni già identificate, elaborando le loro interazioni), è possibile creare la collaborazione iniziale e illustrare ciò con un diagramma di contesto. Il diagramma di contesto può essere creato come indicato, inizialmente con le interfacce di sistema assenti. Il sistema viene descritto come sistema di alto livello ("sistema" stereotipato), che eventualmente realizza diverse interfacce. Gli attori e le rispettive associazioni vengono inoltre indicati, ancora, senza alcun dettaglio inizialmente.

Diagramma di contesto (iniziale)

Diagramma di contesto (iniziale)

Perfezionamento di associazione e interfacce

Successivamente, si perfezionano le associazioni tra attori e sistema e l'interfaccia di sistema. Si può iniziare a ragionare su operazioni e attributi di sistema mentre emergono dal Compito: Ricerca di attori e casi d'uso (In seguito: Compito: Dettaglio di un caso d'uso). Si noti che adesso il sistema compare agli attori mostrando l'interfaccia. La realizzazione di quanto detto può essere mostrata se si desidera (evidenziata dal cerchio tratteggiato nel diagramma), ma può essere omessa senza grandi perdite di informazioni.

In questa fase, identificare a titolo di prova solo le entità di I/O, basate su conoscenza di dominio e su qualsiasi lavoro svolto in precedenza nella realizzazione dei casi d'uso a livello aziendale. Si noti che non è richiesto che le entità di I/O vengano mostrate sul diagramma, ma ciò può essere utile nel ragionamento sulle interazioni attore-sistema.

In questo modo, è possibile iniziare a caratterizzare la o le connessioni tra attore e sistema (ad esempio, registrare il protocollo richiesto) e registrare le entità che circolano tra di loro.

Diagramma di contesto (preliminare)

Diagramma di contesto (preliminare)

Dettagli sulle operazioni di sistema e altre caratteristiche di sistema

In questa fase, si iniziano a costruire gli scenari dei casi d'uso (istanze di casi d'uso) da cui è possibile descrivere le operazioni di sistema (fornite e richieste). Gli scenari possono essere illustrati attraverso i diagrammi di interazione o attività. Ogni fase black-box in un caso d'uso rappresenta una interazione più fine-grained con il sistema e viene associata a una chiamata di operazione (ma non necessariamente una sola operazione; altre fasi black-box potrebbero utilizzare la stessa operazione). Così come per la definizione delle operazioni di sistema nel diagramma di contesto (e quindi nel modello di analisi), i casi d'uso vengono anche annotati, per tracciabilità, alle operazioni richiamate. Le operazione ereditano anche tutti i requisiti di prestazioni e antri requisiti non funzionali che sono stati assegnati alle fasi black-box. Quando si esamina ogni fase black-box eseguita nello scenario, si scopre l'utilizzo di nomi che potrebbero suggerire le variabili di stato e gli archivi che il sistema deve gestire per eseguire lo scenario del caso d'uso. Si possono anche perfezionare le entità di I/O che vengono richieste e associarle con le chiamate di operazione per comporre i segnali inviati tra attore e sistema. 

Potrebbe aiutare a comprendere la divisione dell'interfaccia di sistema in più interfacce specifiche; in realtà, possono esserci requisiti di interfaccia nella Specifica supplementare che gestisce il processo. L'illustrazione in basso mostra l'evoluzione dell'interfaccia di sistema in un "interfaccia di sistema fornita" per ogni tipo di attore, sebbene non si tratti di una prescrizione fissa. Gli attori potrebbero condividere un'interfaccia o potrebbe esserci più di un'interfaccia per attore.

Tale analisi potrebbe anche identificare le interfacce richieste dal sistema, cioè le interfacce che devono essere supportate dagli attori (per elaborare i messaggi dal sistema). Queste possono essere aggiunte al diagramma in un modo simmetrico (ad esempio, vedere "l'interfaccia di sistema richiesta" di IE-services/ESS "required system interface" realizzata dall'attore Emergency Services nel diagramma in basso). Di nuovo, (anche se questo non è mostrato) un attore potrebbe supportare(realizzare) più di una interfaccia.

Le operazioni, gli archivi e così via, devono essere aggiunti a una forma ampliata delle interfacce (nelle sezioni di attributo e operazione) come indicato. Il diagramma viene elaborato solo parzialmente (per questioni di spazio). L'interfaccia fisica dell'ambiente, attore e così via, non sono stati ampliati. Di nuovo, la realizzazione delle interfacce di sistema fornite può essere omessa senza grande perdita di informazioni.

Diagramma di contesto (finale)

Diagramma di contesto (finale).

Questa collaborazione di alto livello, catturata nel diagramma di contesto, consente alle interfacce, alle connessioni che circolano all'interno e all'esterno del sistema e alle caratteristiche di prestazioni associate, di essere rigorosamente specificate, consentendo la continuazione dello sviluppo del sistema indipendentemente da altri elementi nel contesto di sistema.

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