1 – Costruzione dell’alberatura Casi d’uso in Quality Center (la gerarchia guida la costruzione dei deliverable di documentazione anche nei diversi rami di Power Designer): Applicazione (ad es. Quick Trade) Modulo funzionale (ad es. Grafici) Componente applicativo (ad es. Tick by Tick) Caso d’uso (ad es. Visualizza Prezzo Riferimento) Struttura dell’albero in Power Designer Reverse Engineering: Ramo sotto cui vengono importati gli oggetti provenienti da Reverse Engineering di applicazioni esistenti Design: ramo sotto cui vengono inseriti i deliverable di design Analisi: ramo sotto cui vengono elencati i casi d’uso e costruite le matrici di tracciabilità

2. Reverse engineering Utilizzare lo strumento di reverse engineering di Power Designer per importare la struttura delle classi presente nelcodice

3 – Definizione della struttura dei casi d’uso Utilizzando la gerarchia descritta nella prima slide crare una lista dei casi d’uso per ogni componente applicativo, sfruttando lo strumento di Power Designer: NewRequirements Model, presente nel menu di contesto del folder di destinazione Nella popup scegliere Requirement Document View, assegnando il nome dello specifico componente applicativo Nella finestra inserire l’elenco dei casi d’uso in modo conforme a quanto esistente in Quality Center

4 - Creazione dei Class Diagram Nel ramo design in corrispondenza di ciascun componente applicativo creare un class diagram, in cui per ogni caso d’uso elencato al passo precedente vengono visualizzate La pagina Boundary La classe Control principale La pagina boundary che interfaccia il caso d’uso può essere reperita con l’ausilio della mappa messa a disposizione da IWBank all’indirizzo: https://testtrader.iwbank.it/test/restyle/state_map.jhtml?focusOnClick=true&context=iwbPrivProfessional Dal momento che le pagine JSP/JHTML non sono importabili in PD via reverse engineering, la pagina dovrà essere inserita esplicitamente nel grafico tramite creazione di una classe avente nome il nome della pagina e stereotipo “boundary” La classe control che gestisce la logica del caso d’uso Può essere individuata dall’analisi del codice della pagina boundary manualmente o per mezzo di tool La classe potrà essere reperita in PD per mezzo dello strumento di ricerca e poi per mezzoo del “Find in Browser” disponibile da menu di contesto La classe boundary viene legata manualmente alla classe control con una relazione di associazione Le classi vengono rappresentate nei diagrammi nascondendo il dettaglio di attributi e metodi per rendere più leggibile il diagramma (voce Display Preferences del menu di contesto visualizzato cliccando sullo sfondo del diagramma)

5. Costruzione Matrice di Tracciabilità Una volta elencati i casi d’uso ed individuate le classi impattate è possibile costruire la matrice di tracciabilità che, opportunamente manutenuta, servirà per poter effettuare le analisi di impatto Nella toolbar del requirement model, cliccare sul pulsante Create a Traceability Matrix View Il tool genera automaticamente sulle righe della matrice l’elenco dei casi d’uso Nella toolbar della nuova finestra utilizzare il pulsante Select Rows/Columns Utilizzare la popup per selezionare le classi da tracciare Nella matrice spuntare opportunamente gli incroci tra casi d’uso e classi impattate

6 – Problemi aperti La costruzione di matrici di tracciabilità legate ai singoli moduli applicativi è dettata dall’esigenza di avere matrici di dimensione contenuta e quindi facilmente manutenibili. La mancanza di un’unica matrice riepilogativa tuttavia non permette di effettuare agevolmente un’attività propedeutica all’individuazione dei test di regressione (data una modifica ad un modulo software individuare i casi d’uso coinvolti): tale attività risulta di fatto complicata se uno stesso modulo software è utilizzato da più componenti applicative