Curso UML

Curso UML
Introduccin
Visin general
Herramientas de diseo UML
Diagramas UML
Diagrama de Actividades
Diagrama de Secuencia
Diagrama de Colaboracin (UML 1.0)/Comunicacin (UML 2.0)
Diagrama de Estados
Diagrama de clases
Casustica tpica del trabajo con diagramas
Tipos de relaciones
Diagramas de Clases
Relaciones de asociacin especficas
Subtipos de asociaciones
Interfaces
Otros diagramas menos usados
Modelado de casos de uso
Ciclo de vida del software y diagramas
Realizacin del caso de uso: Ficha
Casos de uso ms complejos
Patrones de diseo
Colecciones de patrones de diseo
Patrones GoF
Singleton
AbstractFactory
Proxy
Patrones JEE
Business Delegate
Data Access Object (DAO)
Value List Handler

Introduccin
Este artculo 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 implementacin del patrn Singleton, que
aunque en clase se dio una polticamente correcta, no era una buena implementacin hecha en
Java que es lo que nos interesa. Tambin se elimin el patrn SessionFaade por
ValueListHandler que me pareca ms interesante. Adems de ciertas licencias que me he
tomado para dar ms sentido a las explicaciones del profesor.

Visin 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 especificacin de UML se puede descargar de http://www.omg.org.

Herramientas de diseo UML

Hay multitud de herramientas para disear 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 versin
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 imparta 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 slo es para Windows, por lo tanto no se recomienda su uso.

Diagramas UML
Casos 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 Actividades
Se 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, mtodo, 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 Secuencia
Modela la interaccin entre objetos durante el ciclo de ejecucin 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 ejecucin, si
no slo una de ellas.

Diagrama de Colaboracin (UML 1.0)/Comunicacin (UML 2.0)

Es similar al de secuencia pero no visualiza la lnea temporal. Es decir, muestra los objetos, y
las llamadas entre ellos, pero sin ver la secuencia, simplemente la conexin o dependencia
entre ellos. Se usa muy poco, por no decir nada.
Diagrama de Estados
Este 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 podra ser el siguiente:

Diagrama de clases
Modela cualquier elemento estructural (Clases) del sistema, y sus relaciones. Una clase, sus
atributos y sus mtodos (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. Podramos escribir un diagrama
de cualquier tipo de los mencionados hasta ahora con un diagrama de clases usando
estereotipos:

Un ejemplo algo ms complejo con otros tipos de relaciones (herencia, composicin, etc.) sera
este:

Casustica tpica del trabajo con diagramas

Qu se hace con los diagramas?:
Ingeniera directa: Diagramas hechos desde cero, diagramas de todo tipo.
Ingeniera inversa: A partir de un cdigo fuente se generan los diagramas, normalmente
de clases, aunque tambin pueden ser de secuencia.
Validacin: Ver un diagrama para ver si est bien hecho. Debera haber alguien que
revise y valide los diagramas desde el punto de vista de negocio, y desde el punto de
vista tcnico.
Aplicacin de patrones: Consiste en identificar patrones de diseo dentro del diagrama
de clases.

Tipos de relaciones
Asociacin (lnea continua, flecha abierta). Cooperacin entre clases.
Herencia (lnea continua acabada en tringulo). Un elemento adquiere las propiedades
de otro.
Dependencia (lnea discontinua, flecha abierta). Vnculo genrico de necesidad entre
clases.
Implementacin (lnea discontinua acabada en tringulo). El elemento origen de la
flecha realiza al elemento destino. Quiere decir que implementa la interfaz definida por
 el destino.

Diagramas de Clases
Para ver algunas de las relaciones que se pueden representar en un diagrama de clases,
vamos a dibujar un diagrama de lo que podra ser un sistema de gestin de regalos:

En el diagrama podemos ver 4 tipos distintos de relaciones entre las clases:

Realizacin o implementacin: ClientProxy implementa la interfaz definida por
ClientFacade.
Asociacin de uso: La clase ClientProxy usa la clase GenericClient. Los mtodos de
ClientProxy devuelven o toman como parmetros objetos de la clase GenericClient.
Generalizacin o herencia: StandardClient y VipClient heredan de GenericClient.
Dependencia: GenericClient depende de GiftController, podra ser una asociacin de
uso perfectamente.

Todas las clases definidas deberan tener atributos y mtodos, si una clase no tiene alguno de
ellos, posiblemente no hara falta crearla.
Relaciones de asociacin especficas
Las relaciones tambin se pueden caracterizar por:
Estereotipo.
Navegabilidad. La direccin de la flecha o flechas de la relacin 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 relacin (titular/propiedad,
profesor/alumno). No se suele usar, sobre carga el diagrama.

Subtipos de asociaciones
Agregacin: Una clase se compone de objetos de otras clases. Por ejemplo una
factora 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.
Composicin: 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 podra ser el humo que sale de un coche. El humo
no puede existir si no existe el coche.
Interfaces
Un interfaz es un elemento de programacin que define mtodos sin cdigo. Se representa as:

Se dice que define lo que puede hacer, pero no cmo lo hace. Son los implementadores de la
interfaz los que dicen cmo se hace, es decir, los que implementan una manera propia de
realizar los mtodos/operaciones definidos por la interfaz. Un interfaz es como un estndar.

Esto no quiere decir que todos los implementadores lo hagan bien, un implementador puede
dejar el mtodo en blanco, o puede hacerlo mal. Un ejemplo real puede ser una conexin de
BBDD en en Java. Se define una interfaz en las clases estndar de Java, y cada fabricante
crea una implementacin para usar sus BBDD:
Otros diagramas menos usados
Diagrama de paquetes: Es una simplificacin de un diagrama de clases, slo 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 deberan existir o que son redundantes.

Diagrama de componentes: Representa elementos de software, ya sean libreras,

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. Mquinas fsicas 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 sera el que
se muestra en la siguiente figura:
Modelado de casos de uso
Son el diagrama principal para definir las funcionalidades de un proyecto. Son el inicio de una
funcionalidad, el resto de diagramas (clases, secuencia, actividad, etc.) complementarn la
definicin dada por el caso de uso. El detalle de cada caso de uso (requisito o funcionalidad) se
denomina Realizacin del caso de Uso.

Ciclo de vida del software y diagramas

Los pasos bsicos de cualquier metodologa de proyectos y la relacin con los diagramas UML
es la siguiente:
Captura de requisitos: Casos de uso.
Anlisis: Actividades, clases de anlisis, secuencia y colaboracin y estado.
Diseo: Clases de diseo, componentes, secuencia y estado.
Implementacin.
Pruebas.
Paso a prod: Despliegue.
Mantenimiento.

Realizacin del caso de uso: Ficha

Para la realizacin 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 numrico o alfanumrico.
Nombre: Nombre conciso y suficientemente descriptivo. No tiene porqu ser slo una
palabra, si no ms bien un ttulo.
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 despus de la ejecucin.
Flujo principal o primario: Ejecucin normal o ideal de ejecucin.
Paso 1.
Paso 2.

Paso N.
Flujos secundarios o alternativos: Caminos alternativos a la ejecucin ideal (flujo
principal).

La realizacin del caso de uso se completar con diagramas de actividades, diagramas de

clases de anlisis. Las clases de anlisis deben ser independientes del lenguaje, y se definirn
con estereotipos <<boundary>>, <<control>> y <<entity>>. ver pgina 126 del libro (Manual de
UML).
Boundary: Interfaces con sistemas externos.
 Control: Clases de negocio.
Entity: Persistencia.

Casos de uso ms complejos

En 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 da.
<<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 reutilizacin de otros casos de uso,
tambin para la planificacin, ya que se pueden ver las dependencias entre funcionalidades, es
decir, la planificacin del proyecto depender de estos casos de uso.
Una buena opcin para que no se compliquen los casos de uso es tener una versin simple, y
otra compleja, depende de a quin lo vayamos a ensear.
Patrones de diseo
Su cometido es el de proponer una solucin a un problema que ocurre continuamente en
diferentes mbitos del desarrollo del software. Se proporciona un patrn 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 diseo es http://sourcemaking.com/design_patterns.

Colecciones de patrones de diseo

Los ms conocidos son los de GoF (Gang of Four), un grupo de 4 personas que recopilaron la
coleccin de patrones de diseo ms importante que existe. Otra coleccin son los J2EE Core
patterns. Hay patrones para Web Services, persistencia, etc.

Un patrn de diseo proporciona un problema recurrente en sistemas de software, y propone

una solucin a ese problema, y esa solucin admite N implementaciones.

Patrn de diseo => Problema recurrente => Solucin genrica => N implementaciones.

Para la solucin genrica se usa UML, precisamente para que sea genrico, y se suelen usar
los diagramas de clases y de secuencia para describirlos.

Algunos problemas recurrentes podran ser:

Falta de testing.
Cerrar conexiones.
Problemas de concurrencia.
Interbloqueo.
Inconsistencia de datos.
Problemas de rendimiento.
CPU.
Memoria.

Patrones GoF
Vamos a ver algunos de los ms tpicos patrones de diseo de los GoF.

Singleton
Problema: En ocasiones es complejo limitar las instancias de una clase. Es decir, queremos
que slo haya X instancias de un objeto. Por ejemplo, las conexiones a una BBDD hay que
limitarlas, no podemos crear ilimitadas instancias del objeto conexin porque saturamos la
BBDD.

Solucin: La mejor solucin en Java es usar una clase inner que sea la que cree la instancia
de la clase que la contiene. Hay otras soluciones ms precarias como el uso de synchronized,
pero no son recomendables por su bajo rendimiento. La solucin 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.

Cdigo fuente:

public class Singleton {

// El constructor privado previene que esta clase sea instanciada por otras
private Singleton() {}

/**
* SingletonHolder se carga en la primera ejecucin 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;
}
}

AbstractFactory
Problema: Creacin 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 creacin estos
objetos, o no se tenga que preocupar de las dependencias de los mismos, etc., se usa este
patrn.

Solucin:
Proxy
Problema: 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.

Solucin: La clase proxy actuar como capa previa al acceso del objeto al que queremos
acceder realmente, es posible que cuando llamamos a un mtodo de este proxy, ste haga
algunas cosas antes o despus de lo que hara el mtodo original.
Patrones JEE
Business Delegate
Problema: Los componentes de la capa de presentacin interactuan directamente con los
servicios de la capa de negocio. Esta interaccin directa expone los detalles de implementacin
de la interfaz de servicio de negocio a la capa de presentacin. Como resultado, los
componentes de niveles de presentacin son vulnerables a los cambios en la aplicacin de los
servicios de negocio. Cuando la aplicacin cambia los servicios, el cdigo de la aplicacin en la
capa de presentacin debe cambiar tambin.
Adems, puede haber un impacto negativo en el rendimiento de la red porque los componentes
de niveles de presentacin que utilizan la API de servicios pueden hacer llamadas en la red.

Solucin: Usar un Business Delegate para reducir el acoplamiento entre los clientes de niveles
de presentacin y los servicios de negocio. El Business Delegate oculta los detalles de
implementacin del servicio de negocio, tales como operaciones de bsqueda 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 librera
de acceso a BBDD, o puede que necesite acceder a datos en LDAP, o tiene que recuperar
informacin mediante servicios web de un sistema externo, etc.

Solucin: 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 cmo se recuperan esos datos, no tiene que abrir ni
cerrar conexiones y no sabe si es a LDAP, BBDD o a una aplicacin externa.

Value List Handler

NOTA: Este patrn no se describi durante el curso, pero me pareca ms importante que el
SessionFaade.
Problema: Un problema tpico puede ser la paginacin 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.

Solucin: Usar un clase que sea la responsable de tratar los resultados, a la que le podamos
pedir una pgina 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 pginas de resultados a nuestro
ValueListHandler que usar un iterador para recorrerlos.