Reingeniería de Procesos con UML 2.0

Son muchas las compañías que al cabo del año me piden ayuda para saber como
documentar correctamente sus aplicaciones software. Algunas poseen guías de
usuario (otras ni eso) y documentación de muy bajo nivel (comentarios de los
programas).

Lo que obviamente falta es un nivel intermedio de documentación que ayude a
los analistas de negocio (lo que antes se llamaba orgánicos o funcionales
[porque ahora parece que todo el mundo hace de todo]) a identificar el impacto
de un cambio y a transmitir de un modo adecuado las instrucciones a los equipos
técnicos (¿os suena?). Lo que hace falta es saber modelar los sistemas.

Muchos me contactan porque han leído que el UML es la solución a sus
problemas (y encuentra en
www.adictosaltrabajo.com tutoriales sobre el tema)… no nos engañemos. UML
solamente es una notación para representar diagramas. Podría valernos igual otra
representación tradicional (aunque UML proporciona obviamente sus ventajas sobre
todo en nuevas tecnologías). Lo
que realmente hace falta es una metodología de trabajo para que todo el mundo,
desde un principio, genere una documentación escasa y útil. También hace falta
que, cuando las aplicaciones estén construidas, se establezcan unos
procedimientos sencillos para que, a medida que se van produciendo mejoras, se
vaya generando o completando la documentación deficiente.

Realizar un buen análisis o reingeniería requiere de técnica. Lo que
habitualmente les pasa a los analista, es que si les das una semana o dos para hacer
un análisis, el resultado varia muy poco. Se produce una parálisis del análisis
porque no se tiene un procedimiento estructurado que haga predecible la labor.
No te creas que no te pasa lo mismo cuando subcontratas servicios, acumulado a otros problemas:
desconocimiento del negocio, tecnificación de los problemas, falta de roles
definidos, tendencia a construir código demasiado pronto (sobre todo en
proyectos de nuevas tecnologías)

En mis cursos comento, para sorpresa de mucha gente (y siempre se puede no
estar de acuerdo) que la mayoría de los diagramas UML, que nos ayudan a
descubrir la aplicación y a obtener requisitos de nuestro clientes, se pueden
descartar (por la incapacidad e inconveniencia de mantener una documentación
demasiado grande). Bueno, esto es una guerra compleja en la que seguro muchos
responsables de desarrollo estáis metidos …

UML con Borland Together CE

Hoy vamos a ver como herramientas profesionales como Borland Together versión
CE (Versión Comunitaria y de descarga gratuita) puede ayudarnos a modelar
nuestros sistemas. Together es una de las mejores opciones del mercado, sino la
mejor (según mi opinión) aunque para conseguir toda su potencia, obviamente, hay
que pagar.

Vamos a Web de Borland

http://www.borland.com/products/downloads/download_together.html y elegimos
la versión. Vamos a omitir  algunos pasos porque ya los hicimos en otros
tutoriales (registro
y descarga )

El sistema nos envía un fichero con el fichero de licencia

Instalamos como todos los productos OK,OK,OK

Elegimos el directorio destino

A mi me gusta crear los iconos en el escritorio (aunque luego los reorganizo)

El aspecto es impecable. Podemos ver en la primera pantalla una introducción
a las novedades de UML 2.0. La especificación todavía no es oficial (Marzo 2005) por lo que
podrá sufrir algún cambio.  Las empresas de herramientas, como participan en
estas especificaciones, siempre están un paso por delante del resto de los
mortales (cosa a agradecer)

Una de las cuestiones a tener en cuenta en la futura especificación del UML 2.0 es
que ya no hay 9 tipos de diagrama sino 13 (saber
más). Actualmente con la versión de la herramienta no tenemos cobertura de
todos (hay que adquirir otras versiones de pago)

Vamos a crear un proyecto y ver el aspecto. Seleccionamos un proyecto UML 2.0.

Elegimos en nombre …

 y algunos parámetros básicos

ç

Y ya estamos funcionando.

Podemos, antes de empezar, crear algún paquete para que no
se nos desorganice el proyecto.

Diagramas de casos de uso

Creamos un nuevo diagrama de casos de uso de contexto. Este sería el primer
paso para una reingeniería de una aplicación (mapear el mapa de procesos con los
actores que intervienen). Nota: Como
regla de oro en UML, limitar (pongamos a 30), a priori, la cantidad de elementos
es un diagrama para obligarnos ha hacer muchos complementarios (lo digo por
aberraciones que encontramos por Internet con 2000 bolitas en un solo diagrama)

Y vemos que la dinámica es similar a otras herramientas (para eso están las
especificaciones)

Nos permite generar imágenes directamente a partir de  los esquemas (cosa que otras
herramientas CE no permiten) aunque nos pone abajo una nota (poco molesta). Ya
que nos proporcionan la herramienta, tampoco está mal que se sepa de donde se
saco el diagrama UML (creo que es la mejor publicidad).

Diagramas de actividad UML 2.0

Los diagramas de actividad son los que más cambios han tenido en
UML 2.0. Se definen nuevos artilugios que antes sustituíamos por notas (aunque
sigo opinando que para grupos que empiezan con UML es preferible usar los
mecanismos básicos y abusar de notas, para no obviar información)

Pintar las cajas es fácil. Lo realmente difícil es saber que pintar (que
requiere práctica) ¿Donde esta el fallo en el diagrama anterior? jejeje

Diagramas de componentes UML 2.0

También los diagramas de componentes han evolucionado en UML 2.0. No
olvidemos que lo importante de un componente es el interfaz que implementa de
tal modo que, posteriormente, podamos sustituir el componente por otro que
implemente el mismo interfaz. En UML 2.0 disponemos de nuevos artilugios para
ello.

Diagramas Entidad-Relación

Otra cosa que sorprende habitualmente a mis alumnos en los
cursos de UML es que les recomiendo no representar el modelo de dominio
con diagramas de clases sino utilizar diagramas entidad relación (esto es
realmente un poco de trampa pero ….. práctico …).

Together nos da soporte para este tipo de diagramas
Entidad-Relación (por lo que me da esperanzas de no estar demasiado
desencaminado)

Nos podría quedar inicialmente un diagrama tal que así (faltando
muchos elementos que iremos descubriendo en análisis):

Podemos trabajar con distintos niveles de precisión

Conclusiones

Con UML 2.0 nos va a cambiar el modo de utilizar los diagramas tradicionales. Preparaos para lo que viene….. 
http://www.omg.org/docs/ptc/03-08-02.pdf

Muchas veces tendemos a pensar que las herramientas solucionarán nuestros
problemas. Las herramientas son solo el soporte y debemos basarnos en un habito en el trabajo.
Sin método y disciplina, la cosa no mejorará.

Otra cosa que podrá ser absurda es contratar a 5 consultores, 4 meses, para
documentar nuestros procesos. El día que acaben (el día que acabe el contrato
porque es un trabajo sin fin) ya estará desactualizado, ya que el negocio se
mueve….

Os invito a que me contactéis (
rcanales@autentia.com 
) si queréis solucionar el problema ( o a cualquier otro centro de formación
experimentado [que no solo se dediquen a formar con personal junior] ), ya que
el único modo de resolverlo es a través de la formación personalizada y la
implantación de buenos hábitos y técnicas sobre:

• Dirección moderna de proyectos informáticas
• Estimación rápida de proyectos
• Gestión eficaz del tiempo
• Motivación de equipos
• Análisis y diseño orientado a objeto
• UML y modelado de datos
• Técnicas avanzadas de diseño (patrones)

No hay soluciones milagrosas y como para todo en esta vida requiere:

• Tener claro el problema a resolver (y descomponerlo en fases)
• Una estrategia bien definida (para eliminar las excusas de los que temen
  al cambio)
• Tiempo y paciencia (no es fácil implantar un método)
• Constancia
• Y un poquito de suerte ….