Resumen Variabilidad en las Cualidades en Arquitectura de Software- Variability for Qualities in Software Architecture

Variabilidad en las Cualidades en Arquitectura de Software

Variability for Qualities in Software Architecture

es un resumen ytraduccion del articulo mencionado puede que las traducciones no esten totalmente correctas ya que son interpretaciones mías.

INTRODUCCIÓN

La variabilidad es la capacidad de un sistema de software para adaptarse a diferentes contextos. La variabilidad afecta tanto a la funcionalidad como a los atributos de calidad del sistema.

En trabajos que estudian la variabilidad se centran en los atributos de calidad y en cualidades como la flexibilidad mientras que los atributos de calidad del software a menudo se descuidan. Hay muchas obras que cubren la variabilidad en la funcionalidad existe un brecha de la investigación en cuanto a las cualidades del software.

2. Charla clásica

Matthias Galster en su trabajo Architecting for Variability in Quality Attributes of Software Systems introduce varios escenarios basados en la taxonomía para la variabilidad de atributos de calidad.
Variabilidad en los atributos de calidad debido a variaciones en las necesidades del usuario como los diferentes segmentos de mercado o perfiles del cliente.

• Variabilidad en los atributos de calidad en diferentes fases del proceso de desarrollo de software.
• Variabilidad en los atributos de calidad debido al impacto de la variabilidad en la funcionalidad.
• Variabilidad en los atributos de calidad debido a la variabilidad de otros atributos de calidad.
• Variabilidad en los atributos de calidad debido a la variación en recursos de hardware.

Algunos de los principales hallazgos de la revisión de trabajo relacionada son:

• Cuando se trata de la variabilidad en la calidad los atributos, el rendimiento y la disponibilidad se abordan considerando que no se han investigado la seguridad exhaustivamente.
• En los sistemas basados en servicios, los estudios se realizan sobre laboratorios pero no en casos de la vida real.
• En los sistemas basados ​​en servicios, la variabilidad es acomodada en las actividades de diseño e implementación Y la integración.

3. PRESENTACIONES DEL PAPEL

Modelos para sistemas auto-adaptativos

Este artículo fue presentado por Amir Molzam Sharifloo.
Clasificó estos modelos según el medio ambiente, el sistema y los requisitos. Ambiente se define como todo en el que el sistema no tiene ningún control pero puede impactar en la funcionalidad del sistema.
Para el desarrollo de sistemas auto-adaptativos se tiene en cuenta varios puntos como conocimientos sobre decisiones de diseño y fundamentalmente detrás de las decisiones de diseño que son vitales está la planificación.

Selección automática y composición del modelo de transformaciones alternativas utilizando algoritmos evolutivos.

Presentado por Smail Rahmoun.
Se centró en hacer concesiones entre propiedades no funcionales cuando se prevén varias alternativas de diseño para arquitecturas de software. Se formaliza estas alternativas con las transformaciones de modelos, usando los algoritmos evolutivos para crear un modelo de transformación y finalmente la identificar la transformación que presenta el mejor equilibrio entre el valor funcional y las propiedades a la mano.

Evolución de una línea de productos de software para el comercio electrónico
Systems: un estudio de caso

Presentado por Leonardo Montecchi
Compara el enfoque de la ACFAM con otros tipos de implementaciones de SPL para demostrar su aplicabilidad a dominios y su mayor efectividad en comparación con otras implementaciones. Montecchi evalúa el enfoque ACFAM utilizando un escenario real. Extraen un conjunto de características de cuatro sistemas existentes de comercio electrónico, identifican los puntos en común y las variabilidades y configurar un modelo de características utilizando la metodología ACFAM.

Los hallazgos de los autores indican que ACFAM es de hecho aplicable para los escenarios del mundo real y es más eficaz para la línea de productos de ecommerce ya que requiere menos cambios de código u proporcionó la arquitectura más estable.

4. DISCUSIONES DEL GRUPO DE TRABAJO

Temas seleccionados:

• Complejidad del espacio de diseño
• Atributos de Calidad y Variabilidad

Complejidad del espacio de diseño

Los aspectos que se trataron dieron a las preguntas de por qué la variabilidad hace que nuestros sistemas más complejos y lo que podemos hacer al respecto.

• Fuentes de complejidad: Una fuente de complejidad en los sistemas de variabilidad es el conjunto de relaciones y dependencias entre varios atributos de calidad, así como la interconexión entre los atributos de calidad y funcionalidad. A veces, la funcionalidad tiene que ser eliminada para cumplir con un atributo de calidad en particular.

• Reducir la complejidad: La variabilidad sólo debe considerarse si el ingeniero de software está absolutamente seguro de que será necesario durante la vida de un sistema. Si ya hay soporte de variabilidad incorporado en relación con un aspecto particular puede considerar eliminarlo para aumentar la capacidad de mantenimiento del sistema ya que nunca se utilizará.

• Variabilidad imprevisible: Hay sistemas que experimentan variabilidad en tiempo de ejecución que no se ha previsto al diseñar el sistema, o que no pueden ser controlados, o ambos. Para este caso, se han propuesto tres estrategias:
• Centrar la aplicación en los aspectos que se conocen de antemano. Si el ingeniero de software comienza a adivinar lo que podría suceder, la complejidad del sistema se incrementa innecesariamente.
• El ingeniero de software puede diseñar el sistema con la mentalidad de que puede y fallará en tiempo de ejecución en caso de variabilidad imprevista - el conocimiento sobre la variabilidad adquirida en este caso puede ser visto como un nuevo aspecto que se conoce de antemano para otra versión de la Sistema.
• Una tercera estrategia comprende la definición de reglas basada en datos que desencadena una reacción para los valores observados. La premisa para esta estrategia es la imposibilidad de definir una reacción a cada posible cadena de eventos o eventos que pueden ocurrir simultáneamente.

• Variabilidad en Middleware: la mayoría de middlewares modernos son interceptor-base Por un lado, desde un punto de vista estructural, la arquitectura es bastante estática y en sí misma no es variable.Por otro lado, las instancias de Interceptor en sí soportan la variabilidad ya que el programador puede implementar código arbitrario.

• Investigación Futura: la variabilidad en las arquitecturas de software es un desafío complejo. El conocimiento arquitectónico capturado en patrones arquitectónicos y tácticas parece ser una buena fuente de soluciones a dichos desafíos. La interacción de características, especialmente el modelado de características o el modelado de objetivos entre atributos de calidad, podría ser un área prometedora de investigación.

Atributos de Calidad y Variabilidad


Sin embargo, los participantes del taller discutieron cuatro soluciones potenciales para lidiar con este dilema:

• Decisiones de diseño tempranas: debe decidirse sobre la satisfacción de un solo tipo de requisitos de calidad que no son conflictivos. Esta decisión temprana del diseño permite la selección de patrones arquitectónicos que contribuyen a la satisfacción del requisito de calidad seleccionado.
• Patrones en la ingeniería de aplicaciones: Los patrones arquitectónicos no deben aplicarse en la ingeniería del dominio, sino en la ingeniería de aplicaciones.
• Ninguna arquitectura común: Puede que no exista una arquitectura (de referencia) que responda a las características comunes de todos los requisitos de calidad en conflicto. La razón es que los requisitos de calidad se consideran conductores de la arquitectura. Diferentes requisitos de calidad contradictorios pueden conducir a arquitecturas de software completamente diferentes utilizando diferentes patrones arquitectónicos para que no exista una arquitectura común.
• Patrones y tácticas: Un patrón arquitectónico que contribuye positivamente a un tipo de requisitos de calidad y que contribuye negativamente a los otros tipos de requisitos de calidad debe ser aplicado en la ingeniería del dominio. En la ingeniería de aplicaciones, las tácticas deben utilizarse para compensar el efecto negativo del patrón arquitectónico en un tipo de requisitos de calidad. Además, esta solución no proporciona una solución óptima al problema en cuestión.

REFERENCIAS