Master J2EE de Oracle: Paso 3 de 12: Diseñar y Modelar

Puede encontrar la versión original de este artículo en Inglés en:

http://www.oracle.com/technology/pub/articles/masterj2ee/index.html

Diseñar Primero, Codificar Después

Si hay una cosa que he observado a lo largo de los años, es que los mejores programadores piensan en el diseño de su código antes de escribirlo. Algunos hablarán de su diseño con otros programadores, casi siempre dibujando esquemas en una pizarra mientras lo hacen. Otros utilizarán una herramienta de modelado más sofisticada basada en software que genere el código por ellos. De cualquier forma, los dos grupos se toman el tiempo de pensar las cosas mediante el modelado antes de saltar a la codificación.

Las aplicaciones J2EE son bestias muy complejas, usted se verá trabajando con Java Server Pages (JSPs), Servlets, Web Services, EJB Session Beans, EJB Entity Beans, datos basados en XML y bases de datos Oracle. No se puede juntar toda una aplicación J2EE, dar un palmada y esperar que tenga éxito; en vez de eso, tendrá que pensar primero en el diseño. Eso no quiere decir que tenga que emplear semanas o incluso meses escribiendo un enorme documento, como muestra claramente Agile Modeling, pero necesita hacer algo. El truco está en saber como modelar de forma efectiva y realizar sólo el modelado necesario para tener el trabajo hecho.

Este artículo describe una colección de técnicas para crear efectivos diagramas Unified Modeling Language (UML) utilizando Oracle JDeveloper 10g. Nos enfocaremos en los aspectos orientados a objetos (OO) de una aplicación de comercio electrónico utilizando diagramas de caso de uso UML, diagramas de secuencia UML y diagramas de clases UML. Otros aspectos de su aplicación, como el interface de usuario y su base de datos, son importantes y también deberían ser modeladas de forma similar pero no las discutiremos aquí.

Una aproximación típica al desarrollo de software OO es la identificación de los requerimientos de utilización. En esta situación se aplican los casos de uso aunque podrían fácilmente haber escrito historias de usuarios (del tipo Extreme Programming), y luego modelar la lógica de esos requerimientos con diagramas de secuencia. Sus casos de uso describen como la gente trabaja con el sistema, utilizando terminologia de negocio, etc. Aunque está poca información es crítica para su éxito, no es suficiente para el desarrollo de software y necesita ser transformada en algo más técnico. Aquí es donde entran en juego los diagramas de secuencia, estos se utilizan para representar graficamente cómo se implementará una porción de un caso de uso utilizando sus tecnologías elegidas (en este caso J2EE). Mientras dibuja el diagrama de secuencia identificará métodos/operaciones, que están soportadas por atributos/propiedades, que a su vez están implementados por clases. Toda esta información, así como las relaciones entre clases, forma su esquema de objetos que es capturado por su diagrama(s) de clases UML. Luego su esquema de objetos es mapeado a su esquema de bases de datos, bien codificándolo a mano con SQL o automáticamente mediante un marco de trabajo de persistencia como Oracle TopLink. El mapeo objeto/relacional y el diseño de la base de datos están fuera del ámbito de este artículo, aunque los problemas de estilo son muy importantes también en estas dos actividades.

Dibujar Diagramas de Casos de Uso Efectivos


Figura 1: un diagrama de caso de uso muy pobre.

Los diagramas de casos de uso UML ofrecen una visión de los requerimientos de utilización de su sistema y se utilizan para comunicar el ámbito de los proyectos de desarrollo de software. La Figura 1 mostraba un un diagrama de caso de uso muy pobre; y la Figura 2 muestra la misma información con unos pocos cambios para mejorar su lectura y su utilidad.


Figura 2: un diagrama de caso de uso mejorado.

¿Qué he hecho para mejorar el diagrama? Primero, he aplicado nombres orientados al negocio para los casos de uso. "Create Order Record" es un nombre de orientación técnica, mientras que "Place Online Order" usa terminología de negocios real. La audiencia principal para los diagramas de casos de uso son los esponsors del proyecto, no desarrolladores, por eso debería utiliza terminilogía orientada a negocio siempre que sea posible.

Segundo, he aplicado varias estrategias de distribución básicas:

  • Los símbolos de caso de uso (los óvalos) deberían dimensionarse de forma consistente. Las grandes burbujas paracen más importantes que las pequeñas, a menos que lo haga a propósito para resaltar la importancia, debería mantenerlos del mismo tamaño.
  • Situe los actores de forma consistente en el diagrama. Sitúe los actores humanos al lado izquierdo, los actores de sistema en el lado derecho. La gente de culturas occidentales lee de izquierda a derecha, y como los actores humanos suelen ser el punto de partida de cualquier sistema, usted querrá que la gente empiece a leer el diagrama por ellos.
  • Los casos de uso incluidos están representados a la derecha del caso de uso padre. Esta es una convención de modelado común de UML, y seguir las convenciones comunes hace que sus diagramas sean más fáciles de leer.
  • Los casos de uso extendidos se dibujan debajo de los casos de uso padre. Esta también es una convención común.
  • Indique el tiempo relativo mediante posiciones. La Figura 2 dibujaba el caso de uso order placement justo encima del caso de uso Checkout, reflejando el orden en que se deberían invocar esos casos de uso. Aunque los diagramas de caso de uso no se han diseñado para representar el orden de las operaciones de negocio, esta es una ordenación más natural y por lo tanto hace que el diagrama sea más fácil de entender.

Sus diagramas de casos de uso ofrecen una visión de su entendimiento de los requerimientos del sistema. Por lo tanto, un diagrama de baja calidad podría hacer pensar a sus espónsors que su entendimiento de sus requiermientos también es deficiente. ¿Por qué causarse problemas cuando es así de fácil dibujar buenos diagramas de caso de uso?

Dibujar Diagramas de Secuencia Efectivos


Figura 3: Un diagrama de secuencia bastante pobre.

Los diagramas de secuencia UML modelan el flujo de la lógica dentro de su sistema de una forma visual, permiténdole identificar el comportamiento crítico dentro de sus objetos. La Figura 3 representa un diagrama de secuencia que muestra la lógica detallada de situar un pedido online. Una reto importante de los diagramas de secuencia es que crecen mucho, particularmente en dirección horizontal y lo hacen muy rápidamente. Los diagramas de secuencua se vuelven inmanejables cuando se tiene que hacer scroll de la pantalla, motivando que se pare de modelar prematuramente. La solución es reorganizar el diagrama en unos más pequeños.

Las dos siguiente figuras representan versiones mejoras de la imagen anterior. La Figura 4 muestra los aspectos de interacción con el usuario, mostranto el actor interactuando con las distintas páginas HTML del sistema. Este estilo de diagrama de secuencia le permite explorar cómo interactúa realmente la gente con el sistema sin entrar en los detalles técnicos. Como nos hemos enfocado sólo en este especto del caso de uso es mucho más fácil entrar en detalles. Es importante observar que he roto una regla de la herramienta Oracle JDeveloper en la Figura 4 indicando estereotipos como <<JSP>> y <<servlet>> donde debería haber puesto nombres de objetos.


Figura 4: Realizar un Pedido - Interacción del Usuario.

La Figura 5 muestra una aproximación más tradicional a los diagramas de secuencia, enfocándose en la lógica interna del código para añadir un ítem a un pedido. He aplicado trucos interesantes para mejorar su utilidad.


Figura 5: Realizar un Pedido - Lógica de Flujo Interno.

Primero, las líneas de vida de los objetos se han distribuido de una forma similar a las capas arquitecturales de su sistema. He mostrado Servlet(s), luego Session Bean(s), luego Entity Bean(s). Cuando realice una aproximación por capas encontrará que el flujo de mensajes va de izquierda a derecha.

Segundo, los mensajes están justificados a la izquierda. La lógica implementada por el bean de sesión se parece mucho al código Java real haciendola muy fácil de leer para los programadores Java.

Observe que he utilizado una nota UML para describir los diagramas de secuencia mejorados. Las notas UML lo clarifican para alguien no familiarizado con un diagrama ya dibujado. Puede aplicar notas a cualquier diagrama UML.

Dibujar Diagramas de Clases Efectivos

Los diagramas de clases UML se utilizan normalmente para varios propósitos, incluyendo el modelado de dominio/conceptual, analisis de modelados, y modelado de diseño detallado de su esquema de objetos. JDeveloper incluye la posibilidad de crear diagramas de clases UML; yo usaría esta herramienta para modelado de dominio/conceptual y analisis de modelado. También incluye la posibilidad de crear diagramas EJB, que aplican el perfil estándar de EJB al diagrama de clases UML, que usaremos para crear diagrama a nivel de diseño. La Figura 6 muestra un diagrama pobremente renderizado y la Figura 7 muestra una versión mejorada.


Figura 6: Un pobre renderizado de un esquema de objetos EJB.

Para mejorar el diagrama he empezado redistribuyendo las clases siguiendo unas sencillas reglas: primero, he distribuido el diagrama poniendo los beans de sesión a la izquierda y los de identidad a la derecha. Segundo, siempre que sea posible me gusta dibujar las relaciones de forma horizontal en el diagrama. En un diagrama de clases no EJB prefiero mostrar el árbol de herencias verticalmente, con la clase superior encima de sus subclases. Tercero, para las relaciones compuestas, en este caso entre Order y OrderItem, prefiero dibujar la parte (OrderItem) a la derecha del todo (Order).

También he modificado los nombres de las relaciones para que realmente comuniquen algo de valor. "OrderItem Item" no dice nada, pero "described by" describe la relación real.

Finalmente he realizado unos importantes cambios cosméticos al diagrama. He desactivado la visión del nombre del paquete, los estereotipos UML, y los valores etiquetados. Puedo obtener los nombre de paquete del list box, el color de la clase indica su estereotipo, y puedeo acceder a información relevante (incluyendo los valores etiquetados) haciendo doble click en la clase. El Agile Modeling le aconseja dibujar modelos simples, que es lo que he hecho. También he elegido mostrar los métodos remotos en los Beans de Sesión y sólo las propiedades de los Beans de Entidad, las dos piezas más importantes de su información respectivamente según el tipo de cada clase.


Figura 7: Una versión mejorada del esquema de objetos EJB.

Conclusión

Me gustaría concluir con algunas sencillas guias que le ayudarán inmensamente:

  • Nombre sus diagramas de forma descriptiva: "Online Order System" es mucho más descriptivo que "UML Use Case Diagram 1".
  • Utilice termilogía de negocio. Un buen nombre de clase es Customer, no Cust, sin preocuparse del nombre de la tabla de datos a la que la clase se mapea realmente.
  • Sigua las convenciones de nombrado de Java para los EJBs. Está programando en Java, por lo tanto debería seguir las convenciones Java. www.ambysoft.com/javaCodingStandards.html.
  • Cree pequeños modelos. Los modelos no necesitan ser grandes, ni abarcarlo todo, para ser útiles. Los modelos que son pequeños y concretos son más fáciles de entender y de trabajar con ellos.

El mejor consejo que le puedo dar es que no emplee mucho tiempo en hacer que sus diagramas sean bonitos. Su objetivo real es desarrollar software que funcione, no crear gráficos bonitos. Conociendo y entendiendo las guias comunes de modelaje, será capáz de crear diagramas correctos desde el principio, ciertamente mucho mejores que los presentados en este artículo, sin mucho esfuerzo extra.

Este artículo sólo ha revelado la punta del iceberg del estilo de modelado. Para ver más guías puede visitar: http://www.agilemodeling.com/style/.

Próximos Pasos

  1. Lea sobre UML Modeling and MDA in Oracle JDeveloper 10g:.
  2. Visite los Viewlets:
  3. Descargue Oracle JDeveloper 10g
  4. Aprenda cómo utilizar Oracle JDeveloper para crear un diagrama que captura la información esencial de los requerimientos de un sistema en Modeling Java Classes

Información Adicional

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP