Please enable JavaScript.
Coggle requires JavaScript to display documents.
DISEÑO Y NIVELES DE DISEÑO - Coggle Diagram
DISEÑO Y NIVELES DE DISEÑO
Definición
Especificación de un objeto para alcanzar objetivos en un entorno con requisitos y restricciones
Relación con arquitectura
Objeto → estructuras
Agente → arquitecto
Objetivos → drivers
Entorno → uso y contexto
Niveles
Diseño de la arquitectura → decisiones para satisfacer drivers y crear estructuras
Diseño de interfaces → identificar módulos y contratos según lineamientos de la arquitectura
Diseño detallado de módulos → detalles de implementación (no arquitectónicos)
Proceso general de diseño de la arquitectura
Caja negra
Entradas = drivers
Responsable = arquitecto
Salidas = estructuras
Divide y vencerás
Seleccionar subconjunto de drivers
Tomar decisiones, evaluar e iterar
Reutilizar soluciones existentes
Ahorra tiempo y mejora calidad
Originalidad al combinar soluciones
Principios de diseño
Modularidad → responsabilidades claras y separadas
Cohesión alta y acoplamiento bajo
Acoplamiento bajo evita “efecto onda” ante cambios
Encapsulamiento → ocultar implementación tras interfaces
Clave: buen diseño de interfaces
KISS (mantenerlo simple y directo)
Reducir dependencias
Granularidad apropiada de módulos
Evitar módulos innecesarios en una operación
Conceptos de diseño
Patrones
Origen: Alexander; GoF (23 patrones: Factory, Proxy, Observer…)
Observer → dependencia 1→muchos; al cambiar el sujeto, observadores son notificados/actualizados
Estilos / arquitecturas de referencia
Organización fundamental; se pueden combinar
Ejemplos: Filtros-tuberías, Capas, Cliente/Servidor, N-tercios, Par a par, Publicador-Suscriptor
Casos comunes: Capas, N-tercios, Data Mapper, Lazy Acquisition
Tácticas
Definición → técnicas que controlan la respuesta de un atributo de calidad
Catálogo (Bass et al., 2012): desempeño, disponibilidad, seguridad, modificabilidad, usabilidad, facilidad de prueba, interoperabilidad
Árbol de desempeño
Controlar demanda de recursos: tasa de muestreo, limitar respuestas, priorizar eventos, reducir overhead, limitar tiempos, aumentar eficiencia
Administrar recursos: aumentar recursos, concurrencia, copias múltiples de cálculos/datos, limitar colas, calendarizar recursos
Frameworks
Código reutilizable para problemas recurrentes (UI, comunicación, seguridad, persistencia…)
Implementan patrones y tácticas (ej.: MVC)
Ventajas: uso directo
Inconvenientes: curva de aprendizaje, elección difícil/obsolescencia, incluir todo el framework, soporte limitado a veces
Otros conceptos
Modelos de dominio → abstracciones y relaciones del problema; pueden reutilizarse
Componentes COTS → piezas listas para integrar (p. ej., ESB/middleware)
Servicios web → interfaces que encapsulan sistemas de otras organizaciones
Diseño de las interfaces
Estructuras dinámicas (diagramas de secuencia) que muestran colaboración para soportar drivers
Interfaz = conjunto de mensajes/contrato que recibe un elemento
En arquitectura se identifican interfaces para elementos que soportan drivers
Deben cubrirse todos los requisitos del sistema
Flujo: casos de uso y escenarios → diagramas → métodos y contratos de los módulos
Métodos de diseño de arquitectura
ADD (Attribute-Driven Design)
Entradas: drivers (escenarios de calidad), requisitos funcionales primarios y restricciones
Pasos
Confirmar información suficiente de drivers
Elegir elemento a descomponer
Identificar drivers del elemento
Elegir concepto de diseño (patrones/tácticas)
Instanciar elementos y asignar responsabilidades
Definir interfaces
Verificar/refinar y transformar en restricciones
Repetir iterativamente
Observaciones
Guía detallada
Límites → alcance por iteración difuso y no menciona frameworks (puede quedar muy conceptual)
ACDM (etapa 3: creación/refinamiento)
Filosofía → la arquitectura como plano del proyecto completo
Entradas → drivers + (si aplica) diseño parcial y lista de problemas
Pasos → establecer contexto; particionar; asignar responsabilidades; documentar decisiones/relaciones; cambiar de perspectiva; iterar hasta definir interfaces
Salidas → diseño inicial o refinado, plan maestro actualizado y (opcional) matriz de trazabilidad
Enfoque → iterativo, evita BDUF y favorece retroalimentación temprana
Método de Rozanski & Woods
Pasos → consolidar entradas; identificar escenarios; estilos relevantes; candidato de arquitectura; explorar opciones; evaluar con involucrados; retrabajar arquitectura o revisar requisitos
Comparación
Mecánica → ADD = descomposición recursiva; ACDM/R&W = iteraciones diseño-documentación-evaluación
Participantes → ADD = arquitecto; ACDM y R&W = arquitecto + involucrados
Entradas → ADD/ACDM = drivers (ACDM también alcance); R&W = escenarios
Salidas → ADD = esbozos de vistas; ACDM/R&W = vistas
Terminación → ADD = drivers satisfechos; ACDM = experimentos sin riesgos relevantes; R&W = acuerdo de interesados