UNIVERSIDAD AUTONOMA DE CAMPECHE FACULTAD DE INGENIERIA INGENIERIA EN TECNOLOGIA DEL SOFTWARE DISEÑO Y ARQUITECTURA DE SOFTWARE IMPARTE: ADRIAN E PACHECO ZAPATA ALUMNO: JOSE M INTERIAN CHAN INVESTIGACIÓN 20/SEPTIEMBRE/2024 Tabla de contenido ATAM ....................................................................................................................... 2 SAAM....................................................................................................................... 3 ARID ........................................................................................................................ 4 Walking Skeleton ..................................................................................................... 6 Architecture Spike ................................................................................................... 7 ALMA ....................................................................................................................... 8 1 INVESTIGACIÓN ATAM El Método de Análisis de Compensaciones de Arquitectura (ATAM) es una técnica utilizada para evaluar arquitecturas de software, enfocándose en identificar riesgos y decisiones de diseño que afectan la calidad del sistema. Aquí tienes un resumen de sus pasos clave: 1. Presentación del ATAM: Se introduce el método y sus objetivos. 2. Presentación de los Conductores del Negocio: Se identifican los objetivos y restricciones del negocio. 3. Presentación de la Arquitectura: Se describe la arquitectura actual del sistema. 4. Identificación de Escenarios: Se definen escenarios que representan las preocupaciones de los interesados. 5. Análisis de Escenarios: Se evalúa cómo la arquitectura maneja cada escenario. 6. Identificación de Riesgos y Sensibilidades: Se detectan áreas problemáticas y puntos críticos. 7. Generación de Resultados: Se documentan los hallazgos y recomendaciones. Este método ayuda a asegurar que la arquitectura del sistema cumpla con los requisitos de calidad y permite tomar decisiones informadas sobre posibles mejoras. EJEMPLO Contexto: Una empresa de comercio electrónico está desarrollando una nueva plataforma de ventas en línea y quiere asegurarse de que la arquitectura del sistema pueda manejar un alto volumen de transacciones durante eventos de ventas masivas. 1. Presentación del ATAM: El equipo de arquitectura presenta el método ATAM a los interesados del proyecto, explicando sus objetivos y beneficios. 2. Presentación de los Conductores del Negocio: Los gerentes de negocio explican que el objetivo principal es soportar hasta 100,000 transacciones por minuto durante eventos de ventas masivas, con un tiempo de respuesta inferior a 2 segundos. 3. Presentación de la Arquitectura: El arquitecto del sistema describe la arquitectura actual, que incluye un sistema de microservicios desplegado en la nube con balanceo de carga y bases de datos distribuidas. 2 4. Identificación de Escenarios: Se definen escenarios como “Un usuario realiza una compra durante una venta masiva” y “El sistema maneja un fallo en uno de los servicios de pago”. 5. Análisis de Escenarios: Se evalúa cómo la arquitectura maneja cada escenario, identificando posibles cuellos de botella y puntos de fallo. 6. Identificación de Riesgos y Sensibilidades: Se detecta que el servicio de pago podría ser un punto crítico y que el balanceo de carga necesita optimización para manejar el tráfico esperado. 7. Generación de Resultados: Se documentan los hallazgos y se recomiendan mejoras, como la implementación de un servicio de pago redundante y la optimización del balanceo de carga. Este ejemplo muestra cómo el ATAM puede ayudar a identificar y mitigar riesgos en la arquitectura de un sistema, asegurando que cumpla con los requisitos de calidad del negocio. SAAM El Método de Análisis de Arquitectura de Software (SAAM, por sus siglas en inglés) es una técnica utilizada para evaluar arquitecturas de software, enfocándose en la modificabilidad y otros atributos de calidad. Aquí tienes un resumen de sus pasos clave: Pasos del SAAM: 1. Desarrollo de Escenarios: Se identifican escenarios que representan posibles cambios y usos futuros del sistema. 2. Descripción de la Arquitectura: Se proporciona una descripción clara de la arquitectura actual del sistema. 3. Clasificación de Escenarios: Se clasifican los escenarios en directos (afectan directamente a la arquitectura) e indirectos (afectan a la arquitectura de manera secundaria). 4. Evaluación Individual de Escenarios Indirectos: Se evalúa cómo la arquitectura maneja cada escenario indirecto. 5. Seguimiento de la Interacción entre Escenarios: Se analiza cómo los escenarios interactúan entre sí y afectan a la arquitectura. 6. Evaluación Global: Se realiza una evaluación global de la arquitectura basada en los escenarios y sus interacciones12. Ejemplo de Aplicación del SAAM 3 Contexto: Una empresa de desarrollo de software está creando una aplicación de gestión de proyectos y quiere asegurarse de que la arquitectura sea fácilmente modificable para futuras actualizaciones y nuevas funcionalidades. 1. Desarrollo de Escenarios: Se identifican escenarios como “Agregar una nueva funcionalidad de seguimiento de tiempo” y “Modificar la interfaz de usuario para soportar múltiples idiomas”. 2. Descripción de la Arquitectura: El arquitecto del sistema describe la arquitectura actual, que incluye un diseño modular con componentes separados para la lógica de negocio, la interfaz de usuario y la base de datos. 3. Clasificación de Escenarios: Se clasifican los escenarios; por ejemplo, “Agregar una nueva funcionalidad de seguimiento de tiempo” es un escenario directo, mientras que “Modificar la interfaz de usuario para soportar múltiples idiomas” es un escenario indirecto. 4. Evaluación Individual de Escenarios Indirectos: Se evalúa cómo la arquitectura maneja el escenario indirecto de soporte multilingüe, identificando que la interfaz de usuario necesita ser refactorizada para soportar esta funcionalidad. 5. Seguimiento de la Interacción entre Escenarios: Se analiza cómo la adición de nuevas funcionalidades podría afectar la modularidad y la mantenibilidad del sistema. 6. Evaluación Global: Se realiza una evaluación global, concluyendo que la arquitectura actual es adecuada pero necesita algunas mejoras en la modularidad de la interfaz de usuario para soportar mejor los cambios futuros. Este ejemplo muestra cómo el SAAM puede ayudar a evaluar y mejorar la arquitectura de un sistema, asegurando que sea flexible y adaptable a futuros cambios. ARID El Método de Revisiones Activas para Diseños Intermedios (ARID, por sus siglas en inglés) es una técnica utilizada para evaluar diseños de software en etapas tempranas del desarrollo. Es un híbrido entre la Revisión Activa del Diseño (ADR) y el Método de Análisis de Compensaciones de Arquitectura (ATAM), combinando elementos de ambos para evaluar la idoneidad de un diseño propuesto. Pasos del ARID: 1. Actividades Previas: o Identificación de los Revisores: Se seleccionan los ingenieros de software y otros involucrados en el diseño. 4 o Preparación del Informe de Diseño: El diseñador prepara un informe detallado del diseño, incluyendo ejemplos de uso. o Preparación de Escenarios Base: Se crean escenarios base para ilustrar posibles usos y problemas. o Preparación de Materiales: Se preparan todos los materiales necesarios para la revisión. 2. Revisión: o Presentación del Diseño: El diseñador presenta el diseño a los revisores. o Discusión de Escenarios: Los revisores discuten los escenarios base y proponen nuevos escenarios. o Evaluación del Diseño: Se evalúa cómo el diseño maneja los escenarios propuestos, identificando riesgos y áreas de mejora. Ejemplo de Aplicación del ARID Contexto: Una empresa de tecnología está desarrollando un nuevo sistema de gestión de inventarios y quiere asegurarse de que el diseño preliminar sea adecuado para futuras expansiones y cambios. 1. Actividades Previas: o Identificación de los Revisores: Se seleccionan ingenieros de software y gerentes de producto. o Preparación del Informe de Diseño: El diseñador prepara un informe detallado del diseño, incluyendo ejemplos de cómo se manejarán grandes volúmenes de datos. o Preparación de Escenarios Base: Se crean escenarios como “Agregar una nueva categoría de productos” y “Modificar el algoritmo de búsqueda para mejorar la velocidad”. o Preparación de Materiales: Se preparan diagramas de arquitectura y documentación técnica. 2. Revisión: o Presentación del Diseño: El diseñador presenta el diseño a los revisores, explicando cada componente y su función. o Discusión de Escenarios: Los revisores discuten los escenarios base y proponen nuevos escenarios, como “Integración con un sistema de terceros”. 5 o Evaluación del Diseño: Se evalúa cómo el diseño maneja los escenarios propuestos, identificando que el sistema necesita mejoras en la modularidad para facilitar futuras integraciones. Este ejemplo muestra cómo el ARID puede ayudar a evaluar y mejorar un diseño preliminar, asegurando que sea adecuado para futuros cambios y expansiones. Walking Skeleton El Walking Skeleton es una técnica utilizada en el desarrollo ágil de software para crear una versión mínima y funcional del sistema que atraviesa todas las capas de la arquitectura. Su objetivo es validar la arquitectura y los componentes principales desde el principio, permitiendo iteraciones rápidas y ajustes basados en retroalimentación temprana. Pasos del Walking Skeleton: 1. Identificación de Funcionalidades Clave: Se seleccionan las funcionalidades esenciales que deben estar presentes en la primera versión del sistema. 2. Desarrollo de la Estructura Básica: Se construye una versión mínima del sistema que incluye todas las capas de la arquitectura (interfaz de usuario, lógica de negocio, base de datos, etc.). 3. Integración Continua: Se implementa un proceso de integración continua para asegurar que cada cambio se prueba y se integra de manera eficiente. 4. Iteración y Mejora: Se realizan iteraciones rápidas para agregar funcionalidades y mejorar el sistema basado en la retroalimentación. Ejemplo de Aplicación del Walking Skeleton Contexto: Una startup está desarrollando una nueva aplicación de gestión de tareas y quiere validar su arquitectura desde el principio para asegurar que puede escalar y adaptarse a futuras funcionalidades. 1. Identificación de Funcionalidades Clave: Se seleccionan funcionalidades esenciales como “Crear una tarea”, “Ver lista de tareas” y “Marcar tarea como completada”. 2. Desarrollo de la Estructura Básica: Se construye una versión mínima de la aplicación que incluye una interfaz de usuario simple, una lógica de negocio básica para manejar tareas y una base de datos para almacenar la información. 3. Integración Continua: Se implementa un proceso de integración continua para asegurar que cada nueva funcionalidad se prueba y se integra sin problemas. 6 4. Iteración y Mejora: Basado en la retroalimentación de los usuarios, se realizan iteraciones rápidas para agregar nuevas funcionalidades como “Asignar tareas a usuarios” y “Establecer fechas límite”. Este ejemplo muestra cómo el Walking Skeleton permite validar la arquitectura y los componentes principales del sistema desde el principio, facilitando iteraciones rápidas y ajustes basados en retroalimentación temprana. Architecture Spike El Architecture Spike es una técnica utilizada en el desarrollo ágil de software para explorar y validar aspectos técnicos o de diseño de una arquitectura antes de comprometerse completamente con su implementación. Se trata de una pequeña prueba de concepto que permite al equipo identificar riesgos, evaluar alternativas y obtener una mejor comprensión de los desafíos técnicos. Pasos del Architecture Spike: 1. Definición del Objetivo: Se establece un objetivo claro para el spike, como validar una tecnología específica o probar un enfoque de diseño. 2. Planificación del Spike: Se planifica el trabajo necesario, incluyendo la identificación de las tareas y los recursos requeridos. 3. Ejecución del Spike: Se lleva a cabo la prueba de concepto, implementando una versión mínima y funcional del componente o tecnología a evaluar. 4. Evaluación de Resultados: Se analizan los resultados del spike para determinar si el enfoque es viable y cumple con los requisitos. 5. Documentación y Decisión: Se documentan los hallazgos y se toma una decisión informada sobre cómo proceder con la arquitectura o tecnología evaluada. Ejemplo de Aplicación del Architecture Spike Contexto: Una empresa de desarrollo de software está considerando usar una nueva base de datos NoSQL para su aplicación de gestión de clientes y quiere validar su rendimiento y escalabilidad antes de adoptarla completamente. 1. Definición del Objetivo: El objetivo del spike es validar el rendimiento y la escalabilidad de la base de datos NoSQL en comparación con la base de datos relacional actual. 2. Planificación del Spike: Se planifican las tareas necesarias, como la configuración de un entorno de prueba, la migración de un subconjunto de datos y la implementación de pruebas de rendimiento. 7 3. Ejecución del Spike: Se configura la base de datos NoSQL, se migran los datos de prueba y se ejecutan pruebas de rendimiento bajo diferentes cargas de trabajo. 4. Evaluación de Resultados: Se analizan los resultados de las pruebas, comparando el rendimiento y la escalabilidad de la base de datos NoSQL con la base de datos relacional. 5. Documentación y Decisión: Se documentan los hallazgos, destacando las ventajas y desventajas de la base de datos NoSQL, y se toma una decisión informada sobre si adoptarla o no. Este ejemplo muestra cómo el Architecture Spike permite al equipo explorar y validar aspectos técnicos críticos antes de comprometerse completamente, reduciendo riesgos y mejorando la toma de decisiones. ALMA El Método de Análisis de Arquitectura Basado en ALMA (Architecture-Level Modifiability Analysis, ALMA) es una técnica utilizada para evaluar la modificabilidad de una arquitectura de software. Este método se centra en identificar y analizar los cambios potenciales en el sistema y cómo estos cambios afectan la arquitectura. Pasos del ALMA: 1. Definición del Contexto: Se establece el alcance del análisis y se identifican los objetivos y restricciones del negocio. 2. Identificación de Escenarios de Cambio: Se definen escenarios que representan posibles cambios futuros en el sistema. 3. Evaluación de Escenarios: Se analiza cómo la arquitectura maneja cada escenario de cambio, identificando los componentes afectados y el esfuerzo necesario para implementar los cambios. 4. Análisis de Impacto: Se evalúa el impacto de los cambios en términos de esfuerzo, riesgo y costo. 5. Generación de Resultados: Se documentan los hallazgos y se proporcionan recomendaciones para mejorar la modificabilidad de la arquitectura. Ejemplo de Aplicación del ALMA Contexto: Una empresa de software está desarrollando una plataforma de gestión de contenido y quiere asegurarse de que la arquitectura sea fácilmente modificable para futuras actualizaciones y nuevas funcionalidades. 8 1. Definición del Contexto: Se establece que el objetivo es evaluar la capacidad de la arquitectura para soportar cambios frecuentes en las funcionalidades de gestión de contenido. 2. Identificación de Escenarios de Cambio: Se definen escenarios como “Agregar un nuevo tipo de contenido multimedia” y “Modificar el flujo de trabajo de aprobación de contenido”. 3. Evaluación de Escenarios: Se analiza cómo la arquitectura maneja cada escenario, identificando que la adición de un nuevo tipo de contenido multimedia afectaría principalmente a los módulos de almacenamiento y presentación. 4. Análisis de Impacto: Se evalúa el esfuerzo necesario para implementar estos cambios, identificando que el cambio en el flujo de trabajo de aprobación requeriría modificaciones significativas en la lógica de negocio. 5. Generación de Resultados: Se documentan los hallazgos, destacando que la arquitectura actual es adecuada, pero podría beneficiarse de una mayor modularidad en los componentes de lógica de negocio para facilitar futuros cambios. Este ejemplo muestra cómo el método ALMA puede ayudar a evaluar y mejorar la modificabilidad de una arquitectura de software, asegurando que sea flexible y adaptable a futuros cambios. 9
