icono_twiter icono LinkedIn icono Facebook Icono Xing
Roberto Canales Mora

Creador y propietario de AdictosAlTrabajo.com, Director General de Autentia S.L., Ingeniero Técnico de Telecomunicaciones y Executive MBA por el Instituto de Empresa 2007.
Twitter:

Autor de los Libros: Planifica tu éxito: de aprendiz a empresario y Informática profesional, las reglas no escritas para triunfar en la empresa

Puedes consultar mi CV y alguna de mis primeras aplicaciones (de los 90) aquí

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2008-06-27

Tutorial visitado 14.631 veces Descargar en PDF

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

 

A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL: