Estándares y Arquitectura de Software

Arquitectura de Software

Disciplina que define la estructura, organización y decisiones de diseño de un sistema de software. Ventajas: comunicación con participantes, análisis del sistema y reutilización a grande escala.

RNF y Arquitectura

Los Requerimientos No Funcionales determinan el estilo y estructura arquitectónica a elegir: rendimiento, protección, mantenimiento, seguridad y disponibilidad.

Modularidad

Agrupación lógica de código relacionado entre sí. Es un principio de organización que se mide con cohesión y acoplamiento.

Cohesión

Qué tan bien están relacionados los elementos dentro de un módulo. Se busca alta cohesión.

Acoplamiento

Grado de interdependencia entre módulos. Cómo se comunican entre sí. Se busca bajo acoplamiento.

Cohesión Funcional

El tipo más alto y deseable. Todo el módulo trabaja hacia un único objetivo bien definido.

Cohesión Secuencial

La salida de una parte es la entrada de la siguiente. Ej: order maintenance.

Cohesión de Comunicación

Los elementos operan sobre los mismos datos. Ej: customer maintenance.

Cohesión de Procedimiento

Los elementos siguen una secuencia de pasos relacionados.

Cohesión Temporal

Los módulos se relacionan por dependencias de tiempo. Ej: autenticación de dos factores (2FA).

Cohesión Lógica

Los datos se relacionan lógicamente pero no funcionalmente.

Cohesión Coincidente

El tipo más bajo y negativo. Los elementos solo están juntos porque están en el mismo archivo fuente. No recomendable.

IEEE 1016

Estándar que define cómo documentar el diseño de software mediante un SDD (Software Design Description). Define perspectivas, vistas e inquietudes.

SDD — Software Design Document

Documento formal que describe el diseño de un sistema. Incluye perspectivas, vistas, decisiones de diseño y justificaciones. Basado en IEEE 1016.

Perspectivas (IEEE 1016)

Puntos de vista desde los cuales se observa y documenta un sistema. Cada perspectiva aborda preocupaciones de distintos stakeholders. Ej: lógica, despliegue, proceso, física.

Inquietudes / Concerns

Intereses o preocupaciones que los stakeholders tienen sobre el sistema: rendimiento, seguridad, mantenibilidad, disponibilidad, escalabilidad.

Vistas (IEEE 1016)

Representación del sistema desde la perspectiva de un conjunto de inquietudes. El SDD se compone de múltiples vistas, cada una descrita con un viewpoint.

IEEE 828

Estándar que define el formato para la gestión de la configuración del software. Establece el SCMP: identificación, control de cambios, registro del estado y auditorías.

Arquitectura Monolítica

Sistema desplegado como una sola unidad. Tipos: capas (layered), pipeline y microkernel.

Arquitectura Distribuida

Sistema dividido en múltiples unidades independientes. Tipos: basada en servicios, basada en eventos (broker/mediator), SOA, microservicios y basada en espacio.

Arquitectura en Capas — Layered

Monolítica. Organiza el sistema en capas horizontales donde cada capa solo se comunica con la inmediata. Típico: Presentación → Negocio → Persistencia.

Arquitectura Pipeline

Monolítica. La información fluye en un solo sentido. Componentes: Producer → Transformer → Tester → Consumer.

Arquitectura Microkernel

Monolítica. Tiene un Core System (happy path) y plug-ins especializados e independientes que se agregan en runtime o compile-time.

Arquitectura Basada en Servicios

Distribuida. La UI se conecta a servicios de grano grueso. Servicios más grandes y menos numerosos que microservicios. Buena opción para migrar desde un monolito.

Arquitectura Basada en Eventos — Broker

Distribuida. No hay orquestador central. El evento se publica y el componente que esté libre lo toma. Altamente desacoplada. Ej: tienda en línea (inventario, facturación, envío).

Arquitectura Basada en Eventos — Mediator

Distribuida. Hay un orquestador central que coordina el flujo y decide qué componente ejecuta qué paso. Mayor control, más acoplado. Ej: reserva de vuelos.

Diferencia Broker vs Mediator

Broker: nadie coordina, el evento va al componente libre, orden no garantizado. Mediator: hay un director central que dirige el flujo paso a paso con orden definido.

SOA — Service-Oriented Architecture

Distribuida. Servicios grandes reutilizables que se comunican por un bus centralizado (ESB). Menos flexible que microservicios por el ESB como cuello de botella.

ESB — Enterprise Service Bus

Bus centralizado en SOA que maneja transformación, enrutamiento y orquestación. Su centralización lo convierte en cuello de botella y punto único de fallo.

Microservicios

Distribuida. Cada funcionalidad es un servicio completamente independiente con su propia base de datos. Flujo: Client Request → API Gateway → Service → DB propia.

API Gateway

Punto de entrada único en microservicios que recibe todas las peticiones del cliente y las enruta al servicio correspondiente. También maneja autenticación y logging.

Arquitectura Basada en Espacio

Distribuida. Usa memoria compartida distribuida en lugar de base de datos central. Diseñada para picos de tráfico extremos e impredecibles. Ej: venta de boletos de concierto.

¿Cuál arquitectura usar?

Considerar: tipos de datos y actualizaciones, frecuencia de los cambios y plataforma de ejecución del sistema.

Arquitectura de Seguridad

Protección en cada capa del sistema. Capas de afuera a adentro: UI web/móvil → Autenticación → Funcionalidad de la app → Servicios compartidos → Transacciones y BD.

CMMI — Capability Maturity Model Integration

Estándar de calidad con 316 prácticas clave agrupadas en 18 áreas y 5 niveles de madurez organizacional.

CMMI Nivel 1 — Inicial

Sin protocolos ni estándares. Caótico, sin guía.

CMMI Nivel 2 — Repetible

Tiene métodos estandarizados y control en proyectos.

CMMI Nivel 3 — Definido

Procesos documentados, monitoriza y mejora. Se tiene una metodología. Requiere 3+ años.

CMMI Nivel 4 — Gestionado

Controles avanzados, métricas y retroalimentación de costos y calidad. Requiere 5+ años y 50+ empleados.

CMMI Nivel 5 — Optimización

Mejora continua, todo estandarizado, análisis cuantitativo y cualitativo. Menos del 0.1% de organizaciones lo alcanza.

NIST — AI RMF 1.0

Guías no regulatorias del National Institute of Standards and Technology para el uso responsable de IA. Tres principios: gobernanza responsable, evaluación y mitigación de riesgos, mejora continua.

MoProSoft — NMX-I-059/02-NYCE-2016

Modelo de procesos para la industria de software mexicana. CMMI realista para pymes. Tres niveles: Dirección, Gerencia, Operación.

PSP — Personal Software Process

Proceso enfocado en el individuo. Predictivo. Mejora productividad, reduce errores, mejora calidad y control del trabajo individual.

TSP — Team Software Process

Proceso enfocado en el equipo. Cada persona planea, da seguimiento y reporta su avance. Define roles, medidas estándar de calidad y maximiza productividad del equipo.

Ciclo TSP

Lanzamiento → Estrategia → Plan → Requerimientos → Diseño → Implementación → Pruebas → Postmortem.

Relación PSP-TSP-CMMI

PSP (individuo) → TSP (equipo) → CMMI (organización). La mejora escala de lo personal a lo organizacional.

Metodología Predictiva vs Adaptativa

PSP es predictiva: cada quien documenta su proceso y usa datos para predecir la agenda. Ágil es adaptativa: se ajusta continuamente a los cambios.

Patrones de Diseño

Mejor práctica documentada o núcleo de una solución aplicada con éxito en múltiples contextos. Proveen lenguaje unificado y resuelven problemas comunes ya solucionados antes.

Rol del Arquitecto

Define requerimientos de negocio, elige la arquitectura de software, decide cómo se organizan los componentes y toma decisiones tecnológicas (BD, plataforma, servidor, herramientas).

Rol del Diseñador

Crea diagramas de clases, pantallas UI, prueba y desarrolla el código fuente. Define cómo se construyen y codifican los componentes.

Patrones Básicos

Interface, parent abstract class, accessors methods, constant data manager, immutable object, monitor.

Patrones Creacionales

Crean objetos reduciendo el acoplamiento. Principio: responsabilidad única y abierto/cerrado. Ej: Factory Method, Abstract Factory, Builder, Singleton, Prototype.

Patrones Estructurales

Crean estructuras complejas manteniendo flexibilidad y eficiencia. Basados en herencia. Ej: Proxy/Bridge, Adapter, Decorator, Facade, Composite.

Patrones de Comportamiento

Definen cómo los objetos se comunican e interactúan. Ej: Command, Chain of Responsibility, Mediator, Observer.

Antipatrones

Soluciones conocidas que parecen buenas pero resultan contraproducentes. Lo opuesto a un patrón de diseño.

Patrón Builder

Creacional. Construye objetos complejos paso a paso. Componentes: Director, Builder (interfaz), Builder Concreto. Ventaja: no rompe responsabilidad única. Desventaja: aumenta complejidad.

Patrón Singleton

Creacional. Garantiza una sola instancia de clase con un único punto de acceso global. Ventaja: fácil encontrar errores. Desventaja: dificulta pruebas unitarias, no cumple responsabilidad única.

Patrón Proxy / Bridge

Estructural. Objeto intermedio que controla el acceso a otro. Baja el acoplamiento. Cumple PRU y abierto/cerrado. Uso: clase monolítica con muchas variantes de una funcionalidad.

Patrón Adapter

Estructural. Conector para interfaces incompatibles. Crea una clase traductora intermedia. Uso: integrar código heredado con código moderno. Cumple PRU. Desventaja: aumenta complejidad.

Patrón Decorator

Estructural. Asigna responsabilidades adicionales a un objeto dinámicamente durante ejecución. Uso: cuando la herencia no sirve. Ej: envío de notificaciones. Desventaja: difícil de eliminar.

Patrón Facade

Estructural. Provee una interfaz simplificada a un subsistema complejo.

Patrón Composite

Estructural. Compone objetos en estructuras de árbol para representar jerarquías parte-todo.

PRU — Principio de Responsabilidad Única

Cada clase o módulo debe tener una sola razón para cambiar. Una sola responsabilidad bien definida.

Principio Abierto/Cerrado

Un módulo debe estar abierto para extensión pero cerrado para modificación. Se extiende sin cambiar el código existente.

Refactorización

Proceso sistemático de mejora del código sin crear nueva funcionalidad ni cambiar su comportamiento observable. Hace el código más fácil de entender y menos costoso de modificar.

Lo que NO es refactorización

No modifica la lógica existente, no agrega nueva funcionalidad, no requiere nuevas pruebas. Solo mejora la estructura interna.

Para qué sirve la refactorización

Eliminar código duplicado, hacer el código más fácil de entender, ayuda a encontrar bugs y a programar más rápido.

Código Limpio

Obvio para otros programadores, sin duplicados, número mínimo de clases y partes móviles, pasa todas las pruebas al 100%. Más fácil y económico de mantener.

Cuándo refactorizar — tipos

Preparación (antes de agregar una característica), comprensión (para entender mejor el código), recoger la basura (al encontrarlo de paso), planeada/oportunista, a largo plazo.

Problemas al refactorizar

Branches, ralentizar nuevas características, code ownership, falta de testing, legacy code y bases de datos acopladas al código.