Fase 0: Contexto y Funciones de la Arquitectura de un Sistema

La arquitectura de un sistema define la estructura, identificando componentes como módulos o clases y cómo se organizan e interconectan. Especifica la comunicación entre componentes, incluyendo interfaces y protocolos. Plantea requerimientos no funcionales, abarcando restricciones técnicas y de negocio, y atributos de calidad como rendimiento y seguridad. Funciona como una abstracción simplificada del sistema con varias vistas: la Vista Lógica, que muestra elementos funcionales y su interacción; la Vista de Proceso, centrada en procesos y manejo de información; la Vista Física, que describe la distribución en el hardware; y la Vista de Desarrollo, que enfoca en organización del código y dependencias.

Los Tres Pilares Básicos de la Arquitectura de Software

Los tres pilares básicos de cualquier arquitectura de software son:

  • Componentes: Unidades fundamentales como funciones o microservicios que encapsulan la lógica de negocio.
  • Relación entre los componentes: Define cómo estos interactúan mediante interfaces y protocolos, afectando la modularidad y escalabilidad.
  • Ambiente: Entorno operativo incluyendo infraestructura, sistemas operativos y hardware, esencial para el diseño y operación del sistema.

Juntos, estos elementos aseguran que la arquitectura del sistema sea robusta y eficiente.

El Arquitecto de Software

El Arquitecto de Software diseña sistemas cumpliendo requisitos funcionales y no funcionales y difiere del ingeniero de software que implementa el diseño. Sus funciones incluyen:

  • Administración de riesgo: Proponiendo estrategias para mitigar riesgos del proyecto.
  • Conocimiento de la tecnología: Eligiendo las tecnologías adecuadas basándose en requisitos del sistema.
  • Excelentes habilidades de diseño: Para crear soluciones técnicas escalables y seguras.
  • Interfaz entre cliente y equipo técnico: Traduciendo necesidades de negocio en requerimientos técnicos.
  • Promoción de buenas prácticas de desarrollo.
  • Puente de comunicación entre equipos de desarrollo: Facilitando la colaboración en grandes organizaciones.

Requisitos Funcionales (RF)

Reflejan el comportamiento del sistema, las funciones con las que debe cumplir un sistema.

  • De negocio: La motivación del negocio para que el sistema exista.
  • De usuario: Comportamiento del sistema, descritos como casos de uso.
  • Funcionales detallados: Complemento de los casos de uso. Se describen con el verbo “deber”.
  • De sistema: Describen el hardware y software para que el sistema pueda funcionar.

Requisitos No Funcionales (RNF)

  • Rendimiento: Capacidad del sistema para operar eficientemente (Throughput: tasa efectiva de transacciones, Tiempo de respuesta: tiempo de espera de un sistema interactivo, Deadlines: tiempo que tarda un proceso no interactivo).
  • Escalabilidad: Habilidad del sistema para manejar aumentos de carga (Carga: tps, Conexiones simultáneas, Volumen de datos, Despliegue, escalabilidad horizontal y vertical).
  • Mantenibilidad: Facilidad con la que el sistema puede ser modificado para corregir defectos, mejorar rendimiento o adaptarse a cambios en el entorno (Modificable, Adaptabilidad a nuevos requerimientos funcionales).
  • Seguridad: Facultad del sistema de resistir ataques. Mientras más seguridad tenga un sistema más lento es generalmente (Autenticación: validar acceso y Autorización: permitir uso de componentes por roles, Encriptación: cifrar info, Integridad: asegurar no malversación de datos y No repudio: asegurar que la comunicación llegó al destinatario correcto).
  • Confiabilidad: Capacidad del sistema para funcionar correctamente y sin fallos durante un período determinado bajo condiciones específicas (Disponibilidad: el sistema debe estar preparado para recibir peticiones y responder, Recuperable: en caso de falla el sistema debe poder volver a su estado funcional, 5 9s: porcentaje ideal de disponibilidad).
  • Integrabilidad: Capacidad del sistema de agregar componentes externos (Interoperabilidad: funcionamiento correcto entre distintos sistemas y APIs).
  • Portabilidad: Capacidad del sistema para operar en diferentes entornos de hardware o software (Independencia de plataforma).
  • Verificabilidad: Capacidad del sistema de autochequearse.
  • Soportabilidad: Diagnóstico y Corrección de incidencias.

Fase 1: Estructuración (Identificar Componentes y sus Relaciones)

Repositorio

Gestión centralizada con almacenamiento centralizado/distribuido, modelo pasivo (A petición del usuario se verifica si existió un cambio en el repositorio) y proactivo (Avisa a los usuarios interesados a con los datos que existió un cambio en el repositorio).

  • Ventajas: administración centralizada, seguridad, escalabilidad, mantenibilidad.
  • Desventajas: rigidez del modelo de datos y punto único de falla.

Cliente/Servidor

Basado en servidores que ofrecen servicios, clientes que los requieren y redes que los conectan, parcialmente distribuido.

  • Ventajas: datos y procesamiento distribuidos, escalabilidad.
  • Desventajas: administración de datos por servidor, rendimiento afectado por comunicaciones, y falta de registro centralizado de servicios.

Modelo de Capas

Capas de software con interfaces definidas, desarrollo independiente, todas las capas deben participar.

  • Ventajas: desarrollo incremental, flexibilidad, mantenibilidad.
  • Desventajas: difícil estructuración y dependencias cruzadas.

Objetos Distribuidos

Componentes que definen datos y métodos invocables, comunicación vía ORB (Object Request Broker).

  • Ventajas: diseño flexible, fácil agregar objetos, escalable y configuración dinámica.
  • Desventajas: complejidad en construcción y bajo rendimiento.

SOA (Arquitectura Orientada a Servicios)

Bus de servicios: Punto focal de la arquitectura SOA; Gestiona las transacciones que recibe; Administra los clientes y servicios conectados; Redirige las transacciones de los clientes hacia los servicios que van a procesarlas; Retorna a los clientes correspondientes las transacciones de respuesta de los servicios, permite anonimato entre cliente y servidor.

Servicios: Proceso que implementa una o mas funcionalidades; Se conecta al bus y se identifica como servicio, usando la transaccion sinit; Queda activo en espera de transacciones.

  • Ventajas: reutiliza sistemas existentes, bajo nivel de acoplamiento, escalabilidad, mantenibilidad, interoperabilidad y reusabilidad.
  • Desventajas: alta dependencia de estandares, baja performance (latencia del bus), bus unico punto de falla.

Cloud Computing

Externalización de servicios computacionales como IaaS, PaaS, SaaS, recursos elásticos (pay what you use).

  • Ventajas: servicios ubicuos, reducción de costos, disponibilidad, escalabilidad, elasticidad, flexibilidad, movilidad, disponibilidad.
  • Desventajas: dependencia de entes externos afectando seguridad y confidencialidad.

Fase 2: Modelo de Control (Comportamiento de los Componentes)

Evalúa el flujo de datos entre componentes, utilizando:

Control Centralizado

Un único ente que controla todo mediante el Modelo Call-Return, que es simple, predecible, rígido, testeable, secuencial, bloqueante, y tiene un manejo complejo de excepciones. Además, el Modelo Administrador multiproceso coordina la ejecución sin bloqueos, pero puede generar cuellos de botella si falla.

Control Descentralizado

Control Basado en Eventos es no bloqueante y se maneja mediante:

  1. Transmisión Múltiple PUB/SUB: Componentes publicadores y suscriptores interactúan.
    • Ventajas: Distribución, modelo no monolítico, activación de eventos en función de las alertas.
    • Desventajas: Respuesta incierta con delay, no existe garantía de respuesta, varios manejadores de un mismo evento.
  2. Manejo de Interrupciones: Para eventos de alta prioridad que requieren respuesta inmediata y procesamiento paralelo, típico en sistemas que deben comunicarse en tiempo real, como en arquitecturas SOA, Cliente-servidor y objetos distribuidos.

Este modelo facilita la predicción y coordinación en sistemas complejos.