DIAGRAMAS UML

¿QUÉ ES UML?

Un diagrama UML es una representación

gráfica parcial (vista) de un modelo de un
sistema.
Es una herramienta que permite a los
creadores de sistemas generar diseños
que capturen sus ideas en una forma
convencional y fácil de comprender y así
poder comunicárselas a otras personas.
UML = Unified Modeling Language
Un lenguaje de propósito general para el
modelado orientado a objetos. Impulsado
por el Object Management Group (OMG,
www.omg.org). Se encarga de la
definición y mantenimiento de estándares
para aplicaciones de la industria de la
computación
UML combina notaciones provenientes
desde:
Modelado Orientado a
Objetos;
Modelado de Datos;
Modelado de Componentes;
Modelado de Flujos de Trabajo
(Workflows).
HISTORIA

Entre la guerra de los métodos,

aparecieron los siguientes:
Booch (Rational Software);
OOSE (Objet-Oriented Software
Engineering) de Jacobson
(Objectory: casos de uso);
OMT (Object Modeling Technique)
de Rumbaugh (G&E);
Fusión;
Shlaer-Mellor;
Coad-Yourdon.
 UML “aglutina“ enfoques OO

Rumbaugh
Booch Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
UML, es un lenguaje visual para
especificar, construir y documentar
sistemas.
Unified: Aporte de muchos métodos y
notaciones. Independiente de implementación,
plataforma y lenguajes.
Modeling: Los modelos son utilizados en todas
las ingenierías.
Language: Si hay gente, requieren comunicarse.
Si se tienen que comunicar, se tienen que
entender. Para entenderse necesitan un lenguaje
común.
UML, es un lenguaje de modelado, y
no un método. La mayor parte de los
métodos consisten, al menos al
principio, en un lenguaje y en un
proceso para modelar.
El lenguaje de modelado es la
notación (principalmente gráfica) de
que se valen los métodos para
expresar los diseños. El proceso es
la orientación que nos dan sobre los
pasos a seguir para hacer el diseño.
2010 -May UML 2.3
2009 -Feb UML 2.2
2007 -Nov UML 2.1.2
2007 -Ago UML 2.1.1
2005 -Jul UML 2.0
2003 UML 1.5
2000 UML 1.4

1999 Revisiones menores

UML 1.3
1998 UML 1.2

Nov ‘97 UML aprobado

por el OMG
UML, define una notación y un
metamodelo:
Notación: es el material gráfico que
se ve en los modelos; es la sintaxis
del lenguaje de modelado;
Metamodelo: Modelo que define
otros modelos (un diagrama,
usualmente un diagrama de clases,
que defina la notación)
UML, es un lenguaje estándar para
escribir planos de software;
UML, es un lenguaje expresivo;
UML es un lenguaje para:
Visualizar;
Especificar;
Construir;
Documentar.
 MODELO CONCEPTUAL DE UML

Para comprender UML, se necesita

adquirir un modelo conceptual del
lenguaje, que comprende:
Los bloques básicos de
construcción;
Las reglas que dictan cómo se
pueden combinar esos bloques
básicos;
Algunos mecanismos comunes que
se aplican a través de UML.
 BLOQUES DE CONSTRUCCION

El vocabulario de UML incluye 3

clases de bloques de construcción:
1.Elementos;
2.Relaciones;
3.Diagramas.

Los elementos son abstracciones

que son ciudadanos de primera
clase en un modelo; Las relaciones
ligan los elementos; los diagramas
agrupan elementos.
1. Elementos

Existen 4 tipos:
1. Elementos estructurales;
2. Elementos de
comportamiento;
3. Elementos de agrupación;
4. Elementos de anotación.

Estos elementos son los bloques

básicos de construcción OO de UML.
1.1 Elementos estructurales

Son los nombres de los modelos

UML. En su mayoría son partes
estáticas de un modelo y
representan cosas que son
conceptuales o materiales. Existen
7 tipos:
Clase: conjunto de objetos que
comparten atributos, operaciones,
relaciones y semántica;
interfaz: colección de operaciones
que especifican un servicio de una
clase o componente. Una interfaz
describe el comportamiento visible
externamente de ese elemento. Una
interfaz puede representar el
comportamiento completo de una
clase o componente o sólo una
parte de ese comportamiento;

IOrtografía
colaboración: define una
interacción y es una sociedad de
roles y otros elementos que
colaboran para proporcionar un
comportamiento cooperativo mayor
que la suma de los
comportamientos de sus elementos;

Cadena de
responsabilidad
Caso de uso: es una descripción de
un conjunto de secuencias de
acciones que un sistema ejucuta y
que produce un resultado
observable. Se utiliza para
estructurar los aspectos de
comportamiento en un modelo. Un
caso de uso es realizado por una
colaboración;

Realizar pedido
Clase activa: es una clase cuyos
objetos tienen uno o más procesos
o hilos de ejecución. Es igual que
una clase, excepto en que sus
objetos representan elementos cuyo
comportamiento es concurrente
con otros elementos;

GestorEventos

Suspender()
VaciarCola()
componente: es una parte física y
reemplazable de un sistema que
conforma con un conjunto de
interfaces y proporciona la
implementación de dicho conjunto.
Representa típicamente el
empaquetamiento físico de
diferentes elementos lógicos;

Orderform.java
nodo: elemento físico que existe en
tiempo de ejecución y representa
un recurso computacional, que por
general dispone de memoria y
capacidad de procesamiento.

Servidor
1.2 Elementos de comportamiento

Son las partes dinámicas de los

modelos UML. Hay 2 tipos:
interacción: conjunto de
mensajes;
Máquina de estados: especifica la
secuencia de estados por las que
pasa un objeto

dibujar
esperando
1.3 Elementos de agrupación

Son las partes organizativas. Son

cajas en las que pude
descomponerse un modelo:
paquete: organiza elementos en
grupo. Es puramente conceptual
(sólo existe en tiempo de
desarrollo).

Reglas del negocio

1.4 Elementos de anotación

Son las partes explicativas. Son

comentarios que se pueden aplicar
para describir, clarificar y hacer
observaciones sobre cualquier
elemento de un modelo:
nota: se utilizarán para adornar los
diagramas con restricciones o
comentarios

Devuelve una copia del

objeto receptor
2. Relaciones

Existen 4 tipos:
1. Dependencia; >
2. Asociación;
3. Generalización;
4. Realización.

Estos relaciones son los bloques

básicos de construcción para
relaciones UML.
 3. Diagramas

Es la representación gráfica de un
conjunto de elementos.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Objetos
Diagramas de Comportamiento
 Diagrama de Estados
 Diagrama de Actividad
Diagramas de Interacción
 Diagrama de Secuencia
 Diagrama de Colaboración
Diagramas de implementación
 Diagrama de Componentes
 Diagrama de Despliegue
 State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia

Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelos Componentes

Scenario Component
Scenario Component
Diagramas de
Diagrams
Diagramas de
Diagrams Diagrams
Diagrams despliegue
Estados Diagramas de
Actividad
 UML 2.0

En OMG UML 2.0 se definen una

serie de diagramas adicionales a los
establecidos en OMG UML 1.x. El
conjunto de diagramas se encuentra
organizado en torno a dos
categorías: diagramas
estructurales (representados en
amarillo) y diagramas dinámicos
o de comportamiento
(representados en verde)
En UML 2.0 hay 13 tipos diferentes de
diagramas.
Diagrama de
State Secuencias
Diagramas de
State
UseDiagramas
Case Diagrams
Use Case de Estructura
Diagrams
Use Diagrams
UseCase
Case Estructura
Diagrams paquete Diagrama gral
Diagramas
Diagrams de compuesta interacción
Diagrams
componentes
Diagrama de
Scenario tiempos
Scenario
Diagramas de
Diagrams
Diagrams
despliegue UML 2.0 Diagrama de
comunicación
Scenario Diagramas de
Diagramas de
Diagrams Diagrama de Maquina de
Clases
Casos de Uso estados
Diagrama Diagramas de
De objetos Actividad
Diagrama de Estructura
Compuesta. Se emplea para
visualizar de manera gráfica las partes
que definen la estructura interna de
un clasificador. Cuando se utiliza en el
marco de una clase, este diagrama
permite elaborar un diagrama de
clases donde se muestran los
atributos y las clases, indicando
asociaciones de agregación o de
composición.
Diagrama General de Interacción.
Se emplea fundamentalmente para
representar las interacciones, a través
de diagramas o fragmentos de
diagramas de secuencias, entre los
actores y el sistema como una gran
caja negra, y de diagramas de
actividades en los que aparecen
dichos fragmentos.
Diagramas de Tiempos. Empleados para mostrar
las interacciones donde el propósito fundamental
consiste en razonar sobre la ocurrencia de
eventos en el tiempo que provocan el cambio de
estados de un elemento estructural.
Diagrama de Comunicación. Equivalente al
diagrama de colaboración, los diagramas
aparecen dentro de un frame que posee una
etiqueta para indicar el tipo de diagrama.
Diagrama de Comunicación de análisis y interfaz
diseño:

Diferente
granularidad y nivel
de detalle; control

Estereotipos
específicos para el
análisis,
entidad
Estructural :
pkg Diagrama de Paquete
cmp Diagrama Componentes
Dinámica o Comportamiento
uc Diagrama de Casos de Uso
act Diagrama de Actividad
stm Diagrama de Máquina de
Estados
sd Diagrama de Secuencia
El Diagrama de Casos de Uso permiten,
entre otras cosas, refinar el MCU a través
de las asociaciones de: <<incluye>>).
Permite incorporar el flujo de eventos de
un caso de uso pequeño dentro de un caso
de uso base de la aplicación.
<<extend>>). Permite incorporar el flujo
de eventos de un caso de uso pequeño
bajo la ocurrencia de una determinada
condición, cuando la misma evalúa
verdadero.
El Diagrama de Clases, no ha sufrido
cambios radicales en OMG UML 2.0.
El Diagrama de Secuencia, se le ha
incorporado:
opt : Indica que el fragmento de diagrama es opcional;
alt : Indica que el fragmento de diagrama es una alternativa;
loop: Indica que el fragmento de diagrama se ejecuta
repetidas veces;
par: Indica que el fragmento de diagrama incluye hilos de
ejecución paralelo;
critical: Indica una secuencia que no puede ser interrumpida
por otro proceso;
sd: Representa un diagrama de secuencia.
El Diagrama de Clases de diseño.
El Diagrama de Componentes, uno de los
elementos incorporados consiste en la
definición de puertos a través de los cuales
cada componente software entrega un
conjunto de servicios a través de interfaces
proveídas .
El Despliegue de la Solución sobre la
Infraestructura TI, A través del diagrama de
despliegue se combina la Arquitectura de TI
con la Arquitectura de Aplicación o
Software.
Diagramas de Estructura:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Diagramas de Comportamiento:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados
Diagramas de Interacción:
Diagrama de secuencia
Diagrama de colaboración
Diagrama de tiempos (UML 2.0)
Diagrama de vista de interacción (UML 2.0)
 UML 2.3

Diagramas de estructura: muestra la

estructura estática del sistema y sus
partes en la abstracción y diferentes
niveles de aplicación y cómo estas se
relacionan entre sí.
Esquemas de comportamiento:
muestran el comportamiento dinámico
de los objetos en un sistema, que puede
ser descrito como una serie de cambios
en el sistema con el tiempo.
DIAGRAMA DE CLASE
 Diagrama de clase

 Es el más utilizado y más conocido de los

diagramas orientados a objetos. Es la fuente de
generación de código.
 El diagrama de clase representa clases, sus
partes y la forma en la que las clases de los
objetos están relacionados con otro.
 Una clase es una definición de un tipo de objeto.
 Partes del diagrama de clases

 Atributos: describe las características de una clase de

objetos.
 Operaciones: define el comportamiento de una clase de
objetos
 Estereotipos: ayuda a entender este tipo de objeto en el
contexto de otras clases de objetos con roles similares
dentro del diseño del sistema.
 Asociación: es un término formal para un tipo de relación.
 Herencia: permite organizar las definiciones de la clase para
simplificar y facilitar su implementación.
 Clases

 Las clases son descripciones de un juego de objetos

con características, comportamiento, relaciones y
semánticas comunes. Se usan para modelar un juego
de conceptos o entidades.
› Se denotan con un rectángulo con compartimentos.
› En ellos se ponen el nombre, los atributos, las
operaciones y además se pueden usar para anotar otras
propiedades del modelo como son (reglas del negocio,
responsabilidades, excepciones, etc.)
› Pueden tener interfaces para especificar conjuntos de
operaciones proporcionadas a su ambiente. Todas las
operaciones deben estar asociadas a métodos.
› Pueden tener relaciones de generalización con otras
clases.
 Atributos

 Son descripciones de características, se usan para modelar información

asociada con una entidad, sintaxis:

Nombre_atributo[multiplicidad]:Tipo =
Valor_inicial

 La multiplicidad es opcional e indica el número de atributos por instancia de la

clase.
 Operaciones

 Son descripciones del comportamiento, se

usan para modelar los servicios u
operaciones asociados con una entidad,
esto es, lo que una entidad puede hacer,
sintaxis:
Nombre_operación[parámetros:tipo]:Valor_retorno:tipo
 Interfaces

 Son clases que definen un juego de operaciones externas

accesibles pero sin métodos. Se usan para modelar una serie
de operaciones que definen un servicio que puede ser
ofrecido por diferentes clases.
 Se representan como clases pero con el estereotipo
<<interface>>.
 Solo contienen operaciones públicas
Todos los diagramas soportan el
Diagrama de Clase
Casos de
Diagrama
Uso
de Objetos

Diagrama
de Clase Diagrama
Diagrama de Secuencia
de Actividades

Diagrama
Diagrama
de Estados
de Colaboración
 Modelando Clases

 La representación de una clase es un rectángulo

con 3 divisiones:
 El del nombre define la clase, (un tipo de objeto).
 El de los atributos contiene la definición de los datos.
 Elde las operaciones contiene la definición de cada
comportamiento soportado por este tipo de objeto.
 Ejemplo
La siguiente figura muestra un vuelo de una
aerolínea modelado como una clase UML.

Nombre

Atributos Atributo: tipo de dato

Operaciones Operación(parámetros:
Tipo de dato):valor de
retorno
 Modelando un atributo

 Un atributo describe una pieza de información

que un objeto tiene o conoce de sí mismo. Para
poder usar esta información se debe asignar un
nombre y especificar el tipo de dato.
 El tipo de dato puede ser primitivo o tipo de dato
abstracto (definido)
 Cada atributo puede tener reglas que limiten los
valores asignados a éste. Se puede usar un valor
de default para protegerlo.
 Visibilidad de un atributo

 La definición de un atributo debe especificar que otros

objetos los pueden ver. La visibilidad puede ser:
› Public (+) permite el acceso a objetos de las otras clases.
› Private (-) limita el acceso a la clase, solo operaciones de la
clase tienen acceso.
› Protected (#) permite el acceso a subclases. En el caso de
generalización (herencia), las subclases deben tener acceso
a los atributos y operaciones de la superclase, sino no
pueden heredar.
› Package (~) permite el acceso a los otros objetos en el
mismo paquete.
 Ejemplo Especificación de un atributo
Elemento Ejemplo
Nombre del atributo compañía
Tipo de dato compañía:character
Valor de default (si hay) compañía:character = espacios
Restricciones compañía:character = espacios
{1 a 30}
Caracteres compañía:character = espacios{1
a 30 alfabéticos, espacios,
puntuación, no especiales}

Visibilidad - compañía:character = espacios

{1 a 30 alfabéticos, …….
 Modelando una Operación

 Los objetos tienen comportamientos, cosas que

puedan hacer y que se les puedan dar a éstos.
 Las operaciones requieren un nombre,
argumentos y a veces un valor de retorno.
 Las reglas de privacidad se aplican en la misma
forma que para los atributos: Private, Public,
Protected y Package.
 Ejemplo Especificación de una operación

Elemento Ejemplo
Nombre totalOrderAmount
Definir argumentos/ totalOrderAmount (order:
Parámetros, corresponden integer)
a una instancia de Order
Definir el tipo de dato de totalOrderAmount (order:
retorno integer) : Dollar
Identificar y describir totalOrderAmount (order:
restricciones integer) : {El total es la suma
de cada item (p.u. x cantidad)
Visibilidad + totalOrderAmount (order:
integer) : {El total es la suma ….
 Diagrama de Clases: Asociaciones

 El propósito de la asociación puede expresarse

en un nombre, verbo o frase que describa como
los objetos de un tipo (clase) se relacionan
con objetos de otro tipo (clase). Por ejemplo:
Una persona tiene un coche
Una persona maneja un coche
 Multiplicidad: cuantos objetos van a participar
en la relación
 Asociaciones

Se indica el rol y la multiplicidad.

Un vuelo está asociado con un avión y un avión
puede tener asociados ninguno ó varios números
de vuelo.
 Pasos para el diagrama de clases

 Identificar las clases.

 Mostrar los atributos y operaciones
(posteriormente)
 Dibujar asociaciones
 Etiquetar asociaciones y en caso necesario los
roles
 Indicar multiplicidad
 Dibujar fechas de dirección
 Asociación Reflexiva

 Una clase puede asociarse con sí misma. Una

clase Empleado puede relacionarse con sí misma a
través del rol gerente/dirige.
 No significa que una instancia está relacionada
consigo misma, sino que una instancia de la clase
está relacionada con otra instancia de la misma
clase.
Una instancia de Employee puede ser el gerente de otras
instancias de Employee. Como el rol manages tiene una
multiplicidad de 0…*, significa que puede no tener otros
empleados a quien dirigir.
Una instancia de Employee tiene 1 sólo gerente ó un solo
director.
 Asociación Cualificada

 Un cualificador es un atributo de la clase en el

lado opuesto de la asociación, que permite hacer
una búsqueda en función a su valor. Por ejemplo
“El cliente usa el numOrden para buscar una
orden”.
 Un tipo de objeto usa el cualificador para accesar
el otro tipo de objeto.

cliente numOrden:int orden

 Diagrama de Clase: Agregación y
Composición

 Cada agregación es un tipo de asociación.

 Cada composición es una forma de agregación.

Asociación

Agregación

Composción
 AGREGACIÓN BASICA

 Es un tipo especial de asociación utilizado para modelar una relación “whole

to its parts”.
 Por ejemplo, Coche es una entidad “whole” y Llanta es una parte del Coche.
 Una asociación con una agregación indica que una clase es parte de otra
clase.
 En este tipo de asociación, la clase hijo puede sobrevivir sin su clase padre.
Para representar una relación de agregación, se
dibuja una línea sólida de la clase padre (total) a
la clase hijo (parte), y con un diamante en el
lado de la clase padre.
Una llanta puede existir sin automóvil
 AGREGACIÓN/COMPOSICIÓN

 En este caso el ciclo de vida de una instancia de la

clase hijo depende del ciclo de vida de una instancia de
la clase padre.
 A diferencia de la agregación básica, para representarla
el diamante no es hueco.
 Una instancia de la clase Company debe tener al menos
una en la clase Departamento.
 En este tipo de relaciones, si una la instancia Company
se elimina, automáticamente la instancia
Departamento también se elimina.
 Otra característica importante es que la clase hijo solo
puede relacionarse con una instancia de la clase padre.
 Generalización

 Son asociaciones entre elementos más generales y elementos

más específicos, en los cuales éstos últimos son consistentes
totalmente con los primeros, por lo que heredan las
características proporcionadas por lo elementos generales y
además pueden aumentar información.
 Este tipo de relación también se conoce como herencia.
 En una generalización no hay multiplicidad ni roles. Una
(Asociación define las reglas de cómo los objetos se pueden
relacionar entre ellos.)
 La visibilidad “protected” permite que solo objetos de la
misma clase ó subclase vean el elemento.
 Elementos de la generalización

 Para dibujarla, hay que definir:

 Superclase: es una clase que contiene alguna
combinación de atributos, operaciones y asociaciones
que son comunes a dos o más tipos de objetos que
comparten el mismo propósito.
 Subclase: es una clase que contiene una combinación
de atributos, operaciones y asociaciones que son únicas
a un tipo de objeto definido por una superclase.
 La superclase es reutilizada por la subclase.
 Herencia

Perro

Collie Boxer Dalmata

 Paquetes

 Es un elemento organizador que proporciona

UML al dividir el sistema en paquetes lo hace
más fácil de entender.
 Interfaces

 Una clase tiene una instancia de su tipo, mientras

que una interface debe tener al menos una clase
para implantarla. En UML, una interface es
considerada como una especialización de una
clase.
 Una interface se dibuja como una clase, pero en
el compartimento superior del rectángulo aparece
un texto ó una inicial que indica que se trata de
una interface y no de una clase.
 Una interface no es una clase.
 Ejemplo interface

En el diagrama anterior las clases Professor y

Student implementan a la interface Person y no
heredan de ésta, podemos deducirlo a partir de:
1) El objeto Person de acuerdo a la simbología del
diagrama está como una interface y Professor y
Student están como clases.
2) No se trata de herencia ya que la línea con la
flecha está punteada y no sólida.
 Instancias

 Cuando se modela la estructura de un sistema, a

veces es útil mostrar ejemplos de las instancias de las
clases.
 UML proporciona el elemento instance especification,
que muestra información importante utilizando un
ejemplo.
 La notación es la misma que la de una clase, solo que
en el espacio superior el nombre se forma con:
nombre de la instancia : nombre de la clase
 Además de mostrar las instancias es muy útil
mostrar sus relaciones, el ejemplo muestra dos
instancias de la clase Flight, ya que el diagrama
de clase indica que la relación entre la clase
Plane y la clase Fight es 0 a muchos:
 Roles
 Se puede incluir el rol de las clases, el siguiente
ejemplo de los roles jugados por la clase
Employee (de la asociación reflexiva),
mostramos que la relación es entre un
Employee jugando el papel de gerente y un
Employee jugando el rol de miembro del
equipo.
 Construyendo el diagrama de clase

1. Identificar las clases, nombrarlas y definirlas con lo

que sabes que son parte del modelo.
2. Identificar, nombrar y definir las asociaciones entre
pares de clases. Tener cuidado con clases
reflexivas, asignar multiplicidad.
3. Evaluar cada asociación para determinar si debe ser
una agregación y cada agregación para ver si debe
ser una composición
4. Evaluar las clases para posible generalización
(herencia).
DIAGRAMA DE
componentes
 DIAGRAMA DE
COMPONENTES
Un diagrama de componentes es un diagrama tipo del
Lenguaje Unificado de Modelado.
Un diagrama de componentes representa cómo un
sistema de software es dividido en componentes y
muestra las dependencias entre estos componentes.
 Los diagramas de Componentes prevalecen en el
campo de la arquitectura de software pero pueden ser
usados para modelar y documentar cualquier
arquitectura de sistema.

 Los componentes físicos incluyen archivos,

cabeceras, bibliotecas compartidas, módulos,
ejecutables, o paquetes.
 Los diagramas de componentes se
pueden clasificar en:
 Componentes de despliegue: necesarios y
suficientes para formar un sistema ejecuta. Por
ejemplo: bibliotecas dinámicas (dll), ejecutables
(exe).
 Componentes productos de trabajo: surgen
durante el proceso de desarrollo y queda al final del
mismo.Por ejemplo: buscarCliente.jar, cliente.db.
 Componentes de ejecución: se crean como
consecuencia de un sistema de ejecución Por
ejemplo: objetos que se instancian a partir de una
dll.
Ventajas:
 · Representan aspectos físicos del sistema.
 · Se pueden construir a partir del modelo de clases y
escribir desde cero para el nuevo sistema.
 · Se puede importar de otros proyectos o de productos
terceros.

Desventajas:
 · No representan aspectos irremplazables del sistema
 Conclusión
 Podemos concluir que los diagramas de componentes son una herramienta muy útil
para conocer la manera que se desarrolla el sistema pero incluyendo sus componentes
físicos y estos a la vez relacionados con las clases que nos muestran proporcionan una
perspectiva estática del sistema.
DIAGRAMA DE
objetos
 DIAGRAMA DE OBJETOS
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. Estos no muestran nada
diferente en su
arquitectura a los diagramas de secuencia, pero reflejan multiplicidad
y roles.

 Los diagramas de objetos modelan las instancias de elementos

contenidos en los diagramas de clases. Un diagrama de objetos muestra
un conjunto de objetos y sus relaciones en un momento concreto.
 Ejemplo
 Enel caso del ejemplo se tienen
como casos de uso de la cafetera
RecibirDinero, PedirAzucar,
PedirProducto, DarVueltas y
Cancelar.
 Un diagrama de actividades es
básicamente una proyección de los
elementos de un grafo de actividades ,
un caso especial de maquina de
estados en la que todos ola mayoría de
los estados.
 Un diagrama de actividades muestra el
flujo de actividades. Una actividad es
una ejecución no atómica dentro una
maquina de estados.
DIAGRAMA DE
actividades
 Los diagramas de actividades se utilizan para
modelar los aspectos dinámicos de un sistema.
 Con un diagrama de actividades también se
puede modelar el flujo de un objeto conforme
pasa de estado a estado en diferentes puntos
del flujo de control.
 Por otro lado, estos aspectos dinámicos se pueden
modelar con diagramas de actividades, que se
encuentran en las actividades que tienen lugar entre
los objetos.
DEPENDENCIAS
DEPENDECIAS

 Un diagrama de actividades es una especialización del diagrama de estado,

organizado de acuerdo con las actividades .Normalmente , estos diagramas se
usan para detallar la secuencia de pasos que se ejecutan en un método
 El diagrama de actividades es un artefacto muy
útil y simple para comunicarse con el cliente
porque en esencia es un diagrama de flujo, y
¿quién no ha visto o elaborado un diagrama de
este tipo? La mayoría de los usuarios no tienen
problema en entender este diagrama sin tanta
explicación.
 La esencia del diagrama del diagrama de actividades
consiste en mostrar una secuencia de acciones o
actividades. Ya sea un proceso, un procedimiento, un
conjunto de eventos de un caso de uso o los de un
algoritmo.
 Para mostrar los flujos más básicos sería
suficiente utilizar dos elementos del
diagrama: las actividades o acciones y las
transiciones. En otras palabras, los pasos del
proceso y el orden en que estos ocurren.

De ahí podemos agregar más elementos para

modelar flujos cada vez más complejos. Por
ejemplo, un elemento básico a representar
nos indicaría explícitamente cuál es inicio y
fin del flujo.
SIMBOLOS UTILIZADOS EN
DIAGRAMAS DE ACTIVIDADES
SIMBOLOS UTILIZADOS EN
DIAGRAMAS DE ACTIVIDADES
NOTACION

 ESTADOS DE ACCION
 TRANSICIONES SIMPLES
 ESTADOS DE ACCION COMPUESTAS
 ESTADOS DE ACCION INICIALES Y FINALES
 DESISIONES
 ANDARIVELES
ESTADOS DE ACCION

ES UNA ACCION SIMPLEMENTE,

 ES UNA REPRESENTACION INTERNA Y AL MENOS
UNA TRANSICION SALIENTE
TRANSICIONES SIMPLES

 LAS TRANSICIONES SIMPLES REPRESNTAN EL PASO DE UNA

ACTIVIDAD A OTRA.
 LAS TRANSICIONES SIEMPRE SE DISPARAN DE FORMA INMEDIATA.
ESTADOS DE NIVEL COMPUESTO

 SI RESULTA NECESARIO SE PUEDEN CONSTRUIR DIAGRAMAS DE ACTIVIDAD

JERARQUICOS, DONDE UNA ACTIVIDAD DE UN DIAGRAMA SEA DESCOMPUESTA EN
SUBACTIVIDADES, REPRESENTANDOSE ESTO EN UN DIAGRAMA DE NIVEL
INFERIOR
ESTADOS DE ACCION INICIALES Y FINALES

 EL INICIO DE LAS ACCIONES DE UN DIAGRAMA DE

ACIVIDADES SE DA A PARTIR DE UNA PSEUDOACCION
 UNA TRANSICION A UNA ACCION FINAL REPRESENTA LA
FINALIZACION DEL DIAGRAMA DE ACTIVIDAD
DECISIONES

 UN DIAGRAMA DE ACTIVIDADES EXPRESA UNA

DECISION CUANDO UNA CONDICION ES USADA
PARA INDICAR DIFERENTES TRANSICIONES.
ANDARIVELES

 LOS ANDARIVELES SE USAN PARA ORGANIZAR LAS RESPONSABILIDADES DE

LAS ACTIVIDADES
 USUALMENTE CORRESPONDE A UNIDAES ORGANIZACIONALES
ANDARIVELES
Pasaj ero Vendedor Airline

Solicitar
pasaje
Verificar
existencia vuelo
Dar detalles
vuelo
Informar alternativas y
precios
Seleccionar
vuelo

Solicitar Reservar
pago plazas
Confirmar plaza
Pagar reservada
pasaje

Emitir
billete
TRANSICIONES CONCURRENTES

 PUEDE TENER
MUCHAS
ACCIONES
ORIGEN Y
MUCHAS
ACCIONES
DESTINO
Pasos que se siguen en la construcción del diagrama de actividades
Ejemplo: Proceso de creación de un Documento
Posible secuencia para este proceso:
 1. Abrir la aplicación para procesamiento de textos.
 2. Crear un archivo.
 3. Guardar un archivo con un nombre único en una carpeta.
 4. Teclear el documento.
 5. Si se necesitan ilustraciones, se abre la aplicación relacionada, se
generan los gráficos y se colocan en el documento.
 6. Si se necesita una hoja de cálculo, se abre aplicación relacionada,
se crea la hoja correspondiente y se pone en el documento.
 7. Se guarda el archivo.
 8. Se imprime el documento.
 9. Se sale de la aplicación de oficina.
DIAGRAMA DE ACTIVIDADES
EJEMPLO 1
EJEMPLO 2
EJEMPLO 3
BIFURCACION
EJEMPLO
DIAGRAMA DE caso
de uso
 CONCEPTO:

Un diagrama de casos de

uso es una especie de
diagrama de
comportamiento.
COMPONENTES DE UN DIAGRAMA DE
CASOS DE USO
 RELACIONES DE CASOS DE USO

 INCLUSION (INCLUDE O USE)

 EXTENSION (EXTEND)

 GENERALIZACION
 INCLUSION (INCLUDE O USE)

 Es una forma de interacción o creación, un caso

de uso dado puede "incluir" otro. El primer caso
de uso a menudo depende del resultado del
caso de uso incluido. Esto es útil para extraer
comportamientos verdaderamente comunes
desde múltiples casos de uso a una descripción
individual, desde el caso El estándar de
Lenguaje de Modelado Unificado de OMG define
una notación gráfica para realizar diagramas de
casos de uso, pero no el formato para describir
casos de uso.
 EXTENSION (EXTEND)

 Es otra forma de interacción, un caso de uso dado, (la

extensión) puede extender a otro. Esta relación indica
que el comportamiento del caso de la extensión se
utiliza en casos de uso, un caso de uso a otro caso
siempre debe tener extensión o inclusión.

 "La extensión, es el conjunto de objetos a los que se

aplica un concepto. Los objetos de la extensión son
los ejemplos o instancias de los conceptos."
 GENERALIZACION

 "Entonces la Generalización es la actividad de

identificar elementos en común entre conceptos y
definir las relaciones de una superclase (concepto
general) y subclase (concepto especializado). Es una
manera de construir clasificaciones taxonómicas
entre conceptos que entonces se representan en
jerarquías de clases. Las subclases conceptuales son
conformes con las superclases conceptuales en cuanto
a la intención y extensión."
 EJEMPLO DE DIAGRAMA DE CASOS DE
USO:

El diagrama de la derecha
describe la funcionalidad
de un Sistema
Restaurante muy simple.
Los casos de uso están
representados por elipses
y los actores están, por
ejemplo, los casos de uso
se muestran como parte
del sistema que está
siendo modelado, los
actores no.
DIAGRAMA DE estado
 ¿QUE ES EL DIAGRAMA DE
ESTADO ?
es un diagrama utilizado para
identificar cada una de las rutas o
caminos que puede tomar un flujo
de información luego de
ejecutarse cada proceso.
 MAQUINA DE ESTADO
Una MÁQUINA DE ESTADO es un comportamiento que especifica las
secuencias de estados por las que pasa un objeto a lo largo de su vida en
respuesta a eventos, junto con sus respuestas a estos eventos.

REPRESENTACION GRAFICA DE UNA MAQUINA DE ESTADOS

Las maquinas de estados se visualizan por medio de diagramas de
estado.
Representación grafica de
Estados: condición o situación
Nombre
Efectos de entrada/salida
Transiciones Internas
Subestados
Eventos diferidos
Permite identificar bajo qué argumentos se
ejecuta cada uno de los procesos y en qué
momento podrían tener una variación.
El diagrama de estados permite visualizar de
una forma secuencial la ejecución de cada uno
de los procesos.
Un Diagrama de Estados muestra la secuencia
de estados por los que pasa bien un caso de
uso, bien un objeto a lo largo de su vida, o bien
todo el sistema. En él se indican qué eventos
hacen que se pase de un estado a otro y cuáles
son las respuestas y acciones que genera.
En cuanto a la representación, un diagrama de
estados es un grafo cuyos nodos son estados y
cuyos arcos dirigidos son transiciones
etiquetadas con los nombres de los eventos.
Un estado se representa como una caja
redondeada con el nombre del estado en su
interior. Una transición se representa como una
flecha desde el estado origen al estado destino.
Un diagrama de estados puede representar
ciclos continuos o bien una vida finita, en la que
hay un estado inicial de creación y un estado
final de destrucción (finalización del caso de uso
o destrucción del objeto). El estado inicial se
muestra como un círculo sólido y el estado final
como un círculo sólido rodeado de otro círculo.
En realidad, los estados inicial y final son
pseudoestados, pues un objeto no puede “estar”
en esos estados, pero nos sirven para saber
cuáles son las transiciones inicial y final(es).
ELEMENTOS DE LOS DIAGRAMAS DE ESTADO

Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el
objeto está esperando alguna operación, tiene cierto estado
característico o puede recibir cierto tipo de estímulos. Se representa
mediante un rectángulo con los bordes redondeados, que puede tener tres
compartimientos: uno para el nombre, otro para el valor característico de
los atributos del objeto en ese estado y otro para las acciones que se
realizan al entrar, salir o estar en un estado (entry, exit o do,
respectivamente).
Eventos
Es una ocurrencia que puede causar la transición de un estado a otro de
un objeto. Esta ocurrencia puede ser una de varias cosas:
· Condición que toma el valor de verdadero o falso
· Recepción de una señal de otro objeto en el modelo
· Recepción de un mensaje
· Paso de cierto período de tiempo, después 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.
 Envío de mensajes
Además de mostrar y transición de estados por medio de eventos,
puede representarse el momento en el cual se envían mensajes a
otros objetos. Esto se realiza mediante una línea punteada dirigida
al diagrama de estados del objeto receptor del mensaje.
Transición simple
Una transición simple es una relación entre dos estados que indica
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 representa como una línea
sólida entre dos estados, que puede venir acompañada de un texto
con el siguiente formato:
 event-signature es la descripción del evento que da lugar la
transición, guard-condition son las condiciones adicionales al
evento necesarias para que la transición ocurra, action-
expression es un mensaje al objeto o a otro objeto que se ejecuta
como resultado de la transición y el cambio de estado y send-
clause son acciones adicionales que se ejecutan con el cambio de
estado, por ejemplo, el envío de eventos a otros paquetes o
clases.
Transición interna
Es una transición que permanece en el mismo estado, en vez de
involucrar 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 transición. Se puede especificar el ejecutar
una acción como consecuencia de entrar, salir, estar en un estado,
o por la ocurrencia de un evento.
Generalización de Estados:
· Podemos reducir la complejidad de estos diagramas usando la
generalización de estados.
· Distinguimos así entre superestado y subestados.
· Un estado puede contener varios subestados disjuntos.
· Los subestados heredan las variables de estado y las transiciones
externas.
· La agregación de estados es la composición de un estado a partir
de varios estados independientes.
La composición es concurrente por lo que el objeto estará en
alguno de los estados de cada uno de los subestados concurrentes.
La destrucción de un objeto es efectiva cuando el flujo de control
del autómata alcanza un estado final no anidado. La llegada a un
estado final anidado implica la subida al superestado asociado, no
el fin del objeto.
 Subestados
Un estado puede descomponerse en 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.
Transacción Compleja
Una transición compleja relaciona tres o más estados
en una transición de múltiples fuentes y/o múltiples
destinos. Representa la subdivisión en threads del
control del objeto o una sincronización. Se representa
como una línea vertical de la cual salen o entran varias
líneas de transición de estado.
 Transición a estados anidados
Una transición de hacia un estado complejo (descrito
mediante estados anidados) significa la entrada al
estado inicial del subdiagrama. Las transiciones que
salen del estado complejo se entienden 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 duración.
· La actividad de espera se interrumpe cuando el
evento esperado tiene lugar.
· Este evento desencadena una transición que permite
salir del estado que alberga la actividad de espera. El
flujo de control se transmite entonces a otro estado.
DIAGRAMA DE
secuencia
 CONCEPTO

 Es un tipo de diagrama usado para modelar la interacción entre objetos en un sistema

según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace
diagrams", "event scenarios" o "timing diagrams” .
 UTILIDAD

 Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y

se modela para cada caso de uso.

 Contiene detalles de implementación del escenario, incluyendo los objetos y clases que
se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

 Muestra los objetos que intervienen en el escenario con líneas discontinuas

verticales, y los mensajes pasados entre los objetos como flechas horizontales.
 TIPOS DE MENSAJES

 Existen dos tipos de mensajes:

 Sincrónicos: 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.
 Asincrónicos: 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.
 Pueden ser usados en dos formas:
 De instancia: describe un escenario especifico (un escenario es una instancia de la
ejecución de un caso de uso).
 Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"),
condiciones y bucles.
 ESTRUCTURA

 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 objeto en la recepción final del mensaje.
 DIAGRAMA DE
emplazamiento
Es aquel que muestra las relaciones físicas entre los componentes de
software y de hardware en el sistema entregado. Así, el diagrama de
emplazamiento es un buen sitio para mostrar cómo se enrutan (se refiere a
la selección del camino en una red de computadoras por donde se envían
datos) y se mueven los componentes y los objetos, dentro de un sistema
distribuido.
 Cada nodo de un diagrama de emplazamiento representa
alguna clase de unidad de cómputo; en la mayoría de los casos
se trata de una pieza de hardware. El hardware puede ser un
dispositivo o un sensor simple, o puede tratarse de un
mainframe (Computadora grande, poderosa y costosa utilizada
principalmente en empresas que necesitan procesar gran
cantidad de datos o soportar gran cantidad de usuarios.).

Los componentes en un diagrama de emplazamiento

representan módulos físicos de código y corresponden
exactamente a los paquetes de un diagrama de paquetes de tal
modo que el diagrama de emplazamiento muestra dónde se
ejecuta cada paquete en el sistema.
Las dependencias entre los componentes deben
ser las mismas que las dependencias de paquetes.
Estas dependencias muestran cómo se comunican
los componentes con otros componentes. La
dirección de una dependencia dada indica el
conocimiento en la comunicación.
 Así, en el diagrama, la IU de la unidad de hígado depende de la
Fachada de cliente de unidad de hígado, ya que llama a métodos
específicos en la fachada. A pesar de que la comunicación es en
ambas direcciones, en el sentido de que la Fachada devuelve datos,
la Fachada no sabe quién la llama y, por tanto, no depende de la IU .
En la comunicación entre ambos componentes del Dominio de
atención a la salud, ambos saben que están hablando con otro
componente de Dominio de atención a la salud, así que la
dependencia de la comunicación es en dos sentidos.
 Un componente puede tener más de una interfaz, en cuyo caso usted
podrá ver cuáles componentes se comunican con cada interfaz., la PC
contiene dos componentes: la IU y la fachada de la aplicación. La
fachada de aplicación habla con la interfaz de la aplicación en el
servidor. Un componente de configuración separado se ejecuta sólo
en el servidor. La aplicación se comunica con su componente local del
Dominio de atención a la salud, el cual, a su vez, puede comunicarse
con otros componentes de Dominios de atención a la salud de la red.
 La utilización de los componentes de diversos Dominios de atención a
la salud está oculta para la aplicación. Cada componente del Dominio
de atención a la salud tiene una base de datos local.
 En la práctica, no he visto que se use mucho este tipo de diagramas.
La mayoría de la gente dibuja diagramas para mostrar este tipo de
información, pero se trata de bocetos informales. En general, no
tengo problemas con este tipo de diagramas, ya que cada sistema
tiene sus propias características físicas que se querrán subrayar. A
medida que se tiene que lidiar cada vez más con los sistemas
distribuidos, estoy seguro de que se requerirá mayor formalidad,
según se vaya entendiendo mejor cuáles son los asuntos que se deben
resaltar en los diagramas de emplazamiento.
 DIAGRAMA DE
colaboracion
Un diagrama de colaboración
es una forma de representar
interacción entre objetos .
 En que consiste un diagrama de
colaboración ?

 Muestra cómo las instancias específicas de las clases trabajan juntas para
conseguir un objetivo común.
 Consiste especificar un contrato entre objetos
 Implementa las asociaciones del diagrama de clases mediante el paso de
mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
¿Que representa el algoritmo
de colabora ración?

Representa la parte
esencial para la
descripción de un patrón
de diseño.
 DIAGRAMA DE COLABORACION
Un Diagrama de Colaboración muestra una
interacción organizada basándose en los objetos
que toman parte en la interacción y los enlaces entre
los mismos (en cuanto a la interacción se refiere).
UML –Interacciones
Los objetos interactúan entre sí pasándose
mensajes.
Los objetos se conectan a través de enlaces.
Mensaje: especifica transmisión de información
entre objetos.
Enlace: especifica un camino a lo largo del cual un
objeto puede enviar un mensaje a otro objeto.
Es una conexión semántica entre objetos.
Es una instancia de una relación.
Puede contener los adornos de la relación.
Las Interacciones modelan aspectos dinámicos
del sistema
Llamada.-Invoca una operación sobre un objeto. Puede
ser a sí mismo.

Retorno.-El receptor de una llamada devuelve un valor al

emisor, si es necesario.

Envío.- Envía una señal a un objeto.

Creación.- Para crear un objeto.
Destrucción.- Para destruir un objeto. Puede destruirse a sí
mismo.

Secuenciación
 El flujo de mensajes forma una secuencia.
 La secuencia es indicada por un número antes del mensaje y
una flecha dirigida.
 Para modelar caminos alternativos, se coloca el mismo
número de secuencia seguido de un número de
subsecuencia.
 Secuenciación

Parámetros . Reales Se pueden modelar los parámetros reales enviados y

también los retornos. Ej: 1.2.1: x:=operación(‘m’)
Elementos de un Diagrama de Colaboración
 Objetos o Roles: nodos del grafo.
 Enlaces o comunicaciones: arcos del grafo.
 Mensajes: llevan número de secuencia y flecha
dirigida.
 Anidamiento: se utiliza la numeración decimal
Ej: 1, 1.1, 1.1.1 ........
 Iteración: colocar un * antes del número de
secuencia y una cláusula de condición, si es
necesario. ej. *[x>0].
 Bifurcación: los caminos alternativos tendrán el
mismo número de secuencia, seguido del número
de subsecuencia, y se deben distinguir por una
condición.
Ejemplo: Un lector solicita un libro al bibliotecario, y
le brinda su título. El bibliotecario busca el libro en un
índice y solicita al asistente que le alcance el libro.
Diagrama de secuencia
LECTOR BIBLIOTECARIO INDICE ASISTENTE
Solicita un libro
brindándole el titulo
busca el libro

devuelve información

solicita que le alcance el libro

el libro es entregado
entrega el libro
 Diagrama de colaboración
5:El libro es entregado()

ASISTENTE
4:Solicita que le alcance el libro ()
BIBLIOTECARIO
2:Busca el libro ()

3:devuelve información ()
6:Entrega libro ()
INDICE
1:Solicita libro ()
dándole el titulo ()

LECTOR
DEPENDENCIAS

¿De qué artefactos depende su construcción?

R.- Su construcción depende de:
 Los casos de uso (expandidos).
 Diagrama de secuencias.
 Diagrama de Clases.
¿Qué otros artefactos se generan a
través de él?
R.- Los artefactos que se generan son:
 Diagramas de Estado.
 Diagrama de Componentes.
 Diagrama de Despliegue
¿En qué etapa se realiza su
construcción?

Este tipo de diagramas se utilizan más frecuentemente en la fase

de diseño, es decir, cuando estamos diseñando la implementación
de las relaciones.
EJEMPLO DE
APLICACIÓN
CONTROL DE SEGURIDAD DEL
HOTEL PLAZA
En cuanto a la representación, un Diagrama de
Colaboración muestra a una serie de objetos
con los enlaces entre los mismos, y con los
mensajes que se intercambian dichos objetos.

Los mensajes son flechas que van junto al

enlace por el que “circulan”, y con el nombre
del mensaje y los parámetros (si los tiene) entre
paréntesis. Cada mensaje lleva un número de
secuencia que denota cuál es el mensaje que le
precede, excepto el mensaje que inicia el
diagrama, que no lleva número de secuencia.
Se pueden indicar alternativas con condiciones
entre corchetes (por ejemplo:
[condición_de_test] : nombre_de_método() ), tal y
como aparece en el ejemplo.
También se puede mostrar el anidamiento de
mensajes con números de secuencia como 2.1,
que significa que el mensaje con número de
secuencia 2 no acaba de ejecutarse hasta que
no se han ejecutado todos los 2. x .
 Elementos básicos para el diagrama
de Colaboración
Objeto
Un objeto se representa con un rectángulo, que contiene el
nombre y la clase del objeto en un formato nombreObjeto:
nombreClase.
Enlaces
Un enlace es una instancia de una asociación en un diagrama de
clases. Se representa como una linea contínua que une a dos
objetos. Esta acompañada por un número que indica el orden
dentro de la interacción y por un estereotipo que indica que
tipo de objeto recibe el mensaje.
Flujo de mensajes
Expresa el envío de un mensaje. Se representa
mediante una flecha dirigida cercana a un
enlace.
Marcadores de creación y destrucción de
objetos
Puede mostrarse en la gráfica cuáles objetos son
creados y destruidos, agregando una restricción
con la palabra new o delete, respectivamente,
cercana al rectángulo del objeto
Objeto compuesto
Vehículo_hotel1:Vehículo
Es una representación
alternativa de un
objeto y sus atributos. MT-1234 : Motor
En esta representación
se muestran los
FR-00145 : Frenos
objetos contenidos
dentro del rectángulo
que representa al TR-4583 :
objeto que los Transmisión
contiene. Un ejemplo
es el siguiente objeto
vehículo.
Ejemplo:
Caso de Uso: Pago por servicios.
Actores: Administrador, Agente, Huésped (inicia).
Propósito: Controlar que el huésped cancele su estadía y los servicios
solicitados.
Tipo: Primario y esencial.
Descripción: El agente designado en administración controla que el huésped
cancele su estadía en el hotel y los servicios solicitados.
CURSO NORMAL DE LOS EVENTOS

ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA

1.- Se inicia cuando el huésped desea retirarse del

hotel.
2.- El agente revisa que no exista daños ni perdidas
durante la estadía del huésped.
3.- El administrador calcula el saldo que debe
cancelar, y pide la cancelación total al huésped 5.- El sistema actualiza el pago del huésped.
4.- El huésped cancela al administrador y este le
proporciona una factura.

6.- El administrador recibe las llaves de la

habitación.
7.- El huésped se retira.
EJEMPLO: HOTEL PLAZA
DIAGRAMA DE
despliegue
 Que es el diagrama de Despliegue?

 Los diagramas de despliegue son uno de los

dos tipos de diagramas que aparecen
cuando se modelan los aspectos físicos de
los sistemas orientados a objetos.
 En que consiste?

 Representan la configuración de los nodos

de procesamiento en tiempo de ejecución y
los componentes que residen en ellos.
Muestran la vista de despliegue estática de
una arquitectura y se relacionan con los
componentes ya que, por lo común, los
nodos contienen uno o más componentes.
Que representa?
 Los diagramas de despliegue
muestran la configuración en
funcionamiento del sistema,
incluyendo su hardware y su
software. Para cada
componente de un diagrama
de despliegue se deben
documentar las
características técnicas
requeridas, el tráfico de red
esperado, el tiempo de
respuesta requerido, etc.
DEPENDENCIAS

Estos son:

•NODOS
•INSTANCIAS DE COMPONENTES DE
SOFTWARE
•INSTANCIA DE NODO
•ESTEREOTIPO DE NODO
•ARTEFACTOS
•ASOCIACIÓN
•NODO COMO CONTENEDOR
NODO: es un objeto físico en tiempo de
ejecución que representa un recurso
computacional, generalmente con memoria
y capacidad de procesamiento.
INSTANCIAS DE COMPONENTES DE
SOFTWARE: muestran unidades de software
en tiempo de ejecución y generalmente
ayudan a identificar sus dependencias y su
localización en nodos.

DICTIONARY
INSTANCIA DE NODO:. Una instancia se
puede distinguir desde un nodo por el
hecho de que su nombre esta
subrayado y tiene dos puntos antes del
tipo de nodo base.
ESTEREOTIPO DE NODO:
Un número de estereotipos estándar se
proveen para los nodos, nombrados
«cdrom», «computer», «pc», «pc
client», «pc server», «user pc».
ARTEFACTO: Un artefacto es un
producto del proceso de desarrollo de
software, que puede incluir los
modelos del proceso.
ASOCIACIÓN:
En el contexto del diagrama de
despliegue, una asociación
representa una ruta de comunicación
entre los nodos.
NODO COMO CONTENEDOR:
Un nodo puede contener otros elementos,
como componentes o artefactos.
Notacion
El Diagrama de Despliegue es muy similar al de componentes por lo
que también comparte la forma de notación que se ve a
continuación:
 El diagrama de despliegue :

• Describe la arquitectura física del sistema durante la ejecución,

en términos de:
– procesadores
– dispositivos
– 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.
 Los diagramas de despliegue se suelen utilizar para modelar:

• Sistemas empotrados: Un sistema empotrado es un colección de

hardware con una gran cantidad de software que interactúa con el
mundo físico. Los sistemas empotrados involucran software que
controla dispositivo (motores, actuadores) que a su vez están
controlados por estímulos externos como censores.

• Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo

del espectro de los sistemas distribuidos y requieren tomar decisiones
sobre la conectividad de red de los clientes a los servidores y sobre la
distribución física de los componentes software de los sistemas a través de
nodos.
- Sistemas completamente distribuidos: En el otro
extremo encontramos aquellos sistemas que son
ampliamente o totalmente distribuidos y que
normalmente incluyen varios niveles de servidores Tales
sistemas contienen a menudo varias versiones de
componentes software, alguno de los cuales pueden
incluso migrar de un nodo a otro. El diseño de tales
sistemas requiere tomar decisiones que permitan un
cambio continuo de la topología del sistema.
Pasos para su
construcción
 Cuando se dibuje un diagrama de despliegue:

-Hay que darle un nombre que comunique su propósito.

- Hay que distribuir sus elementos para minimizar los cruces de
líneas.
- Hay que organizar sus elementos espacialmente para que los que
estén cercanos semánticamente también lo estén físicamente.
- Hay que usar notas y colores como señales visuales para llamar la
atención sobre las características importante del diagrama.
- Hay que usar los elementos estereotipados con cuidado.Hay que
elegir un pequeño conjunto de íconos para el proyecto o la
empresa y utilizarlos de forma consistente.
 Un diagrama de despliegue bien estructurado:

-Se ocupa de modelar un aspecto de la vista de despliegue

estática de un sistema.
- Contiene sólo aquellos elementos que son esenciales
para comprender ese aspecto.
- Proporciona detalles de forma consistente con el nivel
de abstracción, mostrando sólo aquellos adornos que son
esenciales para su comprensión.
- No es tan minimalista que no ofrezca información al
lector sobre los aspectos importantes de la semántica.
PANTALLA PRINCIPAL DEL SISTEMA
DIAGRAMA DE DESPLIEGUE PARA INGRESAR AL SISTEMA Y
MOSTRAR COBROS
DIAGRAMA DE DESPLIEGUE DE DETALLES DE
PACIENTES
DIAGRAMA DE DESPLIEGUE DE SOLICITUD DE BUSQUEDA
DE INFORMACION DE PACIENTES
DIAGRAMA DE DESPLIEGUE PARA CAMBIAR CONTRASEÑA
DIAGRAMA DE DESPLIEGUE DE UN CASO EN GENERAL
DIAGRAMAS DE DESPLIEGUE O DISTRIBUCION
 USOS COMUNES
Los diagramas despliegue se utilizan para modelar la vista de despliegue
estática de un sistema. Esta vista cubre principalmente la distribución, entrega
e instalación de las partes que configuran el sistema físico. Hay varios tipos de
sistemas para los que son innecesarios los diagramas de despliegue. Si se
desarrolla un software que reside en una maquina e interactúa solo con
dispositivos estándar en esa maquina, que ya son gestionados por el sistema
operativo(por ejemplo: el teclado, la pantalla y el MODEM de un PC), se pueden
ignorar los diagramas de despliegue.
Por otro lado si se desarrolla un software que interactúa con dispositivos que
normalmente no gestiona el sistema operativo o si el sistema esta distribuido
físicamente sobre varios procesadores, entonces la utilización delos diagramas
de despliegue ayudara a razonar sobre la correspondencia entre el software y el
hardware del sistema.
Cuando se modela la vista de despliegue estática de un sistema, normalmente
se utilizaran los diagramas de despliegue de una de las tres siguientes
maneras:
1.Para modelar sistemas empotrados.
2. Para modelar sistemas cliente / servidor.
3. Para modelar sistemas completamente empotrados.