1. UML con Borland Together CE
3. Diagramas de actividad UML 2.0
4. Diagramas de componentes UML 2.0
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 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 …
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 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.
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).
3. 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
4. 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.
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
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 ( ) 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 ….
Roberto Canales Mora
www.adictosaltrabajo.com