Recopilación
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
Uso
Diagrama
de Objetos
Diagrama
de Clase
Diagrama
de Actividades
Diagrama
de Estados
Diagrama
de Secuencia
Diagrama
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.
 El de 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
Operaciones
Atributo: tipo de dato
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
Nombre del atributo
Ejemplo
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
Definir argumentos/
Parámetros, corresponden
a una instancia de Order
Definir el tipo de dato de
retorno
totalOrderAmount
totalOrderAmount (order:
integer)
Identificar y describir
restricciones
totalOrderAmount (order:
integer) : {El total es la suma
de cada item (p.u. x cantidad)
Visibilidad
+ totalOrderAmount (order:
integer) : {El total es la suma ….
totalOrderAmount (order:
integer) : Dollar
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.
2.
3.
4.
Identificar las clases, nombrarlas y definirlas
con lo que sabes que son parte del modelo.
Identificar, nombrar y definir las asociaciones
entre pares de clases. Tener cuidado con
clases reflexivas, asignar multiplicidad.
Evaluar cada asociación para determinar si
debe ser una agregación y cada agregación
para ver si debe ser una composición
Evaluar
las
clases
para
posible
generalización (herencia).
CREADO POR:
AURORA MENDOZA PASTRANA
DOLORES HERNANDEZ GONZALEZ
José Carlos Sánchez Martínez
DEFINICIÓN

Un diagrama de clases es un tipo de
diagrama estático que describe la
estructura de un sistema mostrando sus
clases, atributos y las relaciones entre
ellos.
ELEMENTOS
Un diagrama de clases esta compuesto
por los siguientes elementos:
 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). A través
de ella podemos Modelar el entorno en
estudio. Una clase es representada por
un rectángulo que posee tres divisiones:
ATRIBUTO

Los atributos o características de una Clase
pueden ser de tres tipos, los que definen el grado
de comunicación 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 accesesible desde
todos lados.
 private (-,): Indica que el atributo sólo será accesible
desde dentro de la clase (sólo sus métodos lo pueden
accesar).
 protected (#,): Indica que el atributo no será accesible
desde fuera de la clase, pero si podrá ser accesado por
métodos de la clase además de las subclases que se
deriven (ver herencia).
METODOS

Los métodos u operaciones de una clase son la
forma en como ésta interactúa con su entorno, éstos
pueden tener las características:
 public (+,): Indica que el método será visible tanto dentro
como fuera de la clase, es decir, es accsesible desde
todos lados.
 private (-,): Indica que el método sólo será accesible
desde dentro de la clase (sólo otros métodos de la clase
lo pueden accesar).
 protected (#,): Indica que el método no será accesible
desde fuera de la clase, pero si podrá ser accesado por
métodos de la clase además de métodos de las
subclases que se deriven (ver herencia).
RELACIÓN ENTRE CLASES
HERENCIA: Indica que una subclase
hereda los métodos y atributos
especificados por una Súper Clase, por
ende la Subclase además de poseer sus
propios métodos y atributos, poseerá las
características y atributos visibles de la
Súper Clase (public y protected).
 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.
 DEPENCDENCIA O INSTANCIA: Representa
un tipo de relación muy particular, en la que
una clase es instanciada (su instanciación es
dependiente de otro objeto/clase).
EJEMPLO
ESMERALDA LIMON ESCUTIA
LUCERO ARENAS FLORES
¿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)
Un diagrama de
clases es un tipo de
diagrama estático
que describe la
estructura de un
sistema mostrando
sus
clases,
atributos y las
relaciones
entre
ellos.
Los diagramas de clases son
utilizados durante el
proceso de análisis y diseño
de los sistemas, donde se
crea el diseño conceptual
de la información que se
manejará en el sistema, y
los componentes que se
encargaran del
funcionamiento y la
relación entre uno y otro.
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
•Muestra un conjunto de
elementos que son estáticos,
como las clases y tipos,
junto con sus contenidos y
relaciones
•Es un grafo de elementos
clasificadores conectados
por varias relaciones
estáticas
Relaciones en un diagrama de clases
Los diagramas de clases están compuestos
por clases y por relaciones entre ellas. Las
relaciones que se pueden usar son:
• Relación de asociación
Una asociación es una conexión entre
clases, una conexión semántica (enlace)
entre los objetos de dichas clases. Un tipo
especial de asociación es la relación de
agregación.
• Relación de dependencia
Una dependencia es una relación entre
elementos, uno independiente y otro dependiente.
Un cambio en el elemento independiente afectará
al elemento dependiente.
• Relación de geneRalización
Una generalización es una relación entre un
elemento más general y otro más específico. El
elemento más específico puede contener sólo
información adicional. Una instancia (un objeto
es una instancia de una clase) del elemento más
específico se puede usar si el elemento más
general lo permite.
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.
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
 En
el caso del ejemplo se tienen
como casos de uso de la cafetera
RecibirDinero, PedirAzucar,
PedirProducto, DarVueltas y
Cancelar.
Oscar Rodríguez
Definición
Demuestra
la serie de
actividades que deben ser
realizadas en un uso-caso,
así como las distintas rutas
que pueden irse
desencadenando en el
uso-caso.
Utilidad
Es utilizado en conjunción de un diagrama
uso-caso para auxiliar a los miembros del
equipo de desarrollo a entender como es
utilizado el sistema y como reacciona en
determinados eventos.
 Se pudiera considerar que un diagrama de
actividad describe el problema, mientras
un diagrama de flujo describe la solución.

Composición
Inicio: El inicio de un diagrama de actividad
es representado por un círculo de color
negro sólido.
 Actividad : Una actividad representa la
acción que será realizada por el sistema la
cual es representada dentro de un ovalo.
 Transición: Una transición ocurre cuando se
lleva acabo el cambio de una actividad a
otra, la transición es representada
simplemente por una línea con una flecha en
su terminación para indicar dirección.

Elementos
Elementos
Ejemplo de
diagrama de
Actividad
(para representar el
funcionamiento del
alquiler de una
película del
videoclub)
INTEGRANTES

RUTH LOPEZ MUÑOZ

DIANA GARCIA VALERIO
MENÙ
CONCEPTO
 COMPONENTES DEL DIAGRAMA
 RELACIONES DE CASOS DE USO
 INCLISION
 EXTENSION
 GENERALIZACION
 EJEMPLO

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.
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.
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.
Jazmín Santamaría
Espinoza
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.
En la Figura 10-01, 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.
INTEGRANTE:
CELERINO HERRERA NAVA
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.
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
BIBLIOTECARIO
4:Solicita que le alcance el libro ()
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
Es
una
representación
alternativa de un
objeto
y
sus
atributos. En esta
representación
se
muestran los objetos
contenidos
dentro
del rectángulo que
representa al objeto
que los contiene. Un
ejemplo
es
el
siguiente
objeto
Vehículo_hotel1:Vehículo
MT-1234 : Motor
FR-00145 :
Frenos
TR-4583 :
Transmisión
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
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
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.
RESPUESTA DEL SISTEMA
5.- El sistema actualiza el pago del huésped.
EJEMPLO: HOTEL PLAZA
Un diagrama de colaboración es
un tipo de diagrama que muestra
las interacciones entre objetos
organizadas y enlazados entre
ellos.
A continuación tenemos los titulos fundamentales
de un diagrama de colaboración:
1.- Objeto
2.- Enlaces
3.- Objeto compuesto
4.- Patrón de diseño
5.- Contexto
6.- Objeto activo:
Un uso de un diagrama de colaboración es mostrar la implementación de
una operación. La colaboración muestra los parámetros y las variables
locales de la operación, así como asociaciones más permanentes. Cuando
se implementa el comportamiento, la secuencia de los mensajes
corresponde a la estructura de llamadas anidadas y el paso de señales del
programa.
Un diagrama de colaboración
muestra relaciones entre roles
geométricamente y relaciona los
mensajes con las relaciones, pero
las secuencias temporales están
menos claras
Prefieren el diagrama de colaboración,
porque pueden usar la distribución
para indicar cómo se conectan
estáticamente los objetos
Descargar

DIAGRAMAS UML - josecsm | Just another WordPress.com …