Diagramas UML

Lenguaje unificado de modelado (UML)

El lenguaje unificado de modelado (UML, por sus siglas
en ingls, Unified Modeling Language) es el lenguaje de
modelado de sistemas de software ms conocido y
utilizado en la actualidad; est respaldado por el Object
Management Group (OMG). Es un lenguaje grfico para
visualizar, especificar, construir y documentar un
sistema. UML ofrece un estndar para describir un
"plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos, funciones del
sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o

para describir mtodos o procesos y no es una Metodologa. Se utiliza para definir
un sistema, 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 el desarrollo de software gran variedad de formas para dar soporte a una
metodologa de desarrollo de software (tal como el Proceso Unificado
Racional, Rational Unified Process o RUP), pero no especifica en s mismo qu
metodologa o proceso usar. UML no puede compararse con la programacin
estructurada, pues UML significa Lenguaje Unificado de Modelado, no es
programacin, solo se diagrama la realidad de una utilizacin en un requerimiento.
Mientras que programacin estructurada es una forma de programar como lo es la
orientacin a objetos, la programacin orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML solo para lenguajes
orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales
muestran diferentes aspectos de las entidades representadas. Los principales
beneficios de UML son: Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas (y no slo de software) utilizando conceptos orientados a objetos.
Establecer conceptos y artefactos ejecutables. Encaminar el desarrollo del
escalamiento en sistemas complejos de misin crtica. Crear un lenguaje de
modelado utilizado tanto por humanos como por mquinas. Mejor soporte a la
planeacin y al control de proyectos. Alta reutilizacin y minimizacin de costos.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado

consiste de vistas, diagramas, elementos de modelo (smbolos) y un conjunto de
mecanismos generales o reglas que indican cmo utilizar los elementos.
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no
es una grfica, pero s una abstraccin que consiste en un nmero de diagramas y
todos esos diagramas juntos muestran una "fotografa" completa del sistema. Las
vistas tambin ligan el lenguaje de modelado a los mtodos o procesos elegidos
para el desarrollo.
Diagramas: Los diagramas son las grficas que describen el contenido de una vista.
Smbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son
los elementos de modelo que representan conceptos comunes orientados a objetos,
tales como clases, objetos y mensajes, y las relaciones entre estos conceptos
incluyendo la asociacin, dependencia y generalizacin. Un elemento de modelo es
utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y
simbologa.
Reglas o Mecanismos generales: Proveen comentarios extras, informacin o
semntica acerca del elemento de modelo; adems proveen mecanismos de
extensin para adaptar o extender UML a un mtodo o proceso especfico,
organizacin o usuario.

Historia
Antes de UML 1.x: Despus de que la Rational Software Corporation contratara a
James Rumbaugh de General Electric, en 1994, la compaa se convirti en la
fuente de los dos esquemas de modelado orientado a objetos ms populares de la
poca: Object-Modeling Technique (OMT) de Rumbaugh, que era mejor
para anlisis orientado a objetos, y el Mtodo Booch (de Grady Booch) que era
mejor para el diseo orientado a objetos. Poco despus se les uni Ivar Jacobson,
el creador del mtodo de ingeniera de software orientado a objetos. Los tres
metodologistas eran conocidos como los Tres Amigos, porque se saba de sus
constantes discusiones sobre las prcticas metodolgicas. En 1996 Rational
concluy que la abundancia de lenguajes de modelado estaba alentando la
adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo unificado,
encargaron a los Tres Amigos que desarrollaran un "lenguaje unificado de
modelado" abierto. Se consult con representantes de compaas competidoras en
el rea de la tecnologa de objetos durante la OOPSLA '96; eligieron "cajas" para
representar clases en lugar de la notacin de Booch que utilizaba smbolos de
"nubes". Bajo la direccin tcnica de los Tres Amigos fue organizado un consorcio
internacional llamado UML Partners en 1996 para completar las especificaciones
del UML. El borrador de la especificacin UML 1.0 de UML Partners fue propuesto
a la OMG en enero de 1997. El resultado de este trabajo, el UML 1.1, fue presentado
ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.
UML 1.x: Como notacin de modelado, la influencia de la OMT domina UML (por
ejemplo, el uso de rectngulos para clases y objetos). Aunque se quit la notacin
de "nubes" de Booch, s se adopt la capacidad de Booch para especificar detalles
de diseo en los niveles inferiores. La notacin de "Casos de Uso" del Objectory y
la notacin de componentes de Booch fueron integrados al resto de la notacin,
pero la integracin semntica era relativamente dbil en UML 1.1, y no se arregl
realmente hasta la revisin mayor de UML 2.0. Conceptos de muchos otros mtodos
orientados a objetos (MOO) fueron integrados superficialmente en UML con el
propsito de hacerlo compatible con todos los MOO. Adems, el grupo tom en
cuenta muchos otros mtodos de la poca, con el objetivo de asegurar amplia
cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es
til en una gran variedad de problemas de ingeniera, desde procesos sencillos y
aplicaciones de solamente un usuario a sistemas concurrentes y distribuidos.
UML 2.x: UML ha madurado considerablemente desde UML 1.1, varias revisiones
menores (UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versin
de UML. A estas le ha seguido la revisin mayor UML 2.0 que fue adoptada por el
OMG en 2005. Aunque UML 2.1 nunca fue lanzado como una especificacin formal,
las versiones 2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero
de 2009. UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado
oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una
versin "En proceso" que fue formalmente liberada en junio de 2015.

Tipos de diagramas UML

Diagramas de estructura
Diagrama de clases: Describe los diferentes tipos de objetos en un sistema
y las relaciones existentes entre ellos.
Diagrama de objetos: (tambin llamado Diagrama de instancias) Foto de
los objetos en un sistema en un momento del tiempo.
Diagrama de paquetes: muestra la estructura y dependencia entre
paquetes, los cuales permiten agrupar elementos (no solamente clases) para
la descripcin de grandes sistemas.
Diagrama de despliegue: muestra la relacin entre componentes o
subsistemas software y el hardware donde se despliega o instala.
Diagrama de estructura compuesta: descompone jerrquicamente una
clase mostrando su estructura interna.
Diagrama de componentes: muestra la jerarqua y relaciones entre
componentes de un sistema software.
Diagrama de perfiles: es un tipo de diagrama que se utiliza muy raramente
en cualquier especificacin.

Diagramas de comportamiento
Diagrama de casos de uso: Permite capturar los requerimientos funcionales
de un sistema.
Diagrama de estado: Permite mostrar el comportamiento de un objeto a lo
largo de su vida.
Diagrama de actividad: Describe la lgica de un procedimiento, un proceso
de negocio o Workflow.
Diagramas de interaccin (Subgrupo dentro de los diagramas de
comportamiento): Describen cmo los grupos de objetos colaboran para
producir un comportamiento.
Diagrama de secuencia: Muestra los mensajes que son pasados entre
objetos en un escenario.
Diagrama de comunicacin: Muestra las interacciones entre los
participantes haciendo nfasis en la secuencia de mensajes.
Diagrama de colaboracin: (Solamente en UML 1.X) Muestra las
interacciones organizadas alrededor de los roles.
Diagrama de (visin de conjunto o resumen de) interaccin: Se trata
de mostrar de forma conjunta diagramas de actividad y diagramas de
secuencia.
Diagrama de tiempo: Pone el foco en las restricciones temporales de un
objeto o un conjunto de objetos.
 Diagrama De Clases
Los diagramas de clases muestran las diferentes clases que componen un sistema
y cmo se relacionan unas con otras. Se dice que los diagramas de clases son
diagramas estticos porque muestran las clases, junto con sus mtodos y
atributos, as como las relaciones estticas entre ellas: qu clases conocen a qu
otras clases o qu clases son parte de otras clases, pero no muestran los
mtodos mediante los que se invocan entre ellas.
Un diagrama de clases est compuesto por los siguientes elementos:
Clase: atributos, mtodos y visibilidad.
Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Clase
Una clase define los atributos y los mtodos 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 objeto tiene el suyo propio). En ocasiones se
utiliza el trmino tipo en lugar de clase, pero recuerde que no son lo mismo, y que
el trmino tipo tiene un significado ms general.
las clases estn representadas por rectngulos, con el nombre de la clase, y
tambin pueden mostrar atributos y operaciones de la clase en otros dos
compartimentos dentro del rectngulo.

En UML, una clase es representada por un rectngulo que posee tres divisiones:

En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la
Clase (pueden ser private, protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma como
interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected
o public).

Atributos y Mtodos
Atributos: Los atributos o caractersticas de una Clase pueden ser de tres tipos, los
que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos
son:
Public (+, ): Indica que el atributo ser visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
Private (-, ): Indica que el atributo slo ser accesible desde dentro de la clase
(slo sus mtodos lo pueden accesar).
Protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de las subclases que
se deriven (ver herencia).

Mtodos: Los mtodos u operaciones de una clase son la forma en como sta
interacta con su entorno, stos pueden tener las caractersticas:
Public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
Private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos de la clase lo pueden accesar).
Protected (#, ): Indica que el mtodo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de mtodos de las
subclases que se deriven (ver herencia).

Relaciones
En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia,
se anotan en cada extremo de la relacin y stas pueden ser:
1 (No ms de uno)
0 a Uno: 01
Uno a Muchos: 1...* (1...n)
0 a Muchos: 0...* (0...n)
Nmero Fijo: m (m denota el nmero).

Herencia (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por una
Super Clase, por ende, la Subclase adems de poseer sus propios mtodos y
atributos, poseer las caractersticas y atributos visibles de la Super Clase (public y
protected). Ejemplo:

En la figura se especifica que Auto y Camioneta heredan de Vehculo, es decir, Auto

posee las Caractersticas de Vehculo (dueno, puertas, ruedas) adems posee algo
particular que es Descapotable, en cambio Camin tambin hereda las
caractersticas de Vehculo (dueno, puertas, ruedas) pero posee como
particularidad propia Tara y Carga. Cabe destacar que fuera de este entorno, lo
nico "visible" es el mtodo Caractersticas aplicable a instancias de Vehculo, Auto
y Camin, pues tiene definicin publica, en cambio atributos como Descapotable no
son visibles por ser privados.

Agregacin:
Para modelar objetos complejos, no bastan los tipos de datos bsicos que proveen
los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere
componer objetos que son instancias de clases definidas por el desarrollador de la
aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del
objeto incluido est condicionado por el tiempo de vida del que lo incluye.
Este tipo de relacin es comnmente llamada Composicin (el Objeto base
se construye a partir del objeto incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida
del objeto incluido es independiente del que lo incluye. Este tipo de relacin
es comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).
Ejemplo:

En donde se destaca que:

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).
Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.
La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado.
Cuando no existe este tipo de particularidad la flecha se elimina.

Asociacin:
Permite asociar objetos que colaboran entre s. Cabe destacar que no es una
relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Ejemplo:

Un cliente puede tener asociadas muchas rdenes de Compra, en cambio una

orden de compra solo puede tener asociado un cliente.
Dependencia o Instanciacin (uso):
Representa un tipo de relacin muy particular, en la que una clase es instanciada
(su instanciacin es dependiente de otro objeto/clase). Se denota por una flecha
punteada. El uso ms particular de este tipo de relacin es para denotar la
dependencia que tiene una clase de otra. Ejemplo:

Una aplicacin grafica que instancia una ventana (la creacin del Objeto Ventana
est condicionado a la instanciacin proveniente desde el objeto Aplicacin). Cabe
destacar que el objeto creado (en este caso la Ventana grfica) no se almacena
dentro del objeto que lo crea (en este caso la Aplicacin).

Casos Particulares
Clase Abstracta: Una clase abstracta se denota con el nombre de la clase y de los
mtodos con letra "itlica". Esto indica que la clase definida no puede ser
instanciada pues posee mtodos abstractos (an no han sido definidos, es decir,
sin implementacin). La nica forma de utilizarla es definiendo subclases, que
implementan los mtodos abstractos definidos.

Clase parametrizada: Una clase parametrizada se denota con un subcuadro en el

extremo superior de la clase, en donde se especifican los parmetros que deben
ser pasados a la clase para que esta pueda ser instanciada. Ejemplo:

El ejemplo ms tpico es el caso de un Diccionario en donde una llave o palabra

tiene asociado un significado, pero en este caso las llaves y elementos pueden ser
genricos. La genericidad puede venir dada de un Template (como en el caso de
C++) o bien de alguna estructura predefinida (especializacin a travs de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos
dependern exclusivamente de la implementacin que se le quiera dar.
 Diagramas 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 estn pensados para representar el
diseo y no puede describir los elementos internos de un sistema. Los diagramas
de casos de uso sirven para facilitar la comunicacin con los futuros usuarios del
sistema, y con el cliente, y resultan especialmente tiles para determinar las
caractersticas 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 cmo.

Un diagrama de casos de uso consta de los siguientes elementos:

Sistema
Actor.
Casos De uso.
Relaciones De Uso. Herencia y Comunicacin.
Descripciones

Sistema
Un sistema en un diagrama de caso de uso es descrito como una caja; el nombre
del sistema aparece arriba o dentro de la caja. sta tambin contiene los smbolos
para los casos de uso del sistema.

Representacin
Grafica

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 fsicas o a sistemas, sino
su rol. Esto significa que cuando una persona interacta con el sistema de diferentes
maneras (asumiendo diferentes papeles), estar representado por varios actores.
Por ejemplo, una persona que proporciona servicios de atencin telefnica a
clientes y realiza pedidos para los clientes estara representada por un actor equipo
de soporte y por otro actor representante de ventas.

Representacin
Grafica
Encontrando a los actores de un diagrama de casos de uso.
Es posible obtener a los actores de un diagrama de casos de uso a travs de las
siguientes preguntas:
Quin utilizar la funcionalidad principal del sistema (actores primarios)?
Quin necesitar soporte del sistema para realizar sus actividades diarias?
Quin necesitar mantener, administrar y trabajar el sistema (actores
secundarios)?
Qu dispositivos de hardware necesitar manejar el sistema?
Con qu otro sistema necesitar interactuar el sistema a desarrollar?
Quin o qu tiene inters en los resultados (los valores) que el sistema
producir?

Existen dos tipos de actores los cuales son:

Principal: Requiere al sistema el cumplimiento de un objetivo.
Secundarios: El sistema necesita de ellos para satisfacer un objetivo.

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 tpicas 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 cmo). Cuando se trabaja con casos de uso, es importante tener presentes
algunas sencillas reglas:
Cada caso de uso est relacionado como mnimo 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
intrnseco)
Representacin
Grafica

Encontrando casos de uso

El proceso para encontrar casos de uso inicia encontrando al actor o actores
previamente definidos. Por cada actor identificado, hay que realizar las siguientes
preguntas:
Qu funciones del sistema requiere el actor? Qu necesita hacer el actor?
El actor necesita leer, crear, destruir, modificar o almacenar algn tipo de
informacin en el sistema?
El actor debe ser notificado de eventos en el sistema o viceversa? Qu
representan esos eventos en trminos de funcionalidad?
El trabajo diario del actor podra ser simplificado o hecho ms
eficientemente a travs de nuevas funciones en el sistema? (Comnmente,
acciones actuales del actor que no estn automatizadas)
Otras preguntas que nos ayudan a encontrar casos de uso pero que no involucran
actores son:
 Qu entradas/salidas necesita el sistema? De dnde vienen esas entradas
o hacia dnde van las salidas?
Cules son los mayores problemas de la implementacin actual del
sistema?

Un caso de uso NO es un diagrama, NO es un smbolo dentro de un diagrama, es

una forma de describir un escenario de interaccin usuario sistema, los diagramas
vienen despus (o antes) y son una forma de tener una visin general de los casos
de uso, sus relaciones con los actores y con otros casos de uso

Relaciones
Comunicacin: Relacin (asociacin) entre un actor y un caso de uso. El
estereotipo de la relacin de comunicacin es: <<communicate>> aunque
generalmente no se estipula ningn nombre, como podemos apreciar en el
siguiente ejemplo de comunicacin:

Inclusin: Un caso de uso base incorpora explcitamente el comportamiento de otro

en algn lugar de su secuencia. La relacin de inclusin sirve para enriquecer un
caso de uso con otro y compartir una funcionalidad comn entre varios casos de
uso, tambin puede utilizarse para estructurar un caso de uso describiendo sus
Subfunciones. El caso de uso incluido existe nicamente con ese propsito, ya que
no responde a un objetivo de un actor. Estas relaciones se representan mediante
una flecha discontinua con el estereotipo <<include>>. Algunos casos de uso tpicos
de inclusin son: comprobar, verificar, buscar, validar, autentificar o login. En
principio, no deberamos abusar de este tipo de relacin, para no hacer una
descomposicin funcional del sistema. A partir de UML 1.3 la relacin <<include>>
reemplaz al denominado <<uses>>. Ejemplo
Extensin: Un caso de uso base incorpora implcitamente el comportamiento de
otro caso de uso en el lugar especificado indirectamente por este otro caso de uso.
En el caso de uso base, la extensin se hace en una serie de puntos concretos y
previstos en el momento del diseo, llamados puntos de extensin, los cules no
son parte del flujo principal. La relacin de extensin sirve para modelar: la parte
opcional del sistema, un subflujo que slo se ejecuta bajo ciertas condiciones o
varios flujos que se pueden insertar en un punto determinado. Este tipo de relacin
produce confusin y no debera utilizarse en exceso. Conviene su uso slo para
insertar un nuevo comportamiento no previsto en un caso de uso existente. Estas
relaciones se representan mediante una flecha discontinua con el estereotipo
<<extend>>. Ejemplo

Especializacin y generalizacin de los casos de uso: Un caso de uso (subcaso)

hereda el comportamiento y significado de otro, es decir las relaciones de
comunicacin, inclusin y extensin del super-caso de uso. En muchas ocasiones
este super-caso de uso es abstracto y corresponde a un comportamiento parcial
completado en el subcaso de uso. O, dicho de otra manera, Los casos de uso hijo
son una especializacin del caso de uso padre. En la medida de lo posible debera
evitarse puesto que produce cierta confusin en algunas ocasiones. Ejemplo.

Descripcin de casos de uso

Las descripciones de casos de uso son reseas 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.
 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 envan los mensajes a los
objetos. En los diagramas de secuencia, los objetos estn representados por lneas
intermitentes verticales, con el nombre del objeto en la parte ms alta. El eje de
tiempo tambin es vertical, incrementndose hacia abajo, de forma que los
mensajes son enviados de un objeto a otro en forma de flechas con los nombres de
la operacin y los parmetros Mientras que el diagrama de casos de uso permite el
modelado de una vista business del escenario, el diagrama de secuencia contiene
detalles de implementacin del escenario, incluyendo los objetos y clases que se
usan para implementar el escenario y mensajes intercambiados entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu
objetos son necesarios para la implementacin del escenario. Si se dispone de la
descripcin de cada caso de uso como una secuencia de varios pasos, entonces se
puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para
que se puedan seguir los pasos.

Caractersticas Diagrama De Secuencia

Los diagramas de secuencia muestran grficamente las interacciones del
actor y de las operaciones a quedan origen.
Los diagramas de secuencia se preparan durante la fase de anlisis de un
ciclo de desarrollo.
Su creacin depende de la formulacin previa de los casos de uso.
El comportamiento del sistema es una descripcin delo que hace, y no como
lo hace.
El diagrama de secuencia muestra un determinado escenario de un caso de
uso, los eventos generados por actores externos, su orden y los eventos
internos del sistema.

Ventajas
Da la posibilidad de representar los mensajes en funcin del tiempo.
La separacin de los mensajes no indica intervalos o cantidades de tiempo, solo
ordenacin temporal.
Es posible aadir restricciones temporales.
Desventajas
Una representacin de un diagrama de secuencia demasiado largo, puede ser
difcilmente entendido por alguien ajeno al Sistema.

Elementos de un Diagrama de Secuencias

Rol de la Clase: El rol de la clase describe la manera en que un objeto se va a
comportar en el contexto. No se listan los atributos del objeto.
Activacin: Los cuadros de activacin representan el tiempo que
un objeto necesita para completar una tarea.

Mensajes: Los mensajes son flechas que representan comunicaciones

entre objetos. Las medias flechas representan mensajes asincrnicos.
Los mensajes asincrnicos son enviados desde un objeto que no va a esperar una
respuesta del receptor para continuar con sus tareas.

Un mensaje puede ser simple, sncrono y asncrono

Mensaje simple: es la transferencia del control de un objeto a otro.
Mensaje sncrono: es cuando el objeto espera la respuesta a ese mensaje
antes de continuar con su trabajo.
Mensaje asncrono: es cuando el objeto no espera la respuesta a ese
mensaje antes de continuar.

Recursividad: En ocasiones un objeto posee una operacin que se invoca a si

misma. A esto se le conoce como recursividad y es una caracterstica fundamental
de varios lenguajes de programacin.
Lneas de Vida: Las lneas de vida son verticales y en lnea de puntos, ellas indican
la presencia del objeto durante el tiempo.

Destruccin de Objetos: Los objetos pueden ser eliminados tempranamente

usando una flecha etiquetada <<destruir>> que apunta a una X.

Loops: Una repeticin o loop en un diagrama de secuencias, es representado como

un rectngulo. La condicin para abandonar el loop se coloca en la parte inferior
entre corchetes [].
 Diagramas De Colaboracin
Los diagramas de colaboracin muestran las interacciones que ocurren entre los
objetos que participan en una situacin determinada. Esta es ms o menos la misma
informacin 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 colaboracin fijan el inters en las relaciones entre los objetos y su topologa.
En los diagramas de colaboracin los mensajes enviados de un objeto a otro se
representan mediante flechas, mostrando el nombre del mensaje, los parmetros y
la secuencia del mensaje. Los diagramas de colaboracin estn indicados para
mostrar una situacin o flujo programa especficos y son unos de los mejores tipos
de diagramas para demostrar o explicar rpidamente un proceso dentro de la lgica
del programa. En versiones recientes de UML este diagrama ha sido reemplazado
por el diagrama de comunicacin.

Los diagramas de colaboracin tienen dependencias a los siguientes artefactos

para su construccin: Los casos de uso (expandidos), Diagrama de secuencias,
Diagrama de Clases. Y los artefactos que se generan ya establecidos estos son:
Diagramas de Estado, Diagrama de Componentes, Diagrama de Despliegue.

Interacciones
Las Interacciones modelan aspectos dinmicos del sistema
Llamada: Invoca una operacin sobre un objeto. Puede ser a s mismo.

Retorno: El receptor de una llamada devuelve un valor al emisor, si es necesario.

Envo: Enva una seal a un objeto.

Creacin: Para crear un objeto.

Destruccin: Para destruir un objeto. Puede destruirse a s mismo.

Secuenciacin
El flujo de mensajes forma una secuencia.
La secuencia es indicada por un nmero antes del mensaje y una flecha
dirigida.
Para modelar caminos alternativos, se coloca el mismo nmero de secuencia
seguido de un nmero de subsecuencia.
Elementos de un Diagrama de Colaboracin
Objetos o Roles: nodos del grafo.
Enlaces o comunicaciones: arcos del grafo.
Mensajes: llevan nmero de secuencia y flecha dirigida.
Anidamiento: se utiliza la numeracin decimal
Iteracin: colocar un * antes del nmero de secuencia y una clusula de condicin,
si es necesario. ej. *[x>0].
Bifurcacin: los caminos alternativos tendrn el mismo nmero de secuencia,
seguido del nmero de subsecuencia, y se deben distinguir por una condicin.

Elementos bsicos
Objeto: se representa con un rectngulo, que contiene el nombre y la clase del
objeto en un formato nombreObjeto: nombreClase.
Enlaces: Un enlace es una instancia de una asociacin en un diagrama de clases.
Se representa como una lnea continua que une a dos objetos. Esta acompaada
por un nmero que indica el orden dentro de la interaccin y por un estereotipo que
indica que tipo de objeto recibe el mensaje.
Flujo de mensajes: Expresa el envo de un mensaje. Se representa mediante una
flecha dirigida cercana a un enlace.
Marcadores de creacin y destruccin de objetos: Puede mostrarse en la grfica
cules objetos son creados y destruidos, agregando una restriccin con la
palabra new o delete, respectivamente, cercana al rectngulo del objeto

Notacin.
Notacin Bsica: Objetos y Mensajes

Notacin Bsica: Asociaciones

Notacin Bsica: Mensajes y

Parmetros
 Diagrama De Estados
Los diagramas de estado son un mtodo conocido para explicar el comportamiento
de un sistema. Que explican todos los estados posibles en los que puede ingresar
un objeto particular y la manera en que modifica el estado del objeto, como resultado
de los eventos que llegan a l. Un diagrama de estados es un diagrama utilizado
para determinar cada una de las rutas o caminos que puede tomar un movimiento
de informacin luego de ejecutarse cada proceso. Permite identificar bajo qu
pruebas se ejecuta cada uno de los procesos y en qu momento podran tener una
variacin. El diagrama de estados permite visualizar de una forma ordenada la
ejecucin de cada uno de los procesos. En un diagrama de estados, un escenario
simboliza un camino dentro del diagrama. Dado que generalmente el espacio entre
dos envos de mensajes representa un estado, se pueden utilizar los diagramas de
secuencia para buscar los diferentes estados de un objeto.

Elementos Del Diagrama De Estados

Estado: Determina un lapso de tiempo del objeto, en el cual el objeto est
esperando alguna ejecucin, tiene cierta caracterstica o puede obtener cierto tipo
de estmulos.
Eventos: Es una ocurrencia que puede causar el cambio de un estado a otro de un
objeto. Esta ocurrencia puede ser:
Condicin que obtiene el valor de verdadero o falso.
Recepcin de una seal de otro objeto en el modelo.
Recepcin de un mensaje.
Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta
hora y fecha particular.
El nombre de un evento tiene alcance dentro del paquete en el cual est definido,
no es local a la clase que lo nombre.
Envo de mensajes: Aparte de mostrar la transicin de estados por medio de
eventos, puede representarse el momento en el cual se envan mensajes a otros
objetos. Esto se ejecuta a travs de una lnea punteada dirigida al diagrama de
estados del objeto receptor del mensaje.
Transicin simple: Una transicin simple es un vnculo entre dos estados que
seala que un objeto en el primer estado puede entrar al segundo estado y ejecutar
ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son
satisfechas. Se protagoniza como una lnea slida entre dos estados, que puede
estar acompaada de un texto con el siguiente formato:
Event-signature, "[" Guard-condition] ", " action-expression ", "send-clause".
Event-signature es la explicacin del evento que da lugar a la transicin.
Guard-condition son las condiciones adicionales al evento, necesarias para
que la transicin ocurra.
Action-expression es un mensaje al objeto o a otro objeto que se ejecuta
como resultado de la transicin y el cambio de estado.
Send-clause son operaciones adicionales que se realizan con el cambio de
estado, por ejemplo, el envo de eventos a otros paquetes o clases.
Transicin interna: Sigue en el mismo estado, en vez de implicar dos estados
distintos. Representa un evento que no causa cambio de estado. Se denota como
una cadena adicional en el compartimiento de acciones del estado.
Acciones: Podemos especificar la solicitud de un servicio a otro objeto como
consecuencia de la transicin. Se puede especificar al realizar una accin como
consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento.
Generalizacin de Estados: Podemos reducir la complejidad de estos diagramas
usando la generalizacin de estados, Distinguimos as entre superestado y
subestados., Un estado puede obtener varios subestados disjuntos, Los subestados
heredan las variables de estado y las transiciones externas, La agregacin de
estados es la composicin de un estado a partir de varios estados independientes.
Subestados: Un estado puede separarse en varios subestados, con transiciones
entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior
como estados de inicio o fin, los cuales se suponen conectados a las entradas y
salidas del nivel inmediatamente superior.
Transaccin Compleja: Una transicin compleja relaciona tres o ms estados en
una transicin de mltiples fuentes y/o mltiples destinos. Representa la subdivisin
en discusiones del control del objeto o una sincronizacin. Se representa como una
lnea vertical de la cual salen o entran varias lneas de transicin de estado.
Transicin a estados anidados: Una transicin de hacia un estado complejo
(descrito mediante estados guardados) significa la entrada al estado inicial del
subdiagrama. Las transiciones que salen del estado complejo se definen como
transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de
profundidad).
Transiciones temporizadas: Las esperas son actividades que tienen asociada
cierta duracin, La actividad de espera se interrumpe cuando el evento esperado
tiene lugar, Este evento desencadena una transicin que permite salir del estado
que alberga la actividad de espera. El flujo de control se transmite entonces a otro
estado.

Notacin
 Diagrama De Actividades
El diagrama de actividades es una variacin directa del diagrama de estados,
nicamente que el diagrama de actividades est enfocado a las actividades y a los
eventos que hacen cambiar de actividad y que no precisamente los nodos son
actividades sino tambin pueden ser estados. Por ejemplo, en un diagrama de
estados, los nodos son: encendido, funcionando, reiniciado, apagado, como lo ven
son estados mientras que en un diagrama de actividades los nodos son encender,
poner en funcionamiento, reiniciar o apagar, como lo notan son actividades que
implican una accin.

Un diagrama de Actividad consiste en mostrar el conjunto de actividades que ocurre

durante un proceso, as mismo indica las posibles rutas que pueden irse
desencadenando en el caso de uso o sirve para modelar la lgica detallada en una
regla de negocio. Tambin ayuda a auxiliar a los miembros del equipo de desarrollo
a entender como es utilizado el sistema y cmo reacciona en determinados eventos.
En muchos sentidos, diagramas UML de actividad son el equivalente orientado a
objetos de los diagramas de flujo y diagramas de flujos de datos (DFD) de desarrollo
estructurado, pero se puede decir que un diagrama de actividades describe el
problema, mientras un diagrama de flujo describe la solucin. La informacin para
elaborar los diagramas de actividad se obtiene de los casos de uso y los
requerimientos.

Para qu sirve el diagrama de actividades?

Capturar las acciones internas de un proceso.
Capturar la especificacin de un caso de uso.
Mostrar flujos entre procesos del negocio.
Describe un proceso de negocio o un flujo de trabajo entre los usuarios y el
sistema.
Describe los pasos que se realizan en un caso de uso.
Describe un protocolo de software, es decir, las secuencias de interacciones
entre componentes permitidas.
Describe un algoritmo de software.

Estructura de un diagrama de actividades

Para desarrollar un diagrama de actividades debe poseer los siguientes elementos:
Inicio: El inicio de un diagrama de actividad es representado por
un crculo de color negro slido.
Actividad: Una actividad representa la accin que ser realizada
por el sistema la cual es representada dentro de un ovalo, luego
de realizarse, se continua con la siguiente actividad.
Transicin: Una transicin ocurre cuando se lleva acabo el
cambio de una actividad a otra, la transicin es representada
simplemente por una lnea con una flecha en su terminacin para
indicar direccin.
Elementos

Otros Elementos

Objetos: En un diagrama de actividad es posible presentar los objetos que entran

o salen de una actividad o que simplemente son afectados por ella.
 Diagramas De Componentes
En los diagramas de componentes se muestran los elementos de diseo de un
sistema de software. Un diagrama de componentes permite visualizar con ms
facilidad la estructura general del sistema y el comportamiento del servicio que estos
componentes proporcionan y utilizan a travs de las interfaces. Puede usar un
diagrama de componentes para describir un diseo que se implemente en cualquier
lenguaje o estilo. Solo es necesario identificar los elementos del diseo que
interactan con otros elementos del diseo a travs de un conjunto restringido de
entradas y salidas. Los componentes pueden tener cualquier escala y pueden estar
interconectados de cualquier manera. Los diagramas de componentes muestran los
componentes del software (ya sea las tecnologas 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
cdigo fuente, las libreras o las tablas de una base de datos. Los componentes
pueden tener interfaces (es decir clases abstractas con operaciones) que permiten
asociaciones entre componentes. "Los diagramas de componentes se generan a
partir del diagrama de clases"

Caractersticas
Los diagramas de componentes describen los elementos fsicos del sistema
y sus relaciones
Muestran las opciones de realizacin incluyendo cdigo fuente, binario y
ejecutable
Los componentes representan todos los tipos de elementos software que
entran en la fabricacin de aplicaciones informticas
Pueden ser simples archivos, paquetes, bibliotecas cargadas
dinmicamente, etc.

Pasos para la elaboracin de un diagrama de componentes

Previamente al diagrama de componentes debemos tener hecho el diagrama
de las clases.
Se debe identificar a todas las clases que participaran en el sistema o sub
sistema a desarrollar.
Una vez identificadas las clases, se procede a identificar sus mtodos.
Estos mtodos pasaran a ser mdulos con lneas de cdigo independientes.
Estos mdulos sern los componentes de nuestro diagrama.
Estos componentes se relacionan entre si por medio de sus interfaces.

UML define 5 estereotipos estndar que se aplican en los componentes

Executable: componente que se puede ejecutar.
Library: biblioteca de objetos esttica o dinmica.
Table: componentes que representan una tabla de base de datos.
File: componente que representa un documento que contiene cdigo fuente o dato.
Document: componente que representa un documento.
Elementos del diagrama de componentes
Componentes: Es una parte fsica de un sistema (modulo, base de datos, programa
ejecutable, etc.). se puede decir que un componente es la materializacin de una o
ms clases, porque una abstraccin con atributos y mtodos pueden ser
implementados en los componentes. Los componentes se pueden agrupar en
paquetes, as como los objetos en clases, adems puede haber entre ellos
relaciones de dependencia como: generalizacin, asociacin, agregacin y
realizacin. Un componente se representa con un rectngulo en el que se escribe
su nombre y en l se muestran dos pequeos rectngulos al lado izquierdo.

Interfaz: es el lazo de unin entre varios componentes. Se representa como un

pequeo crculo situado junto al componente que lo implementa y unido a el por una
lnea continua. La interfaz puede tener un nombre que se escribe junto al crculo.
Un componente puede proporcionar ms de una interfaz.

Interfaces Requeridas: El conector Ensamble une la interfaz requerida del

componente (Componente1) con la interfaz proporcionada de otro
componente (Component2); esto permite que un componente provea los
servicios que otro componente requiere. Las Interfaces son colecciones de
uno o ms mtodos que pueden o no contener atributos.

Paquetes o Subsistemas: Los distintos componentes pueden agruparse en

paquetes segn un criterio lgico y con vistas a simplificar la implementacin Un
paquete se representa con un icono de carpeta.

Son paquetes estereotipados en <<subsistemas>>, Los subsistemas organizan la

vista de realizacin de un sistema, Cada subsistema puede contener componentes
y otros subsistemas, La descomposicin en subsistemas no es necesariamente una
descomposicin funcional, La relacin entre paquetes y clases en el nivel lgico es
el que existe entre subsistemas y componentes en el nivel fsico

Relacin de dependencia: Una relacin de dependencia se representa mediante

una lnea discontinua con una flecha que apunta al componente o interfaz que
provee del servicio o facilidad al otro. La relacin puede tener un estereotipo que se
coloca junto a la lnea, entre el smbolo: <<...>>