Diagramas UML 2.0

1. PROFESOR:
Ing. Juan Alexander Anderson Huerta.
ALUMNOS:
Contreras Pineda Jessica. 06040292
Contreras Valdez Blanca Élide. 06040293
Franco Valtierra Perla Janette. 06040302
Gutiérrez Rodríguez Marco A. 05040998
FECHA: 24 Agosto del 2009

2. Se clasifican en tres clases:
 Diagramas de comportamiento: Permiten exhibir
comportamientos de un sistema o de los procesos de las
organizaciones. Incluyen los diagramas de actividad,
estado, caso típico y de interacción.
 Diagramas de interacción: Es un subconjunto de los
diagramas de comportamiento que permiten enfatizar las
interacciones entre los objetos. Incluyen comunicación,
vista general de interacciones, secuencia y diagrama de
tiempo.
 Diagramas de estructura: Muestran los elementos de una
especificación que sean independientes del tiempo.
Incluyen clase, estructura de componentes, componente,
despliegue, objeto y diagramas de paquetes.

4. Diagrama de Clases.
Diagrama de Estructuras
Compuestas.
Diagrama de Componente.
Diagrama de Despliegue.
Diagrama de Objeto.
Diagrama de Paquetes.
Diagrama de Actividad.
Diagrama de Interacción.
Diagrama de Casos de Uso.
Diagrama de Maquina de
Estado.
Diagrama de Secuencia.
Diagrama de Comunicación.
Diagrama de Resumen de
Interacción.
Diagrama de Tiempo
Conclusiones.
Bibliografía

5. ¿Que es un diagrama de Clases?
Representación de:
 Requerimientos en Entidades y Actuaciones.
 La arquitectura conceptual de un dominio.
 Soluciones de diseño en una arquitectura.
 Componentes de software orientado a objetos.
¿Qué es una Clase?
Artefacto de modelado que Describe un conjunto de objetos que
comparten los mismos:
 Atributos (conocimiento)
 Operaciones (responsabilidad)
 Relaciones (entrelazamiento)
 Semántica (relevancia)

6. ¿Para qué usamos un diagrama de Clases?
Modelar los aspectos estáticos de un sistema
• Realizar la abstracción de un dominio
• Formalizar el análisis de conceptos
• Definir una solución de diseño
• Construir componentes de software

7. ELEMENTOS DE UN DIAGRAMA DE CLASES
 Clase: atributos, métodos y visibilidad.
 Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
 Clase : Es la unidad básica que encapsula toda la
información de un Objeto (un objeto es una instancia de
una clase).
 Atributo: Variables de instancia que caracterizan a la
Clase (pueden ser private, protected o public).
 Método: Son la forma como interactúa el objeto con su
entorno (dependiendo de la visibilidad: private,
protected o public).

8. EJEMPLO:
Una Cuenta Corriente que posee como característica:
• Balance
Puede realizar las operaciones de:
• Depositar
• Girar
• Balance
El diseño asociado es:

9. RELACIONES ENTRE CLASES
 Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por
una Super Clase, por ende la Subclase además de poseer sus propios
métodos y atributos, poseerá las características y atributos visibles de la
Super Clase (public y protected).
Ejemplo:

10.  Agregación:
Para modelar objetos complejos, n bastan los tipos de datos básicos 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 aplicación.
Ejemplo:

11.  Asociación:
La relación entre clases conocida como Asociación,
permite asociar objetos que colaboran entre si. Cabe
destacar que no es una relación fuerte, es decir, el
tiempo de vida de un objeto no depende del otro.
 Ejemplo:

12.  Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que una clase
es instanciada (su instanciación es dependiente de otro
objeto/clase). Se denota por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la
dependencia que tiene una clase de otra, como por ejemplo una
aplicación grafica que instancia una ventana (la creación del
Objeto Ventana esta condicionado a la instanciación proveniente
desde el objeto Aplicación):
Volver

13.  Un diagrama de Estructura Compuesta refleja la
colaboración interna de clases, interfaces o
componentes para describir una funcionalidad. Los
diagramas de estructura compuesta son similares a los
diagramas de clase, a excepción de que estos modelan
un uso especifico de la estructura. Los diagramas de
clase modelan una vista estática de las estructuras de
clase, incluyendo sus atributos y comportamientos.
Un diagrama de Estructura Compuesta se usa para
expresar arquitecturas en tiempo de ejecución,
patrones de uso, y las relaciones de los elementos
participantes, los que pueden no estar reflejados por
diagramas estáticos.

14.  En un diagrama de Estructura Compuesta, las clases se
acceden como partes o instancias en tiempo de
ejecución cumpliendo un rol en particular. Estas partes
pueden tener multiplicidad, si el rol ocupado por la
clase requiere múltiples instancias. Los puertos
definidos por una clase de parte deberían
representarse en la estructura compuesta,
asegurando que todas las partes conectadas provean
las interfaces requeridas especificadas por el puerto.
Hay una flexibilidad extensa, y una complejidad
resultante que viene con el modelado de estructuras
compuestas. Para optimizar su modelado, considere
las colaboraciones de compilación para representar
los patrones reusables respondiendo a su problemas
de diseño.

15. Conceptos de estructura compuesta
 Las entidades de estructura compuesta claves identificadas en la especificación UML 2.0 son
clasificadores estructurados, partes, puertas, conectores, y colaboraciones.
 Parte
Una parte representa un rol jugado en tiempo de ejecución por una instancia de una clase o
por una colección de instancias. La parte puede nombrar solamente un rol, una superclase
abstracta, o puede nombrar una clase concreta específica. La parte puede incluir un factor de
multiplicidad (cardinalidad), tal como el [0..*] mostrado para Viewer en el diagrama.
 Puerta
Una puerta es un punto de interacción que puede ser usado para conectar clasificadores
estructurados con sus partes y con el ambiente. Las puertas pueden opcionalmente
especificar los servicios que proveen y los servicios que requieren de otras partes del sistema.
En el diagrama, cada uno de los cuadrados pequeños es una puerta. Cada puerta tiene un tipo
y esta etiquetado con un nombre, tal como "var", "indVar1", or "view" en el diagrama. Las
puertas pueden contener un factor de multiplicidad, por ejemplo .
Las puertas pueden ya sea delegar los requerimientos recibidos a partes internas, o pueden
entregarlos directamente para el comportamiento del clasificador estructurado en el que la
puerta está contenido. Las puertas públicas que son visibles en el ambiente son mostradas
sobre el borde (límite o frontera), mientras que las puertas protegidas que no son visibles en
el ambiente son mostradas dentro de la frontera (borde o límite). Todas las puertas en el
diagrama son privadas, excepto por la puerta view a lo largo del límite derecho de
FibonacciSystem.

16.  Conector
Un conector une dos o más entidades, permitiéndoles interactuar en tiempo
de ejecución. Un conector es representado por una línea que une una
combinación de partes, puertas y clasificadores estructurados. El diagrama
muestra tres conectores entre puertas, y un conector entre un clasificador
estructurado y una parte.
 Colaboración
Una colaboración es generalmente más abstracta que un clasificador
estructurado. Ésta es mostrada como un óvalo sin relleno conteniendo los
roles que las instancias pueden jugar en la colaboración.
 Clasificador estructurado
Un ClasificadorEstructurado representa una clase, frecuentemente una clase
abstracta, cuyo comportamiento puede ser completa o parcialmente
descrito mediante interacciones entre partes.
Un ClasificadorEncapsulado es un tipo de clasificador estructurado que
contiene puertas. En el diagrama abajo, ambos FibonacciSystem y Variable
son clasificadores encapsulados, porque ambos tienen puertas a lo largo de
sus límites.

17.  Ejemplo de diagrama de estructura compuesta
Como ejemplo, considere un modo posible de modelar la producción de la Sucesión de
Fibonacci.
Diagrama de estructura compuesta UML 2.0
Este diagrama de estructura compuesta UML 2.0 especifica que las instancias de la
clase 'FibonacciSystem' están compuestas de varias partes. La superior de estas partes
está identificada como teniendo el clasificador 'FibonacciFunction'. Tres de las partes
son identificadas por el rol que ellas juegan dentro de instancias del FibonacciSystem –
el rol NMinus2, el rol NMinus1, y el rol N. La quinta parte, identificada por su clasificador
Viewer, incluye una especificación de multiplicidad. En tiempo de ejecución puede
haber 0 o más instancias de Viewer o de alguna subclase concreta de Viewer.
En tiempo de ejecución las instancias de clase que implementan estos tres roles deben
proveer los servicios especificados por la interfaz IVar mediante sus puertas var. Una de
tales clases es Variable, mostrada sobre el diagrama con una puerta llamada var de tipo
Var que realiza la interfaz IVar.
La puerta llamada "view" es una puerta no-pública que puede ser usada por una
instancia de FibonacciSystem para acceder a la(s) instancia(s) opcional(es) de Viewer.

18. La puerta llamada "view" es una puerta no-pública que puede ser
usada por una instancia de FibonacciSystem para acceder a la(s)
instancia(s) opcional(es) de Viewer.
Volver

19. ¿Qué es un componente?
 Un elemento de Software de un sistema, y se encuentra en el computador, Puede ser una
tabla, archivo de datos, archivos ejecutables, biblioteca de vínculos dinámicos, documentos
etc., Un componente es la personificación en software de las clases. Si lo vemos desde el
punto de vista de la programación un componente agrupará a las clases que son las que
representarán la lógica del negocio,
 Quienes formaran componentes reutilizables, ya que si tomamos como referencia la
construcción de un sistema para un negocio pequeño probablemente empiece utilizando una
base de datos de Access, y posteriormente se podrá cambiar a Sql- Server y luego a Oracle,
por consiguiente estos componentes deben ser reutilizables con cualquiera de los
administradores de base de datos seleccionados de acuerdo a los requerimientos.
 Mediante los diagramas de componentes el jefe del desarrollo podrá hacer referencia a las
partes con mayor objetividad con el grupo de desarrollo.

20. Notacion componente.
El presente diagrama de componentes indica que el formulario de
mantenimiento estará compuesto por el formularioBusqueda que seencuentra
en elcomponente Herramientas, así como también la clase botonSalir y
formulario debusquedaCliente, se encuentran en el mismo componente.

21.  Definición Simple
 Un componente es una parte física y reemplazable de un sistema.
agentefraudes.dll
nombre agente.java Realiza
Ej: AgenteFraudes
PoliticaFraudes
BuscarPatrones
system::dialog.dll
{version = 2.0.1}

22.  Componentes y clases
Las clases representan abstracciones lógicas. Los componentes
son elementos físicos del mundo real. Un componente es la
implementación física de un conjunto de otros elementos
lógicos, como clases y colaboraciones.
Ejemplo de un componente y las clases que implementa:
agentefraudes.dll
AgenteFraudes BuscarPatrones
PoliticaFraudes

23.  Dependencias entre componentes Volver
La dependencia entre dos componentes se muestra como una flecha
punteada. La dependencia quiere decir que una componente necesita de
la otra para completar su definición.
Ejemplos: Window Handler
(whnd.cpp)
Graphic lib
<<page>> (graphic.dll)
home.html
Comm Handler Window Handler
(comhnd.cpp) (whnd.obj)
<<file>>
animlogo.java Main Class Comm Handler
(main.cpp) (comhnd.obj)
<<file>> Main Class Client Program
animator.java (main.obj) (client.exe)

24. Describen la arquitectura física del sistema durante la
ejecución, en términos de:
o procesadores
o dispositivos
o componentes de software
• Describen la topología del sistema: la estructura de
los elementos de hardware y el software que ejecuta
cada uno de ellos.

25. • Los nodos son objetos físicos que existen en tiempo
de ejecución, y que representan algún tipo de recurso
computacional (capacidad de memoria y
procesamiento):
o Computadores con procesadores
o Otros dispositivos
o impresoras
o lectoras de códigos de barras
o dispositivos de comunicación
máquina1:
Dell Pentium
Ventas Dell Pentium 466 MMX
466 MMX
Despliega
pos.exe
contactos.exe

26.  Dispositivos
o Los dispositivos del sistema también se representan
como nodos.
o Generalmente se usan estereotipos para identificar el
tipo de dispositivo.
<<printer>> <<router>>
HP LaserJet Cisco Router
5MP X2000

27. Los nodos se conectan mediante asociaciones de comunicación.
o Estas asociaciones indican:
o Algún tipo de ruta de comunicación entre los nodos
o Los nodos intercambian objetos o envían mensajes a través
de esta ruta
o El tipo de comunicación se identifica con un estereotipo que
indica el protocolo de comunicación o la red.
clienteA:
Compaq Pro PC
Servidor de
Servidor de Base de
Aplicaciones:
Datos: VAX
Silicon Graphics O2
clienteB: <<DecNet>>
Compaq Pro PC

28.  Nodos y componentes
 Los nodos son los elementos donde se ejecutan los componente
Ventas
pos.exe contactos.exe
o Si un tipo de componente puede ejecutarse en un tipo de nodo, se crea una
dependencia con el estereotipo <<supports>>
o Una instancia de la componente podría localizarse en una instancia de ese
nodo.
UNIX Transaction
Server Program
Silicon
<<supports>>
Graphics O2

29.  Instancias ejecutándose en un nodo.
máquina1:Dell Pentium 466 MMX
cliente1:Cliente
<<library>>
CL:Transaction
Client Library
Volver

30.  Muestra los objetos y sus interrelaciones en un tiempo
dado, habitualmente en los casos especiales de un
diagrama de clase o de comunicaciones.
 Los diagramas de objetos son utilizados durante el proceso
de Análisis y Diseño de los sistemas informáticos en la
metodología UML.
 Se puede considerar un caso especial de un diagrama de
clases en el que se muestran instancias específicas de
clases (objetos) en un momento particular del sistema. Los
diagramas de objetos utilizan un subconjunto de los
elementos de un diagrama de clase. Los diagramas de
objetos no muestran la multiplicidad ni los roles, aunque su
notación es similar a los diagramas de clase.

31.  Una diferencia con los diagramas de clase es que el
compartimiento de arriba va en la forma, Nombre de
objeto: Nombre de clase.
Por ejemplo:
Volver

32.  En el Lenguaje Unificado de Modelado, un diagrama de
paquetes muestra como un sistema está dividido en
agrupaciones lógicas mostrando las dependencias entre
esas agrupaciones. Dado que normalmente un paquete
está pensado como un directorio, los diagramas de
paquetes suministran una descomposición de la jerarquía
lógica de un sistema.
 Los Paquetes están normalmente organizados para
maximizar la coherencia interna dentro de cada paquete y
minimizar el acoplamiento externo entre los paquetes. Con
estas líneas maestras sobre la mesa, los paquetes son
buenos elementos de gestión. Cada paquete puede
asignarse a un individuo o a un equipo, y las dependencias
entre ellos pueden indicar el orden de desarrollo requerido.

33.  Además de la relación estándar UML de dependencia, hay dos tipos especiales de
las dependencias entre los paquetes se definen:
 package import de importación de paquetes
 package merge paquete de combinación de correspondencia
 Un paquete de importación es "una relación entre un espacio de nombres de
importación y un paquete, lo que indica que el espacio de nombres de
importación, añade los nombres de los miembros del paquete a su propio espacio
de nombres". Por defecto, una dependencia entre dos paquetes sin etiqueta se
interpreta como de una relación de importación de paquetes.
 Un paquete de importación es "una relación entre un espacio de nombres de
importación y un paquete, lo que indica que el espacio de nombres de
importación, añade los nombres de los miembros del paquete a su propio espacio
de nombres". Por defecto, una dependencia entre dos paquetes sin etiqueta se
interpreta como de una relación de importación de paquetes
 Un paquete de mezcla es "una relación entre dos paquetes dirigidos, que indica
que el contenido de los dos paquetes se pueden combinar. Es muy similar a la
generalización en el sentido de que el elemento conceptual fuente añade las
características del elemento objetivo a su propio características resultantes de un
elemento que combina las características de ambos

34.  Diagramas de paquetes puede utilizar los paquetes
que contienen los casos de uso para ilustrar la
funcionalidad de un sistema de software.
 Diagramas de paquetes puede utilizar los paquetes
que representan las diferentes capas de un sistema de
software para ilustrar la arquitectura en capas de un
sistema de software. Las dependencias entre estos
paquetes pueden ser adornadas con etiquetas o
estereotipos para indicar el mecanismo de
comunicación entre las capas.

35. Diagrama de paquetes que contienen nodos y artefactos
Volver

36.  En el Lenguaje de Modelado Unificado, un diagrama
de actividades representa los flujos de trabajo paso a
paso de negocio y operacionales de los componentes
en un sistema. Un Diagrama de Actividades muestra el
flujo de control general.
 En SysML el diagrama de Actividades ha sido
extendido para indicar flujos entre pasos que mueven
elementos físicos (e.g., gasolina) o energía (e.g.,
presión). Los cambios adicionales permiten al
diagrama soportar mejor flujos de comportamiento y
datos continuos.

37.  El diagrama de Actividades UML 2.0, mientras que es similar
en aspecto al diagrama de Actividades UML 1.x, ahora tiene
semánticas basadas en redes de Petri. En UML 2.0, el
diagrama general de Interacción está basado en el
diagrama de Actividades.
 Diagrama de actividad. Es una forma especial de diagrama
de estado usado para modelar una secuencia de acciones y
condiciones tomadas dentro de un proceso.
 La especificación del Lenguaje de Modelado Unificado
OMG define un diagrama de actividad como: “… una
variación de una máquina estados, lo cual los estados
representan el rendimiento de las acciones o
subactividades y las transiciones se provocan por la
realización de las acciones o subactividades[BELL00].”
 El propósito del diagrama de actividad es modelar un
proceso de flujo de trabajo (workflow) y/o modelar
operaciones. Una Operación es un servicio proporcionado
por un objeto, que está disponible a través de una interfaz.
Una Interfaz es un grupo de operaciones relacionadas con
la semántica.

38. Volver

39. Los diagramas UML de secuencia y de colaboración
(llamados diagramas de interacción) se utilizan para
modelar los aspectos dinámicos de un sistema.
Un diagrama de interacción consiste en un conjunto
de objetos y sus relaciones, incluyendo los mensajes
que se pueden enviar entre ellos.
Los diagramas de secuencia destacan el orden
temporal de los mensajes. Los diagramas de
colaboración destacan la organización estructural de
los objetos que envían y reciben mensajes.

40. objetoA:A objetoB:B objetoC:C
Diagrama de secuencia:
destaca el orden temporal <<create>>
mensaje1( )
de los mensajes. mensaje2( )
mensaje3( )
mensaje4( )
objetoA:A
1: <<create>>
2: mensaje1( )
3: <<destroy>>
Diagrama de colaboración:
objetoB:B objetoC:C destaca la relación estructural
2.1: mensaje2( )
entre los objetos que interactúan
2.2: mensaje3( )

41. o Ambos diagramas (secuencia y colaboración) son
semántica mente equivalentes. Se puede pasar de uno
a otro sin pérdida de información.
o En los diagramas de secuencia, la linea de vida de un
objeto es la línea discontinua vertical, que representa
La existencia de un objeto a lo largo de un periodo de
tiempo.
o El foco de control es un rectángulo delgado que
representa el periodo de tiempo durante el cual un
objeto ejecuta una acción.
Volver

42.  ¿Qué es un Caso de Uso?
Pieza de funcionalidad reusable que define la cadena de valor de
los Actores que interactúan con un Sistema.

43.  ¿Para que lo usamos?
1. Empaquetar los escenarios de usabilidad de un sistema.
2. Facilitar la trazabilidad entre los requerimientos y los
distintos artefactos de modelado: Clases, Objetos,
Acciones, Estados, etc., hasta el código.
3. Describir una secuencia de acciones que podemos
organizar en escenarios tipo.
4. Representan todas las maneras posibles de usar los
recursos de un sistema/organización.
5. Despiezar un proceso en funciones reutilizables.
6. Comunicar el alcance y complejidad funcional de un
producto (Censo de Casos de Uso Candidatos).
7. Especificar un “contrato de servicios”entre los Actores y
el Sistema.

44. 1.Diagrama de Casos de Uso
 Elementos del modelo de Casos de Uso
 Especialización de Casos de Uso abstractos

47. 2. Especificación.
 •Nombre
 •Activador
 •Propósito
 •Precondiciones
 •Postcondiciones
 •Invariantes
 •Escenario principal
 •Escenarios posibles
 •Escenarios probables
 •Interfaces con otros CU
 •Interfaces con Actores
 •Objetos participantes

48.  3. Diseño de interfaces con los Actores

49.  4.Formalización de escenarios
con diagramas de Actividad.
 5.Normalización de escenarios
con diagramas de Secuencia
(interacción de objetos).

50.  6.Objetos participantes
en cada escenario de
usabilidad con diagramas
de Clases.
 7.Ciclo de Vida de objetos
complejos con diagramas
de Estados-Transición.

51. 8. Casos de Prueba
 Procedimiento que certifica la coherencia,
completitud y usabilidad de un Sistema, en referencia
a un contrato de funcionalidad establecido con sus
Actores y especificado a través de los Casos de Uso.
 Utiliza artefactos de modelado UML como mecanismo
formal para expresar las precondiciones y
postcondiciones, los resultados esperados y los
observados, secuencias de eventos y parámetros de
entrada.
Volver

52.  Un diagrama de maquina de estado modela el comportamiento de un solo objeto,
especificando la secuencia de eventos que un objeto atraviesa durante su tiempo
de vida en respuesta a los eventos.
Como ejemplo, el siguiente diagrama de maquina de estado muestra los estados
que una puerta atraviesa durante su tiempo de vida.

53.  La puerta puede estar en uno de tres estados:
“Opened”(Abierta), “Closed” (Cerrada) o “Locked”(Bloqueada).
Puede responder a tres estados Abrir, Cerrar, Bloquear y No
bloqueado. Tener en cuenta que no todos los eventos son válidos
en todos los estados: por ejemplo, si una puerta está abierta, no
lo puede bloquear hasta que lo cierre. También tener en cuenta
de que como una transición de estado puede tener una condición
de guarda adjunta. Si la puerta está abierta, esta solo puede
responder al Evento cerrar si la condición doorWay->isEmpty esta
completa. La sintaxis y las conexiones usadas en los diagramas
de maquina de estados se discutirán por completo en las
siguientes secciones.

54.  Estados
Un estado se denota por un rectángulo con las esquinas
redondeadas y con el nombre del estado escrito dentro del
mismo.
 Estados Initial y Final (Iniciales y Finales)
El estado inicial se denota con un círculo negro y se le puede
proporcionar un nombre. El estado final se denota con un
círculo con un punto negro en el medio y también se lo puede
nombrar.

55.  Transiciones
Las transiciones desde un estado al siguiente se denotan
por líneas con flechas. Una transición puede tener un
disparador, una guarda y un efecto, como a continuación.
 “Trigger” (Disparador) es la causa de la transición, la cual
podría ser una señal, un evento, un cambio en alguna
condición, o el pasaje de tiempo. "Guard" (guarda) es una
condición que debe ser verdadera para que el disparador
cause la transición. "Effect" (efecto) es una acción que se
llamará directamente en el objeto que tiene la maquina de
estado como resultado de la transición.

56.  Acciones de Estado
En el ejemplo de transición, un efecto se asoció con la transición.
Si el estado de destino tenía muchas transiciones llegando al
mismo, y cada transición tenía el mismo efecto asociado con
este, sería mejor asociar el efecto con el estado de destino en
lugar de con las transiciones. Esto se puede realizar para definir
una acción de entrada para el estado. El siguiente diagrama
muestra un estado con una acción de entrada y una acción de
salida.
 También es posible definir las acciones que ocurren en los
eventos, o acciones que siempre ocurren. Es posible definir
cualquier número de acciones de cada tipo.

57.  Transiciones recursivas
Un estado puede tener una transición que retorna a sí misma, como en el
siguiente diagrama. Esto es más útil cuando un efecto se asocia con la transición.
 Estados Compuestos
Un diagrama de maquina de estado puede incluir diagramas de sub maquinas,
como en el siguiente ejemplo.
La notación en la versión anterior indica que
La forma alternativa de mostrar la misma los detalles de la sub maquina Check Pin se
información es como el siguiente ejemplo. muestran en un diagrama separado.

58.  Punto de Entrada
Algunas veces no deseará ingresar una sub maquina en un Estado Inicial
normal. Por ejemplo, en la siguiente sub maquina sería normal comenzar
en el estado inicial, pero si por alguna razón no fuera necesario realizar la
inicialización, sería posible comenzar en el estado Ready realizando una
transición al punto de entrada nombrado.
El siguiente diagrama muestra la maquina de estado un nivel hacia arriba:

59.  Punto de Salida
Similar al Punto de Entada, es posible nombrar Puntos de Salida nombrados. El
siguiente diagrama provee un ejemplo donde el estado ejecutado después del
estado de procesos principal depende de que ruta se use para realizar la
transición del estado.
 Pseudo estado “Choice” (Elección)
Un pseudo estado se muestra como un diamante con una transición llegando y
dos o más transiciones saliendo. El siguiente diagrama muestra que cualquier
estado al que se llega después del pseudo estado elección depende del formato
del mensaje seleccionado durante la ejecución del estado anterior.

60.  Pseudo estado “Junction” (unión)
Los pseudo estados unión se usan para unir transiciones múltiples. Una sola unión puede
tener una o más transiciones de entradas y una o más de salida, y se puede aplicar una guarda
a cada transición. Las uniones son libres de semántica; una unión que divide una transición de
entrada en transiciones de salida múltiples realiza una rama condicional estática, opuesto a
un pseudo estado elección que realiza una rama condicional dinámica.
oPseudo estado “Terminate” (terminar)
Ingresar un pseudo terminar indica que la línea de vida de la maquina de estado ha terminado. Un
pseudo estado indica que una línea de vida de la maquina de estado ha terminado. Un pseudo
estado terminar se denota como una cruz.

61.  Estado “History” (Historial)
Un estado historial se usa para recordar el estado anterior de una maquina de
estado cuando fue interrumpida. El siguiente diagrama ilustra el uso de estados
del historial. El ejemplo es una maquina de estado que pertenece a un lavarropas.
En esta maquina de estado, cuando un lavarropas comience, su proceso será desde el
lavado y enjuague hasta el secado. Si hay un corte de luz, el lavarropas se detendrá por
lo que pasará al estado Power off (apagado). Luego, cuando la energía retorne, el
estado Running (ejecutar) ingresa al símbolo de estado Historial, lo que significa que
debería seguir con el proceso donde quedó cuando se corto la energía.

62.  Regiones recientes
Un estado se puede dividir en regiones conteniendo sub estados
que existen y se ejecutan concurrentemente. El siguiente
ejemplo muestra que dentro del estado “Applying Brakes”
(Aplicar frenos), los frenos de adelante y atrás estarán operando
simultáneamente e independientemente. Tener en cuenta el uso
de los pseudo estados en lugar de los pseudo estados elección y
combinación. Estos símbolos se usan para sincronizar los hilos
concurrentes.
Volver

63. Diagramas de Secuencia,
muestran un flujo detallado para
un caso de uso específico o parte
de este. Ellos son en si mismos
explicativos, muestran las
llamadas entre los diferentes
objetos en su secuencia y pueden
mostrar, en un nivel de detalle,
diferentes llamadas a objetos
diferentes.
Un diagrama de secuencia tiene
dos dimensiones: la dimensión
vertical muestra la secuencia de
mensajes/llamadas en el orden
temporal en que ocurren; la
dimensión horizontal muestra la
instancia del objeto para la cual
los mensajes son enviados.

64.  Existen dos tipos de mensajes: síncronos y
asíncronos. Los mensajes síncronos se
corresponden con llamadas a métodos del
objeto que recibe el mensaje. El objeto
que envía el mensaje queda bloqueado
hasta que termina la llamada. Este tipo de
mensajes se representan con flechas con
la cabeza llena. Los mensajes asíncronos
terminan inmediatamente, y crean un
nuevo hilo de ejecución dentro de la
secuencia. Se representan con flechas con
la cabeza abierta.
 También se representa la respuesta a un
mensaje con una flecha discontinua.
 Los mensajes se dibujan
cronológicamente desde la parte superior
del diagrama a la parte inferior; la
distribución horizontal de los objetos es
arbitraria. Durante el análisis inicial, el
modelador típicamente coloca el nombre
'business' de un mensaje en la línea del
mensaje. Más tarde, durante el diseño, el
nombre 'business' es reemplazado con el
nombre del método que está siendo
llamado por un objeto en el otro. El
método llamado, o invocado, pertenece a
la definición de la clase instanciada por el
Volver
objeto en la recepción final del mensaje.

65.  En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de
comunicación es una versión simplificada del diagrama de colaboración de la
versión de UML 1.x.
 Un diagrama de Comunicación modela las interacciones entre objetos o
partes en términos de mensajes en secuencia. Los diagramas de
Comunicación representan una combinación de información tomada desde
el diagrama de Clases, Secuencia, y Diagrama de casos de uso describiendo
tanto la estructura estática como el comportamiento dinámico de un
sistema.
 Los diagramas de comunicación y de secuencia describen información
similar, y con ciertas transformaciones, pueden ser transformados unos en
otros sin dificultad.
 Para mantener el orden de los mensajes en un diagrama de comunicación,
los mensajes son etiquetados con un número cronológico y colocados cerca
del enlace por el cual se desplaza el mensaje. Leer un diagrama de
comunicación conlleva comenzar en el mensaje 1.0, y seguir los mensajes
desde un objeto hasta el siguiente, sucesivamente.

66.  El diagrama de comunicación es dibujada como un diagrama de objeto,
donde un número de objetos se muestran con la relación entre ellos. Las
flechas de mensajes son dibujadas en medio entonces para mostrar el
flujo de los mensajes entre los objetos. Las etiquetas son puestas sobre
el mensaje para mostrar el orden dentro de los mensajes que son
puestos. Ejemplo:

67.  Un ejemplo usando estereotipos:
Volver

68.  El Diagrama de Interacción por Repaso es un diagrama variante de la
actividad. En este diagrama las diferentes secuencias son incluidas en
una actividad que fluyen en orden para mostrar el flujo de trabajo por las
secuencias. Ejemplo:

69.  Detrás de los procesos detallados, los fragmentos están
representados por los siguientes:
 1. Captura de Cliente:

70.  2. Captura de Factura:
Volver

71.  Un diagrama de tiempos o cronograma es una gráfica de formas de onda
digitales que muestra la relación temporal entre varias señales, y cómo varía
cada señal en relación a las demás.
 Un cronograma puede contener cualquier número de señales relacionadas
entre sí. Examinando un diagrama de tiempos, se puede determinar los
estados, nivel alto o nivel bajo, de cada una de las señales en cualquier
instante de tiempo especificado, y el instante exacto en que cualquiera de las
señales cambia de estado con respecto a las restantes.
 El propósito primario del diagrama de tiempos es mostrar los 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.

72.  En el estándar de Lenguaje de Modelado Unificado de OMG los
diagramas de tiempo son una representación especial de interacción que
se enfoca en el tiempo de los mensajes enviados entre objetos. Se
pueden usar estos diagramas para mostrar restricciones detalladas
sobre el tiempo, ó para mostrar los cambios con líneas de vida respecto
al tiempo. Los diagramas de tiempo son generalmente utilizados con
sistemas en tiempo real o en sistemas embebidos.
Volver

73.  El UML es un lenguaje reconocido mundialmente por
la industria de construcción de software.
 El Modelamiento visual es una de las técnicas
probadas que brinda mejores resultados.
 Todos los sistemas tienen una estructura estática y
comportamiento dinámico.
 La estructura se describe con los diagramas de clases,
componentes y despliegue.
 El comportamiento dinámico del sistema se describe
con diagramas de estados, secuencias, colaboración y
actividades.
Volver

74.  http://www.sparxsystems.com.ar/download/ayuda/ind
ex.html?timingdiagram.htm
 http://www.sparxsystems.com.ar/resources/tutorial/u
ml2_statediagram.html
 http://www.sparxsystems.com.ar/download/ayuda/ind
ex.html?compositestructurediagram.htm
 http://www.milestone.com.mx/articulos/componiendo
_lo_descompuesto_diagrama_de_estructura_compue
sta.htm
 http://www.epidataconsulting.com/site/files/Articulo%
20UML%20Code.pdf
 http://es.wikipedia.org/wiki/Diagrama_de_estructura_
compuesta

75.  http://www.vico.org/aRecursosPrivats/UML_TRAD/tall
eres/mapas/UMLTRAD_101A/LinkedDocuments/UML_
diagClases.pdf
 http://upload.wikimedia.org/wikipedia/commons/7/77/
Diagrama_de_tiempos.png
 http://www.sparxsystems.com.es/resources/tutorial/u
ml2_sequencediagram.html
 http://elvex.ugr.es/decsai/java/pdf/3E-UML.pdf
 http://www.economicasunp.edu.ar/02-
EGrado/materias/trelew/analisis_sistemas%20I/info/um
l2%20diagrama.pdf
 http://www.agilemodeling.com/essays/umlDiagrams.h
tm
Volver