Curso UMLCurso UML

IntroducciónVisión generalHerramientas de diseño UMLDiagramas UML

Diagrama de ActividadesDiagrama de SecuenciaDiagrama de Colaboración (UML 1.0)/Comunicación (UML 2.0)Diagrama de EstadosDiagrama de clasesCasuística típica del trabajo con diagramasTipos de relaciones

Diagramas de ClasesRelaciones de asociación específicasSubtipos de asociaciones

InterfacesOtros diagramas menos usadosModelado de casos de uso

Ciclo de vida del software y diagramasRealización del caso de uso: FichaCasos de uso más complejos

Patrones de diseñoColecciones de patrones de diseñoPatrones GoF

SingletonAbstractFactoryProxy

Patrones JEEBusiness DelegateData Access Object (DAO)Value List Handler

IntroducciónEste artículo son los apuntes que escribí durante el curso de UML que impartió Grupo PA en RBC Dexia IS en Enero de 2011. Todo fue escrito usando Google Docs y UMLet mientras el profesor daba la clase, así que fue escrito practicamente en tiempo real. Hay algunas modificaciones como por ejemplo una correcta implementación del patrón Singleton, que

aunque en clase se dio una políticamente correcta, no era una buena implementación hecha en Java que es lo que nos interesa. También se eliminó el patrón SessionFaçade por ValueListHandler que me parecía más interesante. Además de ciertas licencias que me he tomado para dar más sentido a las explicaciones del profesor.

Visión general¿Qué es UML?, es un lenguaje de modelado. Con él podemos describir especificaciones funcionales, algoritmos, diagramas de estado, la arquitectura de un sistema, etc.La especificación de UML se puede descargar de http://www.omg.org.

Herramientas de diseño UMLHay multitud de herramientas para diseñar diagramas UML:

● UMLet (http://www.umlet.com/changes.htm): Es software libre, muy sencillo y extremadamente ligero, pero no por ello deja de ser completo. A pesar de su sencillez se puede dibujar cualquier diagrama UML con él. Está disponible como versión standalone o como plugin de Eclipse. Hay que destacar que este documento se escribió durante un curso de UML como apuntes del mismo mientras el profesor impartía la clase, y los diagramas se fueron dibujando en tiempo real.

● Magic Draw (http://www.magicdraw.com/): Software comercial. Muy completo y muy pesado, consume muchos recursos y está disponible para cualquier plataforma.

● Star UML (http://staruml.sourceforge.net): Es software libre, y bastante completo. La pega es que sólo es para Windows, por lo tanto no se recomienda su uso.

Diagramas UMLCasos de Uso

Representan la funcionalidad del sistema. Hay dos elementos, actores y funcionalidades. Los actores pueden ser personas o sistemas externos.

Hay que seguir la norma KISS (Keep It Simple Stupid), ya que los diagramas se deben mantener inteligibles, complicarlos demasiado los vuelve inmantenibles, como todo.

Diagrama de ActividadesSe utiliza para modelar etapas de un proceso. Es decir, es lo que era un DFD (Diagrama de Flujo de Datos) con el que se pueden representar algoritmos, o el funcionamiento de cualquier proceso, método, etc.

Se usan cuando el caso de uso es complejo, no hace falta hacer un diagrama de actividad para cada caso de uso, algunos son obvios y no se suelen hacer, aunque es muy recomendable.

Diagrama de SecuenciaModela la interacción entre objetos durante el ciclo de ejecución de un proceso. Es decir, la secuencia de llamadas entre objetos en un periodo de tiempo.

No se deben mostrar caminos alternativos, si no un único flujo, es decir, no se muestra la secuencia de cuando todo va bien, y de cuando hay otras bifurcaciones durante la ejecución, si no sólo una de ellas.

Diagrama de Colaboración (UML 1.0)/Comunicación (UML 2.0)Es similar al de secuencia pero no visualiza la línea temporal. Es decir, muestra los objetos, y las llamadas entre ellos, pero sin ver la secuencia, simplemente la conexión o dependencia entre ellos. Se usa muy poco, por no decir nada.

Diagrama de EstadosEste es otro de los diagramas importantes. Modela el ciclo de vida de un objeto, es decir, representa los estados por los que puede transicionar un objeto. Un ejemplo del diagrama de estados de una cuenta podría ser el siguiente:

Diagrama de clasesModela cualquier elemento estructural (Clases) del sistema, y sus relaciones. Una clase, sus atributos y sus métodos (operaciones) se representa así:

El estereotipo sirve para dar una particularidad a la clase, es como declararle un tipo, por tanto, puede haber unas clases de un estereotipo, otras de otro, etc. Podríamos escribir un diagrama

de cualquier tipo de los mencionados hasta ahora con un diagrama de clases usando estereotipos:

Un ejemplo algo más complejo con otros tipos de relaciones (herencia, composición, etc.) sería este:

Casuística típica del trabajo con diagramas¿Qué se hace con los diagramas?:

● Ingeniería directa: Diagramas hechos desde cero, diagramas de todo tipo.● Ingeniería inversa: A partir de un código fuente se generan los diagramas, normalmente

de clases, aunque también pueden ser de secuencia.● Validación: Ver un diagrama para ver si está bien hecho. Debería haber alguien que

revise y valide los diagramas desde el punto de vista de negocio, y desde el punto de vista técnico.

● Aplicación de patrones: Consiste en identificar patrones de diseño dentro del diagrama de clases.

Tipos de relaciones● Asociación (línea continua, flecha abierta). Cooperación entre clases.● Herencia (línea continua acabada en triángulo). Un elemento adquiere las propiedades

de otro.● Dependencia (línea discontinua, flecha abierta). Vínculo genérico de necesidad entre

clases.

● Implementación (línea discontinua acabada en triángulo). El elemento origen de la flecha “realiza” al elemento destino. Quiere decir que implementa la interfaz definida por el destino.

Diagramas de ClasesPara ver algunas de las relaciones que se pueden representar en un diagrama de clases, vamos a dibujar un diagrama de lo que podría ser un sistema de gestión de regalos:

En el diagrama podemos ver 4 tipos distintos de relaciones entre las clases:● Realización o implementación: ClientProxy implementa la interfaz definida por

ClientFacade.● Asociación de uso: La clase ClientProxy usa la clase GenericClient. Los métodos de

ClientProxy devuelven o toman como parámetros objetos de la clase GenericClient.● Generalización o herencia: StandardClient y VipClient heredan de GenericClient.● Dependencia: GenericClient depende de GiftController, podría ser una asociación de

uso perfectamente.

Todas las clases definidas deberían tener atributos y métodos, si una clase no tiene alguno de ellos, posiblemente no haría falta crearla.

Relaciones de asociación específicasLas relaciones también se pueden caracterizar por:

● Estereotipo.● Navegabilidad. La dirección de la flecha o flechas de la relación especifica desde donde

o hasta donde se puede navegar desde una clase.● Cardinalidad.● Restricciones: Se representan con ‘{}’. Por ejemplo: {balance < 5000}.● Roles: Es el papel que juega la clase dentro de la relación (titular/propiedad,

profesor/alumno). No se suele usar, sobre carga el diagrama.

Subtipos de asociaciones● Agregación: Una clase se compone de objetos de otras clases. Por ejemplo una

factoría que monta coches. El coche se compone de ciertas partes como ruedas, volante, etc. Los componentes tienen sentido por separado, pero juntos forman el coche.

● Composición: Una clase crea objetos de otras clases, y éstas no tienen sentido si la clase que las crea. Por ejemplo los movimientos de una cuenta no tienen sentido si la cuenta deja de existir. Otro ejemplo podría ser el humo que sale de un coche. El humo no puede existir si no existe el coche.

InterfacesUn interfaz es un elemento de programación que define métodos sin código. Se representa así:

Se dice que define lo que puede hacer, pero no cómo lo hace. Son los implementadores de la interfaz los que dicen cómo se hace, es decir, los que implementan una manera propia de realizar los métodos/operaciones definidos por la interfaz. Un interfaz es como un estándar.

Esto no quiere decir que todos los implementadores lo hagan bien, un implementador puede dejar el método en blanco, o puede hacerlo mal. Un ejemplo real puede ser una conexión de BBDD en en Java. Se define una interfaz en las clases estándar de Java, y cada fabricante crea una implementación para usar sus BBDD:

Otros diagramas menos usados● Diagrama de paquetes: Es una simplificación de un diagrama de clases, sólo se

representan los paquetes de los que pertenecen las clases. Son muy útiles para ver las dependencias entre los paquetes de un sistema. Se pueden localizar ciclos, o dependencias que no deberían existir o que son redundantes.

● Diagrama de componentes: Representa elementos de software, ya sean librerías, aplicaciones web enteras, un gestor de BBDD, un servidor de aplicaciones, etc. Suele

haber solo un diagrama de este tipo en un proyecto. Se pueden usar interfaces, nombres en las relaciones, estereotipos, etc.

● Diagrama de despliegue: Representa elementos de hardware. Máquinas físicas como pueden ser servidores, PCs, impresoras, etc. Al igual que el diagrama de componentes suele haber solo un diagrama de este tipo en un proyecto. Se pueden usar interfaces, nombres en las relaciones, estereotipos, etc.

● Diagrama de estructura compuesta: Representa roles en las relaciones. Es un diagrama casi sin uso, y por tanto no se va a profundizar en él. Un ejemplo sería el que

se muestra en la siguiente figura:

Modelado de casos de usoSon el diagrama principal para definir las funcionalidades de un proyecto. Son el inicio de una funcionalidad, el resto de diagramas (clases, secuencia, actividad, etc.) complementarán la definición dada por el caso de uso. El detalle de cada caso de uso (requisito o funcionalidad) se denomina Realización del caso de Uso.

Ciclo de vida del software y diagramasLos pasos básicos de cualquier metodología de proyectos y la relación con los diagramas UML es la siguiente:

● Captura de requisitos: Casos de uso.● Análisis: Actividades, clases de análisis, secuencia y colaboración y estado.● Diseño: Clases de diseño, componentes, secuencia y estado.● Implementación.● Pruebas.● Paso a prod: Despliegue.● Mantenimiento.

Realización del caso de uso: FichaPara la realización de un caso de uso usaremos lo que se denomina Ficha del caso de uso. Los datos que tendrá la ficha son:

● Id: Identificador único, ya sea numérico o alfanumérico.● Nombre: Nombre conciso y suficientemente descriptivo. No tiene porqué ser sólo una

palabra, si no más bien un título.● Prioridad.● Incluye: Nombre de los casos de uso que incluye este.● Extiende: Nombre de los casos de uso de los que extiende.● Actores.● Pre y post condiciones: Condiciones que deben darse antes de entrar en el caso de

uso, y como debe quedar el sistema después de la ejecución.● Flujo principal o primario: Ejecución normal o ideal de ejecución.

○ Paso 1.○ Paso 2.○ …○ Paso N.

● Flujos secundarios o alternativos: Caminos alternativos a la ejecución ideal (flujo principal).

La realización del caso de uso se completará con diagramas de actividades, diagramas de clases de análisis. Las clases de análisis deben ser independientes del lenguaje, y se definirán con estereotipos <<boundary>>, <<control>> y <<entity>>. ver página 126 del libro (Manual de UML).

● Boundary: Interfaces con sistemas externos.● Control: Clases de negocio.● Entity: Persistencia.

Casos de uso más complejosEn lo que hemos visto hasta ahora usamos actores y casos de uso, pero se pueden ampliar los diagramas de casos de uso con estereotipos en las relaciones o extension points:

● <<extend>>: Representa opcionalidad. Un caso de uso extiende la funcionalidad de otro. Por ejemplo una transferencia a fecha extiende el caso de uso de una transferencia en el día.

● <<include>>: Representa obligatoriedad. Por ejemplo una transferencia o un pago con tarjeta incluye el caso de uso Debitar dinero de cuenta.

● <<uses>>: No especifica ni opcionalidad ni obligatoriedad.● Extension points: Casos de uso que que amplian la funcionalidad de otros casos de uso.

Los casos de uso dependientes son beneficiosos para la reutilización de otros casos de uso, también para la planificación, ya que se pueden ver las dependencias entre funcionalidades, es decir, la planificación del proyecto dependerá de estos casos de uso.Una buena opción para que no se compliquen los casos de uso es tener una versión simple, y otra compleja, depende de a quién lo vayamos a enseñar.

Patrones de diseñoSu cometido es el de proponer una solución a un problema que ocurre continuamente en diferentes ámbitos del desarrollo del software. Se proporciona un patrón que hay que extrapolar a nuestro caso particular. Suele proponerse un diagrama de clases o secuencia que deberemos adaptar a nuestro sistema.

Una buena referencia sobre patrones de diseño es http://sourcemaking.com/design_patterns.

Colecciones de patrones de diseñoLos más conocidos son los de GoF (Gang of Four), un grupo de 4 personas que recopilaron la colección de patrones de diseño más importante que existe. Otra colección son los J2EE Core patterns. Hay patrones para Web Services, persistencia, etc.

Un patrón de diseño proporciona un problema recurrente en sistemas de software, y propone una solución a ese problema, y esa solución admite N implementaciones.

Patrón de diseño => Problema recurrente => Solución genérica => N implementaciones.

Para la solución genérica se usa UML, precisamente para que sea genérico, y se suelen usar los diagramas de clases y de secuencia para describirlos.

Algunos problemas recurrentes podrían ser:

● Falta de testing.● Cerrar conexiones.● Problemas de concurrencia.

○ Interbloqueo.○ Inconsistencia de datos.

● Problemas de rendimiento.○ CPU.○ Memoria.

Patrones GoFVamos a ver algunos de los más típicos patrones de diseño de los GoF.

SingletonProblema: En ocasiones es complejo limitar las instancias de una clase. Es decir, queremos que sólo haya X instancias de un objeto. Por ejemplo, las conexiones a una BBDD hay que

limitarlas, no podemos crear ilimitadas instancias del objeto conexión porque saturamos la BBDD.

Solución: La mejor solución en Java es usar una clase inner que sea la que cree la instancia de la clase que la contiene. Hay otras soluciones más precarias como el uso de synchronized, pero no son recomendables por su bajo rendimiento. La solución propuesta es totalmente thread-safe. Para el que quiera profundizar en el tema es recomendable la lectura de http://en.wikipedia.org/wiki/Double-checked_locking.

Código fuente:

public class Singleton { // El constructor privado previene que esta clase sea instanciada por otras private Singleton() {} /** * SingletonHolder se carga en la primera ejecución de Singleton.getInstance() * o en el primer acceso a SingletonHolder.INSTANCE, nunca antes. */ private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); }

public static Singleton getInstance() { return SingletonHolder.INSTANCE; }}

AbstractFactoryProblema: Creación de objetos complejos o dependientes del entorno o sistema, o de otros objetos, evitar y controlar el uso de new. Para que el cliente se abstraiga de la creación estos objetos, o no se tenga que preocupar de las dependencias de los mismos, etc., se usa este patrón.

Solución:

ProxyProblema: Sistemas de caja negra y las interacciones con el sistema poco definidas. Necesitamos crear objetos que consumen muchos recursos, pero no queremos instanciarlos a no ser que el cliente lo solicite o se cumplan otras condiciones determinadas.

Solución: La clase proxy actuará como capa previa al acceso del objeto al que queremos acceder realmente, es posible que cuando llamamos a un método de este proxy, éste haga algunas cosas antes o después de lo que haría el método original.

Patrones JEE

Business DelegateProblema: Los componentes de la capa de presentación interactuan directamente con los servicios de la capa de negocio. Esta interacción directa expone los detalles de implementación de la interfaz de servicio de negocio a la capa de presentación. Como resultado, los componentes de niveles de presentación son vulnerables a los cambios en la aplicación de los servicios de negocio. Cuando la aplicación cambia los servicios, el código de la aplicación en la capa de presentación debe cambiar también.Además, puede haber un impacto negativo en el rendimiento de la red porque los componentes de niveles de presentación que utilizan la API de servicios pueden hacer llamadas en la red.

Solución: Usar un Business Delegate para reducir el acoplamiento entre los clientes de niveles de presentación y los servicios de negocio. El Business Delegate oculta los detalles de implementación del servicio de negocio, tales como operaciones de búsqueda y acceso a los detalles de la arquitectura.

Data Access Object (DAO)Problema: Los sistemas tienen que acceder a BBDD mediante JDBC o cualquier otra librería de acceso a BBDD, o puede que necesite acceder a datos en LDAP, o tiene que recuperar información mediante servicios web de un sistema externo, etc.

Solución: Encapsular el acceso a los datos y la forma de conseguirlos. El cliente no debe saber nada de como se obtienen las conexiones, o de las consultas que se hacen, y proporciona los resultados en objetos (TransferObject).

El DAO tendrá las consultas SQL, accesos mediante Hibernate, consultas a terceros, etc. COn lo que el BusinessClient no se entera de cómo se recuperan esos datos, no tiene que abrir ni cerrar conexiones y no sabe si es a LDAP, BBDD o a una aplicación externa.

Value List HandlerNOTA: Este patrón no se describió durante el curso, pero me parecía más importante que el SessionFaçade.Problema: Un problema típico puede ser la paginación de objetos una vez se ha hecho la consulta, o simplemente porque no se quieren tratar todos los objetos que devuelve la consulta de una vez. O a lo mejor se quieren cachear los resultados, etc.

Solución: Usar un clase que sea la responsable de tratar los resultados, a la que le podamos pedir una página nueva de resultados, a la que le podamos pedir que guarde los resultados en caché. Esta clase (ValueListHandler) usa un DataAccessObject para ejecutar la consulta requerida, almacena los resultados. El cliente puede solicitarle páginas de resultados a nuestro ValueListHandler que usará un iterador para recorrerlos.