Sottosistemi Java

La verifica a livello di sottosistema rappresenta un livello di verifica molto importante mirato a controllare che i componenti rispettino i contratti delle interfacce e si integrino in modo corretto con gli altri componenti. La verifica di sottosistema funge da ponte tra la verifica a livello di classe e la verifica a livello di sistema e risulta utile nella gestione dell'ambito e dell'obiettivo.

Se l'intera suite di verifica era focalizzata a livello di classe, si presenteranno successivamente problemi di integrazione. D'altra parte, la focalizzazione sulla sola verifica a livello di sottosistema fornisce soltanto una copertura superficiale dal momento che non consente un sufficiente controllo sulle singole classi.

Si consiglia di utilizzare il processo generale descritto di seguito per verificare un sottosistema:

  1. Definire le classi che appartengono al sottosistema.
  2. Identificare gli stati aggregati all'interno del sottosistema.
  3. Definire il flusso generale mediante il grafico di stato.
  4. Definire le ulteriori verifiche per ottimizzare la copertura.

Definire le classi che appartengono al sottosistema

In teoria sarebbe consigliabile dedicare maggior spazio alla verifica a livello di classe e all'identificazione dei gruppi di classi che possono essere integrati e verificati come sottosistemi. Per definire il contenuto di un sottosistema è necessario identificare le classi che forniscono un servizio coesivo. La selezione deve essere basata sui criteri elencati di seguito:

Identificare gli stati aggregati all'interno del sottosistema

Dopo aver identificato un gruppo di classi che si desidera verificare come sottosistema, si consiglia di utilizzare l'analisi basata sullo stato per comprendere approfonditamente gli scenari che si desidera verificare. Dal momento che si lavora con un sottosistema, è opportuno considerare un comportamento aggregato. Si parla di comportamento aggregato perché il raggiungimento di un determinato stato implica che numerosi oggetti lo hanno singolarmente raggiunto.

Si consideri ad esempio un sistema per la gestione degli immobili che gestisce il processo di acquisto di una casa. Questo tipo di sistema potrebbe prevedere diversi stati quali PreapprovedCustomer, OfferAccepted, HomeInspectionCompleted e PurchaseAndSaleSigned.

Potrebbero anche esistere diverse classi che definiscono il sottosistema, ad esempio Customer, House, Seller, Visit, Offer, Lender, Appraiser, Mortgage, CreditReport, CreditBureau, ApprovalLetter, HomeInspection, PurchaseandSale, LoanApplication, ClosingContract, Commission eccetera.

In questo esempio è possibile pensare a un certo stato, ad esempio lo stato PurchaseAndSaleSigned, come comportamento aggregato di numerose classi e stati come illustrato di seguito:

Classe Stato
Customer UnderAgreement
House UnderAgreement
Seller UnderAgreement
Offer Accepted
ApprovalLetter Delivered
HomeInspection Completed
CreditReport UptoDate

Definire il flusso generale mediante il grafico di stato

Per creare uno scenario di verifica, considerare le diverse azioni necessarie per porre il sistema nello stato PurchaseAndSaleSigned. Lo scenario di verifica deve svolgere azioni individuali in modo tale che nell'esempio riportato accada quanto segue:

A questo punto è possibile creare una verifica. Il modo più semplice di svolgere queste operazioni è generare una verifica per il metodo nella prima classe con cui si desidera interagire. In questo caso è possibile selezionare il metodo getCreditReport dalla classe Cliente perché è il primo che sarà richiamato nello scenario. Quando si crea lo scenario è consigliabile aggiungere gli oggetti necessari alla verifica. Accertarsi di coprire tutti gli stati e le transizioni del sottosistema. Dopo aver terminato, definire i valori da utilizzare nello scenario. Data l'ampia gamma di potenziali scenari di verifica, è preferibile che i dati di verifica siano abbastanza semplici e utilizzino valori tipici e un numero limitato di partizioni di dati.

Definire le ulteriori verifiche per ottimizzare la copertura

Dopo la definizione di un flusso tipico mediante il diagramma del grafico di stato, definire ulteriori scenari per ottimizzare la copertura della verifica. Gli scenari devono sperimentare i diversi stati e le transizioni del sottosistema. Spesso uno scenario è simile a un altro definito precedentemente. In questa situazione, si consiglia di creare nuove verifiche basate su verifiche definite precedentemente. Nelle nuove verifiche verranno richiamati i driver delle verifiche precedentemente definite e aggiunti nuovi messaggi al nuovo diagramma di sequenza della verifica per completare il flusso.

In tal modo è possibile costruire scenari complessi riutilizzando flussi precedentemente definiti e creare soltanto le piccole variazioni necessarie a coprire i nuovi stati e le nuove transizioni.

Concetti correlati
Strategie di verifica
Tecniche di verifica basate sullo stato

Attività correlate
Verifica dei metodi Java
Verifica delle classi Java

Termini di utilizzo | Feedback
(C) Copyright IBM Corporation 2000, 2004. Tutti i diritti riservati.