Resulta que me anote en una materia interesante y estoy necesitando encontrar una herramienta de UML a mano, facil y si es posible colaborativa... esto es online, o "en la nube"
Ya que estoy probando varias opciones, aprovecho para escribir un overview de todas las herramientas que probe. Para cada herramienta se incluye un diagrama generado con esta y la evaluacion de las siguientes caracteristicas:
* Almacenamiento: Si tiene storage para almacenar los diagramas online
* Vistas: Si tiene vistas publicas dinamicas para que se pueda mostrar en una pagina o en un blog la ultima version del diagrama
* Diagramas: Que tipos de diagramas se pueden hacer (diagramas de actividad, casos de uso, clases, objetos, secuencia, despliegue, colaboracion, transicion, componentes)
* Exports: Si se puede exportar como imagen o como algun otro formato editable
* Imports: Si se puede importar imagenes o incluso otros objetos
* Coop: Si es colaborativo, o sea, si varios usuarios pueden editar el diagrama simultaneamente diseñando de manera cooperativa.
* Estabilidad: Si es posible editar sin que se cuelgue o tenga algun otro fallo que afecte el trabajo
* Portabilidad: Si funciona en varios navegadores (por ahora testeados en Mozilla Firefox 3.6.8 con Ubuntu Linux)
* Registracion: Si es necesaria, y que implica
* Costo: Si tiene paquetes de uso gratis, si tiene paquetes de servicio pago, que limitaciones y precios hay de cada uno de ellos
* Engine: Como funciona, si usa java, flash, etc...
Cacoo
http://cacoo.com/
Segun mi opinion, uno de los mejores, si se pudiera guardar el diagrama en la computadora local seria perfecto
* Almacenamiento: SI
* Vistas: SI (ej: https://cacoo.com/diagrams/hB18F3rQnjWqxQ74/view )
* Diagramas: casos de uso, clases, secuencia, estados, componentes, deployment, ER y tiene mas bibliotecas de objetos
* Exports: Solo imagenes en formato PNG (la version gratuita)
* Imports: Cualquier tipo de imagen
* Coop: SI
* Estabilidad: Si tenes una conexion mala no lo uses
* Portabilidad: Funciona bien en firefox 3.6.8 y en Ubuntu Linux
* Registracion: SI o SI es necesaria (tambien con la version gratuita)
* Costo: Gratis (limitacion de 3 colaboradores por diagrama)
Engine: flash
Creatly
http://creatly.com
Este diagramador puede guardar archivos en la computadora local (ademas de poder guardarlos online)
* Almacenamiento: SI
* Vistas: SI
* Diagramas: Actividad, Clase, Colaboracion, Componentes, Deployment, ER, Objetos, Secuencia, Estados, Casos de uso, networking, electronica, de flujo
* Exports: PNG, JPG, PDF, Creatly File
* Imports: Image, Creatly File
* Coop: SI
* Estabilidad: Me colgo el firefox una vez, pero la mayoria de las veces lo pude usar
* Registracion: Se puede usar sin registracion (aunque se recomienda registrarse y es gratuito)
* Costo: Actualmente Gratis para 2 collaborators, U$S4.95 para 5 collaborators y un 1 Gb, U$S9.95 para ilimitado espacio y collaborators. No se puede tener varios proyectos ni exportar archivos en formato "editable" en la version gratuita. Ver http://creately.com/plans7
yUML
http://yuml.me/
Este es rarisimo, hay que poner un codigo (como una especie de lenguaje) y genera el diagrama. No tiene editor y es el que menos funcionalidades tiene, lo unico bueno que tiene es que funciona bien sin impotar cual sea el browser
* Almacenamiento: NO
* Vistas: NO (Algo parecido)
* Diagramas: clases, actividad, casos de uso
* Exports: Imagen PNG
* Imports: NO
* Coop: NO
* Estabilidad: 100% Siempre funciona, porque es muy sencillo
* Portabilidad: 100%, ya que no importa que browser uses, el diagrama se genera del lado del servidor a partir del "codigo" que se le ingrese
* Registracion: no hay
* Costo: Gratis
gliffy
http://www.gliffy.com/
Este es interesante, tiene el estilo del cacoo y al creatly, pero viene con templates base para crear diagramas (con lo que ayuda bastante al usuario primerizo), lastima que no me anda el drag&drop (¿sera mi version de flash?), cualquier cosa pruebenlo (no se necesita registracion para probar). En lo personal para lo que necesito no tiene elementos de suficientes diagramas.
* Almacenamiento: SI
* Vistas: SI (Ej: http://www.gliffy.com/pubdoc/2214754/S.png)
* Diagramas: Diagramas de flujo, networks, ER, UI, Diagramas de clases, secuencia, casos de uso
* Imports: SI, Formatos GIF, JPEG y PNG
* Exports: SVG(Visio), Gliffy Xml, Formatos graficos JPEG y PNG
Coop: SI
* Estabilidad: Por lo visto es estable, pero no lo pude probar bien
* Portabilidad: Me fallo en firefox 3.6.8 con Ubuntu Linux, talvez funcione en otras plataformas
* Registracion: Se puede usar sin registracion (aunque se recomienda registrarse y es gratuito)
* Costo: es Gratis, pero es un trial de 30 dias
gModeler
http://www.gskinner.com/gmodeler/
Mismo problema de drag&drop como con gliffy, mas tarde probare este y otros con otro entorno.
* Almacenamiento: NO (Aunque permite guardar como XML localmente)
* Coop: NO
* Portabilidad: MALA, no funciono en firefox 3.6.8 con Ubuntu Linux
* Registracion: no hay
* Costo: es totalmente Gratis
Mas tarde voy a probar gModeler desde otro entorno
Enlaces:
Cacoo: http://cacoo.com
Creatly: http://creatly.com
yUML: http://yuml.me/
gliffy: http://www.gliffy.com/
gmodeler: http://www.gskinner.com/gmodeler/
martes, 24 de agosto de 2010
jueves, 19 de agosto de 2010
Diagramas UML online
Visiten esta web:
http://yuml.me/
Permite crear diagramas UMLs online usando un lenguaje bastante interesante, no tuve mucho tiempo para probarlo mas que para hacer este diagrama que les estoy mostrando
lunes, 16 de agosto de 2010
La magia del TDD: un ejemplo real en ruby
Este fin de semana comence un proyecto, una nueva gema que "desparsea" los arboles generados por la gema ParseTree. Explicar los detalles de ese proyecto no es el tema de este articulo, sino mas bien contar la experiencia con TDD.
Para los que no saben que es TDD la wikipedia explica. Sin son vagos como para clickear el link, TDD es una metodologia que basicamente tiene dos pilares: "write tests first" (escribir los test primero) y "refactoring".
Resulta que lo que estoy desarrollando consiste en una funcion que revierte o encuentra la preimagen de otra funcion (es decir, genera un string con codigo ruby que resulte en un determinado arbol cuando se parsee con ParseTree).
Manos a la obra:
Paso 1) Escribir los tests primero:
http://github.com/tario/unparse_tree/tree/0ca29f14
En este caso se fue desarrollando de manera de ahorrar lineas y probar *todos* los casos (mas adelante se sabe que se omitieron algunas cosas, pero creo q eso es comun en TDD sobre todo cuando el analisis de cobertura no es viable)
Paso 2) Implementar hasta que todos los tests pasen:
http://github.com/tario/unparse_tree/tree/48c9a997
Cambios hasta que funcione, algunos "harcodean" o ponen "magic values", otros agregan funcionalidad a conciencia, lo importante es que cada commit disminuye el numero de errors + failures reportados y no se modifican los tests
Paso 3) Refactoring:
En esta etapa se modificara el codigo hasta que se vea minimamente "bien", es decir, se eliminara codigo duplicado, se implementaran las cosas "de verdad" en lugar de usar "magic values", "harcodeos" o "if extraños" y cualquier cambio que mejore el diseño/la distribucion del codigo, de mas esta decir que por cada cambio todos los tests siempre tienen que pasar. Todavia no alcance esta etapa en el proyecto... ya llegara.
Paso 4) Vuelta al paso 1:
Con nuevos requerimientos y/o bugs encontrados, se genera una nueva bateria de tests y el ciclo vuelve a comenzar.
De todo esto, en la practica me encuentro con las siguientes ventajas de usar TDD:
* La validacion de si el codigo funciona es automatica, con solo ejecutar un comando puedo saber si "rompi" el codigo o si estoy progresando
* TDD guia a escribir el codigo de manera "correcta" o por lo menos mas prolija
* Se puede testear un numero mas grande de casos, con lo que se cubren mayor cantidad de posibilidades
Y, como todo, tiene sus desventajas (aunque se mitigan y son evidentamente superadas por las ventajas)
* Hay que programar las pruebas que si no se usara TDD, no se tendrian que programar (de todas maneras, con o sin TDD siempre hay que testear el software, y sin TDD se hace de forma manual)
* Las pruebas no garantizan cobertura total, es decir, pueden ser %100 exitosas las pruebas y el software fallar en la practica al haber omitido algo (esta claro que la idea en principio no es confiar ciegamente en las pruebas, mas bien TDD tiene que basarse en la construccion de pruebas)
* Durante la fase de desarrollo, me doy cuenta de errores que se ven en el codigo o al escribir el codigo, pero no puedo corregirlos si no existen tests que pasen como resultado de esa correccion (para resolver esto se puede optar principalmente por dos alternativas, una seria registrar como un "ticket" la necesidad de agregar el test para el proximo ciclo, la otra seria agregar el test en ese mismo momento, aunque eso se alejaria del espiritu del TDD y superpondria los pasos 1 y 2)
Cabe destacar que las ventajas del TDD asi como otras metodologias son apreciables a mediano y largo plazo (TDD mas que otras), ya que a medida que avancen los ciclos de TDD, los tests desarrollados en ciclos anteriores cumpliran el rol de automatizar las regresiones, es decir, que si se modifica el codigo en un proyecto que tiene 8 meses de vida, las pruebas automaticas rebelaran si se rompio funcionalidad implementada al principio del proyecto, tres meses atras, dos meses atras, que implemento otra persona, etc...
Despues de varias iteraciones, volvere a postear para hacer un analisis de las ventajas de TDD a largo plazo
Enlaces
http://en.wikipedia.org/wiki/Test-driven_development
http://github.com/tario/unparse_tree/tree/0ca29f14 (tests creados en el primer ciclo de unparse_tree)
http://github.com/tario/unparse_tree
Para los que no saben que es TDD la wikipedia explica. Sin son vagos como para clickear el link, TDD es una metodologia que basicamente tiene dos pilares: "write tests first" (escribir los test primero) y "refactoring".
Resulta que lo que estoy desarrollando consiste en una funcion que revierte o encuentra la preimagen de otra funcion (es decir, genera un string con codigo ruby que resulte en un determinado arbol cuando se parsee con ParseTree).
Este requerimiento tiene un grado muy alto de testeabilidad ya que se puede calcular el input correspondiente a partir del output esperado (seria como el testeo oracle, pero al revez porq estamos buscando hallar la inversa de una funcion que ya tenemos, que es ParseTree)
Manos a la obra:
Paso 1) Escribir los tests primero:
http://github.com/tario/unparse_tree/tree/0ca29f14
En este caso se fue desarrollando de manera de ahorrar lineas y probar *todos* los casos (mas adelante se sabe que se omitieron algunas cosas, pero creo q eso es comun en TDD sobre todo cuando el analisis de cobertura no es viable)
Paso 2) Implementar hasta que todos los tests pasen:
http://github.com/tario/unparse_tree/tree/48c9a997
Cambios hasta que funcione, algunos "harcodean" o ponen "magic values", otros agregan funcionalidad a conciencia, lo importante es que cada commit disminuye el numero de errors + failures reportados y no se modifican los tests
Paso 3) Refactoring:
En esta etapa se modificara el codigo hasta que se vea minimamente "bien", es decir, se eliminara codigo duplicado, se implementaran las cosas "de verdad" en lugar de usar "magic values", "harcodeos" o "if extraños" y cualquier cambio que mejore el diseño/la distribucion del codigo, de mas esta decir que por cada cambio todos los tests siempre tienen que pasar. Todavia no alcance esta etapa en el proyecto... ya llegara.
Paso 4) Vuelta al paso 1:
Con nuevos requerimientos y/o bugs encontrados, se genera una nueva bateria de tests y el ciclo vuelve a comenzar.
De todo esto, en la practica me encuentro con las siguientes ventajas de usar TDD:
* La validacion de si el codigo funciona es automatica, con solo ejecutar un comando puedo saber si "rompi" el codigo o si estoy progresando
* TDD guia a escribir el codigo de manera "correcta" o por lo menos mas prolija
* Se puede testear un numero mas grande de casos, con lo que se cubren mayor cantidad de posibilidades
Y, como todo, tiene sus desventajas (aunque se mitigan y son evidentamente superadas por las ventajas)
* Hay que programar las pruebas que si no se usara TDD, no se tendrian que programar (de todas maneras, con o sin TDD siempre hay que testear el software, y sin TDD se hace de forma manual)
* Las pruebas no garantizan cobertura total, es decir, pueden ser %100 exitosas las pruebas y el software fallar en la practica al haber omitido algo (esta claro que la idea en principio no es confiar ciegamente en las pruebas, mas bien TDD tiene que basarse en la construccion de pruebas)
* Durante la fase de desarrollo, me doy cuenta de errores que se ven en el codigo o al escribir el codigo, pero no puedo corregirlos si no existen tests que pasen como resultado de esa correccion (para resolver esto se puede optar principalmente por dos alternativas, una seria registrar como un "ticket" la necesidad de agregar el test para el proximo ciclo, la otra seria agregar el test en ese mismo momento, aunque eso se alejaria del espiritu del TDD y superpondria los pasos 1 y 2)
Cabe destacar que las ventajas del TDD asi como otras metodologias son apreciables a mediano y largo plazo (TDD mas que otras), ya que a medida que avancen los ciclos de TDD, los tests desarrollados en ciclos anteriores cumpliran el rol de automatizar las regresiones, es decir, que si se modifica el codigo en un proyecto que tiene 8 meses de vida, las pruebas automaticas rebelaran si se rompio funcionalidad implementada al principio del proyecto, tres meses atras, dos meses atras, que implemento otra persona, etc...
Despues de varias iteraciones, volvere a postear para hacer un analisis de las ventajas de TDD a largo plazo
Enlaces
http://en.wikipedia.org/wiki/Test-driven_development
http://github.com/tario/unparse_tree/tree/0ca29f14 (tests creados en el primer ciclo de unparse_tree)
http://github.com/tario/unparse_tree
martes, 10 de agosto de 2010
Soy malo para los nombres de blogs
He creado un nuevo blog, llamado Soy malo para los nombres de blogs, sera el sumidero de las sobras de todos los blogs, no entren ahi
Enlaces:
http://soymaloparalosnombresdeblogs.blogspot.com/
Suscribirse a:
Entradas (Atom)