Lenguaje Unificado de Modelado

De Wikipedia, la enciclopedia libre

(Redirigido desde UML)

Saltar a navegación, búsqueda

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en
la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje
gráfico para visualizar, especificar, construir y documentar un sistema de software. UML
ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programación, esquemas de bases de datos y
componentes de software reutilizables.

Es importante resaltar que UML es un "lenguaje" para especificar y no para describir

métodos o procesos. Se utiliza para definir un sistema de software, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en
el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso Unificado
Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa (Lengua
de Modelación Unificada), no es programación, solo se diagrama la realidad de una
utilización en un requerimiento. Mientras que, programación estructurada, es una forma de
programar como lo es la orientación a objetos, sin embargo, la orientación a objetos viene
siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para
lenguajes orientados a objetos

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.

Contenido
[ocultar]

•1 Diagramas
•2 Software para modelado en UML
o2.1 Software Libre
o2.2 Freeware para modelado en UML
o2.3 Otro software
•3 Estandarización de UML
•4 Críticas a UML
•5 Véase también
•6 Referencias

•7 Enlaces externos
Diagramas [editar]

Jerarquía de los diagramas UML 2.0, mostrados como un diagrama de clases

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta,
a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema
modelado:

•Diagrama de clases
•Diagrama de componentes
•Diagrama de objetos
•Diagrama de estructura compuesta (UML 2.0)
•Diagrama de despliegue
•Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema

modelado:

•Diagrama de actividades
•Diagrama de casos de uso
•Diagrama de estados

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que

enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

•Diagrama de secuencia
•Diagrama de colaboración
•Diagrama de tiempos (UML 2.0)
•Diagrama de vista de interacción (UML 2.0)

Software para modelado en UML [editar]

A continuación, se listan algunos de los programas más populares para el modelado en
UML
Software Libre [editar]

Estos programas están bajo licencias libres, siendo posible su libre uso, estudio y
modificación.

•ArgoUML, Herramienta de modelado UML escrito en Java (enlace externo)

•BOUML, Ligera herramienta de modelado UML y generación de código C++, Java e
IDL. Disponible para Windows, Unix/Linux y Mac OS X (Sitio Oficial)
•Fujaba, No solo sirve para modelar sino que puede generar código Java
automáticamente. También es capaz de hacer ingeniería inversa y crear los
diagramas a partir del código Java [1].
•Dia Puede ser usado para modelar varios tipos de diagramas UML (enlace externo)
•gModeler Herramienta para modelado de UML basada en Flash (utilizable desde el
navegador), que permite generar código Action Script 2.0 Compatible (enlace
externo)
•MonoUML Herramienta CASE para la plataforma mono (Sitio Oficial)
•Papyrus, Herramienta gráfica basada en Eclipse para el modelado con UML2, es de
código abierto y se ofrece bajo licencia EPL (Sitio Oficial)
•StarUML Herramienta de modelado para Windows desarrollada en Delphi. Bastante
estable y utilizable (enlace externo)
•TCM, Toolkit for Conceptual Modeling, herramienta para crear diversos tipos de
diagramas incluidos UML [http://wwwhome.cs.utwente.nl/~tcm/ Web oficial)
•Umbrello Herramienta para modelado UML para el entorno KDE (enlace externo)
•UMLet Herramienta para modelado rápido de UML también escrita en Java (enlace
externo)
•Netbeans módulo UML

Freeware para modelado en UML [editar]

Aunque gratuitos, estos programas se encuentran bajo licencias que no permiten el estudio
y modificación de los mismos.

•JUDE Community Herramienta de modelado UML (Sitio Oficial)

•Omondo plugin para Eclipse. Herramienta de modelado UML para Java
•Oracle JDeveloper Un IDE para Java con soporte de diagramas UML
•Visual Paradigm for UML, Herramienta de modelado UML y herramienta CASE que
cuenta con una versión gratuita denominada Community Edition (enlace externo)

Otro software [editar]

Software comercial de modelado UML:

•Enterprise Architect de Sparx Systems

•Borland Together
•Corel iGrafx
•Microsoft Visio
•PowerDesigner de Sybase
•Rational Rose de IBM
•Poseidon for UML de GentleWare
•MagicDraw UML
Estandarización de UML [editar]
Además de haberse convertido en un estándar de facto, UML es un estándar industrial
promovido por el grupo OMG al mismo nivel que el estándar CORBA para intercambio de
objetos distribuidos. Para la revisión de UML se formaron dos "corrientes" que promovían
la aparición de la nueva versión desde distintos puntos de vista. Finalmente se impuso la
visión más industrial frente a la académica. Recientemente se ha publicado la versión 2.0 en
la que aparecen muchas novedades y cambios que, fundamentalmente, se centran en
resolver carencias prácticas. Además, esta versión recibe diversas mejoras que provienen
del lenguaje SDL.

Críticas a UML [editar]

A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido
muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la
interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no
se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran
importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con
maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que
un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y
que es compartido entre varias instancias de ejecución del sistema analizado. Sin embargo,
UML si acepta la creación de nuestros propios componentes para este tipo de modelado.
Object Management Group

Véase también [editar]

•Entorno de desarrollo integrado
•Herramienta CASE
•Técnica de Modelado a Objetos
•Programación orientada a objetos
•XMI, un formato estándar basado en XML para el intercambio de modelos UML.
•OCL, Lenguaje de especificación para los diferentes modelos en UML.
•Webml, Metodología para el diseño de Sistemas de Información Web.

Referencias [editar]
•Martin fowler, kendall sccott, "UML Gota a Gota", 1999.

Enlaces externos [editar]

•Grupo Oficial del lenguaje Modelado - (En Ingles)
•Especificación oficial (En Ingles)
•UML Jokes (En Ingles)
•Introducción a UML 2.0 (En Castellano)
•Introducción a UML 2.0 Parte II (En Castellano)
•Introducción a UML 2.0 (En inglés)
•Amplia información sobre UML (En inglés)
•Base de conocimiento de UML (En Castellano)
•Centro de recursos de UML abierto a la comunidad (En Castellano
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15
Introducción a UML 2.0
Introducción a UML 2.0
La evolución de la programación hacia la ejecución y validación automática de modelos
Por: Quirón en: Mar 04 of Oct, 2005 [20:30 UTC] (72825 lecturas)

En este artículo nos introduciremos al mundo del diseño de aplicaciones de software a través de su
puerta más novedosa: UML 2.0.
(19832
bytes)
Tabla de Contenidos

•Introducción
•Conociendo UML 2.0
oObjetivos del UML 2.0
oEl UML y la Industria del Software
oConceptos básicos sobre UML
o(Muy) Breve Reseña Histórica
oEl Nuevo Enfoque del UML 2.0
Reestructuración del Lenguaje
OCL
Especificación para el Intercambio de Diagramas
Infraestructura
Superestructura
oLa Superestructura del UML
Organización de la superestructura
Diagramas de Estructura y Diagramas de comportamiento
Breve descripción sobre los diagramas
oConclusión
•¿Cómo sigo?
•Bibliografía

Introducción
Al momento de desarrollar el nuevo estándar 2.0 de UML, la OMG se planteó, entre otros, dos
objetivos que podríamos considerar principales, debido a la influencia de éstos en la nueva versión del
estándar:

1.Hacer el lenguaje de modelado más extensible.

2.Permitir la validación y ejecución de modelos.

En el presente artículo, se muestran los principales cambios en UML 2.0, cómo éstos influyen en los
objetivos planteados anteriormente, la nueva estructura de UML 2.0, los nuevos diagramas y los
cambios más importantes en los diagramas preexistentes.

La evolución de la programación hacia la ejecución y validación automática de modelos

Conociendo UML 2.0

En este artículo nos introduciremos al mundo del diseño de aplicaciones de software, a través de su
puerta más novedosa: UML 2.0.

Éste es el comienzo de una serie de artículos en los que iremos, poco a poco, conociendo el UML 2.0
en detalle. En el presente trabajo, nos enfocaremos en el lenguaje propiamente dicho; su historia,
estructura, cambios y objetivos de mayor influencia, en esta nueva y radical versión.
Objetivos del UML 2.0
Al momento de desarrollar el nuevo estándar 2.0 del UML, la OMG se propuso, entre otros, dos
objetivos que podríamos considerar principales debido a la influencia de éstos en la versión final del
estándar. Estos objetivos son:

1.Hacer el lenguaje de modelado mucho más extensible de lo que era.

2.Permitir la validación y ejecución de modelos creados mediante el UML.

UML 2.0 se desarrolla sobre la base de estos dos objetivos, causando un quiebre respecto a versiones
anteriores. Para entender la razón del quiebre y el por qué de esta evolución tan marcada, nos
profundizaremos un poco en la historia y definición misma del UML.

El UML y la Industria del Software

El UML se ha vuelto el estándar de facto (impuesto por la industria y los usuarios) para el modelado
de aplicaciones de software. En los últimos años, su popularidad trascendió al desarrollo de software y,
en la actualidad, el UML es utilizado para modelar muchos otros dominios, como por ejemplo el
modelado de procesos de negocios.

Conceptos básicos sobre UML

UML son las siglas para Unified Modeling Language, que en castellano quiere decir: Lenguaje de
Modelado Unificado. Para comprender qué es el UML, basta con analizar cada una de las palabras que
lo componen, por separado.

•Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una
sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre
cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación.
•Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real,
que permiten una mejor interpretación y entendimiento de éste.
•Unificado: unifica varias técnicas de modelado en una única.

Ya que el UML proviene de técnicas orientadas a objetos, se crea con la fuerte intención de que este
permita un correcto modelado orientado a objetos.

(Muy) Breve Reseña Histórica

Las raíces del UML provienen de tres métodos distintos. El método de Grady Booch, la Técnica de
Modelado de Objetos de James Rumbaugh y “Objetory”, de Ivar Jacobson. Conocidas estas tres
personalidades como “los tres amigos”. En 1994 Booch, Rumbaugh y Jacobson dieron forma a la
primera versión del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versión
v1.1 del UML. Desde entonces, UML atravesó varias revisiones y refinamientos hasta llegar a la
versión actual: UML 2.0.

¿Qué es la OMG?

La OMG (Object Management Group) es una asociación sin fines de lucro formada por grandes
corporaciones, muchas de ellas de la industria del software, como por ejemplo: IBM, Apple Computer,
Sun Microsystems Inc y Hewlett-Packard?. Esta asociación se encarga de la definición y
mantenimiento de estándares para aplicaciones de la industria de la computación. Otro de los
estándares definidos por la OMG, además del UML, es CORBA, el cual permite interoperabilidad
multiplataforma a nivel de objetos de negocio.

Podemos encontrar más información sobre la OMG en su sitio oficial: http://www.omg.org/

Es importante destacar que, a lo largo de estas constantes revisiones, muchas técnicas existentes
fueron agregadas a UML. Esta constante ampliación del lenguaje hizo que el UML fuera perdiendo
identidad, convirtiéndose en una agrupación de distintas técnicas de modelado, sin demasiada
cohesión entre ellas. Esto transformó al UML en un lenguaje sin identidad y, en muchos puntos,
ambiguo o falto de coherencia conceptual.
El Nuevo Enfoque del UML 2.0
En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un lenguaje de
programación. Un modelo creado mediante UML no podía ejecutarse. En el UML 2.0, esta asunción
cambió de manera drástica y se modificó el lenguaje, de manera tal que permitiera capturar mucho
más comportamiento (Behavior). De esta forma, se permitió la creación de herramientas que soporten
la automatización y generación de código ejecutable, a partir de modelos UML.

Estándares que conforman el UML

•Superestructura: Es la especificación que usamos todos los días. Aquí se encuentran todos los
diagramas que la mayoría de los desarrolladores conocen.
•Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura, entre
otras.
•OCL: Lenguaje de restricción. De utilidad para especificar conceptos ambiguos sobre los distintos
elementos del diagrama.
•XMI / Intercambio de diagramas: Permite compartir diagramas entre diferentes herramientas de
modelado UML.

Reestructuración del Lenguaje

Para lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o
modificados. La especificación se separó en cuatro especificaciones (paquetes) bien definidas, tal
como se muestra en la Figura 1. Es interesante destacar que el UML 2.0 puede definirse a sí mismo.
Es decir, su estructura y organización es modelable utilizando el propio UML 2.0; de esta manera, se
da un ejemplo de utilización del UML en un dominio distinto al del desarrollo de software. En este
caso, cada paquete del diagrama representa cada una de las cuatro especificaciones que componen el
lenguaje.

::

::
Figura 1: Especificaciones principales del UML 2.0

Veamos a continuación, un poco más en detalle cada una de las principales especificaciones que
componen UML 2.0. No nos explayaremos demasiado, debido a que en futuras ediciones habrá
oportunidad de profundizar en cada una de ellas.

OCL
OCL son siglas en inglés que significan: Object Constraint Language y que en castellano se traducen
como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir
restricciones y expresiones sobre elementos de un modelo. El OCL suele ser útil cuando se está
especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos
para los objetos del dominio. El OCL brinda la posibilidad definir en los elementos de un diagrama,
entre otros: invariantes, precondiciones, poscondiciones y restricciones. El OCL fue incorporado al UML
en la versión 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo más de las muchas
herramientas agregadas al UML.

Especificación para el Intercambio de Diagramas

La especificación para el intercambio de diagramas fue escrita para facilitar una manera de compartir
modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones
anteriores del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el
diagrama; pero este Schema no decía nada acerca de la manera en que el modelo debía graficarse.
Para solucionar este problema, la nueva especificación para el intercambio de diagramas fue
desarrollada utilizando un nuevo Schema XML, que permite construir una representación SVG
(Scalable Vector Graphics). Esta especificación es denominada con las siglas XMI, que en inglés
significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de
Metadata (datos que representan datos). Típicamente esta especificación es solamente utilizada por
quienes desarrollan herramientas de modelado UML.

Infraestructura
En la Infraestructura del UML se definen los conceptos centrales y de más bajo nivel. La
Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto
del UML. Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la
piedra fundamental sobre la cual la Superestructura es definida. Esta última sí es la utilizada por el
común de los usuarios. La Infraestructura brinda también varios mecanismos de extensión, que hacen
del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la
infraestructura existe y cuáles son sus objetivos.

Superestructura
La superestructura del UML es la definición formal de los elementos del UML. Esta definición sola
contiene más de 640 páginas. La superestructura es típicamente utilizada por los desarrolladores de
aplicación. Es aquella sobre la que hablan los libros y la que la mayoría conoce de versiones anteriores
del UML.

La Superestructura del UML

Es en la Superestructura donde encontramos los cambios que más afectan en el día a día a quienes
trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que, en general,
deben interpretar o crear modelos que especifiquen el dominio de tales aplicaciones.

Es aquí dónde se definen los diagramas y los elementos que los componen. La Superestructura se
encuentra dividida en niveles. Estos niveles se conocen como:

•Básico (L1): Contiene los elementos básicos del UML 2.0, entre ellos: Diagramas de clases,
Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso
•Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles, Diagramas
de Componentes y Diagramas de despliegue.
•Completo (L3): Representa la especificación del UML 2.0 completa, como por ejemplo: las
Acciones, Características avanzadas y PowerTypes? entre otros.

Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Básico
(L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de
características (features) bastante amplia entre dos herramientas distintas, aunque éstas sean UML
2.0 compatibles.

Organización de la superestructura
El bloque de construcción básico del UML es un diagrama. La estructura de los diagramas UML está
reflejado por el diagrama de la figura 2, de acuerdo con la especificación del UML 2.0 del Object
Development Group. Los detalles sobre estos diagramas específicos se organizan de acuerdo a esta
estructura taxonómica, que da la perspectiva a los diagramas y a sus interrelaciones. Los diagramas
de interacción comparten propiedades y atributos similares, como lo hacen los diagramas estructurales
y de comportamiento. En color azul se distinguen aquellos diagramas que aparecen en esta versión del
UML.

Figura 2: Estructura taxonómica del UML 2.0

Diagramas de Estructura y Diagramas de comportamiento

Los diagramas estructurales representan elementos y así componen un sistema o una función. Estos
diagramas pueden reflejar las relaciones estáticas de una estructura, como lo hacen los diagramas de
clases o de paquetes, o arquitecturas en tiempo de ejecución, tales como diagramas de Objetos o de
Estructura de Composición. Los diagramas de comportamiento representan las características de
comportamiento de un sistema o proceso de negocios y, a su vez, incluyen a los diagramas de:
actividades, casos de uso, maquinas de estados, tiempos, secuencias, repaso de interacciones y
comunicaciones.

Breve descripción sobre los diagramas

En beneficio de quienes quieran seguir investigando dentro del mundo UML, en el siguiente cuadro se
muestra la importancia que tiene, para un desarrollador, conocer cada una de las nuevas
características del UML 2.0. Sobre esta premisa, ampliaremos la explicación de cada diagrama en las
próximas ediciones, dando más importancia a los diagramas que figuran con mayor prioridad en el
cuadro.

Diagrama Descripción Prioridad

Diagrama de Clases Muestra una colección de elementos de modelado declarativo Alta
(estáticos), tales como clases, tipos y sus contenidos y
relaciones.
Diagrama de Representa los componentes que componen una aplicación, Media
Componentes sistema o empresa. Los componentes, sus relaciones,
interacciones y sus interfaces públicas.
Diagrama de Estructura Representa la estructura interna de un clasificador (tal como Baja
de Composición una clase, un componente o un caso de uso), incluyendo los
puntos de interacción de clasificador con otras partes del
sistema.
Diagrama de Despliegue Un diagrama de despliegue físico muestra cómo y dónde se Media
Físico desplegará el sistema. Las máquinas físicas y los procesadores
se representan como nodos y la construcción interna puede
ser representada por nodos o artefactos embebidos. Como los
artefactos se ubican en los nodos para modelar el despliegue
del sistema, la ubicación es guiada por el uso de las
especificaciones de despliegue.
Diagrama de Objetos Un diagrama que presenta los objetos y sus relaciones en un Baja
punto del tiempo. Un diagrama de objetos se puede considerar
como un caso especial de un diagrama de clases o un
diagrama de comunicaciones.
Diagrama de Paquetes Un diagrama que presenta cómo se organizan los elementos Baja
de modelado en paquetes y las dependencias entre ellos,
incluyendo importaciones y extensiones de paquetes.
Diagrama de Actividades Representa los procesos de negocios de alto nivel, incluidos el Alta
flujo de datos. También puede utilizarse para modelar lógica
compleja y/o paralela dentro de un sistema.
Diagrama de Es un diagrama que enfoca la interacción entre líneas de vida, Baja
Comunicaciones donde es central la arquitectura de la estructura interna y
(anteriormente: cómo ella se corresponde con el pasaje de mensajes. La
Diagrama de secuencia de los mensajes se da a través de un esquema de
colaboraciones) numerado de la secuencia.
Diagrama de Revisión de Los Diagramas de Revisión de la Interacción enfocan la Baja
la Interacción revisión del flujo de control, donde los nodos son Interacciones
u Ocurrencias de Interacciones. Las Líneas de Vida los
Mensajes no aparecen en este nivel de revisión
Diagrama de Secuencias Un diagrama que representa una interacción, poniendo el foco Alta
en la secuencia de los mensajes que se intercambian, junto
con sus correspondientes ocurrencias de eventos en las Líneas
de Vida.
Diagrama de Máquinas Un diagrama de Máquina de Estados ilustra cómo un Media
de Estado elemento, muchas veces una clase, se puede mover entre
estados que clasifican su comportamiento, de acuerdo con
disparadores de transiciones, guardias de restricciones y otros
aspectos de los diagramas de Máquinas de Estados, que
representan y explican el movimiento y el comportamiento.
Diagrama de Tiempos El propósito primario del diagrama de tiempos es mostrar los Baja
cambios en el estado o la condición de una línea de vida
(representando una Instancia de un Clasificador o un Rol de
un clasificador) a lo largo del tiempo lineal. El uso más común
es mostrar el cambio de estado de un objeto a lo largo del
tiempo, en respuesta a los eventos o estímulos aceptados. Los
eventos que se reciben se anotan, a medida que muestran
cuándo se desea mostrar el evento que causa el cambio en la
condición o en el estado.
Diagrama de Casos de Un diagrama que muestra las relaciones entre los actores y el Media
Uso sujeto (sistema), y los casos de uso.

Conclusión
A lo largo del artículo hemos analizado los objetivos y el impacto de éstos en la versión 2.0 del UML.
Analizamos la estructura del UML 2.0, su conformación interna y la división taxonómica de sus
diagramas.

¿Cómo sigo?
Recomendamos leer el siguiente artículo, el cual es la continuación del presente: El Poder Semántico
del UML 2.0 en la Práctica donde se muestran los cambios más importantes en el Lenguaje
Unificado de Modelado, desde el punto de vista del desarrollador, mediante ejemplos.

Bibliografía
Libros recomendados: Hemos revisado varios libros dedicados a la superestructura del UML 2.0.
Entre ellos el que parece ser más destacable es: UML 2.0 in a Nutshell.

•“UML 2.0 in a Nutshell ” de Dan Pilone y Neil Pitman

Excelente referencia para el trabajo diario. La introducción teórica es un poco superficial, debido a que
el foco del libro es la superestructura. El libro puede ser útil tanto a expertos UML como para quienes
recién se inician.
 •“UML 2 for Dummies” de Michael J. Chonoles y James A. Schardt

Libro de muy fácil lectura con una introducción teórica adecuada. El tratamiento de los temas podría
ser un poco más amplio, ya que el libro apunta a personas sin conocimiento del UML.

•“Fast Track UML 2.0” de Kendall Scott y Apress

Libro totalmente orientado a la superestructura. La introducción conceptual teórica a los nuevos

aspectos del UML 2.0 es bastante superficial y carece de un hilo conductor en cuanto a la organización
de los temas. A pesar de esto, los distintos diagramas están bien explicados

Otros libros recomendados de Orientación a Objetos: Para quien quiera una excelente
introducción teórica al mundo del diseño orientado objetos, dejamos estas recomendaciones:

•"Designing Object-Oriented? Software" de Rebecca Wirfs-Brock?, Brian Wilkerson y Lauren

Wiener

Si le preguntan a alguien que trabaje con objetos sobre un libro de diseño orientado a objetos,
seguramente les recomiende este libro

•"Smalltalk Objects, and Design (Paperback)" de Chamond Liu

Otro excelente libro de diseño OO. Un poco más orientado a Smalltalk, pero conceptualmente
completo.

•“Object-oriented Systems Analysis and Design Using UML” de Simon Bennett, Steve McRobb? y
Ray Farmer.

Un libro que combina teoría de objetos y UML, con un enfoque un poco más práctico.

Herramientas A continuación, nombramos algunas herramientas que soportan UML 2.0. Dado que no
todas tienen el mismo nivel de conformidad, el nivel más alto a la fecha lo tiene Enterprise Architect.

Enterprise Architect http://www.sparxsystems.com/

Altova UModel 2005 http://www.altova.com/umodel/
Together http://www.borland.com/together/designerce/index.html
Rational Software Architect http://www-306.ibm.com/software/rational/
Embarcadero Describe http://www.embarcadero.

El Poder Semántico del UML 2.0 en la Práctica

El Poder Semántico del UML 2.0 en la Práctica
¿Cómo sacar provecho de las nuevas características de UML 2.0?
Por: Quirón en: Vie 17 of Feb, 2006 [16:07] (37139 lecturas)
Donde daremos una reseña con los cambios fundamentales en el Lenguaje Unificado de
Modelado desde el punto de vista del desarrollador promedio.

(20758 bytes)
Tabla de Contenidos

•Introducción
•Nuevas características de los diagramas UML 2.0
oLa Superestructura de UML 2.0
•Cambios estructurales
oDiagramas de Composición de Estructuras (Nuevo Diagrama)
Diseñando la Estructura Interna de “Mi PC” Mediante un Diagrama de
Clases
 •Cambios Particulares en los Diagramas Estructurales
oDiagrama de Clases
oDiagramas de Despliegue
Artefactos (Artifacts)
Especificaciones de Despliegue (Deployment Specifications)
oDiagramas de Componentes (Components Diagram)
•Cambios en los Diagramas de Comportamiento
oDiagramas de Caso de Uso
Estructuras Compuestas
Extensiones
oLos Diagramas de Actividades
oDiagramas de Máquina de Estados
•Diagramas de Interacción
oLos Diagramas de secuencias
Fragmentos Combinados
oOperadores de Interacción (Interaction Operators)
oDiagramas de Revisión de interacciones (Nuevo Diagrama)
oDiagramas de Comunicación (Ex diagramas de colaboración)
oDiagrama de Tiempos (Nuevo Diagrama)
•Lo que quedó afuera
•Conclusión

Introducción
En esta entrega nos concentraremos en detallar las nuevas características de los diagramas de mayor
importancia, dentro de UML 2.0, para el desarrollador común. Haremos fuerte hincapié en los
diagramas estructurales, en especial los diagramas de clases, y describiremos someramente los
diagramas de actividades y de secuencia. Se recomienda primero, a modo de introducción, leer el
artículo Introducción a lo nuevo de UML 2.0

Nuevas características de los diagramas

UML 2.0
Haremos mayor hincapié en aquellos diagramas que figuran como "de mayor prioridad", enumerando
de manera somera los cambios en los diagramas de menor prioridad.

La Superestructura de UML 2.0

La superestructura del UML es la definición formal de los elementos que componen el UML 2.0. Éste se
encuentra organizado en paquetes, que definen los elementos internos del UML y de qué manera se
relacionan. La figura 1 muestra esta estructura.
Figura 1: Organización Interna de la Superestructura

Cambios estructurales
Como puede observarse, el diseño interno del UML 2.0 se encuentra orientado a objetos. Para
entender qué significado tiene esta idea, podemos hacernos preguntas tales como: ¿Qué tienen en
común los diagramas de clases, las colaboraciones, los componentes y los paquetes? Algunas de las
características en común que podemos encontrar son: todos tienen “elementos” (por llamarlos de
algún modo), que se asocian los unos a los otros mediante “relaciones”; el significado de las mismas
puede depender del diagrama. Esta es una buena aproximación. Ahora, si lo pensamos un poco más,
todos estos “elementos” pueden tener propiedades, estereotipos, restricciones, tagged values, etc. Si
tuviéramos que modelar esto, mediante un diagrama de clases, es dado a pensar que éste se vería
como indica la Figura 2. Y, efectivamente, es así como se ve internamente en la superestructura de
UML 2.0; sólo que, los “elementos”, se llaman en realidad Clasificadores. Esto quiere decir que, si
tenemos una Clase llamada -por ejemplo- Astronauta, ésta es una instancia de un clasificador (en
este caso, el clasificador clase), y no es la clase particular Astronauta un Clasificador.

Basicamente un Clasificador es a una Clase, lo que una Clase es a un Objeto.

Los clasificadores tienen otras características muy interesantes, útiles a los objetivos del UML 2.0.
Veamos
Diagramas de Composición de Estructuras (Nuevo
Diagrama)
Los diagramas de composición de estructuras (Composite Structures Diagram) fueron específicamente
diseñados para la representación de patrones de diseño, y son una de las modificaciones de mayor
impacto dentro de UML 2.0. Esta modificación al UML hace que ahora todos los Clasificadores puedan
tener una estructura compuesta. Mediante una composición de estructuras, el comportamiento de las
instancias de otros Clasificadores contenidos (estructura interna) en un Clasificador determinado,
puede especificarse como Colaboraciones. Los conceptos principales para describir la estructura
interna son: Partes, Puertos y Conectores.

Diseñando la Estructura Interna de “Mi PC” Mediante un Diagrama de

Clases
Para describir cada uno de estos nuevos elementos tomaremos un ejemplo: Supongamos que
deseamos modelar el concepto “PC simplificada”. Esta PC consta sólamente de teclado y monitor;
también sabemos que, internamente, una PC cuenta con una placa de video, la cual se encarga de
enviar información al exterior a través de la interfaz de video. En la figura 3 mostramos el diseño,
utilizando la nueva notación de UML 2.0. La misma incluye los siguientes nuevos artefactos:

•Partes (parts): Una parte es una propiedad contenida en un clasificador. Una parte vive y muere
siguiendo el mismo ciclo de vida que el objeto que lo contiene. En nuestro ejemplo, la placa
de Video es parte de la PC. Hay que tener en cuenta que esto implica que la placa de video no
puede cambiarse, debido a que respeta el mismo ciclo de vida que la PC.
•Puertos (ports): Un puerto describe un punto de interacción para un clasificador. Los puertos
son conocidos, esto significa que se le pueden enviar mensajes. Un puerto puede tener una
interfaz requerida (necesarias para la clase) o una interfaz provista (que brinda la clase). En
nuestro ejemplo tenemos los puertos: inPCPort, outPCPort, outTecladoPort y
InSalidaDeVideoPort?; las interfaces provistas (notadas con un círculo cerrado en el extremo)
InterfazDeEntradaTeclado? e InterfazDeSalidaVideo?, y las interfaces requeridas (notadas con
un semi-círculo abierto): InterfazDeEntradaTeclado? y InterfazDeSalidaVideo?.
•Conectores (Connectors): Los conectores especifican un Enlace (Link) entre Partes, que
representa una instancia de asociación. Este enlace representa la posibilidad de comunicación
entre una o más partes. En nuestro ejemplo la placa de video se comunica con el procesador.

Si bien estas modificaciones afectan a todos los Clasificadores, tienen mayor impacto y utilidad en
Clases, Componentes y Colaboraciones.

Figura 3: Diagramas de clase compuesto para el ejemplo “mi PC”

La nueva notación permite mostrar claramente que la Placa de Video y el Procesador forman parte
de la PC. Esta relación es aún más fuerte que la relación de composición, debido a que una placa de
video no puede ser utilizada por otro objeto. Formalmente hablando, ninguna otra instancia en el
dominio puede tener una asociación con esa instancia de la PlacaDeVideo?.
Los diagramas de composición de estructuras permiten, potencialmente, documentar arquitecturas de
software de manera un poco más clara que en versiones anteriores del UML 2.0.

Cambios Particulares en los Diagramas

Estructurales
Ya hemos enumerado cambios que afectan de manera transversal a varios de los diagramas del UML
2.0. Ahora nos enfocaremos en los cambios particulares de algunos de los diagramas de UML.

Diagrama de Clases
Uno de los cambios que seguramente será muy utilizado es la notación “Lollipop”: Mediante esta
notación, las dependencias de un clasificador a una interfase pueden mostrarse mediante un semi-
círculo abierto, que significa "interfaz requerida". Las interfaces implementadas por un clasificador se
muestran con un círculo, cuyo significado es "interfaz provista". Ejemplos de interfaces requeridas y
provistas pueden verse en la figura 3 de estructuras compuestas. En La figura 4 mostramos un
ejemplo detallando cómo se representaría la notación Lollipop mediante clases e interfaces (a la
manera tradicional).
 Figura 4: Ejemplo de
Interfaz Provista e Interfaz Requerida

Diagramas de Despliegue
Según la especificación de la OMG (UML 2.0 Superestructura, p. 8), se establece que: “es un diagrama
que representa la arquitectura de ejecución de un sistema. Éste, representa los artefactos del sistema
como nodos, los cuales son conectados a través de caminos de comunicación para crear redes de
sistemas de complejidad arbitraria.” Al antiguo diagrama de despliegue, se le agregaron los siguientes
elementos:

Artefactos (Artifacts)
Típicamente los artefactos eran utilizados para representar la versión compilada de un componente; el
UML 2.0 permite representar cualquier elemento empaquetable (por ejemplo un jar). Los artefactos
pueden tener atributos, como se muestra en la figura 5.

Figura 5: Un artefacto con atributos

Especificaciones de Despliegue (Deployment Specifications)
Las especificaciones de despliegue son una colección de propiedades (properties) que especifican
cómo un artefacto será desplegado. A través de éste, pueden especificarse, por ejemplo, el archivo
web.xml, para desplegar una aplicación web en java (cuya correspondencia en .NET sería el archivo
web.config). Este ejemplo se ve en la figura 6.

Figura 6: Un Ejemplo de
Especificación de despliegue.

Diagramas de Componentes (Components Diagram)

Según la especificación de la OMG (UML 2.0 Superestructura, p. 7), se afirma que: "es un diagrama
que muestra la organización y dependencias entre componentes." Las modificaciones más importantes
realizadas al diagrama de componentes son: El cambio en la notación de los componentes. Ahora se
notan como muestra la figura 7: Con un estereotipo, en vez de los dos rectángulos pequeños cruzados

Antigua notación

Nueva notación

Figura 7: Antigua y nueva notación de componentes respectivamente

Otro cambio importante, dentro de los diagramas de componentes, son los conectores de ensamblado
(assembly connectors) que se utilizan para representar las interfaces provistas y requeridas por un
componente. La representación del mismo puede verse en la figura 8.

Figura 8:
Componente con interfaces provistas e Interfaces requeridas
Cambios en los Diagramas de
Comportamiento
Diagramas de Caso de Uso
Según la especificación de la OMG (UML 2.0 Superestructura, p. 17), los diagramas de casos de uso
son diagramas que muestran las relaciones entre actores y el sistema.

Estructuras Compuestas
Ahora que ya conocemos la noción de clasificador, podemos notar que un Caso de Uso puede ser parte
de (estar compuesto en) cualquier clasificador (no solamente packages). Por ejemplo, un caso de uso
puede ser parte de una clase. Ver Figura 9.

Figura 9: Caso de uso como parte de un clasificador.

Extensiones
Las condiciones para una Extensión pueden ser especificadas adjuntando una nota a la relación de
extensión.

Figura 10: Casos de Uso y

puntos de extensión
Los casos de Uso pueden ser representados como clases (notación de clasificador) y se nota con una
elipse en la parte superior derecha (Estereotipo)
 Figura 11: Caso de Uso representado como una Clase con su
estereotipo
También utilizando el concepto de estereotipos (stereotypes), los actores pueden ser representados
mediante distintos íconos, tales como computadoras o relojes.

Los Diagramas de Actividades

Muchos cambios fueron realizados en los diagramas de actividad. Mostraremos solamente los más
importantes, aunque muchos nuevos aspectos quedarán fuera. Los cambios realizados son tendientes
a:

•Dar soporte en la definición de procesos de negocio.

•Brindar una semántica similar al de las redes de petri.
•Permitir una mayor y más flexible representación de paralelismo.

Si va a trabajar con diagramas de actividades, es conveniente repasarlos debido a que los cambios
producidos, tanto semánticos como sintácticos, son muy profundos. En la figura 12 puede verse un
ejemplo de un diagrama de actividades con alguno de los nuevos elementos que lo componen.

Figura 12: Ejemplo Diagrama de Actividades

En el ejemplo podemos ver alguno de los nuevos elementos tales como: entradas, parámetros y
regiones e interrupciones.

Diagramas de Máquina de Estados

Un diagrama de Máquina de Estados ilustra cómo un elemento, muchas veces una clase, se puede
mover entre estados que clasifican su comportamiento, de acuerdo con disparadores de transiciones,
guardias de restricciones y otros aspectos de los diagramas de Máquinas de Estados, que representan
y explican el movimiento y el comportamiento. Al igual que los diagramas de secuencia, las Máquinas
de Estados permiten un mejor rehúso, a través del agregado de Puntos de Entrada y Puntos de Salida
(Entry / Exit Points). Las máquinas de estados son ahora generalizables y soportan una vista centrada
en la transición. Las capacidades de generalización incluyen: agregar estados y transiciones, extender
estados, reemplazar transiciones, reemplazar maquinas compuestas, etc. Lo que permite que, por
ejemplo, dada una clase que hereda de otra, especificar ambas clases mediante máquinas de estados
que heredan funcionalidad.

Diagramas de Interacción
Como dijimos anteriormente, el UML 2.0 se encuentra diseñado de manera Orientada a Objetos,
dentro de la nueva organización interna, y cuenta con los llamados “Diagramas de Interacciones”, que
son una subcategoría de los diagramas de comportamiento. Estos diagramas muestran la interacción
entre distintos clasificadores de un modelo desde distintos puntos de vista, es decir, haciendo foco en
distintos aspectos de la interacción. Esto hace que todos los diagramas de interacción tengan ciertas
características compartidas, como por ejemplo la capacidad de crear Diagramas de descripción de
interacción y la utilización de fragmentos combinados. Dichos conceptos serán descriptos a
continuación utilizando los diagramas de secuencias.

Los Diagramas de secuencias

Las modificaciones de los diagramas de secuencias tienden básicamente a permitir la reutilización de
los diagramas, agregando los elementos de tipos Fragmento Combinado.

Fragmentos Combinados
Un Fragmento combinado describe una interacción reutilizable. En la figura 13 se muestra la sintaxis
de éste, y en la figura 15 mostramos cómo pueden ser reutilizados en un fragmento combinado.

Figura 13: Sintaxis de un Fragmento Combinado

Operadores de Interacción (Interaction Operators)

Los operadores de interacción contienen un cierto número de operandos y un identificador en el
pentágono superior izquierdo del Operador (ver figura 14). Mediante los operadores, pueden definirse:
Alternativas, Opciones, Quiebres de secuencia (breaks), ejecuciones paralelas, ciclos (loops) y varios
más.
 Figura 14: Ejemplos de
Operadores de Interacción loop (ciclo) y alt (alternativa)

Diagramas de Revisión de interacciones (Nuevo

Diagrama)
Es un diagrama que muestra cómo interactúan varios diagramas de interacciones. Este tipo de
diagramas es muy útil para mostrar de qué manera distintos escenarios se combinan. En el ejemplo
de la figura 15, se muestra la interacción de un cliente con un cajero ATM, separado en cuatro
fragmentos:

•Secuencia de login: la cual pedirá un usuario y una clave a un cliente. (la secuencia supone que
la clave y usuario ingresados son válidos).
•Secuencia de seleccionar una operación. Las operaciones permitidas por este cajero son cancelar
o extraer dinero.
•Si cancela, se ejecutará la secuencia de deslogueo del cliente. Luego finalizará la operatoria.

Si seleccionar 'extraer dinero' se ejecutará la secuencia de extracción. Luego finalizará la operatoria.

 Figura 15: Diagramas descripción
de interacción, ejemplo cajero ATM.

Diagramas de Comunicación (Ex diagramas de

colaboración)
Quizás el cambio más profundo en los diagramas de comunicación es que anteriormente tenían el
nombre de “Diagramas de Colaboración”. Por ser las colaboraciones un diagrama de interacción, al
igual que los diagramas de secuencias, heredan la misma capacidad de soportar fragmentos
combinados.

Diagrama de Tiempos (Nuevo Diagrama)

El propósito primario de los diagramas de tiempos (o temporizados) es mostrar los cambios en el
estado, o la condición, de una línea de vida de una instancia (de un Clasificador o un Rol de un
clasificador), a lo largo del tiempo y de manera lineal. El uso más común es mostrar el cambio de
estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Un
diagrama de tiempos se ve tal y como lo muestra la figura 16. No resulta trivial leer un diagrama de
tiempos; si no se lo conoce, puede resultar poco intuitivo.
 Figura 16: Diagrama
de Tiempos

Lo que quedó afuera

Por una cuestión de espacio, varios temas muy interesantes relativos a UML 2.0 quedaron sin abordar.
Entre los temas más destacados encontramos:

•Nuevas características en los diagramas: hay muchas nuevas características en UML 2.0 que
hemos pasado por alto; algunos ejemplos son: templates, restricciones para las relaciones,
varios nuevos elementos en los diagramas de secuencias y máquinas de estados, diagramas
de paquetes, etc.
•MDD (Model Driven Development) y MDA (Model Driven Architecture)
•Perfiles: un tema bastante relevante y que quedó fuera, es el de Perfiles (Profiles), porque
explicarlo debidamente requiere un espacio considerado.
•Diagramas de Arquitectura: analizar cómo realizar Diagramas de Arquitecturas utilizando UML
2.0.
•OCL: la utilización de OCL será sin dudas una de las técnicas de mayor crecimiento dentro de la
Ingeniería de Software. Así como hubo un tiempo en que los casos de uso no eran siquiera
conocidos, y hoy son moneda de uso corriente, con OCL es dado a pensar que pasará algo
similar, debido, en gran parte, al poder de expresividad que brinda sobre los modelos.
•MOF, del inglés: Meta Object Facility. Representa el diseño interno del UML con las estructuras
necesarias para dar soporte a la automatización (MDA y MDD)

Conclusión
En esta entrega hemos analizado los cambios en el UML 2.0 desde un punto de vista bastante amplio,
teniendo en cuenta principalmente aquellos cambios de mayor impacto para el desarrollador
promedio. Sin duda, muchos de los conceptos aquí vistos no podrán faltar en la caja de herramientas
de cualquier desarrollador en el corto plazo. Diagramas de estructura compuesta, así como las
modificaciones en la mayoría de los diagramas de comportamiento, serán de uso común, debido al
gran poder de expresividad que éstos brindan. Sin embargo, sin perder de vista el trabajo cotidiano,
es importante recordar, siempre que hablemos del UML 2.0, las dos premisas que rigen su estructura:
(1) Hacer el lenguaje de modelado mucho más extensible. (2) Permitir la validación y ejecución de
modelos creados mediante el UML.

Ejercicio Puede ser un ejercicio interesante, modelar este mismo ejemplo utilizando la versión
anterior del UML (1.5)y analizando cuáles son sus implicancias.
Recomendaciónes Si piensa trabajar con UML 2.0, nuestra recomendación es capacitarse
adecuadamente sobre el diagrama que está por modelar y utilizar una herramienta que cumpla con el
nivel de conformidad más alto posible; esto le permitirá sacar un mayor provecho del libro.

Nuestros recomendados

•“UML 2.0 in a Nutshell ” de Dan Pilone y Neil Pitman

Excelente referencia para el trabajo diario. La introducción teórica es un poco superficial debido a que
el foco del libro es la superestructura. El libro puede ser útil tanto a expertos UML como para quienes
recién se inician.

•“Enterprise Architect “

La herramienta recomendada.

Temario

1. Tecnología de Objetos
1.1. Diferencia entre Análisis y Diseño
1.2. Análisis y Diseño Orientado a Objetos
1.3. Objetos y Clases
1.4. Práctica Inicial de Análisis y Diseño
2. El ciclo de vida y el plan de trabajo con base en el Proceso Unificado
2.1. El Ciclo de Vida
2.2. Fases e Iteraciones
2.3. Artefactos y UML en el Proceso Unificado
2.4. Responsabilidades (trabajadores)
 2.5. Disciplinas (flujos de trabajo) de ingeniería y de soporte

NOTA: A lo largo del curso los diferentes artefactos se van relacionando con su correspondiente(s)
fase(s) dentro del Proceso Unificado para reafirmar la relación entre UML y el Proceso Unificado.
3. La Importancia del Modelado Visual
4. Antecedentes de UML
5. Modelo de Casos de Uso
5.1. Actores
5.2. Casos de Uso
5.3. Diagrama de Casos de Uso
5.4. Paquetes de Casos de Uso
5.5. Relaciones <<include>> y <<extend>>
5.6. Puntos de extensión
5.7. Paquetes de Casos de Uso
6. Especificación de Casos de Uso (Flujos de Eventos)
6.1. Documentación de un Caso de Uso
6.2. Caso de Uso de Alto Nivel
6.3. Flujos Primarios, Alternos y Excepcionales
6.4. Precondiciones y postcondiciones
6.5. Requerimientos especiales del caso de uso
6.6. Escenarios
6.7. Las Pruebas y los Casos de Uso
7. Modelo Conceptual
7.1. Conceptos
7.2. Atributos
7.3. Relación de Asociación
7.4. Diagrama del Modelo Conceptual
7.5. Identificación de conceptos mediante un análisis de Casos de Uso
8. Diagramas de Secuencia
8.1. Clases y Objetos
8.2. Línea de Vida
8.3. Foco de Control
8.4. Mensajes y Operaciones
8.5. Diagrama de Secuencia
8.6. Diagrama de Colaboración
8.7. Diferencias entre el Diagrama de Colaboración y de Secuencia
8.8. Impacto del Diagrama de Interacción en el Diagrama de Clases
9. Patrones de Asignación de Responsabilidades
9.1. Qué son los patrones
9.2. Patrones para la Asignación de Responsabilidades
9.3. Alta Cohesión y Bajo Acoplamiento
9.4. Diseño en 3 Capas
10. Diagramas de Clases
10.1. Clases
10.2. Atributos
10.3. Operaciones
10.4. Alcance de Atributos y Operaciones
10.5. Relaciones de Asociación, Agregación y Dependencia
10.6. Generalización: la implementación de la herencia
10.7. Visibilidad entre Clases
10.8. Navegabilidad
10.9. Multiplicidad
10.10. Completando el diagrama de clases mediante el diagrama de interacción
10.11. Paquetes de clases
11. Diagramas de Componentes
11.1. Componentes
11.2. Interfases
11.3. La interfase en el diagrama de clases
11.4. La interfase en el diagrama de componentes
11.5. Relación de Realización
11.6. Tipos de Componentes
11.7. Dependencias
12. Diagramas de Distribución
12.1. Nodos
12.2. Asociaciones entre Nodos
12.3. Dispositivos
12.4. Diagrama de Distribución
13. Implementación en el lenguaje seleccionado
13.1. Interpretación del Diagrama de Clases
13.2. Interpretación del Diagrama de Secuencia
13.3. Interpretación del Diagrama de Componentes
14. Generación de Código
14.1. Uso de herramientas CASE para la Generación de Código
14.2. Generación de Código
 14.3. Ingeniería Inversa
14.4. Round Trip Engineering
15. Segundo Caso Práctico
15.1. Segundo Caso Práctico para Repasar los Conceptos Aprendidos en una simulación de proyecto y
donde además se incluyen nuevos artefactos de UML:
15.2. Planeación del caso práctico bajo RUP: Identificación de fases, actividades y planeación de
tiempos
15.3. Entrevista de requerimientos
15.4. Modelado de negocios
15.5. Modelo de casos de uso (a partir de los procesos analizados en el diagrama de actividad)
15.6. Modelo Conceptual
15.7. Diagrama de estados
15.8. Diagrama de interacción
15.9. Diagrama de clases
15.10. Diagrama de componentes
15.11. Diagrama de despliegue
15.12. Codificación
15.13. Generación de código e ingeniería inversa
16. Diagramas de Actividad (Visto dentro del segundo caso práctico para modelar el negocio)
16.1. Actividades
16.2. Transiciones
16.3. Decisiones
16.4. Carriles y responsabilidades dentro del proceso
16.5. Trabajo en paralelo (barras de sincronización)
16.6. Paso de las actividades al modelo de casos de uso
16.7. Modelado de casos de uso con diagramas de actividad
16.8. Modelado de procesos de negocio con diagramas de actividad
17. Diagramas de Estado (Visto dentro del segundo caso práctico)
17.1. Estados
17.2. Transiciones
17.3. Eventos
17.4. Acciones
17.5. Condiciones de guardia
17.6. Superestados
17.7. Historia
17.8. Modelado de análisis y diseño con un diagrama de estados

http://www.osmosislatina.com/lenguajes/uml/basico.htm

Porque es importante UML ?

Hoy en día, UML ("Unified Modeling Language") esta consolidado
como el lenguaje estándar en el análisis y diseño de sistemas de
computo. Mediante UML es posible establecer la serie de
requerimientos y estructuras necesarias para plasmar un sistema de
software previo al proceso intensivo de escribir código.

En otros términos, así como en la construcción de un edificio se

realizan planos previo a su construcción, en Software se deben
realizar diseños en UML previa codificación de un sistema, ahora bien,
aunque UML es un lenguaje, éste posee más características visuales
que programáticas, mismas que facilitan a integrantes de un equipo
multidisciplinario participar e intercomunicarse fácilmente, estos
integrantes siendo los analistas, diseñadores, especialistas de área y
desde luego los programadores.
Complejidad / Objetos
Entre más complejo es el sistema que se desea crear más beneficios
presenta el uso de UML ("Unified Modeling Language"), las razones de
esto son evidentes, sin embargo, existen dos puntos claves : El
primero se debe a que mediante un plano/visión global resulta más
fácil detectar las dependencias y dificultades implícitas del sistema, y
la segunda razón radica en que los cambios en una etapa inicial
(Análisis) resultan más fáciles de realizar que en una etapa final de un
sistema como lo seria la fase intensiva de codificación.

Puesto que UML es empleado en el análisis para sistemas de

mediana-alta complejidad, era de esperarse que su base radica en
otro paradigma empleado en diseños de sistemas de alto nivel que es
la orientación a objetos, por lo que para trabajar en UML puede ser
considerado un pre-requisito tener experiencia en un lenguaje
orientado a objetos.

Hoy en día, entre los lenguajes orientados a objetos más utilizados se

encuentran Java y C#, además de otros más antiguos como C++ y
SmallTalk, aunque el programar en todos estos lenguajes requiere
experiencia previa sobre la sintaxis y bloques específicos, el
paradigma empleado en todos ellos es el mismo : Objetos.

Lo anterior permite que un análisis en UML sea realizado

independiente del lenguaje en el que finalmente sea implementando
el Sistema (Java,C#,C++,SmallTalk), misma característica que
permite a personal no familiarizado en lenguajes de programación
participen en el análisis y diseño de un sistema.

Conceptos / Diagramas
Entre los conceptos fundamentales de orientación a objetos se
encuentran los siguientes :

•Un modelo es una abstracción del problema que se intenta resolver.

•Un dominio es el mundo de donde proviene el problema .

•Un modelo consiste de objetos que interactúan entre sí enviándose

mensajes.
•Cada objeto posee características propias (atributos) y operaciones
que puede realizar (métodos); las valores asignados a un objeto
en determinado momento determinan su estado.

•Una clase es un molde para describir un objeto que agrupa

características (atributos) y comportamientos (métodos).

•Los objetos son instancias de Clases.

A continuación se enumeran los 9 diagramas que forman la base de

UML, y dictan la manera en que es diseñado un sistema :

•Uso-Caso
•De Estado (Statechart)
•Clases
•Actividad
•Objetos
•Componentes
•Secuencia
•Ejecución (Deployment)
•Colaboración

El uso y diseño de estos diagramas es tema del resto de esta guia

para UML.

diagrama Uso-Caso

Definición y Usos
Un diagrama Uso-Caso describe lo que hace un sistema desde el
punto de vista de un observador externo, debido a esto, un diagrama
de este tipo generalmente es de los más sencillos de interpretar en
UML, ya que su razón de ser se concentra en un Que hace el sistema,
a diferencia de otros diagramas UML que intentan dar respuesta a un
Como logra su comportamiento el sistema.

Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado

un escenario en el sistema, esto es, lo que ocurre cuando alguien
interactúa con el sistema: "Acude un mesero a colocar la orden, la
orden es tomada por el cocinero, y posteriormente se abona a la
cuenta del cliente el cargo".
Un Uso-Caso es empleado con más frecuencia en alguna de las
siguientes etapas :

•Determinación de Requerimientos: Por lo general nuevos

requerimientos de sistema generan nuevos usos-casos, conforme
es analizado y diseñado el sistema.

•Comunicación con el Cliente: Debido a la sencillez de este tipo de

diagramas, son fáciles de emplear para comunicarse con el cliente
final del proyecto.

•Generación de pruebas de Sistemas: A través de los diagramas uso-

caso se pueden generar una serie de pruebas de sistema.

En la siguiente sección se describen los diversos elementos que

componen un diagrama Uso-Caso.

Composición
•Actor: Un actor representa quien o que inicia una acción dentro del
sistema, en otras palabras, es simplemente un rol que es llevado
acabo por una persona o cosa. Un Actor en un diagrama Uso-Caso
es representado por una figura en forma de persona.

•Uso-Caso: El uso-caso en sí es representado por un ovalo que

describe la funcionalidad a grosso modo que se requiere por el
sistema.

•Comunicación: Este elemento representa la relación que existe

entre un Uso-Caso y un Actor, dicho elemento es representado
simplemente por una linea recta que se extiende de la figura del
actor hacia el ovalo del uso-caso.

•Limite de Sistema (System Boundry): Empleado para delimitar

los limites del sistema, y representado por un rectángulo con color
de fondo distintivo.

•Generalización : Una generalización indica que un uso-caso (ovalo)

es un caso especial de otro caso, en otros términos, representa
una relación padre-hijo, donde el hijo puede ser suplido
directamente por el padre en cualquier momento. Este elemento es
 representado por una linea con flecha que se extiende del uso-caso
hijo hacia el uso caso padre (general).

•Inclusión : Una inclusión es utilizada para indicar que un uso-caso

(ovalo) depende de otro caso, dicho de otra manera, significa que
la funcionalidad de determinado caso se requiere para realizar las
tareas de otro. Este elemento es representado por una linea
punteada con flecha y comentario <<include>> que se extiende del
uso-caso base hacia el uso caso de inclusión.

•Extensión : Una extensión representa una variación de un uso-caso

a otro, aunque similar a una generalización, una extensión
representa una dependencia especifica, mientras una
generalización no implica que los usos-casos dependen uno del
otro. Este elemento es representado por una linea punteada con
flecha y comentario <<extend>> que origina del uso-caso base hacia
el uso caso de extensión.

Ilustración

diagrama de Actividad
Definición y Usos
Un diagrama de Actividad demuestra la serie de actividades que
deben ser realizadas en un uso-caso, así como las distintas rutas que
pueden irse desencadenando en el uso-caso.

Es importante recalcar que aunque un diagrama de actividad es muy

similar en definición a un diagrama de flujo (tipicamente asociado en
el diseño de Software), estos no son lo mismo. Un diagrama de
actividad es utilizado en conjunción de un diagrama uso-caso para
auxiliar a los miembros del equipo de desarrollo a entender como es
utilizado el sistema y como reacciona en determinados eventos.Lo
anterior, en contraste con un diagrama de flujo que ayuda a un
programador a desarrollar codigo a través de una descripción lógica
de un proceso. Se pudiera considerar que un diagrama de actividad
describe el problema, mientras un diagrama de flujo describe la
solución.

En la siguiente sección se describen los diversos elementos que

componen un diagrama de Actividad.

Composición
•Inicio: El inicio de un diagrama de actividad es representado por un
círculo de color negro sólido.

•Actividad : Una actividad representa la acción que será realizada

por el sistema la cual es representada dentro de un ovalo.

•Transición: Una transición ocurre cuando se lleva acabo el cambio

de una actividad a otra, la transición es representada simplemente
por una linea con una flecha en su terminación para indicar
dirección.

•Ramificación (Branch) : Una ramificación ocurre cuando existe la

posiblidad que ocurra más de una transición (resultado) al
terminar determinada actividad.Este elemento es representado a
través de un rombo.
•Unión (Merge) : Una unión ocurre al fusionar dos o más
transiciones en una sola transición o actividad.Este elemento
también es representado a través de un rombo.

•Expresiones Resguardadas (Guard Expressions) : Una expresió

resguardada es utilizada para indicar una descripción explicita
acerca de una transición. Este tipo de expresión es reprsentada
mediante corchetes ([...] y es colocada sobre la linea de
transición.

•Fork : Un fork representa una necesidad de ramificar una transición

en más de una posibilidad. Aunque similar a una ramificación
(Branch) la diferencia radica en que un fork representa más de una
ramificación obligada, esto es, la actividad debe proceder por
ambos o más caminos, mientras que una ramificación (Branch)
representa una transición u otra para la actividad (como una
condicional). Un fork es representado por una linea negra solida,
perpendicualar a las lineas de transición .

•Join : Una join ocurre al fusionar dos o más transiciones

provenientes de un fork, y es empleado para dichas transiciones en
una sola,tal y como ocurria antes de un fork .Un fork es
representado por una linea negra solida, perpendicualar a las
lineas de transición .

•Fin : El fin de un diagrama de actividad es representado por un

círculo, con otro circulo concentrico de color negro sólido.

•Canales (Swimlanes) : En determinadas ocasiones ocurre que un

diagrama de actividad se expanda a lo largo de más de un
entidad o actor, cuando esto ocurre el diagrama de actividad es
particionada en canales (swimlines), donde cada canal
representa la entidad o actor que esta llevando acabo la
actividad.

Diagramas de Clases : Definición y Usos

Un diagrama de Clases representa las clases que serán utilizadas
dentro del sistema y las relaciones que existen entre ellas.
Los diagramas de Clases por definición son estáticos, esto es,
representan que partes interactúan entre sí, no lo que ocurre cuando.

Ilustración
http://docs.kde.org/stable/es/kdesdk/umbrello/index.html

Manual de Umbrello UML Modeller

Umbrello UML Modeller Autores

Traductor: Marcos Fouces Lago

revisión 1.2 (2003-10-15)
Copyright © 2001 Paul Hensgen
Copyright © 2002, 2003 Umbrello UML Modeller Autores

Umbrello UML Modeller ayuda en el proceso de desarrollo de software usando el

estándar 'Unified Modelling Language' (UML) que le permitirá crear diagramas para
diseñar y documentar sus sistemas.

Tabla de contenidos

1. Introducción
2. Introducción a UML
Acerca de UML
Elementos de UML
Diagrama de casos de uso
Diagrama de clases
Diagramas de secuencia
Diagramas de colaboración
Diagrama de estado
Diagrama de actividad
Elementos de ayuda
Diagramas de componentes
Diagramas de implementación
Diagramas de relación de entidad
3. Trabajando con Umbrello UML Modeller
Interfaz de usuario
Título
Ventana de documentación
Área de trabajo
Crear, cargar y guardar proyectos
Nuevo proyecto
Guardar modelo
Cargar modelo
Editar modelo
Añadir y eliminar diagramas
Crear diagramas
Eliminar diagramas
Renombrar diagramas
Editar diagramas
Insertar diagramas
Borrar elementos
Editar elementos
Editar clases
 Asociaciones
Notas, textos y cajas
4. Importación y generación de código
Generación de código
Generación de código
Importación de código
5. Otras características
Otras características de Umbrello UML Modeller
Copia de objetos como imágenes PNG
Exportar como imagen
Impresión
Carpetas lógicas
6. Autores e historia
7. Copyright

Capítulo 1. Introducción
Umbrello UML Modeller es una herramienta de diagramas ¨ que ayuda en el proceso del
desarrollo de software. Umbrello UML Modeller le facilitará la creación de un producto de
alta calidad, especialmente durante fases de análisis y diseño del proyecto. UML también
puede usarse para documentar sus diseños de software para ayudarle a usted y al resto de
desarrolladores.

Tener una buena maqueta del software es la mejor forma de comunicarse con otros
desarrolladores que participen en el proyecto, así como con sus clientes. Una buena
maqueta de extremadamente importante para los proyectos de mediano o gran tamaño, pero
también resulta útil para los más pequeños. Aunque trabaje en un pequeño proyecto
personal, podrá beneficiarse de una buena maqueta porque esta le proporcionará una visión
global que le ayudará en la creación de un mejor código.

UML es el lenguaje de diagramas que se utiliza para la descripción de tales maquetas. Es

posible representar las ideas en UML utilizando diversos tipos de diagramas. Umbrello
UML Modeller 1.2 soporta los siguientes tipos:

•Diagrama de clase
•Diagrama de secuencia
•Diagrama de colaboración
•Diagrama de caso de uso
•Diagrama de estado
•Diagrama de actividad
•Diagrama de colaboración
•Diagrama de secuencia

Puede encontrar más información sobre UML en la página web de OMG,

http://www.omg.org. quien creó el estándar UML.

Esperamos que disfrute de Umbrello UML Modeller y que este le sirva en la creación de
software de gran calidad. Umbrello UML Modeller es una herramienta libre, y lo único que
le pedimos es que informe a los desarrolladores de Umbrello UML Modeller de fallos,
problemas o sugerencias en la dirección de correo electrónico (uml-devel AT
lists.sourceforge.net).

Capítulo 2. Introducción a UML

Tabla de contenidos

Acerca de UML
Elementos de UML
Diagrama de casos de uso
Diagrama de clases
Diagramas de secuencia
Diagramas de colaboración
Diagrama de estado
Diagrama de actividad
Elementos de ayuda
Diagramas de componentes
Diagramas de implementación
Diagramas de relación de entidad

Acerca de UML
Este capítulo proporciona una introducción rápida a las características básicas de UML.
Tenga en cuenta que no se trata de un manual de referencia de UML sino de una breve
introducción. Si desea más información sobre UML, o sobre el análisis y diseño del
software en general, le recomendamos que lea cualquier de los libros publicados sobre el
tema. También hay una buena cantidad de tutoriales en Internet, que puede utilizar como
punto de partida.

El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar y

documentar esquemas de sistemas de software orientado a objetos. UML no es un método
de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o
cómo diseñar el sistema, sino que símplemente le ayuda a visualizar el diseño y a hacerlo
más accesible para otros. UML está controlado por el grupo de administración de objetos
(OMG) y es el estándar de descripción de esquemas de software.

UML está diseñado para su uso con software orientado a objetos, y tiene un uso limitado en
otro tipo de cuestiones de programación.

UML se compone de muchos elementos de esquematización que representan las diferentes

partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que
representa alguna parte o punto de vista del sistema. Umbrello UML Modeller soporta los
siguientes tipos de diagramas:

•Diagrama de casos de uso que muestra a los actores (otros usuarios del sistema), los
casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus
relaciones.
•Diagrama de clases que muestra las clases y la relaciones entre ellas.
•Diagrama de secuencia muestra los objetos y sus múltiples relaciones entre ellos.
•Diagrama de colaboración que muestra objetos y sus relaciones, destacando los
objetos que participan en el intercambio de mensajes.
•Diagrama de estado muestra estados, cambios de estado y eventos en un objeto o en
parte del sistema.
•Diagrama de actividad que muestra actividades, así como los cambios de una a otra
actividad junto con los eventos que ocurren en ciertas partes del sistema.
•Diagrama de componentes que muestra los componentes de mayor nivel de la
programación (cosas como Kparts o Java Beans).
•Diagrama de implementación que muestra las instancias de los componentes y sus
relaciones.
 •Diagrama de relaciones de entidad que muestra los datos y las relaciones y
restricciones entre ellos.

Elementos de UML
Diagrama de casos de uso

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo
de casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no están pensados para representar
el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos
de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el
cliente, y resultan especialmente útiles para determinar las características necesarias que
tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que
debe hacer el sistema, pero no cómo.

Umbrello UML Modeller mostrar un diagrama de casos de uso

Caso de uso

Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de

actividades de un sistema que produce un resultado concreto y tangible.

Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un
sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué
requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas:

•Cada caso de uso está relacionado como mínimo con un actor.

•Cada caso de uso es un iniciador (es decir, un actor)
•Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)

Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de
relaciones más comunes entre casos de uso son:

•<<include>> que especifica una situación en la que un caso de uso tiene lugar dentro
de otro caso de uso
•<<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado
punto de extensión) un caso de uso será extendido por otro.
•Generalización que especifica que un caso de uso hereda las características del
«super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma
muy similar a las herencias entre clases.

Actor

Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema
participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente
real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.

Los actores no representan a personas físicas o a sistemas, sino su papel. Esto significa que
cuando una persona interacciones con el sistema de diferentes maneras (asumiendo
diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que
proporciona servicios de atención al cliente telefónicamente y realiza pedidos para los
clientes estaría representada por un actor «equipo de soporte» y por otro actor
«representante de ventas».

Descripción de casos de uso

Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente
tienen el formato de una nota o un documento relacionado de alguna manera con el caso de
uso, y explica los procesos o actividades que tienen lugar en el caso de uso.

Diagrama de clases

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se
relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos»
porque muestran las clases, junto con sus métodos y atributos, así como las relaciones
estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de
otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.
Umbrello UML Modeller mostrando un diagrama de clases

Clase

Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de
esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de
atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en
lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un
significado más general.

En ¨, las clases están representadas por rectángulos, con el nombre de la clase, y también
pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro
del rectángulo.

Representación visual de una clase en UML

Atributos

En UML, los atributos se muestran al menos con su nombre, y también pueden mostrar su
tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados
visualmente:
 •+ Indica atributos públicos
•# Indica atributos protegidos
•- Indica atributos privados

Operaciones

La operaciones (métodos) también se muestan al menos con su nombre, y pueden mostrar

sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden
mostrar visualmente:

•+ Indica operaciones públicas

•# Indica operaciones protegidas
•- Indica operaciones privadas

Plantillas

Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo.
El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un
objeto). Las plantillas existen en C++ y se introducirán en Java 1.5 con el nombre de
Genéricos.

Asociaciones de clases

Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras:

Generalización

La herencia es uno de los conceptos fundamentales de la programación orientada a objetos,

en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es
heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y
operaciones propias.

En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía
que representa el concepto de herencia de una clase derivada de la clase base. En UML, las
generalizaciones se representan por medio de una línea que conecta las dos clases, con una
flecha en el lado de la clase base.

Representación visual de una generalización en UML

Asociaciones

Una asociación representa una relación entre clases, y aporta la semántica común y la
estructura de muchos tipos de «conexiones» entre objetos.
Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí.
Describe la conexión entre diferentes clases (la conexión entre los objetos reales se
denomina conexión de objetos o enlace).

Las asociaciones pueden tener una papel que especifica el propósito de la asociación y
pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en
la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que
recibe información del otro). Cada extremo de la asociación también tiene un valor de
multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados
con un objeto del extremo contrario.

En UML, las asociaciones se representan por medio de líneas que conectan las clases
participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada
uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores
no negativos, con un asterisco (*) representando el infinito en el lado máximo.

Representación visual de una asociación en UML

Acumulación

Las acumulaciones son tipos especiales de asociaciones en las que las dos clases
participantes no tienen un estado igual, pero constituyen una relación «completa». Una
acumulación describe cómo se compone la clase que asume el rol completo de otras clases
que se encargan de las partes. En las acumulaciones, la clase que actúa como completa,
tiene una multiplicidad de uno.

En UML, las acumulaciones están representadas por una asociación que muestra un rombo
en uno de los lados de la clase completa.

Representación visual de una relación de acumulación en UML

Composición

Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto
significa que las composiciones también forman relaciones completas, pero dichas
relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente
existen como parte del conjunto, y si este es destruido las partes también lo son.

En UML, las composiciones están representadas por un rombo sólido al lado del conjunto.
Otros cmopnentes de los diagrama de clases

Los diagramas de clases pueden contener más componentes aparte de clases.

Interfaces

Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas
directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases
pueden heredarse de las interfaces pudiendo así realizarse instancias a partir de estos
diagramas.

Tipo de datos

Los tipo de datos son primitivas incluidas en algunos lenguajes de programación. Algunos
ejemplos son: bool y float. No pueden tener relación con clases, pero las clases sí pueden
relacionarse con ellos.

Enumeraciones

Las enumeraciones son simples listas de valores. Un ejemplo típico de esto sería una
enumeración de los días de la semana. Al igual que los tipos de datos, no pueden
relacionarse con las clases, pero las clases sí pueden hacerlo con ellos.

Paquetes

Los paquetes, en lenguajes de programación, representan un espacio de nombres en un

diagrama se emplean para representar partes del sistema que contienen más de una clase,
incluso cientos de ellas.

Diagramas de secuencia

Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que
se invocan) en un momento dado. Los diagramas de secuencia ponen especial énfasis en el
orden y el momento en que se envían los mensajes a los objetos.

En los diagramas de secuencia, los objetos están representados por líneas intermitentes
verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es
vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto
a otro en forma de flechas con los nombres de la operación y los parámetros.
Umbrello UML Modeller mostrando un diagrama de secuencia

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se
pasa el control a objeto llamado hasta que el método finalize, o asíncronos donde se
devuelve el control directamente al objeto que realiza la llamada. Los mensajes síncronos
tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control
del programa.

Diagramas de colaboración

Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que
participan en una situación determinada. Esta es más o menos la misma información que la
mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones
se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las
relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan

mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del
mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo
programa específicos y son unos de los mejores tipos de diagramas para demostrar o
explicar rápidamente un proceso dentro de la lógica del programa.
Umbrello UML Modeller mostrando un diagrama de colaboración

Diagrama de estado

Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los
estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos
que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través
de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer
puede tener durante su vida uno de los siguientes estados:

•Listo
•Escuchando
•Trabajando
•Detenido

y los eventos que pueden producir que el objeto cambie de estado son

•Se crea el objeto

•El objeto recibe un mensaje de escucha
•Un cliente solicita una conexión a través de la red
•Un cliente finaliza una solicitud
•La solicitud se ejecuta y ser termina
•El objeto recibe un mensaje de detención
•etc
Umbrello UML Modeller mostrando un diagrama de estado

Estado

Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente
una clase y representa un resumen de los valores y atributos que puede tener la clase. Un
estado UML describe el estado interno de un objeto de una clase particular

Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar
representados por estados, sino únicamente aquellos cambios que pueden afectar
significativamente a la forma de funcionamiento del objeto

Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay
ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no
hay ningún evento que pueda sacar a un objeto de su estado de fin.

Diagrama de actividad

Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los

diagramas de actividad son una forma especial de los diagramas de estado, que únicamente
(o mayormente) contienen actividades.
Umbrello UML Modeller mostrando un diagrama de actividad

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la
diferencia de que todas las actividades están claramente unidas a objetos.

Los diagramas de actividad siempre están asociados a una clase, a una operación o a un
caso de uso.

Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La

ejecución paralela se representa por medio de iconos de fork/espera, y en el caso de las
actividades paralelas, no importa en qué orden sean invocadas (pueden ser ejecutadas
simultáneamente o una detrás de otra).

Actividad

Una actividad es un único paso de un proceso. Una activa es un estado del sistema que
actividad interna y, al menos, una transición saliente. Las actividades también pueden tener
más de una transición saliente, si tienen diferentes condiciones.

Las actividades pueden formar jerarquías, lo que significa que una actividad puede estar
formada de varias actividades «de detalle», en cuyo caso las transiciones entrantes y
salientes deberían coincidir con las del diagrama de detalle.

Elementos de ayuda
Existen unos pocos elementos en UML que no tiene un valor semántico real en la maqueta,
pero que ayudan a clarificar partes del programa. Estos elementos son

•Línea de texto
•Notas de texto y enlaces
•Cajas

Las líneas de texto son útiles para añadir información textual a un diagrama. Es texto es
libre y no tiene ningún significado para la maqueta.

Las notas son útiles para añadir información más detallada de un objeto o una situación
específica. Tienen la gran ventaja de que se pueden anclar a los elementos UML para
mostrar que una nota «pertenece» a un objeto o situación específicos

Las cajas son rectángulos repartidos libremente que pueden usarse para juntar objetos
haciendo los diagramas más legibles. No tienen significado lógico en la maqueta

Diagramas de componentes

Los diagramas de componentes muestran los componentes del software (ya sea las
tecnologías que lo forman como Kparts, componentes CORBA, Java Beans o simplemente
secciones del sistema claramente distintas) y los artilugios de que está compuesto como los
archivos de código fuente, las librerías o las tablas de una base de datos.

Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que
permiten asociaciones entre componentes.

Diagramas de implementación

Los diagramas de implementación muestran las instancias existentes al ejecutarse así como
sus relaciones. También se representan los nodos que identifican recursos físicos,
típicamente un ordenador así como interfaces y objetos (instancias de las clases).

Diagramas de relación de entidad

Los diagramas de relaciones de entidad (diagramas ER) muestran el diseño conceptual de

las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema
de información y las relaciones y restricciones existentes entre ellas. Una extensión de los
diagramas de relaciones de entidad llamado «diagramas de relaciones de entidad
extendida» o «diagramas de relaciones de entidad mejoradas» (EER), se utiliza para
incorporar las técnicas de diseño orientadas a objetos en los diagramas ER.
Umbrello mostrando un diagrama de relaciones de entidad

Entidad

Una Entidad es cualquier concepto del mundo real con una existencia independiente. Puede
ser un objeto con una existencia física (ejemplo, máquina, robot) o puede ser un objeto con
una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de
atributos que describen las propiedades de la entidad.

Nota: No existen notaciones estándar para representar los diagramas ER. Los diferentes
textos sobre este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los
diagramas EER utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe
S. (2004). Fundamentals of Database Systems 4ª ed. Addison Wesley (Fundamentos de los
sistemas de bases de datos)

En un diagrama ER, las entidades se representan como rectángulos, con el nombre de la

clase, y también pueden mostrar atributos y operaciones de la clase en otros dos
«compartimentos» dentro del rectángulo.

Representación visual de una entidad en un diagrama ER

Atributos de la entidad

En los diagramas ER, los atributos de la entidad se muestra con su nombre en un

compartimento diferente de la entidad a la que pertenecen.

Restricciones

Las restricciones en los diagramas ER especifican las restricciones de los datos en el

esquema de información.

Existen cuatro tipos de restricciones soportadas por Umbrello:

•Clave primaria: El conjunto de atributos declarados como clave primaria es única para
la entidad. Solo puede haber una clave primaria en una entidad y ninguno de los
atributos que la componen puede ser NULL.
•Clave única: El conjunto de atributos declarados como única son únicos para la
entidad. Pueden haber muchas restricciones únicas en una entidad. Los atributos que
lo componen pueden tener el valor NULL. Las claves únicas y primarias identifican
de forma única una fila de una tabla (entidad)
•Clave externa: Una clave externa es una restricción referencia entre dos tablas. La
clave externa identifica una columna o un conjunto de columnas en un tabla
(referenciada) que referencia una columna o conjunto de columnas en otra tabla
(referenciada). Las columnas en la tabla referenciada deben formar una clave
primaria o una clave única.
•Restricción de comprobación: Una restricción de comprobación (también conocida
como restricción de comprobación de tabla) es una condición que define los datos
válidos cuando se añaden o actualizan datos en una tabla de la base de datos
relacional. Se aplicará una restricción a cada fila de la tabla. La restricción debe ser
un predicado. Puede referirse a una o varias columnas de la tabla.

Ejemplo: precio >= 0

Conceptos del diagrama de relaciones de entidades extendido (EER)

Especialización

La especialización es una manera de formar nuevas entidades utilizando entidades que ya

se hayan definido. Las entidades nuevas, conocidas como entidades derivadas, asumir (o
heredar) atributos de las entidades que ya existían, y que se refieren a las entidades base. Se
pretende ayudar a reutilizar datos con pequeñas o ninguna modificaciones.

En Umbrello, se puede especificar la especialización de separación y de solapamiento

La especialización de separación

La especialización de separación especifica que las subclases de la especialización se

pueden separar. Esto significa que una entidad puede ser miembro de más de una de las
entidades derivadas de la especialización
Representación visual de una especialización de separación en un diagrama EER

Especialización de solapamiento

Cuando las entidades derivadas no tienen restricciones para separarse, el conjunto de

entidades se dice que están en una especialización de solapamiento. Ésto significa que al
igual que en el mundo real la entidad puede ser miembro de más de una entidad entidad
derivada de la especialización

Representación visual de la especialización de solapamiento en un diagrama EER

Categoría
Una entidad derivada se dice que es una Categoría cuando representa una colección de
objetos que es un subconjunto de unión de distintos tipos de entidades. Una categoría se
modela cuando se necesita relaciones de superclase/subclase sencillas con más de una
superclase, donde las superclases representan diferentes tipos de entidad (similar a la
herencia múltiple en la programación orientada a objetos).

Representación visual de una categoría en un diagrama EER

Capítulo 3. Trabajando con Umbrello UML Modeller

Tabla de contenidos

Interfaz de usuario
Título
Ventana de documentación
Área de trabajo
Crear, cargar y guardar proyectos
Nuevo proyecto
Guardar modelo
Cargar modelo
Editar modelo
Añadir y eliminar diagramas
Crear diagramas
Eliminar diagramas
Renombrar diagramas
Editar diagramas
Insertar diagramas
Borrar elementos
Editar elementos
Editar clases
Asociaciones
Notas, textos y cajas

Este capítulo presentará el interfaz de usuario de Umbrello UML Modeller y le informará

de todo lo que necesita saber para iniciar su primer esquema. Todas las acciones de
Umbrello UML Modeller son accesibles a través del menú y de las barras de herramientas,
pero Umbrello UML Modeller también hace un constante uso del botón derecho del ratón.
Puede utilizar el botón derecho en la práctica totalidad de los elementos del área de trabajo
o de la vista en árbol de Umbrello UML Modeller para abrir un menú con las funciones
más útiles aplicables al elemento en particular sobre el que está trabajando. Algunos
usuarios encuentran el manejo de estos menús un tanto confuso inicialmente, porque están
más acostumbrados a trabajar con el menú o las barras de herramientas, pero una vez que se
acostumbre al botón derecho, verá que puede acelerar enormemente su trabajo.

Interfaz de usuario
La ventana principal de Umbrello UML Modeller está dividida en tres áreas que le
ayudarán a mantener una visión general de todo el sistema y a acceder rápidamente a los
diferentes diagramas mientras trabaja en su proyecto.

Esas áreas reciben el nombre de:

•Vista en árbol
•Área de trabajo
•Ventana de documentación
Interfaz de usuario de Umbrello UML Modeller

Título

La vista en árbol está situada en la parte superior izquierda de la ventana, muestra todos los
diagramas, clases, actores y casos de uso de los que está compuesto su esquema. Le permite
tener una perspectiva de los elementos que componen su esquema. La vista en árbol
también le proporciona una forma rápida de pasar de un diagrama a otro de su esquema así
como de introducir elementos de su esquema en el diagrama actual.

Si está trabajando en un modelo con bastantes clases y diagramas, la vista en árbol le puede
ayudar a controlarlo todo organizando los elementos de su esquema en carpetas. Puede
crear nuevas carpetas seleccionando la opción adecuada en el menú contextual (botón
derecho

Ventana de documentación

La ventana de documentación es esa ventana pequeña situada al fondo a la izquierda de

Umbrello UML Modeller, le permite previsualizar rápidamente la documentación para el
objeto seleccionado. Esta ventana es bastante pequeña debido a que su propósito es darle
una rápida noción del elemento en cuestión sin acaparar mucho espacio en la pantalla. Si
desea ver la documentación más detalladamente puede abrir las propiedades del objeto.

Área de trabajo

El área de trabajo es el la ventana principal de Umbrello UML Modeller y donde todo se

lleva a cabo la parte importante del trabajo. Aquí es donde editará y verá los diagramas de
su esquema. El área de trabajo muestra el diagrama sobre el que se está trabajando en cada
momento, sólo es posible mostrar uno cada vez.

Crear, cargar y guardar proyectos

Lo primero que necesita para empezar a hacer cosas interesantes en Umbrello UML
Modeller es crear un esquema sobre el que trabajar. Cuando se inicia Umbrello UML
Modeller, siempre se carga el último esquema sobre el que se ha estado trabajando o crea
uno vacío (según la configuración establecida en preferencias). Esto le permitirá empezar a
trabajar inmediatamente.

Nuevo proyecto

Si en algún momento necesita crear un nuevo esquema, hágalo seleccionando

(NuevoArchivo o pinchando sobre el icono Nuevo en la barra de herramientas. Si está
trabajando en un esquema que ha sido modificado, Umbrello UML Modellerle preguntará
si quiere o no guardar sus cambios antes de cargar el nuevo esquema.

Guardar modelo

Puede guardar su esquema en cualquier momento seleccionando Guardar desde el menú

Archivo o pulsando sobre el botón Guardar en la barra de herramientas de la aplicación. Si
necesita guardar su modelo con un nombre diferente puede usar la opción Guardar como
desde el menú Archivo.

Umbrello UML Modeller también le permite ir guardando su trabajo automáticamente cada

cierto tiempo. Puede indicar si desea o no esta opción así como el intervalo de tiempo en
preferencias.

Cargar modelo

Para cargar un esquema ya existente puede seleccionar la opción Abrir desde el menú
Archivo o pulsar sobre el icono Abrir de la barra de herramientas. Puede acceder a los
esquemas usados recientemente en el submenú Abrir reciente en el menú Archivo.

Umbrello UML Modeller sólo puede trabajar en un sólo esquema al mismo tiempo, esto
hace que si intenta cargar un nuevo esquema en el programa cuando ha realizado alguna
modificación sobre el que está trabajando, Umbrello UML Modeller le preguntará si quiere
guardar sus cambios antes de cerrarlo y abrir el nuevo. Puede iniciar dos o más instancias
de Umbrello UML Modeller al mismo tiempo, también puede copiar y pegar entre dos
instancias.

Editar modelo
En Umbrello UML Modeller existen básicamente dos formas de editar los elementos de su
modelo.

•Editar los elementos del esquema directamente a través de la vista en árbol.

•Editarlos a través de un diagrama.

Usando el menú contextual de los distintos elementos de la vista en árbol podrá añadir,
eliminar y modificar casi todos los elementos de su esquema. Pinchando con el botón
derecho del ratón sobre las carpetas en la vista en árbol también podrá crear diferentes tipos
de diagramas dependiendo si la carpeta en cuestión es vista de caso de uso o vista lógica,
actores, casos de uso, clases, etc...

Una vez que ha añadido algún elemento a su modelo, podrá editarlo mediante su diálogo de
propiedades al que podrá acceder seleccionando la opción Propiedades en el menú
contextual que aparece al pinchar con el botón derecho en los objetos de la vista en árbol.

También puede editar su esquema creando o modificando sus elementos por medio de los
diagramas. En la siguiente sección tiene más detalles de como hacer esto.

Añadir y eliminar diagramas

Su esquema UML está formado por un conjunto de elementos de UML y las asociaciones
entre ellos. Dado que no es posible ver el esquema directamente, se usan diagramas para
ello.

Crear diagramas

Para crear un nuevo diagrama en su esquema seleccione el tipo de diagrama que necesita en
Nuevo del menú Diagrama y asígnele un nombre. Se creará el diagrama y podrá verlo en la
vista de árbol

Recuerde que Umbrello UML Modeller emplea a menudo menús contextuales, también
puede pulsar botón derecho sobre una carpeta de la vista en árbol y seleccionar el tipo de
diagrama que desee desde la opción Nuevo del menú contextual. Observe que puede crear
diagramas de caso de uso sólo desde las carpetas de vista de casos de uso y los otros tipos
de diagramas sólo pueden ser creados en las carpetas de vista lógica.

Eliminar diagramas

Si desea eliminar un diagrama de su esquema, puede hacerlo activándolo y seleccionando

Borrar desde el menú Diagrama. También puede eliminarlo seleccionado Borrar desde el
menú contxtual del diagrama en la vista en árbol.

Dado que el borrado de diagramas es algo delicado porque se puede perder mucho trabajo
si se hace accidentalemente, Umbrello UML Modeller le pedirá confirmación antes de
eliminar cualquier diagrama. Una vez que un diagrama ha sido borrado y el archivo ha sido
guardado, ya no será posible recuperarlo.

Renombrar diagramas

Si quiere cambiar el nombre de un diagrama ya existente, puede hacerlo seleccionando

Renombrar desde el menú que le aparece al botón derecho sobre la vista de árbol.

Otra forma de renombrar un diagrama es hacerlo a través de su diálogo de propiedades que

puede ver seleccoinado 'Propiedades' desde el menú contextual o haciendo doble click
sobre la vista de árbol.

Editar diagramas
Cuando esté trabajando en un diagrama, Umbrello UML Modeller tratará de ayudarle
indicándole algunas sencillas reglas sobre qué elementos son válidos en los distintos tipos
de diagramas así como las relaciones que pueden existir entre ellos. Si usted es un experto
en UML seguramente ni se dé cuenta, pero si está empezando le ayudará a crear
correctamente diagramas que cumplan el estándar.

Una vez que ha creado sus diagramas, es hora de editarlos. Algún novato observador habrá
observado la diferencia entre editar un diagrama y editar el esquema. Como ya sabrá, los
diagramas son vistas de su esquema. Por ejemplo, si crea una clase editando un diagrama
de clases estará editando el diagrama y el modelo, pero si cambia el color o otra opción
visual en un diagrama de clases, estará editando sólo el diagrama sin modificar el esquema.

Insertar diagramas

Una de las primeras cosas que hará cuando edite un nuevo diagrama es insertar elementos
en ellos (clases, actores, casos de uso,etc.). Existen básicamente dos formas de hacer esto:

•Arrastrando elementos ya existentes en su esqumas desde la vista en árbol.

•Crear nuevos elementos en su modelo y añadirlos a su diagrama al mismo tiempo
usando alguna de las herramientas de edicción de la barra de herramientas.

Para introducir elementos ya existentes en su esquema, simplemente arrástrelos desde la

vista en árbol y suéltelos en el lugar del diagrama donde quiere situarlos. Siempre podrá
mover elementos en los diagramas empleando la herramienta 'Seleccionar'.

la segunda forma de añadir elementos a su diagrama es usando las herramientas de edicción

de la barra de herramientas principal (observe que esto también añadirá los elementos a su
esquema).

La barra de herramientas principal está situada, por omisión, en la parte derecha de la

ventana de la aplicación. Desde Umbrello UML Modeller 1.2 se situa en la parte superior
de la ventana. Puede situarla en cualquier otra parte o anclarla en otro punto. Las
herramientas que contiene (es decir, lo botones que ve sobre ella) cambiarán según el
modelo de diagrama sobre el que esté trabajando en cada momento. El botón de la
herramienta que está seleccionada en cada momento aparece activado. Podrá pasar a la
herramienta de selección pulsando Esc.

Una vez que ha seleccionado una herramienta de edición en la barra de herramientas de

trabajo (por ejemplo la herramienta para insertar clases) el puntero del ratón adopta forma
de cruz, ahora puede insertar elementos en su esquema haciendo click en su diagrama.
Observe que los elemtos en UML deben tener un nombre único así que si tiene una clase
llamada “claseA” en un diagrama y utiliza la herramienta insertar para introducir otra clase
en otro diagrama, no podrá llamarla “claseA”. Dado que se supone que se trata de
elementos diferentes, sus nombres también deberán serlo. Si lo que quiere hacer es añadir el
mismo elemento en su diagrama la herramienta insertar clase no es adecuada para esto, lo
que debe hacer es arrastar y soltar la clase desde la vista en árbol.

Borrar elementos

Podrá borrar cualquier elemento seleccionando la opción Borrar desde su menú contextual.

De nuevo hay una gran diferencia entre eliminar un objeto de un diagrama y eliminarlo de
todo el esquema. Si borra un objeto de un diagrama, únicamente lo eliminará de ese
diagrama concreto, seguirá formando parte de su esquema y si otros diagramas lo usan
seguirá estando ahí. En cambio, si borra el elemento desde la vista en árbol sí que lo
eliminará completamente de su esquema, con lo que desaparecerá de todos los diagramas
donde aparecía.
Editar elementos

Puede editar la mayoría de los elementos de UML de sus esquemas y diagramas abriendo
su diálogo de propiedades y seleccionando las opciones pertinentes. Para editar las
propiedades de un objeto, seleccione Propiedades desde su menú contextual (haciendo
botón derecho). Cada elemento tiene un diálogo de varias páginas donde configurar las
opciones correspondientes a estos elementos. En algunos elementos, como los actores, sólo
disponen de un par de opciones como el nombre del objeto y su documentación mientras
que para otros como las clases puede editar sus atributos y operaciones, seleccionar lo que
quiere que se vea en el diagrama, incluso los colores.

Para la mayoría de los elementos UML, si usa la herramienta selección (la flecha) puede
abrir el diálogo de propiedades haciendo doble click sobre ellos. La exepción a esto son las
asociaciones en cuyo caso un doble click crearía un punto de anclaje, para ello tiene que
emplear el menú contextual (haciendo botón derecho) e ir al diálogo de propiedades.

Observe que también puede seleccionar la opción de propiedades desde el menú contextual
de los elementos en la vista en árbol. Esto también le permite editar las propiedades de los
diagramas como seleccionar si la rejilla debe o no verse.

Editar clases

Aunque la edición de propiedades de todos los objetos ya haya sido tratada en la sección
anterior, las clases merecen una explicación adicional debido a su mayor complejidad y a
que poseen más opciones que la mayoría de los elementos de UML.

En el diálogo de propiedades de una clase es posible configurar cualquier parámetro, desde

el color que emplea hasta sus atributos y operaciones.

Preferencias generales de clase

La pestaña de preferencias generales del diálogo de propiedades se explica por si mismo.

Desde ahí podrá cambiar el nombre de la clase, la visibilidad, la documentación, etc.. Esta
pestaña siempre está disponible.

Configuración de los atributos de las clases.

En la configuración de atributos podrá añadir, editar o borrar atributos (variables) de una

clase. Puede mover atributos arriba y abajo en la lista pulsando la flecha del lateral de la
ventana. Esta pestaña siempre está disponible.

Configuración de operaciones de clase

De modo similar a la página de configuración de atributos, aquí podrá añadir, editar y

borrar operaciones de su clase. Cuando añada o edite una operación, deberá insertar la
información básica en el diálogo Propiedades de operaciones. Si lo que desea es añadir
parámetros a su operación deberá pulsar sobre Nuevo parámetro para que se muestre el
diálogo Propiedades del paámetro. Esta página siempre está disponible.

Configuración de la plantilla de clase

Desde ahí podrá añadir plantillas de clase, es decir clases no especificas o tipos de datos. En
Java 1.5 recibirán el nombre de genéricas.
Página de asociaciones de clase

La página de asociaciones de clase muestra todas las asociaciones de esa clase en el

diagrama actual. Si hace doble click sobre una asociación podrá ver sus propiedades y,
dependiendo del tipo de asociación podrá modificar algunos parámetros tales como el
nombre del rol o incluir multiplicidad. Si la asociación no permite que estas opciones sean
modificadas, el diálogo de propiedades de asociación será de sólo lectura y sólo podrá
modificar la documentación asociada con esta asociación.

Esta página sólo estará disponible si abre las propiedades de clase desde un diagrama. Si
selecciona las propiedades de clase en un menú contextual desde la vista en árbol, esta
página no estará disponible.

Página de visualización de clase

En la página de opción de visualización podrá definir los elementos que deben mostrarse en
un diagrama. Una clase podrá mostrarse simplemente como un rectángulo con su nombre
escrito en él (especialemente útil si tiene varias clases o si, de momento, no está interesado
en los detalles de cada clase) o bien mostrar completamente todos los paquetes,
estereotipos,atributos y operaciones.

Dependiendo de la cantidad de información que desee ver, podrá seleccionar las

correspondientes opciones en esa página. Los cambios que realize ahí sólo será opciones de
visualización para el diagrama. Esto quiere decir que “esconder” la opercación de una clase
sólo hará que no se muestren en el diagrama, pero la operción seguirá ahí formando parte
de su esquema. Esta operación sólo estará disponible si selecciona las propiedades de clase
desde un diagrama. Si abre las propiedades de clase desde la vista en árbol está página no
estará disponible ya que esta opción de visualización carece de sentido en este contexto.

Página para configurar los colores de la clase

En la página color de objetos podrá configurar los colores que desee para las líneas y el
relleno de los objetos. Obviamente, esta opción sólo tiene sentido para las clases que se
muestran en los diagramas y no aparece cuando abre el diálogo de propiedades de clase
desde la vista en árbol.

Asociaciones

Las asociaciones relacionan dos objetos UML entre si. Normalemente, las asociaciones se
definen entre dos clases, sin embargo algunos tipos de asociación también pueden darse
entre casos de uso y actores.

Para crear una asociación seleccione la herramienta adecuada en la barra de herramientas

de trabajo (asociación genérica, generalización, agregación, etc.) y pinche primero sobre el
primer elemento de la asociación y luego sobre el segundo. Observe que lo que hacemos
son dos clicks, no arrastrar el click de un objeto a otro.

Si intenta crear una asociación que no se ajuste a las especificaciones de UML, Umbrello
UML Modeller no aceptará crearla y le mostrará un mensaje de error. Un ejemplo de esto
sería si exixtiera una generalización desde la clase A hasta la B y tratase de crear otra desde
B hasta A.

Pulsando con el botón derecho del ratón sobre una asociación verá un menú contextual con
las acciones que pueden realizarse. Si quiere borrar una asociación, simplemente seleccione
la opción Borrar en ese menú contextual. También puede seleccionar la opción propiedades
y, según el tipo de asociación, editar los atributosque posea.

Puntos de anclaje

por omisión, las asociaciones se representan mediante una línea recta que conecta los dos
objetos de un diagrama.

Podrá añadir puntos de anclaje haciendo doble click en cualquier parte de la línea de
asociación.Esto puntos de anclaje se representan mediante un punto azul cada vez que se
selecciona la línea, podrá moverlo a su antojo hasta dar la forma deseada a la (ex)recta de
asociación.

Si desea eliminar puntos de anclaje, haga doble click sobre ellos.

Observe que el único modo de editar las propiedades de una asociación es a través del
menú contextual. Si trata de hacer doble click sobre él como haría con cualquier otro objeto
UML, se insertará un punto de anclaje.

Notas, textos y cajas

Las notas,textos y cajas pueden aparecer en cualquier tipo de diagrama, carecen de valor
semántico pero son útiles para añadir comentarios o explicaciones adicionales para facilitar
la comprensión del diagrama.

Para añadir una nota o texto debe seleccionar la herramienta correspondiente de la barra de
herramientas y pinchar sobre el punto del diagrama donde desee añadirlo. Puede editar el
texto a través de su menú contextual o, en el caso de las notas, haciendo doble click sobre
él.

Anclajes

Los anclajes sirven para unir una nota con otro elemento UML. P. ej. si suele usar una
determinada nota para explicar o realizar algún comentario sobre una clase o una
asociación en concreto, puede usar los anclajes para dejar claro que la nota “pertenece” a
esa clase o asociación y no a otras.

Para anclar una nota con otro elemento UML, utilice la herramienta anclaje de la barra de
herramientas de trabajo. Primero deberá pinchar sobre la nota y luego sobre el elemento
UML al que quiere asociar la nota.

Capítulo 4. Importación y generación de código

Tabla de contenidos

Generación de código
Generación de código
Importación de código

umbrello; es una herramienta de modelado UML, y como tal, su propósito principal es el de

ayudar en el análisis y diseño de sus sistemas. Sin embargo, para realizar la transición entre
el diseño y la implementación, Umbrello UML Modeller permite la generación de código
fuente en diferentes lenguajes de programación como ayuda inicial. Además, si desea
utilizar UML en un proyecto C++ ya iniciado, Umbrello UML Modeller puede ayudarle a
crear una maqueta de su sistema a partir del código fuente realizando un análisis del código
e importando las clases encontradas en el.

Generación de código
Umbrello UML Modeller puede generar código fuente en varios lenguajes de
programación, a partir de la maqueta UML para ayudar a comenzar la implementación de
su proyecto. El código generado consta de declaraciones de clases con sus métodos y
atributos, de forma que usted pueda “rellenar los espacios en blanco” proporcionando la
funcionalidad de las operaciones de sus clases.

Umbrello UML Modeller 1.2 viene provisto con soporte para la generación de código en
ActionScript, Ada, C++, CORBA IDL, Java™, JavaScript, PHP, Perl, Python, SQL y
XMLSchema.

Generación de código

Para generar código con Umbrello UML Modeller, en primer lugar hay que crear o cargar
una maqueta que contenga al menos una clase. Una vez que este listo para comenzar a
escribir el código, seleccione el Asistente de generación de código en el menú Código para
iniciar un asistente que le guiará a través del proceso de generación de código.

El primer paso es seleccionar las clases para las que desea generar código fuente. De forma
predeterminada se seleccionan todas las clases de la maqueta, y usted puede eliminar
aquellas para las que no desea generar código eliminándolas de la lista de la izquierda.

El siguiente paso del asistente le permite modificar los parámetros que el generador de
código utilizará en el proceso. Las opciones disponibles son las siguientes:
Opciones de generación de código en Umbrello UML Modeller

Opciones de generación
Comentado del Código

La opción Escribir comentarios de documentación aún si está vacía instruye al Generador

de código a escribir comentarios del tipo /** blah */ aún cuando el bloque de comentarios
se encuentre vacío. Si usted ya agregó documentación a sus clases, métodos o atributos en
su Maqueta, el Generador de código escribirá estos comentarios como documentación
Doxygen sin importar lo que haya definido aquí, pero si selecciona esta opción Umbrello
UML Modeller escribirá comentarios para todas sus clases, métodos y atributos aún cuando
no exista documentación en la Maqueta, en cuyo caso usted deberá documentar sus clases
más tarde editando directamente el código fuente.

Escribir comentarios para las secciones incluso si la sección está vacía producirá que
Umbrello UML Modeller escriba comentarios en el código fuente para delimitar las
diferentes secciones de una clase. Por ejemplo “Métodos públicos” o “Atributos ” antes de
la sección correspondiente. Si selecciona esta opción Umbrello UML Modeller escribirá los
comentarios para todas las secciones de las clases aún si la sección está vacía. Por ejemplo,
escribirá un comentario diciendo “Métodos protegidos” aún si no existen métodos
protegidos en su clase.

Carpetas
Escribir todos los archivos generados a la carpeta. Aquí debe seleccionar la carpeta donde
desea que Umbrello UML Modeller guarde los archivos fuente generados.

La opción Incluir archivos de cabecera desde la carpeta le permite insertar un encabezado al

comienzo de cada archivo generado. Los archivos de encabezado pueden contener
información acerca del copyright o la licencia, y contener variables que son evaluadas al
momento de generación. Usted puede puede mirar a modo de ejemplo los archivos de
encabezamiento distribuidos con Umbrello UML Modeller para ver como se utilizan estas
variables para reemplazar su nombre o la fecha y hora del momento de generación.

Política de sobreescritura

Esta opción le dice a Umbrello UML Modeller qué hacer si el archivo que desea crear ya
existe en la carpeta de destino. Umbrello UML Modeller no puede modificar archivos
fuente existentes, por lo que debe elegir entre sobreescribir el existente, saltar la generación
de ese archivo en particular, o dejar que Umbrello UML Modeller elija un nombre diferente
para el archivo. Si uste elije la opción de utilizar un nombre diferente, Umbrello UML
Modeller agregará un sufijo al nombre del archivo.

Lenguaje

Umbrello UML Modeller generará por omisión código fuente en el lenguaje que usted haya
seleccionado como Lenguaje activo, pero con el Asistente para la generación de código
usted tiene la opción de cambiar esto a otro idioma.

Asistente para la generación de código

El tercero y ultimo paso del asistente le mostará el estado del proceso de generación de
código. Usted necesitará hacer click en el botón de Generación de código para que las
clases sean escritas para usted.

Recuerde que las opciones que seleccione en el asistente de generación de código sólo son
válidas para esa generación en concreto, la siguiente vez que ejecute el asistente deberá
volver a seleccionar todas las opciones aunque sean las mismas. Puede evitar esto
definiendo en la sección Generación de código del menú Preferencias->Configurar
modelador de UML Umbrello UML Modeller....

Si ha ha establecido las opciones del asistente de generación de código y quiere generar

directamente algún código sin el asistente, seleccione Generar todo el código desde el menú
Código. Esto generará código para todas las clases de su esquema con la configuración
actual (incluso la carpeta de salida y las opciones de sobreescritura así que tenga cuidado).

Importación de código
Umbrello UML Modeller puede importar código fuente de sus pryectos actuales para
ayudarle a crear los esquemas de sus sistemas. Umbrello UML Modeller 1.2 sólo puede
hacerlo con C++ aunque en el futuro estará disponible para más lenguajes.

Para importar clases en su esquema seleccione la entrada Importar clases desde el menú
Código. Una vez ahí, seleccione los archivos que contengan las declaraciones de clases de
C++ y pulse aceptar. Se importaran las clases y pasarán a ser parte de su esquema en la
vista en árbol. Recuerde que Umbrello UML Modeller no creará ningún tipo de diagrama
para mostrar sus clases, sólo las importará a su esquema para que pueda usarlas luego en
cualquier diagrama.
Menú para la importación de código fuente en Umbrello UML Modeller

Capítulo 5. Otras características

Tabla de contenidos

Otras características de Umbrello UML Modeller

Copia de objetos como imágenes PNG
Exportar como imagen
Impresión
Carpetas lógicas

Otras características de Umbrello UML Modeller

Este capítulo explica brevemente otras características que ofrece Umbrello UML Modeller.

Copia de objetos como imágenes PNG

Además de ofrecer la funcionalidad normal de copiar, cortar y pegar que se espera en la

administración de los objetos de los diferentes diagramas, Umbrello UML Modeller puede
copiar los objetos como imágenes PNG de forma que pueda insertarlos en cualquier otro
tipo de documento. No es necesario hacer nada especial para utilizar esta característica,
basta con que seleccione un objeto de un diagrama (clase, actor, etc.) y lo copie (Ctrl-C o
mediante el menú), abra un documento de KWord (o cualquier otro programa que admita el
pegado de imágenes) y seleccione la opción de pegar. Esta es una gran característica para
exportar partes del diagrama como simples imágenes.

Exportar como imagen

También puede exportar como imagen un diagrama completo. Lo único que tiene que hacer
es seleccionar el diagrama que desa exportar y a continuación la opción Exportar como
imagen... del menú Diagrama.

Impresión

Umbrello UML Modeller le permite imprimir diagramas individuales. Pulse el botón

Imprimir en la barra de herramientas de aplicación o seleccione la opción Imprimir en el
menú Archivo para obtener un diálogo de impresión estándar de KDE donde podrá
imprimir los diagramas.

Carpetas lógicas
Para organizar mejor la maqueta, especialmente en los proyectos grandes, es posible crear
carpetas lógicas en la vista de árbol. Basta con que seleccione la opción Nueva->Carpeta en
el menú contextual de la carpeta predeterminada en la vista de árbol. Las carpetas se
pueden anidar, puede mover objetos de una a otras por el procedimiento normal de arrastrar
y soltar.

Organización de una maqueta con carpetas lógicas en Umbrello UML Modeller

Capítulo 6. Autores e historia

Este proyecto fue iniciado por Paul Hensgen como uno de sus proyectos universitarios. El
nombre original de la aplicación era UML Modeller. Paul se encargó de todo el desarrollo
hasta finales de 2001, cuando el programa llegó a la versión 1.0.

La versión 1.0 ya ofrecía muchas funcionalidades, pero una vez que el proyecto fue
revisado en la universidad de Paul, otros desarrolladores pudieron unirse al equipo y
comenzar a enviar valiosas contribuciones a UML Modeller, como el cambio de un archivo
binario a uno , sXMLoporte para más tipos de diagramas UML, generación de código e
importación de código por nombrar algunas.

Paul tuvo que retirarse del equipo de desarrollo en verano de 2002 pero, como software
libre que es, el programa continúa mejorando y evolucionando, y es mantenido por un
grupo de desarrolladores de diferentes lugares del mundo. Además, en septiembre de 2002,
el proyecto cambió el nombre de UML Modeller a Umbrello UML Modeller. Existen varias
razones para el cambio del nombre, siendo la más importante que sólo “uml” (como era
conocido) —resultaba un nombre muy genérico— y causaba problemas con algunas
distribuciones. La otra razón importante es que los desarrolladores piensan que Umbrello es
un nombre más impactante.

El desarrollo de Umbrello UML Modeller así como las discusiones sobre el futuro del
programa son abiertas y tiene lugar en Internet. Si desea contribuir con el proyecto, no dude
en ponerse en contacto con los desarrolladores. Hay muchas formas para ayudar en el
desarrollo de Umbrello UML Modeller

•Informando de fallos o sugerencias

•Arreglando fallos o añadiendo funcionalidad
•Escribiendo buena documentación o traduciéndola a otros idiomas
•Y, por supuesto... programando con nosotros

Como puede ver, hay muchas formas en las que puede contribuir. Todas ellas son muy
importantes y todo el mundo es bienvenido.

Puede contactar con los desarrolladores de Umbrello UML Modeller en (uml-devel AT

lists.sourceforge.net).