Backtesting

DD-BACKTESTING.md

Versione: 2.0 (resto del documento)

DD-BACKTESTING.md

Versione: 2.0 Data: 2025-10-26 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à: Agisce come pannello di controllo reattivo per il backtesting. Non raccoglie più direttamente gli input di contesto (ticker, date), ma reagisce ai cambiamenti dello stato globale gestito da AppState. Il suo compito è avviare le operazioni e presentare i risultati finali.

• 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-CONNECTORS.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, state-driven e progettato per garantire il disaccoppiamento.

1. Impostazione del Contesto (Stato Globale): L’utente definisce il contesto per l’analisi: a. Seleziona un ticker dal WatchlistManagerTab. b. Imposta l’intervallo di date globale tramite i controlli nella Toolbar principale. c. Queste azioni aggiornano le proprietà current_ticker e global_date_range in AppState.

2. Azione (UI): L’utente clicca il pulsante “Run Backtest” nel BacktestTabWidget.

3. Orchestrazione (Thread Principale): MainWindow istanzia il BacktestWorker. Il worker recupera i parametri di contesto (ticker, date) direttamente da AppState e viene avviato in un thread separato.

4. Esecuzione (Thread in Background): Il BacktestWorker esegue i seguenti passaggi in sequenza: a. Richiede i dati storici al DataManager usando i parametri di contesto. b. Passa i dati e la strategia al BacktestEngine. c. Riceve dal motore la lista grezza delle operazioni. d. Calcola un set completo di risultati: statistiche, metriche di performance, curva di equity, log delle operazioni, etc. e. Impacchetta tutti questi dati in un unico dizionario results.

5. Comunicazione (Segnale): Una volta completata l’elaborazione, il BacktestWorker emette un segnale finished(results).

6. Visualizzazione (UI): a. BacktestTabWidget riceve il dizionario results. b. I dati vengono smistati ai vari componenti UI (tabella delle statistiche, TradeLogWidget, ChartingTabsWidget).

---

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.