A mi tampoco me gusta el UML aunque sea necesario… y deba usarlo.

(Esto empezó siendo un comentario a un post de Rodrigo)


En eso estamos…. Vamos que no me gusta el UML, que lo entiendo, lo comprendo y lo respeto, pero a mi no me gusta, que le vamos hacer. A ver si consigo explicarme …


Creo que UML es una buena herramienta y es necesaria, pero no es adecuada para todo tipo de proyectos, en especial para proyectos pequeños y medianos, supongo que es por eso por lo que Rodrigo dice que tiene “tendencia al mal uso”.


También pienso que UML requiere un nivel alto de experiencia, UML es un lenguaje y al igual que todos los lenguajes hay gente que los habla/escribe/entiende bien, muy bien, mal y regular. UML requiere mucha experiencia en el análisis de proyectos. Es como aquellos que creen que por usar el mejor editor de textos del mundo escribirán best-sellers mientras que el buen escritor escribirá bien a lápiz, boli o usando el notepad.


Yo creo que UML es para que los analistas modelen y los programadores programen, si se cambian o alteran los papeles el proyecto se convertirá en un desastre. ¿Se te ocurriría dejar a un arquitecto hacer un tabique ó lo que es peor a un albañil hacer un proyecto?


UML esta pensado para diseñar y documentar. UML debe ser como los planos de un edificio, en donde cada uno encontrará lo que busca, sin embargo creo que se olvida el hecho de que hay tres grandes cosas que documentar en un proyecto.


– El problema, la solución, y el código.
 
Y las tres están unidas por lo que un cambio en cualquiera de ellas, implicará un cambio en al menos una de las otras partes. Mantener toda esta documentación perfectamente sincronizada (es la única manera de que sirva de algo) supone un elevado esfuerzo.


UML propone una serie de diagramas y símbolos para documentar las tres fases, podrá estar limitado ó no, por lo que creo que cuando Rodrigo dice: “El error en este caso es que se nos olvida que significa la L de UML, Lenguaje. Y un lenguaje tiene como único cometido permitir la comunicación.”, “Seleccionar una serie de diagramas es como arrancar las páginas a partir de la J del diccionario de la RAE y obligar a que la gente solo use las palabras que quedan. Seleccionar diagramas concretos es limitar la capacidad de comunicación usando UML.”


De este modo da por hecho el cualquier analista con conocimientos de UML, entenderá el UML, de otro modo si cada uno hace lo que le da la gana, usa los diagramas que más le gusten con su simbología personalizada estaría por el contrario impidiendo la comunicación de igual forma.


Para que dos o más personas se entiendan necesitan establecer un lenguaje común que ha de estar formado por un conjunto de símbolos (alfabeto). Esto es lo que propone UML.


Tú puedes diseñar una solución a un problema y documentarla usando UML yo puedo entenderla usando mis conocimientos de UML, sin necesidad de mirar y entender el código. Piensa que puede estar programada en Berzotas.Net del cual yo no tengo ni idea.


En cuanto a la documentación, UML puede que no sea la panacea para documentar el código, pero ayudará a identificar cada uno de los sistemas de nuestro aplicativo y como interactúan entre ellos. Obviamente a los programadores nos gusta más (también por que lo hemos hecho así durante mucho tiempo) ver otra case de documentación.


Con lo expuesto, coincido plenamente con lo que dice Rodrigo acerca que solo es un lenguaje, que es muy fácil usarlo mal, exige mucho esfuerzo de aprendizaje, que no proporciona muchas ventajas salvo en proyectos grandes o complejos.

SharePoint – Sharepoint designer workflows

Hoy he estado probando el diseñador de Workflows que trae el nuevo Microsoft Office SharePoint Designer, y me he quedado asombrado, de la facilidad de uso y de la gran cantidad de cosas que se pueden hacer con el. Para hacer unas pruebillas he creado un sencillísimo flujo de trabajo, consistente en crear un anuncio en una lista de anuncios cuando se introduce una tarea y eliminarlo cuando una tarea se completa.


Abrimos nuestro sitio con el SharePoint Designer (SD), una vez cargado, nuevo contenido de SharePoint y Flujo de Trabajo.



Un asistente nos ayudará en la tarea, le indicamos el nombre que tendrá este flujo de trabajo y sobre que lista o biblioteca de documentos actuará. También debemos indicarle como se va ha iniciar este flujo de trabajo.



Si se indica “Permitir que este flujo de trabajo se inicie manualmente desde un elemento” podremos iniciar el flujo de trabajo  estemos en sharepoint viendo un elemento de la lista a la cual esta asociado el flujo de trabajo, en este caso la lista de tareas, mediante un botón nuevo que nos permitirá examinar el estado de los flujos de trabajo. Lo veremos después.   


Usando el asistente disponemos de un botón “Comprobar flujo de trabajo” con el cual podemos comprobar la coherencia de nuestro flujo de trabajo y nos indicará si existen o no errores en el diseño.


También podemos asociar al flujo de trabajo unos parámetros internos (Inicio…) con datos sobre el estado del flujo, así como las variables que deseemos que internamente mantendrá nuestro flujo de trabajo, en el ejemplo que he realizado, el ID del anuncio creado, se guarda en una variable interna del flujo de trabajo para posteriormente poder eliminar el anuncio que se corresponde con ese ID.


Una vez completados el titulo, la lista y el modo de iniciarse, especificaremos los pasos de los que consta nuestro flujo de trabajo.



Cada paso se puede iniciar si se desea con una condición, de manera que podríamos iniciarlo solo cuando algún campo del elemento de la lista con el que estamos trabajando cumple dicha condición. Por cada condición especificaremos también las acciones que se llevarán a cabo

En mi ejemplo, no se requiere de ninguna condición especifica para que las acciones se lleven acabo, el simple hecho de crear un elemento iniciará el flujo de trabajo. Las acciones ha realizar serán las de crear una nueva entrada en la lista de anuncios, almacenar el ID del elemento creado en una variable interna del flujo de trabajo, el flujo permanecerá entonces activo hasta que el estado del elemento sea completado, en cuyo caso el flujo terminará eliminando la entrada creada anteriormente usando el ID guardado.



Una vez completado podemos comprobar que todo esta correcto y guardarlo en nuestro sitio. Podemos crear tantos flujos de trabajo como deseemos dentro de un sitio incluso podemos encadenar unos con otros.



La proxima vez que entremos en nuestro sitio el flujo de trabajo estará activo.


    


Podemos comprobar el estado del flujo de trabajo mediante el botón de “Workflows” del que hablabamos antes




También existen una serie de informes acerca de como se están desarrollando los flujos de trabajo. Si puedo los postearé mañana. Finalmente solo decir que estoy impresionado con la facilidad que ofrece el asistente que sin lugar a dudas cumplirá las espectativas. Por lo menos las mías ya que personalmente creía que los workflows habría que programarlos usando WinFX y el SDK del Workflow foundation, el cual llevaba ya algún tiempo mirando.