Directriz: Análisis de variabilidad
Análisis de variabilidad crea un modelo que separa los cambios a partir de los aspectos más estables del modelo de dominio. Esto permite la externalización de tipos anticipados de cambios y sus correspondientes reglas, permitiendo la futura introducción no intrusiva de cambios en el diseño existente.
Relaciones
Descripción principal

Introducción

El diseñador de servicio debe ser consciente de que en la formación de un Artefacto: Especificación de servicio debe equilibrar dos fuerzas que compiten;

  • Especialización; la necesidad de garantizar que un servicio hace lo que se necesita de él, rellenando la función identificada durante la Actividad: análisis de activos existentes.
  • Generalización; la necesidad de garantizar que un servicio es tan reutilizable como sea posible, en tales requisitos futuros no necesita el rediseño importante de los servicios existentes.

Para esta finalidad, el diseñador puede emplear técnicas denominadas comúnmente análisis de "factores comunes y variabilidad". Estas técnicas se conocen y se han documentado durante algún tiempo, sobre todo en el área de la formulación de patrones [Coplien, Gabriel] y la ingeniería de la línea de productos de software [GBS, JGBS01, JB02, MRR04, Parnas, SBM01]. Se trata de áreas en las que el diseñador también equilibra estas mismas fuerzas en patrones ( la necesidad de capturar la variabilidad como parámetros para el patrón, permitiendo así la aplicabilidad del patrón en distintas situaciones).

En la literatura de patrones [Coplien] describe factores comunes como "la esencia de una abstracción" y variabilidad como "el condimento de la vida", mientras [Gabriel] describe de forma más concreta la relación entre los factores comunes y la abstracción:  una buena abstracción necesita capturar los aspectos comunes de la solución al tiempo que especifica las variabilidades de los elementos individuales.

Abstracción en programación es el proceso de identificar patrones comunes que tienen variaciones sistemáticas; una abstracción representa el patrón común y proporciona un medio para especificar qué variación utilizar.

En un sentido similar [Parnas] define una familia de programas (lo describiríamos en términos de línea de productos de software hoy en día) basados en las propiedades comunes del conjunto y las propiedades especiales de los miembros individuales:

Consideramos que un conjunto de programas constituye una familia, aunque siempre merece la pena estudiar los programas del conjunto evaluando primero las propiedades comunes del conjunto y determinando posteriormente las propiedades especiales de los miembros individuales de la familia

Captura de la variabilidad

Muchos sistemas se crean con muy poca previsión para incorporar los cambios resultantes de nuevos requisitos. El análisis de factores comunes y variabilidad crea un diseño elástico que es mucho más adaptable al cambio. Esto se lleva a cabo evitando la codificación y el diseño duros de aspectos del dominio que se anticipan al cambio a través del proceso de externalización: separando los aspectos más rápidamente cambiantes de los aspectos funcionales y estructurales del dominio de los aspectos más estables y no cambiantes. Esta técnica permite que el diseño del sistema evoluciones y crezca en razón de los nuevos requisitos sin alteraciones intrusivas. Durante el análisis, los factores comunes y las variabilidades se modelan en términos de jerarquías de tipo. Cada punto de variabilidad se identifica y externaliza. Por ejemplo, instancias de variación como Cliente de organización y Cliente individual se pueden modelar como dos realizaciones de un Tipo de cliente que puede posteriormente expandirse cuando sea necesario. El tipo externalizado (caso de Tipo de cliente) está asociado con las reglas del cliente que incluyen a todos los clientes y permiten que se realicen ajustes y extensiones en tipos de regla específicos y en cada tipo de cliente.

El primer paso en el análisis es la identificación de dependencias en el tipo tanto desde la perspectiva funcional (estáticas) como desde la de proceso (dinámica). La identificación de tipos de procesos que depende de tipos de entidades (funcional) es una buena heurística para la refactorización del diseño:

  • Identificar elementos comunes de función y proceso (por ejemplo, Proceso empresarial de reserva).
  • Separar aspectos cambiantes de aspectos menos cambiantes. Identificar tipos clave relacionados con función y proceso que se anticipen al cambio o que sean dependientes (el Tipo de reserva varía según el tipo de cliente; si el tipo de cliente cambia, el Tipo de reserva puede cambiar en consecuencia).
  • Externalizar las variaciones y crear jerarquías de tipo con instancias conocidas (el Tipo de frecuencia es Preferido o Regular, la Parte es Organizativa o Individual).

Estos puntos de variabilidad son un componente clave de los sistemas de compilación flexibles y adaptables. Al externalizar los puntos de variabilidad, podemos modificarlos sin que ello tenga impacto en el resto del diseño. Por tanto, el efecto onda del cambio queda contenido y limitado por los puntos de variabilidad. Un diagrama de clase UML que muestra esta jerarquía ofrece una guía básica para un diseño detallado y, en última instancia, para la implementación.

Los principios básicos de diseño de factores comunes y variabilidad son por lo tanto:

  1. Separar los aspectos cambiantes de los menos cambiantes de un dominio
  2. Separar la interfaz de la implementación
  3. Concretar lo que cambia. Si algún elemento del dominio está en constante flujo, entonces podríamos garantizar la materialización de dicho elemento en una clase (o en una capa más alta de reutilización).
  4. Crear activos en cada nivel de reutilización. Los niveles de reutilización son los siguientes: clase base, jerarquía de herencia, jerarquía de agregación, clúster, infraestructura, componente, patrón, arquitectura genérica.
  5. Cada elemento de reutilización tiene sus propias reglas de comportamiento, además de los metadatos necesarios para autodescribir de forma reflexiva y adaptable el elemento de reutilización para las consultas de tiempo de ejecución de las funciones de servicio

Referencias

[Arsanjani]    A. Arsanjani. Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules. Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

[Coplien]    J. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley Professional; primera edición, 1998.

[Gabriel]    R. P. Gabriel. Patterns of Software: Tales from the Software Community. Oxford University Press, 1998.

[GBS]    J. van Gurp, J. Bosch and M. Svahnberg. Managing Variability in Software Product Lines. http://citeseer.ist.psu.edu/568368.html

[GHJV]    E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns. Addision-Wesley 1994.

[JGBS01]    J. van Gurp, J. Bosch, and M. Svahnberg. On the notion of variability in software product lines. In Proceedings 2nd Working IEEE / IFIP Conference on Software Architecture (WICSA), páginas 45--54. IEEE Computer Society, 2001. http://citeseer.ist.psu.edu/vangurp01notion.html

[JB02]    M. Jaring, J. Bosch, Representing Variability in Software Product Lines: A Case Study, de aparición en la Second Product Line Conference (SPLC-2), San Diego CA, 19-22 de agosto de 2002. http://citeseer.ist.psu.edu/jaring02representing.html

[MRR04]    Jurgen Meister, Ralf Reussner, and Martin Rohde. Managing Product Line Variability by Patterns. http://se.informatik.uni-oldenburg.de/pubdb_files/pdf/ManagingProductLineVariabilityByPatterns-Final.pdf

[Parnas]    D. L. Parnas. On the Design and Development of Program Families. IEEE Transactions on Software Engineering, SE-2(1):1--9, 1976.

[SBM01]    A. Stephenson, D. Buttle and J. McDermid. Extending Commonality Analysis for Embedded Control System Families. Lecture Notes in Computer Science, Volume 1951, 2001. http://citeseer.ist.psu.edu/stephenson51extending.html

[SGB01]    M. Svahnberg, J. van Gurp, J. Bosch, A Taxonomy of Variability Realization Techniques, submitted June 2001. http://citeseer.ist.psu.edu/svahnberg01taxonomy.html