Quartz 4

Backtesting

3 min read

DD-BACKTESTING.md

Versione: 1.0 Data: 2025-10-10 Scopo: Descrivere in dettaglio l’architettura, i pattern e il flusso di dati del sottosistema di Backtesting. Documento Principale: FIRE 25.07 - ARCHITECTURE-OVERVIEW

1. Panoramica e Responsabilità

Il sottosistema di Backtesting è il cuore analitico di FIRE. La sua responsabilità principale è eseguire una strategia di trading su un set di dati storici per simularne il comportamento e valutarne la performance in modo oggettivo.

Il sistema è progettato per produrre un’analisi di livello istituzionale, fornendo non solo un log delle operazioni, ma un set completo di metriche di rischio/rendimento e visualizzazioni grafiche per una valutazione approfondita.

2. Architettura e Componenti Chiave

Il sottosistema segue rigorosamente il principio della “UI 100% Reattiva”. La logica di business è completamente disaccoppiata dall’interfaccia utente per garantire che calcoli potenzialmente lunghi non blocchino mai l’applicazione.

  • BacktestTabWidget (Componente UI):

    • Responsabilità: Raccogliere gli input dell’utente (ticker, intervallo di date, strategia selezionata, opzioni di visualizzazione) e presentare i risultati finali. Agisce da orchestratore lato UI ma non contiene logica di business.

  • BacktestWorker (Worker Asincrono - QRunnable):

    • Responsabilità: Orchestrare l’intero processo di backtesting in un thread separato. È il punto di contatto tra il mondo della UI e la logica di calcolo. Non interagisce mai direttamente con i widget, ma comunica i risultati tramite segnali Qt.

  • DataManager (Servizio Core):

    • Responsabilità: Fornire i dati storici richiesti dal worker. Abstrae la fonte dei dati (CSV, API, etc.).
    • Approfondimento: DD-DATA-MANAGEMENT.md

  • BacktestEngine (Motore di Calcolo):

    • Responsabilità: Eseguire il ciclo di backtesting “barra per barra” (iterativo). Applica la logica della strategia (init/next) ai dati storici e restituisce la lista grezza delle operazioni (trades) generate.

  • ChartingTabsWidget e altri widget di visualizzazione:

    • Responsabilità: Ricevere i dati elaborati e visualizzarli in formati appropriati (grafico a candele, curva di equity, tabella delle statistiche, log delle operazioni).

3. Flusso dei Dati

Il flusso di dati è unidirezionale e progettato per garantire il disaccoppiamento e la reattività.

  1. Input (UI): L’utente definisce i parametri nel BacktestTabWidget e avvia l’analisi.
  2. Orchestrazione (Thread Principale): MainWindow istanzia il BacktestWorker, gli passa i parametri necessari e lo avvia in un thread separato. L’interfaccia utente rimane immediatamente disponibile per altre interazioni.
  3. Esecuzione (Thread in Background): Il BacktestWorker esegue i seguenti passaggi in sequenza: a. Richiede i dati storici al DataManager. b. Passa i dati e la strategia al BacktestEngine per l’esecuzione del ciclo iterativo. c. Riceve dal motore la lista grezza delle operazioni. d. Calcola un set completo di risultati: statistiche di base, metriche di performance avanzate (Max Drawdown, Sharpe Ratio, Calmar Ratio, etc.), la curva di equity, il log delle operazioni e dati di analisi aggiuntivi (es. regimi di volatilità). e. Impacchetta tutti questi dati in un unico dizionario results.
  4. Comunicazione (Segnale): Una volta completata l’elaborazione, il BacktestWorker emette un segnale finished(results).
  5. Visualizzazione (UI): a. MainWindow (o BacktestTabWidget) riceve il dizionario results. b. I dati vengono smistati ai vari componenti UI: - Le statistiche popolano un modello dati (BacktestStatsModel). - Il log delle operazioni viene inviato al TradeLogWidget. - I dati per i grafici (prezzi, equity, segnali) vengono inoltrati al ChartingTabsWidget, che agisce da router per aggiornare i singoli grafici.

4. Guide Pratiche (Opzionale)

Al momento non sono state identificate guide pratiche specifiche per questo sottosistema che non siano già coperte dalla documentazione dell’API delle Strategie.

Graph View