Nello studio delle architetture software, ma più in generale quando si vuole analizzare un prodotto da sviluppare o un problema da risolvere vengono utili le 6 domande: WHO, WHAT, WHERE, HOW, WHY, WHEN che permettono di analizzare a 360° il problema. Vediamo nel dettaglio cosa indicano e come possiamo utilizzarle al meglio.
Il primo passo da fare nello studio di un problema è capire chi interagisce con il sistema, definendo i casi d’uso. Un caso d’uso è un comportamento, offerto o desiderato, richiesto da un attore al sistema che si sta studiando.
Tramite i casi d’uso è possibile individuare i confini del sistema per capire quello che è interno o che è esterno e definire i requisiti funzionali. Tutti i casi d’uso si devono basare sul punto di vista dell’utente o più in generale dell’attore e non descrivere quali sono le iterazioni per sviluppare l’operazione. In ogni caso non deve mai spiegato il come ma bisogna limitarsi al cosa si vuole modellare.
Ad esempio se il sistema è una calcolatrice un caso d’uso può essere il calcolo della somma da parte di un attore che è lo studente. Il caso d’uso dovrà mettere in luce questa operazione senza mettere in luce il come verrà svolta l’operazione all’interno della calcolatrice. In UML si parla di diagramma dei casi d’uso.
Dopo aver capito chi interagisce nel sistema bisogna domandarsi quali siano nel informazioni utili a fornire una risposta al problema che si sta studiando. E’ molto semplice in questo caso sbagliare l’analisi e ragionare nella logica dei dati che vorremmo memorizzare a database. Lo scopo di questa analisi è SOLO quello di mostrare quali sono le informazioni del business del sistema che stiamo andando a sviluppare, scomponendo il dominio e identificando concetti, attributi e associazioni. In UML si hanno i diagrammi delle classi per esplicare le informazioni necessarie.
In questa fase si analizza dove sono dislocate le informazioni del sistema. L’analisi va condotta sia sui casi d’uso che sul modello delle informazioni. Nei casi d’uso si analizza la posizione fisica dei singoli attori.
In questa fase di analisi ci si interroga su come lavora il sistema e su come le informazioni che abbiamo modellato creano delle attività. Ogni attività viene avviata da un evento esterno, un’azione di input. E’ importante capire che si va ad analizzare il come lavora il sistema e non il perchè e il quando. Il diagramma UML utilizzato in questo caso è quello delle attività. Per specificare correttamente come lavora il sistema sarebbe necessario definire un diagramma delle attività per ogni caso d’uso.
In questa fase ci si interroga sul perchè le attività vanno svolte. Effettivamente questo tipo di domanda è più corretta da fare nel caso di sviluppo concreto dell’applicazione. Ma analizzando in questo momento il perchè si potranno mettere in evidenza altri requisiti necessari.
L’ultima parte da analizzare sono le temporizzazioni. In questo caso è necessario valutare due tipi di temporizzazioni. Il primo riguarda la frequenza con la quale si verificano determinate operazioni. Il secondo invece riguarda i vincoli di tempo che si hanno tra l’avvio di una computazione e la sua computazione. Entrambe le tipologie generano dei requisiti non funzionali.