Sistema Analizador de Dependencias Multi-Lenguaje (DepAnalyzer)

Informe de Arquitectura de Software

Versión 1.1

ÍNDICE GENERAL

1. Introducción
   1. Propósito (Diagrama 4+1)
   2. Alcance
   3. Definiciones, siglas y abreviaturas
   4. Organización del documento
2. Objetivos y restricciones arquitectónicas
   1. Priorización de requerimientos
      1. Requerimientos funcionales
      2. Requerimientos no funcionales
   2. Restricciones arquitectónicas
3. Representación de la arquitectura del sistema
   1. Vista de uso
      1. Diagrama de casos de uso
   2. Vista lógica
      1. Diagrama de sub-sistemas (paquetes)
      2. Diagrama de secuencia (vista de diseño)
      3. Diagrama de colaboración (vista de diseño)
      4. Diagrama de objetos
      5. Diagrama de clases
      6. Diagrama de base de datos
   3. Vista de implementación (vista de desarrollo)
      1. Diagrama de arquitectura de software
      2. Diagrama de arquitectura del sistema (diagrama de componentes)
   4. Vista de procesos
      1. Diagrama de procesos del sistema (diagrama de actividades)
   5. Vista de despliegue
      1. Diagrama de despliegue
4. Atributos de calidad del software
   1. Escenario de funcionalidad
   2. Escenario de usabilidad
   3. Escenario de confiabilidad
   4. Escenario de rendimiento
   5. Escenario de mantenibilidad
   6. Otros escenarios de calidad
5. Evidencias de calidad y pruebas

1. Introducción

1.1 Propósito (Diagrama 4+1)

Este informe describe la arquitectura de software de DepAnalyzer siguiendo el enfoque 4+1, articulando las vistas de uso, lógica, implementación, procesos y despliegue, y vinculándolas con los requerimientos establecidos en FD03 y las restricciones de FD01/FD02.

Las decisiones de arquitectura priorizan:

• Cobertura funcional del análisis de dependencias multi-ecosistema (Maven, Gradle, npm y Python).
• Seguridad operativa en la actualización de versiones (confirmación explícita y backup).
• Interoperabilidad para CI/CD (salida JSON y códigos de salida).
• Mantenibilidad mediante separación modular del código.

1.2 Alcance

Este documento cubre la arquitectura del sistema implementado en la versión actual del proyecto, incluyendo:

• Flujo de análisis (analyze) y visualización interactiva (tui).
• Flujo de remediación guiada (update) con --dry-run y respaldo .bak.
• Integración con OSS Index y NVD mediante selección de fuente (--oss, --nvd o modo automático).
• Estructura de paquetes, componentes y comunicación interna.

No se incluye una arquitectura de aplicación web o móvil, ni persistencia basada en una base de datos relacional, porque el producto es una herramienta CLI/TUI local orientada a archivos y APIs externas.

1.3 Definiciones, siglas y abreviaturas

1.4 Organización del documento

• Sección 2: presenta objetivos arquitectónicos y priorización de requerimientos.
• Sección 3: documenta las vistas arquitectónicas con diagramas Mermaid.
• Sección 4: define escenarios de atributos de calidad con criterios verificables.

2. Objetivos y restricciones arquitectónicas

2.1 Priorización de requerimientos

2.1.1 Requerimientos funcionales

2.1.2 Requerimientos no funcionales

2.2 Restricciones arquitectónicas

3. Representación de la arquitectura del sistema

3.1 Vista de uso

Esta vista muestra cómo los actores interactúan con las capacidades centrales del sistema.

3.1.1 Diagrama de casos de uso

flowchart LR
    U[Usuario técnico] --> UC1[Analizar proyecto]
    U --> UC2[Exportar reporte JSON]
    U --> UC3[Visualizar TUI]
    U --> UC4[Actualizar dependencias guiadas]
    U --> UC5[Simular actualizaciones]
    U --> UC6[Fallar build por CVE crítico]
    CI[Pipeline CI/CD] --> UC1
    CI --> UC2
    CI --> UC6

3.2 Vista lógica

La vista lógica refleja la descomposición del sistema en subsistemas y sus colaboraciones.

3.2.1 Diagrama de sub-sistemas (paquetes)

flowchart TD
    CLI[cli]
    CORE[core]
    PARSER[parser]
    REPO[repository]
    REPORT[report]
    UPDATE[update]
    TUI[tui]
    SECURITY[security]
    GRAPH[core.graph]
    CLI --> CORE
    CLI --> TUI
    CLI --> UPDATE
    CORE --> PARSER
    CORE --> REPO
    CORE --> REPORT
    CORE --> GRAPH
    UPDATE --> CORE
    UPDATE --> PARSER
    UPDATE --> REPORT
    REPO --> SECURITY

3.2.2 Diagrama de secuencia (vista de diseño)

sequenceDiagram
    actor Usuario
    participant CLI as DepAnalyzerCli
    participant PA as ProjectAnalyzer
    participant PD as ProjectDetector
    participant PR as Parser Maven/Gradle
    participant RC as RepositoryClient
    participant OI as OssIndexClient
    participant NVD as NvdClient
    participant RG as ReportGenerator
    Usuario ->> CLI: analyze . --nvd -o json
    CLI ->> PA: analyze(request)
    PA ->> PD: detect(projectPath)
    PD -->> PA: ProjectType
    PA ->> PR: parse dependencies/repositories
    PR -->> PA: dependencies + repositories
    PA ->> RC: getLatestVersion(...)
    RC -->> PA: latest versions
    PA ->> OI: getVulnerabilities(...)
    OI -->> PA: vulns OSS Index
    PA ->> NVD: getVulnerabilities(...)
    NVD -->> PA: vulns NVD
    PA -->> CLI: DependencyReport
    CLI ->> RG: toJson(report)
    RG -->> Usuario: dependency-report.json

3.2.3 Diagrama de colaboración (vista de diseño)

flowchart LR
    A[1 Usuario invoca comando] --> B[2 DepAnalyzerCli coordina flujo]
    B --> C[3 ProjectAnalyzer orquesta análisis]
    C --> D[4 ProjectDetector]
    C --> E[5 Parsers]
    C --> F[6 RepositoryClient]
    C --> G[7 OssIndexClient]
    C --> H[8 NvdClient opcional]
    C --> I[9 ReportGenerator/ConsoleRenderer]
    B --> J[10 UpdateCommand/UpdatePlanner]
    J --> K[11 BuildFileUpdater + BuildFileBackup]

3.2.4 Diagrama de objetos

classDiagram
    class cmd_Analyze {
        command = "analyze"
        useNvd = true
        output = "json"
    }

    class analyzer_ProjectAnalyzer {
        projectType = "GRADLE_KOTLIN"
        timeout = 1800
    }

    class report_DependencyReport {
        projectName = "demo-app"
        outdatedCount = 6
        vulnerableCount = 4
    }

    class updater_UpdatePlan {
        suggestions = 3
        dryRun = false
    }

    cmd_Analyze --> analyzer_ProjectAnalyzer: executes
    analyzer_ProjectAnalyzer --> report_DependencyReport: builds
    report_DependencyReport --> updater_UpdatePlan: optional remediation

3.2.5 Diagrama de clases

classDiagram
    class Depanalyzer
    class Analyze
    class Tui
    class Update

    class ProjectAnalyzer {
        +analyze(projectDir, ...): DependencyReport
    }

    class ProjectDetector {
        +detect(directory): ProjectType
    }

    class RepositoryClient {
        +getLatestVersion(repository, groupId, artifactId): String?
    }

    class OssIndexClient {
        +getVulnerabilities(dependencies): Map
    }

    class NvdClient {
        +getVulnerabilities(dependencies): Map
    }

    class DependencyReport
    class ReportGenerator
    class ConsoleRenderer

    class AnalyzerUpdatePlanner {
        +plan(projectDir, options): UpdatePlan
    }

    class BuildFileUpdater {
        <<interface>>
        +applyUpdate(file, suggestion): Boolean
    }

    class PomBuildFileUpdater
    class GradleGroovyBuildFileUpdater
    class GradleKotlinBuildFileUpdater
    class BuildFileBackup

    Analyze --> ProjectAnalyzer
    Tui --> ProjectAnalyzer
    Update --> AnalyzerUpdatePlanner
    ProjectAnalyzer --> ProjectDetector
    ProjectAnalyzer --> RepositoryClient
    ProjectAnalyzer --> OssIndexClient
    ProjectAnalyzer --> NvdClient
    ProjectAnalyzer --> DependencyReport
    ReportGenerator --> DependencyReport
    ConsoleRenderer --> DependencyReport
    AnalyzerUpdatePlanner --> BuildFileUpdater
    BuildFileUpdater <|.. PomBuildFileUpdater
    BuildFileUpdater <|.. GradleGroovyBuildFileUpdater
    BuildFileUpdater <|.. GradleKotlinBuildFileUpdater
    BuildFileBackup --> BuildFileUpdater

3.2.6 Diagrama de base de datos

El sistema no utiliza una base de datos relacional. El almacenamiento se realiza sobre archivos del proyecto analizado y salidas generadas por la herramienta.

flowchart LR
    A[Proyecto Java] --> B[pom.xml / build.gradle / build.gradle.kts]
    B --> C[Parsers y updaters]
    C --> D[build file actualizado]
    C --> E[backup .bak]
    C --> F[dependency-report.json]

3.3 Vista de implementación (vista de desarrollo)

Describe cómo el diseño lógico se materializa en componentes de código y capas de responsabilidad.

3.3.1 Diagrama de arquitectura de software

flowchart TD
    subgraph C1[Presentación]
        CLI[CLI Commands]
        TUI[TUI App]
    end

    subgraph C2[Aplicación]
        CORE[ProjectAnalyzer]
        UPD[UpdatePlanner/Updater]
    end

    subgraph C3[Dominio y Reporte]
        MODEL[DependencyReport / Vulnerability]
        RENDER[ConsoleRenderer / ReportGenerator]
    end

    subgraph C4[Infraestructura]
        PARSERS[Parsers Maven/Gradle]
        REPOS[RepositoryClient]
        OSS[OssIndexClient]
        NVD[NvdClient]
        SAFE[InputSafety]
    end

    CLI --> CORE
    TUI --> CORE
    CLI --> UPD
    CORE --> MODEL
    CORE --> RENDER
    CORE --> PARSERS
    CORE --> REPOS
    CORE --> OSS
    CORE --> NVD
    REPOS --> SAFE

3.3.2 Diagrama de arquitectura del sistema (diagrama de componentes)

flowchart LR
    C0[DepAnalyzerCli.kt] --> C1[ProjectAnalyzer.kt]
    C0 --> C2[UpdateCommand.kt]
    C0 --> C3[AnalyzeTuiApp.kt]
    C1 --> C4[ProjectDetector.kt]
    C1 --> C5[PomDependencyParser.kt]
    C1 --> C6[GradleGroovyDependencyParser.kt]
    C1 --> C7[GradleKotlinDependencyParser.kt]
    C1 --> C8[RepositoryClient.kt]
    C1 --> C9[OssIndexClient.kt]
    C1 --> C10[NvdClient.kt]
    C1 --> C11[ReportGenerator.kt]
    C1 --> C12[ConsoleRenderer.kt]
    C2 --> C13[UpdatePlanner.kt]
    C2 --> C14[BuildFileUpdater.kt]
    C2 --> C15[BuildFileBackup.kt]
    C8 --> C16[InputSafety.kt]

3.4 Vista de procesos

Modela la coordinación de tareas en ejecución, incluyendo escenarios de degradación por fallas externas.

3.4.1 Diagrama de procesos del sistema (diagrama de actividades)

flowchart TD
    A([Inicio]) --> B[Recibir comando CLI/TUI]
    B --> C[Detectar tipo de proyecto]
    C --> D[Parsear dependencias y repositorios]
    D --> E[Consultar versiones recientes]
    E --> F[Consultar CVEs OSS Index]
    F --> G{--nvd}
    G -- Sí --> H[Consultar NVD y fusionar resultados]
    G -- No --> I[Continuar]
    H --> J[Construir DependencyReport]
    I --> J
    J --> K{output json}
    K -- Sí --> L[Generar dependency-report.json]
    K -- No --> M[Renderizar consola/TUI]
    L --> N{usuario ejecuta update}
    M --> N
    N -- Sí --> O[Planificar sugerencias]
    O --> P{confirmación usuario}
    P -- Sí --> Q[Crear backup y aplicar cambios]
    P -- No --> R[Registrar omitidas]
    N -- No --> S([Fin])
    Q --> S
    R --> S

3.5 Vista de despliegue

Presenta escenarios de ejecución física del sistema en local y en CI.

3.5.1 Diagrama de despliegue

flowchart TD
    subgraph Local[Entorno Local Desarrollador]
        U[Usuario]
        BIN[depanalyzer / depanalyzer.bat / depanalyzer.exe]
        JDK[JDK 25+]
        PROJ[Proyecto Java objetivo]
        OUT[dependency-report.json / .bak]
    end

    subgraph External[Servicios Externos]
        OSS[OSS Index API]
        NVD[NVD API]
        REPO[Maven/Repositorios remotos]
    end

    subgraph CI[GitHub Actions]
        WF[Workflow test.yml]
        REL[Workflow release-native.yml]
    end

    U --> BIN
    BIN --> JDK
    BIN --> PROJ
    BIN --> OUT
    BIN --> OSS
    BIN --> NVD
    BIN --> REPO
    WF --> BIN
    REL --> BIN

4. Atributos de calidad del software

4.1 Escenario de funcionalidad

4.2 Escenario de usabilidad

4.3 Escenario de confiabilidad

4.4 Escenario de rendimiento

4.5 Escenario de mantenibilidad

4.6 Otros escenarios de calidad

4.6.1 Seguridad

4.6.2 Interoperabilidad

5. Evidencias de calidad y pruebas

Los reportes se publican en GitHub Pages para centralizar la evidencia solicitada por el curso. La URL base del sitio es:

https://upt-faing-epis.github.io/proyecto-si784-2026-i-u1-analizador-de-dependencias/

Los reportes de Sonar y Snyk dependen de los secretos SONAR_TOKEN y SNYK_TOKEN configurados en GitHub. Si esos secretos no están disponibles, el workflow publica una página de estado indicando la configuración pendiente sin bloquear la publicación del resto de evidencias.

6. Ingeniería Inversa e Infraestructura

Los diagramas se contrastaron con src/main/kotlin, build.gradle.kts, .github/workflows e infrastructure/terraform; representan componentes implementados.

flowchart TD
    REPO[Repositorio] --> CI[CI]
    REPO --> QUALITY[Quality and Pages]
    REPO --> RELEASE[Native Release]
    REPO --> TF[Terraform]
    QUALITY --> JACOCO[JaCoCo >= 70%]
    QUALITY --> PIT[PIT]
    QUALITY --> BDD[Cucumber]
    QUALITY --> UI[Playwright + videos]
    QUALITY --> STATIC[Sonar + Semgrep + Snyk]
    QUALITY --> PAGES[GitHub Pages]
    RELEASE --> BIN[Binarios multiplataforma]
    TF --> ENV[Environment github-pages]
    TF --> VARS[Variables de calidad]