Ingenieria inversa en eclipse Java2UML con ObjectAid

Siempre he estado intentando mitigar el impacto de los diseños de Java, al traspasarlos a papel, ya que en muchos casos, siempre me ha parecido más sencillo diseñar la solución con código delante, antes que meramente en papel, teniendo que imaginar relaciones, herencias e implementaciones que prefiero plasmar físicamente en código antes que en papel.

Para superar esa barrera, que probablemente no debería hacerse con “la norma” en la mano, he usado diferentes herramientas para convertir el código creado en Java a un diagrama UML. Después de varios intentos he encontrado uno que después de haberlo usado voy a decir que es decente, para iniciar un diseño, aún no siendo todo lo cómodo que me gustaría que fuese, tiene muchas ventajas.

Este es ObjectAid lo que más me gusta de esta herramienta es su integración en eclipse y su más que buena capacidad de drag and drop, arrastrar una clase, o un paquete o un proyecto completo a un diagrama, lo convierte en UML, sencillamente me encanta.

La instalación es tan sencilla como la de cualquier otro plugin de eclipse, si no habéis hecho ninguna, podeis acercaros a la página de ObjectAid y veréis una ayuda al respecto de cómo instalarlo, pero en resumen, se trata de descargar los ficheros, descomprimirlos y copiar y pegar las carpetas features y plugins en vuestra instalación de eclipse. Reiniciar eclipse y ya lo tenéis disponible. (Un truco, si no funciona a la primera, podéis arrancar por línea de comandos: eclipse.exe -clean)

Un pequeño ejemplo de uso, puede ser crear un proyecto sencillo, en el que metéis unas cuantas clases, relacionándolas entre ella, implements, extends… y una vez las tenéis implementadas, nuevo-ObjectAid UML Diagram-ClassDiagram. Esto crea un fichero de extensión ucls, si lo abrís en vuestro eclipse, lo único que hace falta para generar los diagramas UML es arrastrar la clase que queréis representar en el diagrama, dentro del propio editor en eclipse.

Además automáticamente nos genera un fichero con una imagen png (como debe ser)  para exportar lo que hemos creado.

Aunque ante todo, la gran ventaja de este plugin de eclipse, es que se encuentra vivo, en desarrollo y que espero al menos la parte gratuita de este plugin sea libre es decir open source en algún momento. Mejor antes que después.

UML herencia y clases abstractas para estructuras de datos

Una pequeña entrada, para recordar todos los apuntes de UML que se han ido haciendo a los largo del tiempo en este blog.

La herencia sirve para solucionar en diseños de software, cuando una clase debe heredar comportamientos de otra, los ejemplos más habituales de herencia, son los de animales, el clásico de clase padre Animal, de la que herada Pajaro y por debajo de Pajaro se crea una clase hija tipo Canario o Loro.

Vamos a suponer que necesitamos definir un objeto, que estará representado por una cantidad variable de propiedades, como puede ser, el objeto persona, que puede tener una serie de propiedades, pero aunque muchas veces comunes, no siempre las mismas. Y no solo no siempre las mismas, sino que incluso a veces solo necesito una o dos y no quiero crear el objeto con todas sus propiedades.

Como se puede ver la realción entre Persona y la propiedad, es de (rombo vacio o blanco) agregación y no de compoosición, ya que el objeto persona está definido por sus propiedades, pero no tiene una relación tan fuerta como para ser una composición (rombo negro)



Como es habitual, vamos a complicar los ejemplos habituales de herencia, y poner un ejemplo de una estructura de metadatos, que ya de por si puede ser molesta, y esa estructura de metadatos, vamos a representarla en forma de que cada propiedad que tenemos en el sistema de metadatos, puede ser de diferentes tipos, en este caso, vamos a contemplar (Entero, lista de enteros, cadena, lista de cadenas, booleanos y fechas) esta lista puede alargarse lo que se quiera.


Para solucionar la estructura de metadatos que pueden tener nuestros datos, vamos a definir un objeto que tendrá un conjunto de propiedades, vamos a llamar al objeto

Una representación posible de la herencia en UML, consiste en el ejemplo que podemos ver justo debajo, donde las clases de tipo IntegerProperty...*Property, heredan de la calse AbstractProperty, de la cual heredan el parámetro name.

 

Una cosa curiosa del ejemplo que se puede ver en este caso, es que las clases hijas de AbstractProperty, no solo heredan de su padre, sino que también deben hacer sobreescritura "override" de los métodos que declara la interfaz IProperty.

Otras entradas de UML en este blog:

UML casos de uso escenarios
UML - Agregación vs composición
Diseño de clase asociativa

UML Casos de Uso -- Escenarios

Después del éxito de esta entrada sobre UML, siguiendo con ese tema, tenemos otro tema de UML.

Un tema que a veces da para discutir en lo que a diseño UML se refiere, los escenarios.

¿Qué es un escenario en UML?

Un escenario en UML es una circustancia o situación, en la que se puede encontrar un sistema. Es decir, si cogemos un ejemplo de sistema, por ejemplo, este blog, una escenario podría ser, escribir esta entrada. Como puede entenderse de este concepto, un escenario es ampliio, y puede tener, diferentes formas de "ejecutarse" u ocurrir.

¿Para que sirven los escenarios?

Los escenarios, como hemos dicho, definen situaciones en las que se encuentra un sistema, esto quiere decir que, el conjunto de escenarios, definien el sistema, o al menos, lo que puede hacer el sistema. De lo que deducimos, que los escenarios nos sirven para definir, que hace y que no hace un sistema.

En un sistema de reservas on-line, podemos definir escenarios como pueden ser: Dar de alta un usuario, hacer una reserva on-line, dar de baja un usuario, modificar una reserva, pero podríoamos no tener un escenario de borrar una reserva, porque el sistema no la contemple.

¿Como se definen los escenario?

Hemos visto, que los escenarios definen al sistema, pero claro, al mismo tiempo, lo que puede hacer el sustema, define a los escenarios, esto lleva a una paradoja, que solo el "alcance" del sistema puede definir. El alcance es lo que define, que si y que no hace el sistema. (Si trabajas en un sector que funcione por proyectos, preguntate el alcance del tuyo ;) )

¿Partes del escenario?

un escenario, en si mismo puede dividirse, en acciones, estas acciones, defienn que caminos puede tomar un escenario. Como hemos visto, un escenario podría ser, dar de alta un usuario (todo un clásico), este escenario, dependiendo de lo que signifique dar de alta, hará una serie de acciones, que desencadenarán en posibles resultados diferentes.Al ver que los escenarios son condicionales, eso nos hace pensar, que pueden tener diferentes salidas o resultados, dar de alta un usario, puede acabar correctaement econ el usuario dado de alta, o incorrectamente, porque falten datos para el alta (por poner un ejemplo)

La ejecución "perfecta" de un escenario, se denomina Happy Path o Camino Feliz.

Entradas relacionadas en este blog:

UML diseño de agregación vs composición

Diseño UML Clase asociativa

Ingeniería inversa con eclipse Java2UML

Ingeniería inversa con eclipse Java2UML

Pequeña entrada, para que no se me olvide esto de escribir en el blog, que llevo unos días, que no escribo nada, esto de las vacaciones...

Esta entrada va sobre como conseguir que Eclipse, ese IDE de Open Source, que se puede utilizar para desarrollar Java, nos haga todos los diagramas que podemos sacar del cogidogo Java en UML, diagrama de clases, y las relaciones entre ellos, como usan unos de otros, y sobre todo la herencia entre ellos, bien represenada, y tal, para ello, podemos hacer uso de dos páginas que en su momento a mi me dieron muchísima ayuda, y para no repetir todo lo que ya está allí alojado, dejo los enlaces.

Explicación paso a paso

El plugin

Ojo, para hacer funcionar el segundo plugin respetar las versiones de eclipse, debe ser la 3.2 enlace a la version

Entradas relacionadas de UML en este blog:

agregación vs composición

Clase asociativa

UML diseño de agregación vs composición

Esto, es una parte muy sencilla, pero al mismo tiempo básica para el diseño de un diagrama de clases UML, la forma de representar que un objeto tiene como contenido a otro, esto quiere decir que un objeto de un tipo, puede contener a otro, en un sentido abstracto de posesión, es decir, por ejemplo un objeto de tipo, por ejemplo, ciudad tiene una lista de objetos de tipo aereopuerto, esto quiere decir, que una ciudad, tiene un número de aereopuertos, destacar, que la cardinalidad del extremo que lleva el rombo, es siempre uno, ahi va un ejemplo:



En la misma linea, la composición, es una relación más fuerte de los objetos, asi como la agregación, es el hecho de que un objeto posea a otro, la composición es cuando la relación entre ambos objetos es tal, que el agregado es una parte importante del agregador, de tal forma que el primero no tiene sentido suelto, y el segundo, necesita definir al primero para ampliar su significado, ya se que esto suena un tanto etereo, pero con un ejemplo se ve mejor:



El avión tiene sentido por si solo, pero esta claro que esta compuesto de 2 alas, esta relación es de mucha fuerza, mucho más que el caso de los aereopuertos, y esta claro, que un avión siempre tendrá sus dos alas, y estas siempre serán del mismo avión. El caso de los aereopuertos, es claramente más sueve la relación.

Entradas relacionadas de UML en este blog:

Ingeniería inversa con eclipse Java2UML

Clase asociativa

Diseño UML Clase asociativa

Para el diseño en UML, existe una singularidad, que trata sobre una situación muy concreta, en lo que a diseño del software se refiere, una clase asociativa, esta es una clase, que existe, para cada instancia de una clase, sobre otra, se ve esto más claro con un ejemplo, si tuvieramos una clase que fuese, usuario, y otra que fuera concierto, la relación entre ellas, sería tal que un usuario, puede asistir a los conciertos que quiera, y a un concierto pueden ir los usuarios que entren el e aforo, es decir la cardinalidad de los dos extremos sería multiple (representada por un asterisco), pero para el caso de las entradas a los conciertos, por cada usuario, tendría una opción de comprar una entrada, y si estuvieramos en un sistema de compra de entradas para conciertos, la entrada, sería esa clase asociativa, para cada existencia de un usuario a un concierto, existe una y solo una entrada, no puede tener dos entradas para el mismo concierto. Nose si se explica bien, pero veamos el diagrama: