Hasta no hace demasiado, pensaba que los documentos de textos eran una herramienta bastante válida para la creación y consulta de análisis funcionales basados en casos de uso. Eso sí, trabajando en aplicaciones de tamaño medio o incluso en servicios/módulos con funcionalidades muy específicas para aplicaciones grandes.

Actualmente estoy trabajando en un proyecto grande, y por ello se dividen los análisis funcionales en diferentes documentos de texto. Hasta ahí no tendría por qué haber ningún problema, ya que están divididos por subsistema para no tener un macro-documento funcional. Pero en este caso no es así, por que en muchos de los diferentes subsistemas, se encuentran repetidos casos de uso.

Esto es, que encuentras copy/paste de la descripción de un mismo caso de uso en diferentes documentos, y ésto en mi opinión nos lleva a dos grandes problemas:
- Problemas del mantenimiento del caso de uso para el analista, que debe controlar en qué documentos se repite para no perder coherencia.
- Desconocimento por parte del desarrollador de si es o no exáctamente el mismo caso de uso, debe comparar varios documentos, y aquí podemos heredar el problema de si están correctamente actualizados los documentos o no, lo que conlleva a péridas de tiempo y a posibles errores funcionales o duplicación de código.

Por otro lado, un compañero me ha prestado el libro UML Distilled(en mi caso la second edition) de Martin Fowler, muy recomendable por lo que he leído hasta el momento, sobre todo para los que no tenemos demasiados conocimentos sobre UML, y que además toca otros temas interesantes sobre desarrollo de software, aunque de forma superficial, como Extreme programming, diseño por contrato... En éste libro, encontramos en el tercer capítulo el tema de los casos de uso, y nos encontramos con que UML soluciona éste problema, forma similar a cómo lo haríamos programando, con los includes.

Un include es un tipo de relación de casos de uso (las otras relaciones serían generalization y extend), que como hemos comentado sería algo así a como lo haríamos programando, entonces llegamos a la conclusión que sí, se podría hacer en un documento de texto por ejemplo de ésta forma:"CU X ir a documento Y CU Z", que claro sigue teniendo el problema de mantenimiento del documento, puede cambiar el nombre del documento, el nombre del caso de uso...

Todo ésto me lleva a hacerme un par de preguntas, ¿existen herramientas para la gestión correcta de casos de uso? ¿open source :)?

Ya leí en infoq la noticia sobre la ponencia de Matt Raible en la ApacheCon sobre frameworks web, pero ha sido ha raíz del post de Martín sobre el tema que me decidí a prestar más atención a las transparencias de la ponencia.

Me parece bastante objetivo el formato de la comparativa a base de los pros y contras, los criterios de evaluación y las gráficas "bonitas" :). Tanto en la presentación que en un principio iba a realizar, como en la que finalmente realizó.

De estas transparencias me han gustado especialmente las recomendaciones para elegir un framework:

6 factores importantes:
Tipo de aplicación que vas a desarrollar.
Facilidad de desarrollo / opción "full-stack".
Comunidad detrás del proyecto.
Futuro del proyecto y hoja de ruta.
Mantenimiento.
Características técnicas.

No creas el hype:
No creas todo lo que leas en blogs y artículos.
Pruébalo tú mismo.
Cree a los desarrolladores, no a los evangelistas.
Cree a los desarrolladores con experiencia de un framework y que lo hayan usado en producción.
Ten cuidado con los intereses corporativos.
Los libros son una buena señal.

La mejor herramienta para el trabajo:
Los frameworks tienen puntos fuertes, ¿tu aplicación encaja dentro de esos puntos?
Selecciona 2 o 3 frameworks para tu tipo de aplicación...
... y prototipa!
Si prototipar se hace duro, cambia.
Haz más de un prototipo y haz una presentación con los pros y contras de cada framework.

Después de elegir:
Documenta las razones de tu elección.
Permite que los desarrolladores lo discutan.
Permite que escriban tu prototipo con otros frameworks.
No tengas miedo a probar nuevos frameworks.
No tengas miedo a usar viejos frameworks.
No tengas miedo a usar tu framework actual.

Y por fin, las conclusiones finales:
El futuro en cuanto a frameworks es brillante por la competitividad que existe entre ellos.
Los desarrolladores deberían conocer más de un framework.
Deberías probar un framework antes de descartarlo.
La variedad de frameworks web es algo bueno.
Haciendo una buena investigación, podemos ahorrar tiempo y dinero.
Las pruebas son el mejor camino para un futuro mantenimiento.

Ah! y por cierto, cómo se comenta en las transparencias no incluyas struts 1, elimínalo de inicio, por lo que llevo trabajando con struts no podría estar más de acuerdo :D.

En ocasiones, necesitamos ejecutar funciones javascript al cargarse una página (validaciones, autocompletados...).

Lo típico es hacerlo en el evento onload del body o poniendo las llamadas a nuestras funciones javascript dentro del código para que se vayan ejecutando mientras se carga la página, ésta sería la forma intrusiva de hacerlo, la forma no intrusiva sería utilizar window.onload.

window.onload = mifuncion();

Hay un problema que fácilmente nos puede surgir, cuando tenemos varias asignaciones a window.onload, ya que se ejecutará sólo la última.

En un principio se me ocurrió solucionarlo con una asignación común para toda la web, el problema es evidente, para una web más o menos grande llegaría a ser una macro-función, además de ser una solución nada elegante.
Al final a googleando un poco, acabé encontrando la solución en el blog de Robert Hahn, donde plantea tres formas de hacerlo para "que funcione", y una solución que al parecer es la ideal, simplemente es asignar a window.onload ésta función que nos devuelve una función anónima:

function makeDoubleDelegate(function1, function2) {
return function() {
if (function1)
function1();
if (function2)
function2();
}
}

Para probarlo simplemente con éste código, podemos ver que funcina correctamente:

window.onload = makeDoubleDelegate(window.onload, alert('1'));
window.onload = makeDoubleDelegate(window.onload, alert('2'));
window.onload = makeDoubleDelegate(window.onload, alert('3'));

Éste fin de semana (17 y 18 de Noviembre), se celebra aKademy'07, el encuentro de desarrolladores de KDE a nivel nacional, en el local de Hispalinux en Zaragoza. Está orientado a perfiles técnicos, se puede ver el programa en su web, y la entrada es libre hasta llenar el aforo del local.

Una lástima que no pueda asistir, tiene pinta de ser interesante.

Lo anuncia Aitor, en el blog de Linking Paths:

Peepcode es una web dónde se puede encontrar material para formarse en Ruby on Rails. Los materiales son de pago aunque tienen precios muy asequibles y, por lo que cuentan, de mucha calidad.

Viendo lo que han hecho ya, tanto Alberto como Aitor, por la comunidad java en español desde javaHispano y JavaConGanas, los materiales que vayan creando tienen toda mi confianza y seguro que ayuda mucho también a la comunidad hispana de RoR. Vamos, que si vuelvo a sacar tiempo para trastear RoR, no dudaré en pagar por tener material de calidad y en castellano.