1 – Costruzione dell’alberatura

1. 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. 2. Reverse engineering • Utilizzare lo strumento di reverse engineering di Power Designer per importare la struttura delle classi presente nelcodice

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