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