UML con Rational Visual Modeler V7.0

0
20138

Primeros pasos con IBM Rational Modeler 7.0

 

Periódicamente nos gusta revisar las opciones del mercado en
lo que a herramientas UML se refiere. Vamos a aprovechar para mostrar cómo
usamos y enseñamos a usar UML.

La descarga e instalación es trivial, por lo que hoy nos
vamos a centrar en pintar, a modo de evaluación unos cuantos diagramas y
descubrir  las capacidades de esta herramienta.

Vamos a construir un proyecto base:

                                          

En el tipo, elegimos General->Modelo en blanco. Es un
detalle que venga en castellano. En la ayuda podemos ver que disponemos de
todos los diagramas.

Como diagrama pre-determinado debemos elegir uno. Un
consejo, no empecemos por los diagramas de clase. Para hacer un buen diseño,
hace falta hacer un buen análisis y una buena toma de requisitos. Si partimos
de clases nos deberíamos plantear si no pecamos de deformación técnica.

Una de las cosas más confusas en UML es organizar
correctamente los diagramas. Tenemos dos vistas de la misma información:
Modelos y diagramas.

Siendo muy puristas (http://doi.ieeecomputersociety.org/10.1109/52.469759),
podemos recordar los modelos o vistas 4+1 de:

·        
Modelo de casos de  uso: Casos de uso, prueba, colaboraciones, etc…

·        
Modelo lógico: Paquetes, objetos, clases, entidades (aunque suene
pecaminoso), etc.…

·        
Modelo de proceso: Estados, secuencias, concurrencia,
sincronización tiempo, etc.

·        
Modelo de desarrollo: Organización estática del producto: Componentes,
interfaces

·        
Modelo físico: Despliegue, nodos, componentes

 

Nosotros no vamos a ser tan ortodoxos (la regla  de oro es
saltarte las normas sólo cuando las conozcas) y vamos a empezar a hacerlo más
sencillo creando sobre la marcha otra organización (siempre luego se puede
reestructurar J a modelos más
formales)… por eso, que luego vienen las críticas, que lo haga yo así ahora, no
significa que lo tenga que hacer así nadie más (cada uno que elija su camino).

Creamos un modelo llamado casos de uso. En el diagrama principal
vamos a pintar un diagrama de casos de uso de contexto.

 

Mucha gente, con estas herramientas (entre los que me
incluyo cuando cambias entre una y otra) nos volvemos locos porque, aunque
conceptualmente son parecidas, cada una tiene sus particularidades y encontrar
las cosas cuesta. Lo primero que tenemos que mirar es el menú de puntos de
vista. Esto significa que en función del rol y tipo de proyecto que hayamos
decidido hacer (recordamos que elegimos un proyecto donde verlo todo), se nos
activen unos menús y diagramas u otros.

Lo más práctico inicialmente puede ser crearte un punto de
vista personalizado, donde este todo activo.

Elegimos todas las opciones de UML.

Nos fijamos en la barra de elemento en la derecha y veremos
que ha crecido 

La aplicación es muy intuitiva, como otras que vimos en el
pasado: Poseidón o Visual Paradigm (cuando pone el ratón en un elemento te
aparecen los iconos de las posibilidades que tienes)

Recordemos que UML provoca habitualmente malas interpretaciones
y que deberíamos poner notas para aclarar los diagramas. Otras normas
fundamentales: Limitar el número de elementos en un diagrama y no tratar de
hacer los diagramas completos (no pintar todas las relaciones sino las
significativas.. que no quita para que no estén).

A la hora de estructurar los modelos, hemos dicho que nos
tomaríamos unas licencias. Creamos el modelo de Actores para tenerlos todos
juntitos (como nota, si no tenemos todos esos actores en una aplicación típica…
es posible que se nos esté olvidando algo de la aplicación… que posiblemente
saldrá al final).

 

Fijarse en el detalle de la barra de herramientas: Disponer
todo y alinear… muy útil.

En los cursos de UML que damos, es raro pero evitamos usar
las herramientas… no confundamos un cursos de Análisis y diseño con uno de usar
una herramienta (aunque se pueden contar las dos cosas a la vez.. una cosa
puede despistar la otra). Es más importante y difícil saber lo que pintar que
luego pintarlo (y darle integridad)

Creamos otro modelo, reservado para el negocio. En este
punto, sería el equivalente a un modelo entidad relación. Aunque lo pintemos
con un diagrama de clases, no confundamos los términos, todavía estamos a un
nivel muy alto y deberíamos pensar más en un modelo entidad relación (de hecho,
en metodología como Métrica3, no acabo de entender por qué se tiene que elegir
entre una cosa y la otra). Francamente, me gusta que las herramientas UML me
dejen pintar diagramas entidad relación y luego puedas elegir la notación, de
las muchas disponibles (y si luego te generan los scripts de creación de tablas
y relaciones… mejor) aunque esta herramienta no es el caso.

Creamos un modelo de clases: Antes de empezar, lo
descomponemos en 3: presentación, negocio y servicio… podría haber más (sobre
todo cuando tenemos clases de acceso a datos)

Vamos a crear un modelo de colaboraciones (para guardar
secuencias concretas sobre nuestros casos de uso). A un caso de uso (pulsando
en botón derecho), le vamos a añadir un diagrama de secuencia para concretarlo.

Los actores ya los tenemos, por lo que no vamos a crearlos
otra vez.

Lo seleccionamos dentro de los elementos existentes.

Las primeras secuencias que hacemos, son para descubrir la
funcionalidad (la maqueta, los campos de ida y de vuelta y las entidades y
campos involucrados… muy útiles para métodos formales y heurísticos de
estimación de proyectos).

Creamos un nuevo tipo (que podríamos definir y guardar con
los actores) que es el sistema.

Ahora podemos definir los mensajes entre el actor y el
sistema.

A este nivel, los diagramas deberían poder leerse como una
secuencia completa.

Recordamos que, siendo también ortodoxos, los mensajes de
retorno se utilizarían como salidas excepcionales del sistema. La notación es
mensaje (valiable:Tipo):Retorno, por lo que el retorno es implícito al mensaje
… aunque esto es de larga discusión.

Podemos configurar en las opciones, si queremos que se
pinten automáticamente o no.

Podemos tener en una colaboración una secuencia o varias. De
hecho, se podría tener distintos niveles de detalles (el tiempo de análisis y
diseño no es infinito).  Normalmente es mejor analizar y diseñar en amplitud y
sólo en profundidad en los puntos clave (se supone que nuestros frameworks de
desarrollo debería resolver las partes más complejas y comunes)

Creamos un segundo diagrama…

En este caso, en vez de usar la línea de vida de sistema,
vamos a tirar un pelín de los patrones de GRASP  y de los estereotipos de RUP…
advertimos que como siempre a nuestro estilo poco formal pero creemos que más
práctico (Interfaces, gestores y entidades)…

Para los que hayáis trabajado con Struts os sonará esto de
las acciones… aunque todavía no estamos diciendo cómo hacerlo. Lo que quiero
decir, es que de independientemente del Framework, hay una clase de acción que
se va a encargar de interceptar la petición del usuario y llamar a la lógica de
negocio.

Creamos una clase de interfaz….

Y suele ser una buena práctica que todas las clase de una
familia tengan los mismos compromisos a través de la pertenecia a un interfaz
(compromiso más fuerte respecto al framework).

Hacemos lo mismo con los Gestores, aunque ahora no les agrupamos
con el interfaz marcador… ya no tienen tantas cosas en común.

Si os fijáis, las clases están estereotipadas. Lo que no he
visto es cómo crear tus propios estereotipos e iconizarlos. Lo curioso es que
cuando creas otro tipo de proyectos si aparecen eso estereotipos de RUP.

Ahora añadimos desde elemento existente.

Elegimos nuestro interfaz y gestor.

Pero ahora, cuando creemos mensajes, estos ya sí se
convertirán en métodos de la clase. Esto hay que hacerlo con cariño porque…
todavía no hemos aplicado ningún principio de orientación a objeto ni patrones….

Asignamos el nombre del método y la clase.

Repetimos la operación del interfaz al gestor.

Bueno, esto va cogiendo forma…

Aunque los diagramas de secuencia evolucionan y permiten
cada vez representa más cosas (bucles y bifurcaciones), a mí personalmente no
me gusta. Prefiero que los diagramas de secuencia sean los más simples y
optimistas.

Vamos a explotar un caso de uso con un diagrama de
actividad. Lo hacemos a partir del botón derecho.

 

Ahora, sólo tenemos que pintar nuestros diagramas que nos
pueden valer para entrevistarnos con los clientes y obtener otras secuencias y
condiciones complejas. Los diagramas de actividad son especialmente importantes
para representar procesos batch y secuencias de flujos.

A media que vamos ligando los artilugios de UML, disponemos
mayores capacidades de navegabilidad entre los elementos.

Vemos el resultado

Vamos a crear unos diagramas más, para volver a navegar y
ver cómo queda.

Volvemos a ver las dependencias. Ojo a la barra justo encima
del diagrama, donde podemos definir el nivel de profundidad de las relaciones
que hay que mostrar en pantalla.

Cuanto más técnicos somos, más nos gustan los diagramas de
clase. Vamos a ver cómo dentro de Rational Modeler utilizar los asistentes de
creación de patrones.

Ahora sólo hay que navegar por ella.

Elegimos la vista de patrones y elegimos el adecuado. Con el
botón derecho, elegimos aplicarlo. Jeje .. ahora tenemos que saber que
significa cada uno … pero no vale más o menos, porque hay que poner nombres a
cada clase.

Elegimos los nombres

Y vemos cómo queda todo….

Borramos el patrón del diagrama (no del modelo) y
reorganizamos automáticamente:

Bueno, ahora sólo hace falta estudiar un poco…

Rational Modeler es una herramienta perteneciente a una
familia más amplia…. Cuando echas de menos algo te tienes que preguntar ¿No
será que no tengo la adecuada? Características que buscamos y no encontramos en
esta versión per si en otras.

Siguiendo este link, podemos ver la comparativa entre
versiones donde sólo destacamos unos pocos puntos.

http://www-1.ibm.com/support/docview.wss?rs=2042&context=SSRTLW&context=SSJM4G&context=SSSTY3&context=SSCGQ7C&q1=Comparison&uid=swg27010975&loc=en_US&cs=utf-8&lang=en

Esta versión en concreto no hace transformaciones a código.

Tampoco disponemos de la capacidad de ver cómo Java las
secuencias.

Pero recordemos, esta es la herramienta de modelado…

Como conclusión: Me parece una herramienta muy rápida y
estable. También la definiría como sobria… y buena opción para modelar
sistemas.

 

Enlace recomendado: What’s new in IBM Rational Software Modeler V7.0

 

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad