Publicado en
Autor
En esta ocasión les hablaré de Smart Decisions, un juego que he desarrollado junto con mis colegas Rick Kazman del Software Engineering Institute (SEI) así como Serge Haziyev y Olha Hrytsay de la empresa Softserve. El objetivo del juego es ilustrar la manera en que se realiza el diseño de la arquitectura mediante el método de diseño Attribute Driven Design (ADD). Como parte del juego, se simula el diseño de un sistema de Big Data.
Comenzaremos recordando el método de diseño ADD y después hablaremos acerca de los detalles del juego incluyendo un enlace para descargar los materiales y jugarlo.
Repaso: diseño de arquitectura
La actividad de diseño de la arquitectura (ver SG29) se enfoca en la traducción de drivers, hacia un conjunto de estructuras que conforman la arquitectura. Recordemos que los drivers incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG28).
Attribute Driven Design
La transformación antes mencionada se puede realizar de manera sistemática usando el método de diseño Attribute Driven Design (ADD). ADD es un método iterativo de diseño de arquitecturas de software. El método consta de siete pasos que se muestran en la figura 1.
Figura 1. Pasos del método de diseño ADD.
Las actividades son las siguientes:
- El arquitecto se asegura de que tiene una buena comprensión acerca de los drivers que se usan como entradas al proceso de diseño.
- Se elige el subconjunto de drivers que serán tratados en la iteración.
- El diseño procede mediante el refinamiento de uno o más elementos que son elegidos en este paso. El refinamiento puede involucrar la descomposición de un elemento en subelementos y sus relaciones, o bien puede involucrar diseño adicional de elementos previamente identificados. Al inicio del proceso de diseño de sistemas ‘greenfield’ (desde cero), el único elemento que puede ser elegido es el sistema mismo, que es concebido como un único elemento. En iteraciones subsecuentes, o en el diseño de cambios a un sistema existente, se eligen uno o más elementos previamente definidos.
- Este paso involucra la identificación y selección de conceptos de diseño, que describiremos a continuación, que permitirán satisfacer los drivers elegidos para la iteración
- Una vez que los conceptos de diseño han sido elegidos, los elementos que se derivan son identificados y conectados. En este paso es donde nuevas estructuras se crean o estructuras existentes se refinan. Adicionalmente, las responsabilidades de los elementos se establecen y las interfaces expuestas por los elementos se definen.
- A pesar de que la documentación formal ocurre después del proceso de diseño, cierta información debe registrarse durante el diseño, cuando aún se encuentra fresca en la mente del arquitecto y hay menos probabilidad de que la olvide. En este paso se registra dicha información que incluye bosquejos de las estructuras creadas en el paso previo junto con decisiones de diseño y su justificación (rationale).
- En este paso, el arquitecto realiza un análisis de las decisiones de diseño que fueron realizadas durante la iteración y también del proceso de diseño en su conjunto. Como resultado, se toma la decisión de seguir realizando más iteraciones o de parar el diseño y de proceder a la implementación.
Conceptos de diseño
En el paso 4 del método ADD se eligen conceptos de diseño, que son los “bloques de construcción” del diseño de la arquitectura (ver SG46). Estos bloques son soluciones probadas a problemas recurrentes de diseño y pueden ser de naturaleza conceptual o concreta. Los tipos de conceptos de diseño que se consideran incluyen: arquitecturas de referencia, patrones, tácticas, familias tecnológicas y productos o frameworks.
Una de las dificultades que existen al momento de diseñar una arquitectura de software es la selección de conceptos de diseño. Existen cientos de patrones y tecnologías de dónde escoger y, además, la selección es complicada pues frecuentemente no es sencillo entender la influencia que puede tener un concepto de diseño particular sobre los atributos de calidad del sistema. Por ejemplo, cierta tecnología, ¿impacta o favorece el desempeño?
Como se puede apreciar, el diseño de arquitecturas de software no es una tarea sencilla, sin embargo, el uso de un método como ADD permite realizar esta actividad de manera sistemática lo cual aumenta las posibilidades de obtener un mejor resultado.
Smart Decisions
Dada la importancia de diseñar arquitectura siguiendo un método como ADD, decidimos desarrollar un juego cuyo objetivo es ilustrar conceptos importantes asociados con el diseño de arquitectura. Está diseñado para jugarse tanto por estudiantes como por practicantes que no tengan mucha experiencia en el diseño de arquitecturas. Cabe señalar que el juego no busca sustituir a los cursos de diseño de arquitectura, sino más bien, busca ser un complemento a los mismos.
Algunos de los conceptos principales que son ilustrados en el juego son los siguientes:
- El diseño arquitectural se desarrolla de manera iterativa y puede realizarse de manera sistemática usando un método como ADD.
- El diseño arquitectural comienza con drivers e involucra realizar decisiones de diseño. Algunas de estas decisiones incluyen elegir conceptos de diseño, lo cual generalmente es complicado, sobre todo para los diseñadores que se enfrentan con una “página en blanco” al iniciar el diseño.
- Todo concepto de diseño tiene una influencia sobre los drivers y, más específicamente, sobre los atributos de calidad.
- Las decisiones de diseño tienen consecuencias: algunas decisiones son mejores (de ahí que el juego se llame “Smart Decisions”) y algunas no lo son tanto. Por otro lado, las decisiones que se hacen en una iteración pueden tener consecuencias en iteraciones posteriores.
- Las decisiones de diseño deben ser registradas y analizadas como parte del proceso de diseño.
Smart Decisions requiere un mínimo de dos jugadores y un máximo de seis. Los jugadores pueden ser individuos o grupos de individuos. Adicionalmente, requiere de un facilitador que explique el contexto y la mecánica del juego. El juego se juega en una serie de rondas que representan distintas iteraciones del proceso de diseño de un sistema nuevo (greenfield).
En la primer iteración, el facilitador describe la manera en que los pasos de ADD se llevan a cabo en el juego. Como parte de la explicación inicial, el facilitador presenta también el contexto del juego, es decir, la descripción de los drivers del sistema que se va a diseñar. Actualmente, Smart Decisions cuenta con un contexto de juego de un sistema de Big Data, sin embargo, está diseñado para ser extensible y que en el futuro se puedan agregar contextos de juego relacionados con otros dominios aplicativos.
Para cada iteración, el juego proporciona la siguiente información, que equivale a lo que se obtendría de los pasos 2 y 3 de ADD:
- Objetivo de la iteración.
- Drivers a considerar.
- Elemento a refinar.
- Alternativas de conceptos de diseño a considerar.
A continuación, los jugadores deben elegir conceptos de diseño a partir de las alternativas que se les proponen. Esto representa la actividad que se realiza en el paso 4 de ADD y es la parte medular del juego. Los conceptos de diseño se presentan como un conjunto de cartas y cada una de estas cartas contiene información acerca de un concepto de diseño particular (ver figura 2). La información que se presenta en la carta incluye un nombre, un diagrama (si aplica), una descripción y una lista de drivers así como la influencia del concepto de diseño sobre los mismos. La influencia se mide mediante puntos, que están representados como estrellas. Un punto significa que el concepto de diseño no contribuye mucho a satisfacer el driver mientras que tres puntos significa que el concepto de diseño contribuye en gran medida para satisfacer el driver.
Figura 2. Tarjeta de un concepto de diseño relacionado con Big Data.
Una vez que los jugadores han elegido una carta, calculan un total en base a la influencia del concepto de diseño seleccionado sobre los drivers asociados a la iteración. Después de eso, simulan el paso 5 de ADD tirando dos dados. Respecto al paso 6 de ADD, como parte del juego no se realizan bosquejos del diseño, pero sí se documentan las decisiones de diseño, es decir los conceptos de diseño elegidos.
El paso 7 de ADD es guiado por el facilitador quien describe cuáles eran las opciones más apropiadas a elegir como parte de las iteraciones. Dependiendo de lo elegido, los jugadores reciben puntos adicionales o bien son penalizados. Para cada iteración se calcula un puntaje total que combina los puntos de las cartas elegidas, el resultado de tirar los dados y los bonos o penalizaciones resultantes del análisis. Al final del juego, se suman los puntos recibidos en las distintas iteraciones y se calcula un total. El jugador con el total más alto gana.
Una vez que termina el juego, el facilitador promueve una discusión con los participantes con el fin de intercambiar experiencias y opiniones relativas al juego y al proceso de diseño de arquitecturas en general. Esta discusión es un aspecto fundamental dentro de las sesiones de juego.
Conclusión
Smart Decisions es un juego que busca ilustrar el proceso que se sigue para diseñar arquitecturas de software usando ADD. Actualmente, el juego dispone de contenido enfocado al diseño de un sistema de Big Data, pero en el futuro esperamos disponer de otros contextos de juego. Hemos tenido la oportunidad de realizar sesiones de juego con diversas poblaciones que incluyen arquitectos de software, profesores y también con estudiantes(1). A raíz de estas sesiones, hemos recibido retroalimentación muy positiva acerca del juego.
Por último, cabe señalar que el juego está disponible de forma gratuita en http://www.smartdecisionsgame.com
Los invitamos a que lo descarguen, lo jueguen y nos den su opinión al respecto. Adicionalmente, estamos buscando contribuciones de la comunidad para generar otros contenidos en áreas distintas a Big Data.
Referencias
- Cervantes, H., Haziyev, S., Hrytsay, O., Kazman, R. “Smart Decisions: An Architecture Design Game”, http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=436542, SATURN Conference 2015.
El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Además de realizar docencia e investigación dentro de la academia en temas relacionados con arquitectura de software, realiza consultoría y tiene experiencia en la implantación de métodos de arquitectura dentro de la industria. Ha recibido diversos cursos de especialización en el tema de arquitectura de software en el SEI, y está certificado como ATAM Evaluator y Software Architecture Professional por parte del mismo. http://humbertocervantes.net
- Log in to post comments