Creación: 26-04-2009
Índice de contenidos
1.Introducción
2. Entorno
3.¿Qué significan los símbolos de AgileDraw?
4.Ejemplos
5.¿Puedo usar más símbolos, a parte de los básicos vistos antes?
6.Buenas prácticas con AgileDraw
7.Conclusiones
8.Sobre el autor
1. Introducción
En este tutorial vamos a ver una introducción a AgileDraw. AgileDraw, más que una herramienta, se trata de una técnica de modelado rápido. Es decir, AgileDraw persigue los principios de comunicación eficaz frente a herramientas, y comprensión frente a procesos. De esta forma AgileDraw nos proporciona cuatro elementos básicos para pintar nuestros modelos: círculos, cajas, líneas y texto. Con estos elementos nos centraremos más en el qué (lo que pretendemos comunicar), en vez de hacer hincapié en el cómo (que notación o herramienta utilizamos).
En la propia página de AgileDraw nos recomiendan que lo usemos cuando:
- Prefiramos simplicidad frente a complejidad.
- Documentación suficientemente buena frente a artefactos precisos.
- Compartir conocimiento frente a herramientas.
- Algo práctico frente a abstracciones idealizadas.
- Y por supuesto, conceptos frente a notación compleja.
Esto no quiere decir que AgileDraw pretenda sustituir el puesto al UML. Todo lo contrario, AgileDraw lo complementa perfectamente, tal como podemos ver en esta imagen sacada de su web:
2. Entorno
El tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil MacBook Pro 17′ (2.93 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM, 128GB Solid State Drive).
- NVIDIA GeForce 9400M + 9600M GT with 512MB
- Sistema Operativo: Mac OS X Leopard 10.5.6
3. ¿Qué significan los símbolos de AgileDraw?
En los sistemas informáticos, la información se identifica de dos maneras, en movimiento o almacenada. Basándose en esta premisa, AgileDraw utiliza los siguientes componentes:
- Puntos:
- Círculos que representan movimiento, flexibilidad. Por ejemplo «Listeners» como servidores de aplicaciones servidores de bases de datos, servidores de mensajes, …
- Cajas que representan cosas estáticas, faltas de movimiento, rígidas. Por ejemplo hardware, clases, entidades o tablas, interfaz de usuario, o en general cualquier cosa.
- Conectores: Las líneas representan la conexión entre los puntos. Las lineas pueden tener puntas de flecha para representar dirección. Podremos tener lineas de dos tipos:
- Solidas que representan concreción, sincronismo, asociaciones fuertes. Por ejemplo comunicación síncrona, relaciones entre entidades, …
- Punteadas que representan abstracción, asíncrono, asociaciones débiles. Por ejemplo comunicaciones asíncronas, extensión de clases abstractas, …
- Texto: Usaremos texto para describir los distintos puntos y conectores.
4. Ejemplos
Veamos algunos ejemplos sacados de la propia página de AgileDraw.
Una arquitectura a nivel general:
Un modelo de dominio:
Un diagrama de clases conceptual:
5. ¿Puedo usar más símbolos, a parte de los básicos vistos antes?
Claramente SI. AgileDraw no nos limita los símbolos que debemos usar en nuestros modelos, de hecho nos anima a usar cualquier cosa que sea significativa y comúnmente aceptadas por todos los interesados. Veamos un ejemplo:
Podemos observar en el ejemplo como el PC del cliente se representa con una especia de monitor, Internet se representa con la típica «nube», la base de datos con un «tambor», y un fichero de log con el típico rectángulo con una esquina «doblada».
AgileDraw también nos propone el uso de colores en nuestros modelos. Por defecto son los siguientes códigos de color, aunque como siempre podemos usar cualquier convención que queramos, siempre y cuando sea comúnmente aceptada por todos los interesados.
| Rojo | Acción, confianza, energía, poder, peligro, alerta. |
| Marrón | Orden, convención, conservador, estable. |
| Naranja | Resistencia, energía, creatividad, alegría, determinación, éxito, construcción. |
| Oro | Salud, prosperidad. |
| Amarillo | Sabiduría, felicidad, energía intelectual. |
| Verde | Vida, naturaleza, bienestar. |
| Azul | Verdad, distancia. |
| Púrpura | Realeza, misterio, imaginación. |
| Blanco | Pureza, limpieza. |
| Negro | Muerte, estabilidad. |
| Gris | Seguridad, madurez, neutralidad. |
También podemos usar sombras, degradados, fotos, bocadillos, distintos tipos de fuentes, … y en general cualquier cosa que haga más comprensible nuestro modelo.
6. Buenas prácticas con AgileDraw
En la página de AgileDraw podemos encontrar las siguientes buenas prácticas:
- Mantenlo sencillo, limitando el numero de distintos elementos en el mismo diagrama.
- Usa texto para describir las conexiones y los puntos. Puedes usar fuentes más pequeñas para elementos menos relevantes del diagrama.
- Los diagramas deberían ser auto explicativos. Para no usar documentación adicional, puedes usar notas o leyendas en el propio diagrama.
- Otras buenas prácticas cogidas de Comparison of Diagramming Methods, by Keith Stiern:
- El contexto del diagrama debe ser claro.
- Cada diagrama debe presentar una vista del sistema que sea independiente del resto de vistas.
- El contexto del diagrama se debe comprender claramente por su título, un texto, una referencia a otro contexto, o cualquier combinación de estos. En definitiva, el diagrama tiene que dejar claro que es lo que está representando.
- Debe tenerse en cuanta la fecha y la versión del documento. De esta manera no haremos cosas basadas en una versión antigua, ya que rápidamente se podrá identificar con que versión del documento están trabajando todos los interesados.
- Si hay más de un tipo de diagrama para un sistema, cada tipo de diagrama debe ser Ortogonal al resto de tipos. Esto quiere decir que cada tipo de diagrama debe presentar aspectos del sistema desde perspectivas que son totalmente independientes
7. Conclusiones
Como podéis ver AgileDraw es muy sencillo, ya que no tiene una notación extensa o un conjunto de reglas estrictas. Simplemente pretende mejorar la comunicación entre equipos, usando para ello herramientas sencillas (tan solo tenemos 4 elementos básicos: circulo, cuadrado, linea y texto).
Este tipo de técnicas son más que recomendables ya que ayudan a mejora la comprensión del sistema y mejorar el entendimiento entre los distintos miembros del equipo.
Además AgileDraw no necesita de una potente aplicación de modelado. Lo más potente y flexible para estas cosas suele ser un simple papel y un lápiz, una pizarra, o similar.
8. Sobre el autor
Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y ScrumMaster
Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)
mailto:alejandropg@autentia.com
Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»
