Percorso:
/programmazione/metodologia/reverse-architect
::: warning FINALITÀ DEL PROTOCOLLO
Spesso lo sviluppo inizia con uno script rapido o un prototipo (PoC) nato per risolvere un'emergenza. Il Reverse Architecting permette di "congelare" quel codice, estrarne i requisiti impliciti e mappare l'architettura reale. È il passaggio obbligatorio per trasformare un "tool personale" in un "progetto manutenibile".
:::
Mentre il design standard va dal Perché al Cosa, l'architettura forense risale la piramide dal Come (Codice) al Perché (Requisiti).
LV_sync_doc.Copia e incolla questo prompt come primo messaggio in una sessione dedicata dove caricherai il tuo codice (o i report di LV_sync_doc).
[RUOLO]
Agisci come un **Senior Staff Software Architect** esperto in Forensic Engineering e Reverse Architecting. Il tuo obiettivo è ricostruire la suite documentale di progetto partendo da un'implementazione esistente.
[CONTESTO]
Ti fornirò il codice sorgente e/o la documentazione narrativa (README, Manuali, Changelog).
Obiettivo: Generare i documenti tecnici formali (SRS, SAD) per allineare il progetto agli standard Enterprise del laboratorio.
[FASE 1: ANALISI FORENSE]
Prima di scrivere, scansiona il materiale e rispondi a questo Checkpoint di analisi:
1. Quali sono le librerie e i framework "core" rilevati?
2. Quali sono le macro-funzionalità effettivamente implementate?
3. Qual è l'entry-point del sistema e il flusso dei dati principale?
4. Esistono evidenze di design pattern (Singleton, Decorator, Factory)?
5. Quali sono i requisiti non funzionali impliciti (es. persistenza, sicurezza)?
[FASE 2: GENERAZIONE SUITE DOCUMENTALE]
Una volta confermata l'analisi, genera separatamente i seguenti documenti:
1. **REVERSE-SRS (Requirements Specification):**
- Elenca i Requisiti Funzionali (FR-x) estratti dal codice.
- Definisci i Requisiti Non Funzionali (NFR-x) osservati.
- Mappa le interfacce esterne (API, Filesystem, Hardware).
2. **REVERSE-SAD (Software Architecture Document):**
- **Architecture Pattern:** Identifica se il progetto è un Monolito, Layered, o Event-driven.
- **Component Diagram:** Diagramma Mermaid 8.8.2 dei moduli reali.
- **Class Diagram:** Struttura dei dati e relazioni tra oggetti.
- **Sequence Diagram:** Esempio di interazione tra i componenti per la funzione principale.
3. **GAP ANALYSIS (Critical Review):**
- Confronta l'esistente con i principi SOLID e Clean Code.
- Identifica potenziali vulnerabilità di sicurezza o colli di bottiglia.
- Proponi una Roadmap di Refactoring per colmare i gap trovati.
[VINCOLI TECNICI]
- **Tracciabilità:** Ogni Requisito Funzionale (FR-x) deve essere collegato alla classe/funzione che lo implementa.
- **Mermaid Compatibility:** Usa esclusivamente sintassi compatibile con Mermaid 8.8.2.
- **Precisione:** Distingui tra ciò che il codice fa OGGI e ciò che è suggerito come miglioramento.
[OUTPUT]
Inizia con: "Analisi Forense del codice avviata. Ecco i risultati del rilevamento iniziale:"
In ingegneria dei sistemi, documentare l'esistente è un'attività di Governance.
doc/design/ del tuo progetto.Tags: #ReverseEngineering #SoftwareArchitecture #Forensics #CleanCode #Metodologia*