¿Qué es la arquitectura de software? Parte 1


1. Definición Core & Pilares

La arquitectura es la estructura de alto nivel del sistema (elementos, propiedades externas y relaciones). Se centra en la abstracción y omite detalles internos de implementación.

  • Abstracción: Ocultar detalles sin importancia para simplificar.
  • Descomposición: Separar preocupaciones (separation of concerns).
  • Composición: Coordinar e integrar los componentes.

Proactividad vs. Ingeniería Inversa: Diseñar y documentar la arquitectura antes de codificar. Reconstruirla mediante ingeniería inversa del código no es óptimo porque el código real suele divergir del diseño original y carece de abstracción.


2. Herramientas de Descripción

Los sistemas complejos requieren múltiples herramientas y perspectivas:

Vistas Arquitectónicas (Modelos 4+1)

  • Vista Lógica: Estructura conceptual del diseño.
  • Vista de Desarrollo: Organización física de módulos y archivos.
  • Vista de Proceso: Hilos, concurrencia, rendimiento.
  • Vista Física (Despliegue): Distribución en hardware y red.

Estilos vs. Patrones vs. Marcos

  • Estilos: Restricciones estructurales a nivel global (ej. Arquitectura en Capas, Tuberías y Filtros).
  • Patrones: Soluciones concretas a problemas comunes (ej. MVC, Cliente-Servidor).
  • Marcos (Frameworks): Convenciones estandarizadas para el modelado en dominios grandes (ej. DoDAF, TOGAF).

3. Niveles y Procesos de Diseño

La arquitectura ocurre a tres niveles:

  1. Nivel Empresarial: Alineación de TI con procesos y objetivos del negocio (Arquitectura Empresarial).
  2. Nivel de Sistema: Definición de componentes del software y sus conexiones.
  3. Nivel de Componente: Diseño estructural de módulos individuales.

El Proceso de Síntesis

Consiste en equilibrar restricciones (requisitos funcionales vs. atributos de calidad y negocio).

  • Atributos de Calidad: Rendimiento, seguridad, escalabilidad, confiabilidad.
  • Compromisos (Trade-offs): Es imposible optimizar todo a la vez (ej. rendimiento vs. seguridad).
  • Rationale (Justificación): Registrar el por qué de cada decisión es crucial para mitigar la deuda técnica y facilitar el mantenimiento a largo plazo.

4. Evaluación de la Arquitectura

Debe realizarse de forma continua a lo largo del ciclo de vida del software.

Preguntas Clave para Auto-evaluación

  1. ¿Satisface los requisitos funcionales y de calidad?
  2. ¿Respeta las restricciones tecnológicas y de negocio?
  3. ¿Equilibra bien las prioridades en conflicto (ej. seguridad vs. performance)?
  4. ¿Es flexible a cambios y comprensible para el equipo de desarrollo?

Técnicas de Evaluación

  • Análisis de casos de uso y evaluación de riesgos.
  • Checklists y cuestionarios basados en buenas prácticas.
  • Modelado matemático, simulación y prototipado.
  • Revisiones de expertos (walkthroughs, inspecciones).

Métricas de Control

  • Estructurales: Acoplamiento, cohesión, complejidad ciclomática, tamaño de componentes.
  • De Calidad: Tiempo de respuesta, densidad de defectos, porcentaje de reusabilidad.

Articulo análizado