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