Reingeniería De Procesos

Reingeniería de Procesos con UML 2.0
Roberto Canales Mora

1. UML con Borland Together CE 2. Diagramas de casos de uso 3. Diagramas de actividad UML 2.0 4. Diagramas de componentes UML 2.0 5. Diagramas Entidad-Relación 6. 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 nuevastecnologí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 buenaná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: desconocimientodel 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 ... 1. 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 supotencia, 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 ficherode 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 deherramientas, 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...