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):
1.
2.
3.
4.
•
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=iwbP
rivProfessional
– 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