Patrones de Arquitectura de Software: Soluciones de Diseño para Necesidades Comunes

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 13,97 KB

Patrones de Arquitectura: Soluciones de Diseño a una Necesidad

Un patrón de arquitectura proporciona una solución de diseño reutilizable y probada para abordar una necesidad específica en el desarrollo de software.

Características:

  • Esquema genérico: Los patrones ofrecen una solución abstracta y generalizable que puede ser aplicada en diversos contextos.
  • Probado: Han sido validados en múltiples proyectos y escenarios, demostrando su eficacia.
  • Recurrente: Se utilizan repetidamente para resolver problemas similares.

Especificación:

  • Componentes: Definición de las partes individuales que componen la solución.
  • Responsabilidades: Asignación clara de las funciones y responsabilidades de cada componente.
  • Relaciones: Descripción de cómo interactúan los componentes entre sí.

Descripción de un Patrón

Nombre del Patrón:

Cada patrón tiene un nombre específico que lo identifica y describe su propósito.

Contexto:

  • Situación que origina la necesidad: Identificación del problema o situación que crea la demanda del patrón.
  • Ámbito de la necesidad: Contexto general donde surge la necesidad del patrón.
  • Descripción de las situaciones que la originan:
    • Descripción general: Visión amplia del contexto y el problema.
    • Descripción detallada: Análisis más profundo y específico de las circunstancias que requieren la solución.

Requerimiento:

  • Descripción genérica de la necesidad: Definición amplia del problema a resolver.
  • Define lo que se debe resolver: Establecimiento de objetivos y resultados esperados.
  • Fuerzas presentes en el contexto:
    • Propiedades: Características inherentes al problema.
    • Requisitos: Necesidades que deben ser satisfechas.
    • Restricciones: Limitaciones que deben ser consideradas.

Solución:

  • Esquema de solución de la necesidad: Propuesta de solución para abordar el problema identificado.
  • Balance de fuerzas: Equilibrio entre las distintas fuerzas presentes en el contexto.
  • Estructura:
    • Componentes: Elementos de la solución.
    • Relaciones: Interacciones entre los componentes.
  • Comportamiento:
    • Organización de componentes: Cómo se estructuran y funcionan los componentes en conjunto.
  • Priorización de fuerzas: Ordenación de las fuerzas según su importancia y impacto en la solución.

Clasificación de Patrones

1. Patrones Simples

A. Capas (Layers):

  • Estructura: Aplicaciones descompuestas en tareas con diferentes niveles de abstracción.
  • Contexto: Sistemas estructurados con diversos niveles de acción.
  • Requerimiento: Organización inadecuada genera problemas de escalabilidad y mantenibilidad.
  • Solución: Estructuración en esquema multi-capa.
  • Características:
    • La capa K se relaciona solamente con la capa K-1. No hay otras dependencias entre capas.
    • Cada capa puede estar integrada por distintos componentes.
    • Los componentes pueden interactuar entre sí, pero quedan acoplados.
    • Cada capa expone una interfaz con los servicios que provee.
    • El comportamiento puede ser top-down o bottom-up.
  • Implementación:
    • Determinar el número de capas según el nivel de abstracción requerido.
    • Asignar responsabilidades a cada capa.
    • Especificar los servicios ofrecidos por cada capa.
    • Definir la estructura de cada capa.
    • Especificar la interfaz de cada capa.
    • Especificar el método de comunicación intercapas.
    • Definir el esquema para el manejo de errores.
  • Análisis:
    • Ventajas: Componentes estandarizados. Cambios afectan el nivel local. Reutilización de capas/componentes.
    • Desventajas: Cambios afectan en cascada. Ineficiencia. Complejo de definir.

B. Tubos y Filtros (Pipes and Filters):

  • Estructura: Aplicaciones en actividades para procesar flujos de datos donde cada actividad es un filtro unido por un tubo a los filtros contiguos.
  • Contexto: Procesar flujos de datos.
  • Requerimiento: Descomponer el procesamiento en una serie de actividades (filtros) que transforman datos de entrada en datos de salida. Transformaciones independientes y sin estado.
  • Solución:
    • Tubos (pipes): Conecta origen de datos con un filtro, filtro con filtro, y filtro con salida de datos. Esquema de procesamiento FIFO.
    • Filtros (filters): Aplica procesos de transformación de datos de entrada en datos de salida. Filtros independientes sin estado compartido y desconocimiento de otros filtros.
  • Implementación:
    • Dividir el sistema en una secuencia de procesos ordenados e independientes.
    • Definir el formato de los datos transmitidos por los tubos.
    • Especificar el procesamiento de cada filtro.
    • Construir los filtros.
    • Definir el esquema para el manejo de errores.
  • Análisis:
    • Ventajas: Arquitectura flexible. No requiere de archivos intermedios. Filtros reutilizables. Procesamiento paralelo. Construcción independiente.
    • Desventajas: Información no compartida. Conversión de datos (ineficiencia). Errores pueden afectar el flujo de procesamiento.

C. Pizarrón (Blackboard)

  • Contexto: Dominio en el que no hay una solución completa y específica para un problema.
    • Problema: Conocimiento parcial de la solución.
    • Cada solución requiere diferentes paradigmas.
    • El problema abarca muchas especialidades.
    • No es factible una solución completa.
    • Módulos aportan parcialmente a la solución.
  • Solución:
    • Conjunto de sistemas independientes trabajando colaborativamente.
    • Datos compartidos en un repositorio centralizado.
    • Control centralizado que coordina la ejecución de los sistemas.
    • Sistemas especializados independientes leen y escriben en el pizarrón.
    • Monitoreo centralizado del estado del sistema.
    • Decisión centralizada de las acciones a seguir basada en el progreso alcanzado.
  • Ventajas: Flexibilidad para incorporar diversas perspectivas, facilita la contribución de múltiples expertos, divide problemas grandes en más pequeños y manejables, permite integración de soluciones parciales.
  • Desventajas: Coordinación compleja entre sistemas, riesgo de soluciones parciales que no se integran bien, requiere gran ancho de banda y recursos, más orientado a la investigación que a aplicaciones comerciales directas.

2. Sistemas Interactivos

A. Modelo Vista Controlador (MVC):

  • Qué es: El sistema se divide en tres partes: Modelo, Vista, y Controlador.
    • Modelo: Datos y funcionalidad esencial.
    • Vista: Comunicación con el usuario.
    • Controlador: Controla cambios al modelo.
    • Interfaz de usuario: Vista + Controlador.
    • Lógica del negocio: Controlador + Modelo.
    • Controlador desacopla la vista del modelo.
  • Contexto: Sistemas interactivos con interfaz flexible.
  • Requerimiento:
    • Interfaz con diferente representación. Texto, gráficos, listas, iconos.
    • Paradigmas de ingreso diversos.
      • Digitación: cajas de texto.
      • Selección: listas desplegables, iconos.
      • Ingreso mixto.
    • Interfaz cambiante: mejora, evolución.
    • Facilidad de modificación de la interfaz.
    • Funcionalidad nueva implica modificar la interfaz.
    • Presentación de la información en multi-formato.
  • Solución: Tres componentes:
    • Comunicación (Vista): Envía requerimientos del usuario y recibe datos del modelo.
    • Administración (Controlador): Define el comportamiento del sistema y solicita servicios al modelo.
    • Procesamiento (Modelo): Provee la funcionalidad requerida por las vistas.
  • Implementación:
    • Separar la funcionalidad de la interacción del usuario.
    • Diseñar e implementar el modelo, las vistas, los controladores, y las relaciones entre vistas y controladores.
  • Análisis:
    • Ventajas: Modelo soporta múltiples vistas. Flexible, mantenible, adaptable. Frameworks implementan MVC.
    • Desventajas: Complejidad. Vista sin acceso directo a datos (ineficiencia). Acoplamiento intrínseco.

B. Presentación Abstracción Control (PAC):

  • Estructura: Jerárquica de agentes cooperativos, cada uno responsable de una parte de la funcionalidad.
  • Contexto: Sistemas interactivos desarrollados utilizando agentes.
  • Requerimiento:
    • Estructurar un sistema interactivo mediante agentes funcionando de forma integrada.
    • Generar interfaces flexibles de usuario.
    • Separar la presentación de la funcionalidad.
  • Solución: Definir estructura jerárquica de tres niveles de agentes.
    • Alto nivel: Funcionalidad central del sistema.
    • Bajo nivel: Manejo de interfaces específicas de usuarios.
    • Intermedios: Relacionan agentes de bajo nivel.
    • Cada agente está compuesto por:
      • Presentación: Aspecto visible del agente.
      • Abstracción: Modelo de datos interno y operaciones sobre ellos.
      • Control: Conexión entre presentación y abstracción, y comunicación con otros agentes.
  • Implementación:
    • Definir la funcionalidad central del sistema.
    • Estructurar la jerarquía de agentes.
    • Definir e implementar cada agente.
      • Funcionalidad.
      • Interfaz.
      • Modelo de datos.
      • Mecanismo de control.
  • Análisis:
    • Ventajas: Asigna responsabilidades específicas. Funcionamiento independiente. Soporta multitarea.
    • Desventajas: Sistema complejo. Baja eficiencia. Complejo mecanismo de control.

3. Patrones Adaptables:

(No se especifica en detalle).

4. Sistemas Distribuidos:

(No se especifica en detalle).

Ejercicios

1. Flujos de Trabajo (Workflow)

En flujos de trabajo (workflow), la arquitectura más adecuada es Tubos y Filtros, en la que cada filtro implementa una funcionalidad específica. Además, se podría proponer SOA, ya que cada servicio implementaría los requerimientos de cada departamento.

2. Procesamiento de Datos:

Para sistemas que requieren el procesamiento de una cadena de procesos, el patrón Tubos y Filtros es ideal. En este patrón, el procesamiento no inicia en el tubo, sino en el filtro que procesa la información. Los filtros no necesariamente conocen su predecesor ni sucesor, ya que son independientes. Los tubos no realizan las transformaciones en los datos; los filtros son quienes lo hacen.

3. Sistemas Electorales

En sistemas electorales que necesitan ingresar información de locales de votación y mesas receptoras de votos, identificar al presidente de la mesa, registrar las mesas electorales constituidas, ingresar resultados y obtener resultados acumulados, la arquitectura SOA es adecuada. Permite que diferentes servicios (validación de votantes, registro de resultados, consolidación de datos, etc.) se desarrollen, desplieguen y gestionen de forma independiente, ofreciendo flexibilidad y escalabilidad. Además, el patrón MVC es adecuado para la interfaz de usuario, separando claramente la lógica de negocio (Modelo), la interfaz de usuario (Vista), y el control de la interacción del usuario (Controlador).

4. Patrones No Funcionales:

El patrón MVC mejora la mantenibilidad, portabilidad y verificabilidad del sistema.

  • Mantenibilidad: Permite trabajar en partes específicas del sistema sin afectar las otras.
  • Portabilidad: La separación entre el modelo y la vista permite cambiar la forma de presentación sin modificar la lógica de negocio y adaptar múltiples plataformas.
  • Verificabilidad: La separación de responsabilidades del modelo permite la integración de pruebas unitarias, automáticas y de integración de manera aislada, facilitando la identificación y corrección de errores.

5. Patrones Complejos (Pizarrón):

El patrón Pizarrón facilita la resolución de problemas complejos al permitir que múltiples módulos (agentes) colaboren escribiendo y leyendo en un espacio común de datos, denominado pizarra. Cada agente tiene acceso compartido a la pizarra, lo que permite la colaboración, resolviendo la sobre-escritura con mecanismos de sincronización. La pizarra centraliza los datos y las comunicaciones, pero no controla el flujo de ejecución, esto lo realiza el controlador. La interacción entre los agentes y la pizarra es gestionada por un coordinador que asegura que todas las contribuciones sean validadas y coherentes antes de ser integradas en la solución final.

Entradas relacionadas: