El lenguaje UML

y sus modos de utilizacin

Contenido
7.1 Introduccin
7.2 Evolucin histrica
7.3 Cmo es utilizado en la comunidad informtica?
7.4 Perspectivas
7.5 Diagramas
7.6 Relacin con el proceso de desarrollo
7.7 Seleccin del modo de uso
7.8 Referencias
Objetivos

Qu es el lenguaje UML (Unified Modelling Lengage).

Cules son los modos de su utilizacin en el desarrollo de software.
Qu aportan los diagramas de UML a la documentacin de un proyecto.
7.1 Introduccin

Hemos seleccionado como medio de documentacin de los aspectos tcnicos

desarrollados a lo largo del libro al lenguaje UML (Unified Modeling Language). Lo
elegimos por ser el estndar en la industria. y los modelos que lo componen sern los
que utilicemos por ejemplo en la presentacin del proyecto del caso testigo que
comenzaremos a desarrollar en el captulo 10.

7.1.1 Qu es UML?
UML es un lenguaje que est compuesto por un conjunto de diagramas agrupados por
un metamodelo que ayuda a especificar y disear el software de sistemas;
particularmente software orientado a objetos. Por
muchos aos fue el estndar de hecho de la comunidad informtica, aunque despus de
seis aos de su primera versin fue adoptado como tal.
7.1 Introduccin
7.1.1 Qu es UML?

Es un estndar abierto controlado por Object Management Group (OMG) [1]. Desde el ao 2005 el
lenguaje UML es un estndar aprobado por la ISO como ISO/IEC 19501:2005 Information technology
Open Distributed Processing Unified Modeling Language (UML) Version 1.4.2.
De la misma manera que un constructor de casas o edificios antes de apilar ladrillos elabora un plano,
un desarrollador de software antes de escribir cdigo hace un plano que le permita evaluar alternativas
de su diseo. Igual que una modista utilizando hojas de papel construye un molde para sus prendas en
forma previa a cortar la tela y coserla, un desarrollador de software necesita elaborar un modelo que
describa los diferentes aspectos del problema por resolver y de la solucin propuesta. UML es un
lenguaje de especificacin y diseo que permite a los desarrolladores construir modelos para estudiar,
analizar y decidir acerca de la estructura y del comportamiento que propondr como solucin y, en
definitiva, cmo estar compuesto y cmo se comportar el cdigo que implementar dicha solucin.
7.1 Introduccin
7.1.2 Preguntas frecuentes
Las preguntas que deseamos responder son las que con frecuencia hemos escuchado en personas sin experiencia
en la utilizacin de los diagramas de UML. Basaremos nuestra presentacin en las necesidades derivadas de la
complejidad del problema por resolver y en la experiencia del desarrollador.
Estas preguntas son:
1. Debo construir un diagrama/modelo para cada aspecto del problema?
2. Debo construir un diagrama/modelo para cada aspecto de la solucin?
3. Cules diagramas es necesario construir?
4. Los diagramas que debo construir dependen de la metodologa de desarrollo que utilizamos?
5. En qu momento del ciclo de vida del proyecto debo construirlos?
6. Quin construye cada modelo? Qu rol?
7. Cundo se utilizan los diagramas a lo largo del ciclo de vida del proyecto?
8. Qu debo incluir en cada diagrama? Cun detallados deben ser?
9. Qu aporta cada diagrama?
10. Cmo relaciono los diagramas?
11. Cmo los mantenemos actualizados ante cambios?
12. Qu herramientas puedo utilizar?
7.2 Evolucin histrica

Durante muchos aos no existi un estndar que permitiera documentar la

especificacin y el diseo del software. Los miembros de distintos grupos de desarrollo
tenan un obstculo cada vez que deban intercambiar informacin. Alrededor del ao
1995 ya se haba instalado la programacin orientada a objetos como estndar en la
industria a travs del uso del lenguaje C++. Sin embargo, no haba un estndar de
especificacin y diseo; lo que s haba eran distintas propuestas en tal sentido. Entre las
ms conocidas podemos mencionar los diagramas de Booch [2] [3] y Rumbaugh [4].
Tampoco haba una metodologa estndar definida de desarrollo de software
esencialmente inspirada en el nuevo paradigma de entonces, la programacin orientada
a objetos.
Por esos das ambas propuestas fueron una mezcla de lenguaje y forma de usarlo, es
decir, una metodologa.
7.2 Evolucin histrica

Aos despus estas propuestas fueron fundidas con la inclusin de los casos de uso
aportados por Ivar Jacobson y sus colegas [6], en lo que se llam UML. Fueron
popularizados como los tres amigos y la herramienta que produjo la empresa que los
reuni, Rational, fue la primera en soportar dicho lenguaje. De esta unin adems
fueron publicados dos libros: uno que describa el lenguaje [7] y otro, la metodologa
propuesta que se llam Proceso Unificado de Desarrollo de Software [8].
El lenguaje ha tenido algunos cambios desde su versin 1.1 hasta la 1.5. Hoy da la
vigente es la 2.0, la cual ha incorporado nuevos diagramas orientados a construir
especificaciones de procesos de negocio. Estos
diagramas son los utilizados para hacer modelado de flujo de trabajo y procesos en lo
que se llama BPM (Business Process Modeling). Tambin ha incorporado diagramas
temporales en los que se pueden especificar restricciones de tiempo en diagramas de
objetos.
 7.2 Evolucin histrica

En la figura 7.1.a se muestra un diagrama de clases utilizando la notacin de Booch [2].

7.3 Cmo es utilizado en la comunidad informtica?

Antes de responder las preguntas planteadas, haremos un repaso de cmo es utilizado UML [5] y a
partir de ste ensayaremos las respuestas.
7.3.1 Dibujo (Sketch)
Usado por los desarrolladores para comunicar diferentes aspectos de un sistema. Definicin de
aspectos de diseo en reuniones colaborativas. Se utilizan herramientas o se hacen a mano alzada. No
interesan detalles
aportados por el lenguaje. Slo se incorporan aqullos que resulten relevantes al objetivo con que se
construy el diagrama.
7.3.2 Plan (Blueprint)
Usado como herramienta desde la cual se comprende un sistema por desarrollar (diagramas previos al
cdigo) o ya desarrollado (documentan cdigo ya existente - ingeniera inversa). Interesan los detalles
ya que de all se guiarn los desarrolladores para escribir el cdigo casi mecnicamente.
Se utilizan herramientas de tipo CASE (Computer Aided Software Engineering), es decir, asistidas por
computadoras.
7.3 Cmo es utilizado en la comunidad informtica?
7.3.3 Lenguaje de programacin
Usado como lenguaje de programacin a partir del uso de herramientas sofisticadas. Interesan todos
los detalles. Generadores de cdigo sustituyen a los programadores. Ejemplo: Model Driven
Architecture (MDA), Platform Independent Model (PIM), Platform Specific Model (PSM).
Es importante para el desarrollador no confundir el modo en que est haciendo uso de UML y ubicarse
as en la perspectiva correcta. La mayor cantidad de fallas en su utilizacin que hemos observado se
debi a que en el mismo proyecto se usaba en la modalidad Dibujo para algunos diagramas y se
pretenda utilizar como Plan para otros. Los diagramas as construidos generan desconcierto en los
miembros de los grupos de desarrollo que, ante esta situacin, desestiman su uso y padecen su
carencia.
Su uso ms difundido es en la modalidad Dibujo. Esto es debido al objetivo con que se construyen los
diagramas y en general toda documentacin. En el seno del grupo de desarrollo el objetivo est dado
por la necesidad de comunicacin entre los miembros, para lo cual alcanza su uso en esta modalidad.
Tambin alcanzan los diagramas as construidos como documentacin a futuro para realizar
mantenimiento del sistema durante su vida til en servicio. Sin embargo, deseamos refinar este
concepto y para ello distinguiremos dos perspectivas distintas que determinarn dentro de esta
modalidad de uso la informacin que se va a incorporar en los diferentes diagramas.
7.4 Perspectivas

Las dos perspectivas que mencionamos estn motivadas por las dos diferentes vistas que
los desarrolladores necesitan en dos momentos del ciclo de vida del proyecto de desarrollo
[5]. stas son independientes de la
metodologa utilizada y estn determinadas por las diferentes preocupaciones de los
desarrolladores en los momentos mencionados: la comprensin del problema por resolver
y la propuesta de una solucin.
Martin Fowler [5] llama a estas perspectivas conceptual y de software. Nosotros
compartimos esta visin pero las llamaremos problema y solucin.
7.4.1 Problema (concepcin y anlisis)
La preocupacin y el objetivo de los primeros momentos de cualquier proyecto son
entender cmo los usuarios interactuarn con el sistema, entender las reglas del negocio,
definir un lenguaje comn y determinar el
alcance del proyecto. Para la realizacin de estas tareas, la utilizacin de UML para expresar
conceptos es muy importante. Ms que la precisin, se necesita la posibilidad de concebir y
analizar conceptos.
7.4 Perspectivas
7.4.1 Problema (concepcin y anlisis)
UML ofrece diagramas de casos de uso para mostrar la interaccin de los actores con el sistema,
diagramas de clases para la perspectiva conceptual, diagramas de actividad para modelar flujos de
trabajo y diagramas de estado para mostrar el ciclo de vida de los conceptos extrados del dominio del
problema.
7.4.2 Solucin (diseo)
La otra perspectiva est dada por la elaboracin de una solucin. La preocupacin es elaborar un
diseo que sea quizs escalable, flexible de cambiar, fcil de probar, etctera. Para definir este diseo
queremos ser ms precisos y nos ayudamos de diagramas de clases con mayor cantidad de adornos
(detalles) para definir la estructura de nuestro sistema, diagramas de secuencia para mostrar su
comportamiento, diagramas de paquetes para realizar particiones y separar incumbencias y diagramas
de estado para mostrar ciclos de vida y de componentes para documentar instalacin en distintos
ambientes. Todos estos diagramas definen la estructura y el comportamiento del cdigo; por esta razn
en UML Distilled: A Brief Guide to the Standard Object Modeling Language [5] la llaman software. Si
bien proponemos la utilizacin en la modalidad Dibujo, queda claro que en esta perspectiva
detallaremos aspectos que en la anterior no era necesario.
7.4 Perspectivas
7.4.3 Respuestas a las preguntas frecuentes
A continuacin respondemos las preguntas que nos formulamos en una seccin anterior.
1. Debo construir un diagrama/modelo para cada aspecto del problema?
Por lo general los sistemas de software, por las caractersticas del problema por resolver y de su
solucin, enfatizan algunos aspectos en desmedro de otros. Esto implica que no siempre ser necesario
construir todos los diagramas. Por ejemplo, para un sistema complejo con varias y diferentes reas de
negocio seguramente ser til construir un diagrama de paquetes que muestre la distribucin de las
funcionalidades en cada uno de ellos. Adems, son indicados los diagramas de actividad en estos casos
en los que puede documentarse el flujo de informacin entre los diferentes roles. En el caso de un
sistema pequeo estos modelos no aportan mayor informacin.
2. Debo construir un diagrama/modelo para cada aspecto de la solucin?
Siguiendo el mismo razonamiento que en la pregunta anterior, no siempre los diagramas aportan
informacin de utilidad. Por ejemplo, en modelos de clases simples los diagramas de clases son
suficientes. Sin embargo, cuando estas clases participan de relaciones con otras clases, y stas son
complejas, es necesario entender cmo interactan las instancias de estas clases en memoria. En estos
casos son de utilidad los diagramas de secuencia y/o comunicacin que muestran los aspectos
dinmicos.
7.4 Perspectivas
7.4.3 Respuestas a las preguntas frecuentes

3. Cules diagramas son necesarios construir?

Siguiendo el criterio de que la documentacin por construir es aquella que se necesita y que el objetivo
de su construccin es la comunicacin, los diagramas que deben construirse son aquellos que
comunican informacin acerca del problema o la solucin. Muchas veces dos o ms diagramas
muestran la misma informacin; en estos casos debemos optar por aquel que lo haga de forma ms
clara.
4. Los diagramas que debo construir dependen de la metodologa de desarrollo que utilizamos?
La respuesta a esta pregunta podra ser no. Sin embargo, necesita una aclaracin. Algunas
metodologas proponen, adems de la forma de trabajo, una forma de documentar el proyecto. Por
ejemplo, el Proceso Unificado de Desarrollo basa el trabajo con los requerimientos funcionales en los
casos de uso. Otras no lo hacen; por ejemplo, algunas de las metodologas giles. Nuestra experiencia
es que se puede elegir una forma de trabajo y una forma de documentacin de manera que ambas
sean independientes. De hecho, actualmente estamos trabajando con una empresa que eligi como su
metodologa Scrum y documenta los requerimientos utilizando casos de uso en lugar de tarjetas con
storyboards.
7.4 Perspectivas
7.4.3 Respuestas a las preguntas frecuentes

5. En qu momento del ciclo de vida del proyecto debo construirlos?

Independientemente de la metodologa elegida, cualquiera sea, en los primeros momentos de un
proyecto de desarrollo se busca como objetivo achicar los riesgos del negocio, esto es, obtener un
conocimiento del negocio o dominio que el sistema por desarrollar debe resolver. Este conocimiento
no es tcnico, sino conceptual. Construiremos entonces los diagramas desde la perspectiva del
problema, conceptual segn Martin Fowler [5]. Documentaremos las entidades ms importantes como
clases, las reglas de negocio como responsabilidades que sern validadas por estas clases, las
funcionalidades ms importantes como casos de uso y los flujos de informacin como diagramas de
actividad. Cuando el proyecto avance y contemos con un modelo del negocio, vendr entonces el
momento de definir la arquitectura del sistema y construiremos para ello diagramas de paquetes,
componentes y nodos. Tambin diagramas de secuencia que muestren las interacciones entre los
diferentes componentes. Luego disearemos el interior de cada paquete y entonces agregaremos
nuevos diagramas de clases, ahora con el objetivo de hacer al sistema escalable, flexible de cambiar y
mantener.
7.4 Perspectivas
7.4.3 Respuestas a las preguntas frecuentes
6. Quin construye cada modelo? Qu rol?
La construccin de los diferentes modelos est a cargo de los diferentes roles dentro de un grupo de
desarrollo. Por lo general los analistas construyen diagramas de casos de uso, actividad y clases de
dominio para sus tareas de relevar y analizar requerimientos; el arquitecto, los relacionados a
documentar la arquitectura y los diagramas de diseo son elaborados por el resto de los
desarrolladores.
7. Cundo se utilizan los diagramas a lo largo del ciclo de vida del proyecto?
Los diagramas se utilizan desde que son construidos hasta que el proyecto finaliza. Se construyen
cuando surge la necesidad de hacerlo y luego se consultan durante el ciclo de vida del proyecto.
8. Qu debo incluir en cada diagrama? Cun detallados deben ser?
Esta es la pregunta cuya respuesta est directamente alineada con el uso de UML en la modalidad
Dibujo. Si deseamos mostrar que una determinada clase complementa a otra en un diseo, basta con
mostrar sus relaciones, cardinalidad y los mtodos que tienen la responsabilidad de la implementacin
de dicho complemento. Seguramente ambas clases tendrn una cantidad de atributos y otros mtodos
que no son determinantes y no agregan informacin acerca del aspecto que se busca comunicar. Por lo
tanto, esos detalles (adornos) no se incluyen.
7.4 Perspectivas
7.4.3 Respuestas a las preguntas frecuentes

9. Qu aporta cada diagrama?

Cada diagrama es una vista diferente del problema y la solucin. Algunos muestran aspectos dinmicos,
otros estticos y en general, si se construyen por contextos, muestran las distintas partes que
componen a ambos. En un prximo captulo, cuando presentemos cada diagrama, nos referimos al
aporte de informacin de cada uno en detalle.
10. Cmo relaciono los diagramas?
Al constituir diferentes vistas del mismo sistema, todos los diagramas pueden y deben relacionarse. Por
ejemplo, las actividades de un diagrama de actividad seguramente son casos de uso de un diagrama de
tal tipo; los objetos de un diagrama de secuencia seguramente se pueden relacionar con las clases de
las cuales proviene; las clases pueden relacionarse con los casos de uso que implementan, etctera.
Este tipo de relaciones se denominan trazas y por lo general las herramientas CASE permiten
administrarlas. Son de gran utilidad al momento de evaluar el impacto de cambios en un sistema
grande. La trazabilidad entre los diferentes diagramas es una ayuda importante durante el ciclo de vida
del desarrollo que permite establecer relaciones entre los componentes.
7.4 Perspectivas
7.4.3 Respuestas a las preguntas frecuentes
11. Cmo los mantenemos actualizados ante cambios?
sta es la pregunta que se hacen muchos desarrolladores y, como no hallan respuesta, deciden no
documentar sus diseos. Creemos que es un sntoma de no haberse decidido por uno de los modos de
uso de UML. Si hubiesen elegido por alguno de los otros dos, deberan mantener actualizada todo el
tiempo la documentacin, ya que de all se genera el cdigo. En la modalidad Dibujo, por incluir slo lo
relevante, es raro que la documentacin quede en algn momento desactualizada. Si sucede esto
significa que ha habido un cambio importante y por lo tanto se justifica el esfuerzo de actualizarla. En
los casos en que adems se necesite contar con documentacin que refleje detalles de la
implementacin se puede construir utilizando herramientas como Doxygen [11], que la elaboran en
forma inversa a partir del cdigo ya escrito.
12. Qu herramientas puedo utilizar?
Existen en el mercado una gran variedad de herramientas para la construccin de diagramas de UML.
stas varan en funcionalidad y, por supuesto, en precio. Las ms elaboradas adems estn integradas
con otras que permiten realizar tareas de gestin de los proyectos. Tambin las hay de tipo open
source y libres. Citamos algunas muy conocidas como Modelio [13], ArgoUML [14], Rational Rose [9] y
Enterprise Architect [10].
7.4 Perspectivas
7.4.4 Madurez y nivel de conocimiento de los desarrolladores

Es importante mencionar que un aspecto para considerar al momento de decidir qu

documentar y qu no en un proyecto es la experiencia de los miembros del grupo de
desarrollo. Seguramente cuando en l haya personas con poca experiencia y menor
conocimiento debern documentarse con ms detalle algunos aspectos del sistema en
desarrollo. De esta forma la documentacin cumplir acabadamente con uno de los
objetivos mencionados en el inicio del captulo que es comunicar. Esta comunicacin
contar con ms informacin y con ms detalles a efectos de soportar la falta de
experiencia y conocimiento.
7.5 Diagramas
En la figura 7.2 se muestran los diferentes diagramas que componen el conjunto de
diagramas de UML.

En un prximo captulo presentamos cada diagrama en detalle. A continuacin describimos

sus propsitos.
7.5 Diagramas
7.5.1 Diagramas estticos
Diagramas de clases: Un diagrama de clases describe la estructura de un sistema. Muestra las clases,
sus atributos y mtodos y las relaciones entre ellas.
Diagramas de objetos: Un diagrama de objetos muestra una vista parcial o completa de la estructura
de un sistema en un momento determinado a partir de las instancias de las clases del sistema.
Diagramas de paquetes: Un diagrama de paquetes muestra cmo un sistema se divide en
agrupaciones lgicas mostrando las dependencias entre ellas. El criterio de agrupamiento est dado
para los paquetes que encapsulan funcionalidad por la cohesin desde el punto de vista del negocio y
para los paquetes que encapsulan aspectos de la tecnologa por la cohesin de la prestacin de
servicios.
Diagramas de componentes: Un diagrama de componentes en el Lenguaje de Modelado Unificado
representa cmo un sistema de software se divide en componentes y muestra las dependencias entre
stos. Estos componentes pueden ser libreras estticas, libreras dinmicas, etctera.
Diagramas de instalacin: Un diagrama de nodos sirve para modelar el hardware utilizado en las
implementaciones del sistema, los componentes desplegados en el hardware y las asociaciones entre
ellos. Cabe mencionar que otros nombres para este mismo diagrama que suelen usarse son
"despliegue" y "nodos".
 7.5 Diagramas
7.5.2 Diagramas dinmicos
Diagramas de actividad: Un diagrama de actividad muestra un flujo de informacin entre
roles de negocio o entre componentes de la tecnologa.

Diagramas de estados: Un diagrama de estados muestra los estados posibles de las

diferentes entidades, los eventos por ellas recibidos y su transicin entre ellos.

Diagramas de casos de uso: Un diagrama de casos de uso muestra la funcionalidad

ofrecida por el sistema desde la perspectiva de los actores externos y la relacin entre estas
funcionalidades.

Diagramas de comunicacin: Un diagrama de comunicacin expresa la interaccin entre

componentes en trminos de mensajes intercambiados.

Diagramas de secuencia: Un diagrama de secuencia muestra la interaccin entre

componentes y el orden temporal en que estos mensajes son enviados y recibidos.
7.6 Relacin con el proceso de desarrollo

Con el advenimiento de las metodologas giles que enfatizan, como se mencion en

captulos anteriores, la comunicacin verbal in situ frente a la documentacin, se gener en
la comunidad un falso conflicto.
Se cre la imagen de que si la metodologa era gil no era necesario documentar. Esta
situacin es comentada en Is Design Dead? [12], donde Martin Fowler cuenta que hasta
Kent Beck hace un borrador de parte de sus diseos aunque sin ninguna notacin, aun
cuando ste es una de las dos personas que concibieron Extreme Programming, la primera
metodologa no conducida por los planes. Es verdad que algunas metodologas conducidas
por los planes enfatizan parte de su flujo de trabajo e informacin en la documentacin
generada y otras no lo hacen, como acabamos de comentar, pero tambin es cierto que en
todas ellas, estn basadas en lo que fuere, cuando participa un grupo de personas es
necesario comunicar y acordar, y para esto es que la documentacin debe ser construida.
7.7 Seleccin del modo de uso

Hemos enfatizado la utilizacin de UML en el modo Dibujo (Sketch) frente a la

modalidad Plan (Blueprint) y Lenguaje de Programacin porque seguramente ser
la primera forma y la ms directa en que los lectores de
este libro lo utilizarn. An falta tiempo a criterio de estos autores para que el
concepto de UML como Lenguaje de Programacin en el diseo de arquitecturas
conducidas por los modelos (Model Driven Architecture
- MDA) se utilice como herramienta corriente de desarrollo. Respecto de la
utilizacin como Plan (Blueprint) lo hemos observado en algunos proyectos de
gran volumen donde haban sido definidos roles de diseadores y
programadores de forma separada en el contexto de proyectos remotos. El
resultado de su utilizacin de esta forma no es eficiente y se convierte a la larga en
una restriccin para los desarrolladores.