Definiciones Clave en Arquitectura de Software
“La arquitectura representa las decisiones de diseño significativas que configuran un sistema, donde la importancia se mide por el costo del cambio.” (G. Booch)
“La arquitectura es una hipótesis que debe demostrarse mediante la implementación y las mediciones.” (T. Gilb)
“La arquitectura son las decisiones que desearías poder tomar correctamente al principio de un proyecto, pero no necesariamente tienes más probabilidades de acertar que con cualquier otra cosa.” (R. Johnson)
“La arquitectura se define, según la práctica recomendada, como la organización fundamental de un sistema, materializada en sus componentes, sus relaciones entre sí y con el entorno, y los principios que rigen su diseño y evolución.” (IEEE)
“La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema, que comprenden los elementos de software, las propiedades visibles externamente de dichos elementos y las relaciones entre ellos.” (L. Bass)
“La única manera de ir rápido es ir bien.” (R. Martin)
“Si crees que la buena arquitectura es cara, prueba con la mala arquitectura.” (B. Foote & J. Yoder)
“Todo beneficio obtenido tiene un costo asociado.” (JRG)
Funciones de la Arquitectura
- Define la estructura del sistema.
- Especifica la comunicación entre componentes.
- Establece restricciones técnicas y de negocio.
- Define atributos de calidad.
- Abstrae el sistema en diferentes vistas (lógica, física, de desarrollo, de procesos).
Funciones del Arquitecto de Software
- Administrar riesgos técnicos y de proyecto.
- Conocer y evaluar tecnologías emergentes y establecidas.
- Poseer sólidas habilidades de diseño de sistemas.
- Actuar como interfaz entre el cliente y el equipo técnico.
- Promover y aplicar buenas prácticas de desarrollo.
- Servir como puente de comunicación entre diferentes equipos de desarrollo.
Requisitos No Funcionales (Atributos de Calidad)
- Performance (Rendimiento): Capacidad del sistema para ofrecer una respuesta eficiente bajo carga.
- Escalabilidad: Habilidad para manejar un aumento de carga sin degradar el servicio o rendimiento.
- Mantenibilidad: Facilidad con la que se pueden agregar, modificar o quitar funcionalidades, corregir errores o adaptar el software.
- Seguridad:
- Usuario: Autenticación, autorización y perfilamiento.
- Datos: Encriptación, integridad, no repudio.
- Confiabilidad (Fiabilidad): Capacidad del sistema para operar sin fallos, incluyendo alta disponibilidad (medida en ‘nueves’), uso de réplicas, bajo acoplamiento y estrategias activo-activo / activo-pasivo.
- Integrabilidad: Facilidad para integrarse con APIs y sistemas externos.
- Portabilidad: Capacidad del sistema para operar en diferentes plataformas o entornos siendo agnóstico a ellas.
- Verificabilidad: Facilidad para verificar el correcto funcionamiento mediante pruebas automatizadas (autotest), transacciones simuladas (dummy), etc.
- Soportabilidad: Facilidad para operar y mantener el sistema en producción, incluyendo Integración Continua/Despliegue Continuo (CI/CD), registros (logs), documentación clara y bitácoras de procesos.
Fases del Diseño de Software Arquitectónico
Contexto: Comprender el ambiente operativo, los requerimientos funcionales (FN) y no funcionales (NF), y las restricciones del proyecto.
Estructuración: Identificar los componentes principales del sistema y sus relaciones. Se utilizan diagramas de bloques, diagramas de flujo de datos e interfaces. Se consideran estilos arquitectónicos como Cliente-Servidor (CL-SV), Arquitectura Orientada a Servicios (SOA), Capas, Repositorio, Sistemas Distribuidos, Cloud, etc.
Modelo de Control: Definir el comportamiento dinámico de los componentes y cómo interactúan entre sí para cumplir los requerimientos del sistema.
Descomposición Modular: Dividir el sistema en módulos o unidades más pequeñas y manejables. Existen diferentes enfoques:
3.1 Modelo de Objetos: El sistema se estructura en componentes independientes (funciones, objetos, módulos, subsistemas, etc.) que se comunican entre sí según los requerimientos del procesamiento.
3.2 Flujo de Datos: La descomposición se basa en las transformaciones que se aplican a los datos a medida que fluyen por el sistema. Cada proceso transforma los datos que recibe antes de entregarlos al siguiente.
Patrones y Estilos Arquitectónicos Comunes
Objetos Distribuidos
Los objetos pueden proveer y recibir servicios. Se comunican a través de un ORB (Object Request Broker). Es una arquitectura inherentemente compleja.
Ventajas:
- Flexible.
- Fácil adición de nuevos objetos/servicios.
- Configuración dinámica.
- Escalabilidad.
- Mantenibilidad.
Desventajas:
- Complejo de construir y gestionar.
- Potenciales problemas de rendimiento debido a la comunicación remota.
Cliente-Servidor
Modelo donde los clientes solicitan y consumen servicios, y los servidores los exponen y proveen. La comunicación se realiza a través de la red.
Ventajas:
- Parcialmente distribuido.
- Relativamente simple de implementar para casos básicos.
Desventajas:
- Administración individual de cada servidor.
- El rendimiento puede deteriorarse si el servidor se sobrecarga.
- Los datos no se comparten fácilmente entre servidores (puede llevar a silos de datos).
- No hay un registro centralizado de servicios disponibles.
Arquitectura Orientada a Servicios (SOA)
Compuesta por Clientes, un Bus de Servicios Empresarial (ESB – Enterprise Service Bus) y Servicios. Utiliza estándares como XML, SOAP, REST, JSON para la comunicación.
Ventajas:
- Alta integrabilidad entre sistemas heterogéneos.
- Mantenimiento simplificado a nivel de servicio individual.
- Gestión centralizada (potencialmente a través del ESB).
- Buena escalabilidad y seguridad (si se implementa correctamente).
- Permite reutilizar sistemas existentes exponiéndolos como servicios.
- Bajo nivel de acoplamiento entre servicios.
Desventajas:
- El ESB puede convertirse en un punto único de fallo y cuello de botella.
- Complejidad en entornos grandes con muchos servicios.
- Potencial baja performance debido a la sobrecarga de comunicación (especialmente con SOAP/XML).
- Alta dependencia de estándares y del middleware (ESB).
Capas
Organiza el sistema en capas horizontales, cada una con responsabilidades únicas. Las capas se comunican típicamente solo con sus vecinas adyacentes.
Ventajas:
- Modularidad y separación de conceptos.
- Mantenible, ya que los cambios en una capa afectan mínimamente a otras.
- Permite un desarrollo progresivo o incremental.
- Flexible (en teoría, aunque puede volverse rígida).
Desventajas:
- Puede ser difícil definir correctamente las responsabilidades de cada capa.
- Riesgo de dependencias cruzadas si no se respeta la comunicación entre capas adyacentes.
- Baja performance si hay muchas capas que atravesar para una solicitud.
Repositorio
Ideal para sistemas que manejan grandes cantidades de datos que deben ser accedidos y manipulados por múltiples componentes. Los datos se centralizan en un repositorio.
- Modelo Pasivo: Los componentes consultan el repositorio; este no notifica cambios.
- Modelo Proactivo: El repositorio notifica a los componentes suscritos sobre eventos o cambios relevantes.
Recomendable cuando todos los componentes comparten un modelo de datos común y se requiere administración centralizada.
Ventajas:
- Eficiente para compartir grandes volúmenes de datos.
- Administración centralizada de datos.
- Seguridad y control de acceso centralizados.
- Escalabilidad del repositorio.
- Mantenibilidad de los datos.
Desventajas:
- El repositorio es un punto único de fallo.
- Dificultad para cambiar el modelo de datos una vez establecido.
- Puede ser difícil integrar aplicaciones existentes si no se adaptan al modelo de datos central.
- Requiere una política centralizada de administración de datos.
Cloud Computing
Modelo basado en la externalización de servicios de cómputo (infraestructura, plataformas, software) a través de internet. Modelos comunes: IaaS (Infraestructura como Servicio), PaaS (Plataforma como Servicio), SaaS (Software como Servicio). Ofrece recursos elásticos (pago por uso).
Ventajas:
- Servicios ubicuos y accesibles desde cualquier lugar.
- Reducción de costos (potencial, depende del uso y gestión).
- Alta disponibilidad y redundancia (ofrecida por el proveedor).
- Escalabilidad y Elasticidad bajo demanda.
- Flexibilidad para aprovisionar y desaprovisionar recursos.
- Movilidad.
Desventajas:
- Dependencia de un proveedor externo.
- Preocupaciones sobre seguridad y soberanía de datos.
- Confidencialidad de la información.
- Dependencia de la conectividad a internet.
Ejemplo de Aplicación: Arquitectura SOA
Dado que la arquitectura seleccionada es SOA, se identifican tres tipos principales de componentes: clientes, servicios y el bus del sistema (ESB).
Servicios Principales del Sistema
- Servicio de gestión de clientes de la empresa (CRUD: Crear, Leer, Actualizar, Borrar). No confundir con los procesos cliente.
- Servicios de Ventas:
- Servicio de Pedidos
- Servicio de Facturación
- Servicio de Despacho
- Servicio de Cobranzas
- Servicios de Finanzas:
- Servicio de Ingresos
- Servicio de Egresos
- Servicios de Producción:
- Servicio de Manejo de Materias Primas
- Servicio de Productos Terminados
- Servicio de Bodegaje
- Servicios Gerenciales: Generan estadísticas para cada gerencia y a nivel consolidado.
- Servicio de Base de Datos: Encargado del manejo de la persistencia de datos y del control de roles de usuario a nivel de base de datos.
- Servicio de Autenticación de Usuarios: Encargado de validar las credenciales del usuario para el acceso al sistema.
Procesos Clientes
Los procesos Clientes generan las transacciones con las solicitudes de procesamiento de datos hacia los servicios que las satisfacen. Existen tres tipos de Clientes, perfilados para acceder únicamente a los datos definidos en sus perfiles:
- Cliente Administrador: Tiene acceso a los servicios de administración del sistema (configuración, gestión de usuarios, etc.).
- Cliente Operativo: Encargado del procesamiento diario de los datos, según el área funcional a la que pertenece (ventas, finanzas, producción).
- Cliente Gerencial: Muestra estadísticas e informes de gestión, adaptados al nivel jerárquico y área del usuario.
Bus de Servicio (ESB)
Finalmente, el Bus de Servicio actúa como el concentrador de todas las conexiones entre clientes y servicios. Es responsable de administrar el tráfico de transacciones, el enrutamiento, la transformación de mensajes (si es necesario) y la orquestación de servicios.
