UNIVERSIDAD NACIONAL AMAZONICA DE MADRE

DE DIOS

Tipos de Diagramas

Jorge Raul Sotomayor Perales

Profesión: Ing. De sistemas
Mgtr. En Ingeniería de Software
Raul.perales@hotmail.es
2018
 Diagramas de estructura: mostrar la
estructura estática del sistema que se está
modelando
◦ Incluye: diagramas de clase, componentes y/o
objetos.

 Diagramas de comportamiento: muestra el

comportamiento dinámico entre los objetos
y el sistema.
◦ Incluye: diagramas de actividades, casos de uso y
de secuencia
 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.
 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.
 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.
 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.
 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
 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
 Casos de Diagrama
Uso de Objetos

Diagrama
de Clase Diagrama
de Secuencia

Diagrama
Diagrama de Colaboración
de Actividades
Diagrama
de Estados
 La clase define las reglas; los objetos
expresan los hechos.
 La clase define que puede ser; el objeto
describe que es.
 Se considera un caso especial del diagrama
de clases.
 Puede construirse junto con el de clases.
 Describe una instancia de un diagrama de
clase en un momento en particular.
 Este diagrama contiene objetos y ligas.
 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.
 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
 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.
 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.
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, …….
 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.
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 ….
 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
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.
 La dirección en las flechas de la asociación
determinan en que dirección puede
recorrerse una asociación en el momento de
la ejecución.
 Una asociación sin flechas significa que se
puede ir de un objeto a otro y viceversa.
 Por ejemplo la siguiente el tipo de flecha en
la asociación implica que desde el objeto
Reservación puedes recuperar (dirigirte
hacia) el objeto Cliente. También implica
que del objeto Cliente puedes recuperar el
juego de reservaciones para ese cliente.
 1….* hecha para 1
Reservación Cliente

Supongamos que los requerimientos para un

sistema de reservaciones requieren que
“desde una reservación, que el sistema
pueda recuperar el cuarto
1….* hecha para 1
Reservación Cuarto
 Cuando se modela una asociación entre
clases, a veces es necesario incluir otra
clase que contiene información valiosa
acerca de la relación.
 Se representa como una clase normal solo
que la línea que la une con la línea que
conecta las asociaciones primarias es
punteada.
 La siguiente figura muestra una clase
asociación para el ejemplo de los vuelos.
 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
 Supongamos que las personas que trabajan
en una empresa se tienen registradas sus
habilidades, esto significa que cualquier
empleado puede tener cualesquiera
habilidades. ¿Es necesario crear una clase
asociación que contenga la información de
ambas clases?
 Dibujar las entidades y su asociación.
 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.
 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

 Cada agregación es un tipo de asociación.
 Cada composición es una forma de
agregación.

Asociación

Agregación

Composción
 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.
 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.
HACER LOS DIAGRAMAS DE ASOCIACIÓN INDICANDO
SI EXISTE AGREGACIÓN / COMPOSICIÓN. ANOTAR
LA MULTIPLICIDAD.

1)Jugadores basketball y equipo basketball

2)Libro y capítulos del libro
3)Motor y automóvil
4)Líneas de un pedido y el pedido
5)En una empresa se llevan a cabo proyectos, estos
proyectos están formados por una ó más
actividades y a su vez cada actividad tiene 1 ó más
tareas específicas. Cada tarea es asignada a un
empleado y los empleados pueden o no tener
asignadas tareas.
 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.
 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.
 Perro

Collie Boxer Dalmata

 Es un elemento organizador que proporciona
UML al dividir el sistema en paquetes lo hace
más fácil de entender.
 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.
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.
 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:
 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.
 Establecimiento del problema: para el sistema de control de
inventario:
“Nuestro sistema está diseñado para inventariar y embarcar
únicamente productos identificados. Estos productos pueden ser
comprados directamente de proveedores y revenderlos, o podemos
empacarlos juntos para crear un producto especial. Los clientes
colocan órdenes para uno ó más ítems pero nosotros detectamos en
el sistema clientes que hayan o no hayan comprado. Cada ítem
corresponde a un producto. Identificamos cada producto usando un
número serial único. El cliente puede preguntar sobre el estatus de
su orden utilizando el número de orden.
Los embarques de productos de los proveedores se reciben y se
colocan en el inventario. Cada producto es asignado a una ubicación
con lo que se puede encontrar fácilmente cuando se surten las
órdenes. Cada ubicación tiene un identificador único. Las órdenes
para los clientes se embarcan a medida que los productos están
disponibles, por lo que puede haber más de un envío para satisfacer
una sola orden de compra, pero puede ser que un solo embarque
contenga productos de múltiples órdenes. Los ítems que no se
entregaron son colocados en una backorder con una referencia a la
orden original”.
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).
 Introducción al modelado del software
 Presentación de UML
 Modelado de Casos de Usos
◦ Diagramas de casos de uso
 Modelado Estructural
◦ Diagramas de clases
◦ Paquetes
 Un caso de uso especifica un
comportamiento deseado del sistema.
 Representan los requisitos funcionales del
sistema.
“Un caso de uso especifica un conjunto de
secuencias de acciones, incluyendo
variantes, que el sistema puede ejecutar y
que produce un resultado observable de
valor para un particular actor.”
(Definición en UML)

 Describen qué hace el sistema, no cómo lo

hace. 50
 Partes de un caso de uso (cdu)
◦ Conjunto de secuencias de acciones; cada
secuencia representa un posible comportamiento
del sistema
◦ Actores, roles que pueden jugar los usuarios
◦ Variantes: versiones especializadas, un cdu que
extiende a otro o un cdu que incluye a otro
◦ Un caso de uso realiza un trabajo tangible.

51
 Emisor Centralita Receptor

listo( )

tono

marcar_numero

tono_sonando
timbre_sonando

Escenario para_tono
telefono_cogido

para_timbre

Los Casos de uso son ideados por Jacobson a principios de los noventa y
están inspirados en los Escenarios utilizados para describir procesos.
actor caso de uso

Gestionar Préstamos
Responsable
Prestamos

asociación

53
 Un actor representa un conjunto
coherente de roles que juegan los
usuarios de los casos de uso al
interaccionar con el sistema.
 Roles jugados por personas, dispositivos,
u otros sistemas.
 El tiempo puede ser un actor (“procesos
iniciados automáticamente por el
sistema”).
 No forman parte del sistema.
54
 Un usuario puede jugar diferentes roles.
 En la realización de un caso de uso pueden
intervenir diferentes actores.
 Un actor puede intervenir en varios casos de
uso.
 Identificar casos de uso mediante actores y
eventos externos.
 Un actor necesita el caso de uso y/o participa
en él.

55
 Dos tipos de actores:
◦ Principal:
Requiere al sistema el cumplimiento de un
objetivo.

◦ Secundarios:
El sistema necesita de ellos para satisfacer un
objetivo.

56
 Un caso de uso describe un conjunto de
secuencias de interacciones entre actores y
el sistema (escenarios): flujo principal y
flujos alternativos o excepcionales.
 Un escenario es una instancia de un caso de
uso
 Un escenario es una historia particular de
uso de un sistema.
 Escenarios principales vs. Escenarios
secundarios

57
 Son iniciados por un actor con un objetivo en
mente y es completado con éxito cuando el
sistema lo satisface.
 Puede incluir secuencias alternativas que
llevan al éxito y fracaso en la consecución del
objetivo.
 El sistema es considerado como una “caja
negra” y las interacciones se perciben desde
fuera.
 El conjunto completo de casos de uso
especifica todas las posibles formas de usar
el sistema, esto es el comportamiento
requerido. 58
 Son documentos de texto, no son
diagramas.
◦ El modelado de casos de uso consiste en escribir
texto, no en dibujar diagramas.
 Describir el flujo de eventos
◦ Texto estructurado informal
◦ Texto estructurado formal (plantillas)
◦ Pseudocódigo
◦ Notaciones gráficas: diagramas de secuencia
 Debe ser legible y comprensible para un
usuario no experto.
 Debe indicar: actores, flujos principal y
excepcionales.
59
60
Realizar Venta (en un Terminal de Punto de Venta
o TPV)

Actor Principal: Cajero

Flujo Principal: Un cliente llega al TPV con un conjunto de
artículos. El Cajero registra los artículos y se genera un ticket. El
cliente paga en efectivo y recoge los artículos.

1. El cliente llega al TPV con los artículos.

2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a
la transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de artículos.

61
Realizar Venta (en un Terminal de Punto de Venta
o TPV)

5. El sistema calcula el total de la compra y lo muestra.

6. El cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a devolver que
entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.

62
Realizar Venta
Diagrama de secuencia

:Sistema

: Cajero
crearNuevaVenta()

* introducirItem(cod,cantidad)

finalizarVenta()

hacerPago(cantidad)

63
 Reservar Libro Prestamo Revista

Profesor

Prestamo Libro Devolver Revista

Socio

Devolver Libro Actualizar Catalogo

Bibliotecario

Extender Prestamo
Consultar
Socio
64
 Con un caso de uso se describe un
comportamiento esperado del sistema, pero
no se especifica cómo se implementa.
 Una caso de uso se implementa a través de
una colaboración:
“Sociedad de clases y otros elementos que
colaborarán para realizar el comportamiento
expresado en un caso de uso”
 Una colaboración tiene una parte estática
(diagramas de clases) y una parte dinámica
(diagramas de secuencia).

65
caso de uso

colaboración

Hacer Pedido

Gestión Pedidos
realización

66
 Tres tipos de relaciones:
◦ Generalización
 Un cdu hereda el comportamiento y significado de
otro.
◦ Inclusión
 Un cdu base incorpora explícitamente el
comportamiento de otro en algún lugar de su
secuencia.
◦ Extensión
 Un cdu base incorpora implícitamente el
comportamiento de otro cdu en el lugar
especificado indirectamente por este otro cdu.

67
 Extensión
«extend»
Hacer Pedido
Hacer Pedido Urgente
(establecer
prioridad)
«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización

«include»
Seguir Pedido Examinar retina

68
 Permite factorizar un comportamiento en
un caso de uso aparte y evitar repetir un
mismo flujo en diferentes casos de uso.
 Ejemplo:
Hacer Pedido:
Obtener y verificar el número de
pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
…

69
 El caso de uso base incluye una serie de
puntos de extensión.
 Sirve para modelar:
◦ la parte opcional del sistema, o
◦ un subflujo que sólo se ejecuta bajo ciertas
condiciones.

70
 Ejemplo:

Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del usuario;
Establecer prioridad: punto de extensión
Enviar pedido para ser procesado según
la prioridad.

71
1) Identificar los usuarios del sistema.
2) Encontrar todos los roles que juegan los
usuarios y que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
6) Revisar y validar con el usuario.

72
 Resumen
 Actores Principales y Secundarios
 Personas involucradas e Intereses
 Precondiciones
 Poscondiciones
 Escenario Principal (Flujo Básico)
 Extensiones (Flujos Alternativos)
 Requisitos de Interfaz de Usuario
 Requisitos No-Funcionales
 Cuestiones Pendientes

73
 Resumen: Un cliente llega al TPV con un conjunto de
artículos. El cajero registra los artículos y se genera un
ticket. El cliente paga en efectivo y recoge los
artículos.
 Actores: Cajero (principal), Sistema (secundario)
 Personal Involucrado e Intereses:
◦ Cajero: quiere entradas precisas, rápidas y sin errores de pago.
◦ Compañía: quiere registrar transacciones y satisfacer clientes.
◦ ...
 Precondición: El cajero se identifica y autentifica.
 Poscondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza la contabilidad y el inventario.

74
 Escenario Principal (Flujo Básico):
1. El cliente llega al TPV con los artículos.
2. El cajero inicia una nueva venta.
3. El cajero introduce el identificador de cada artículo.
4. El sistema registra la línea de venta y presenta descripción
del artículo, precio y suma parcial.
El cajero repite los pasos 3 y 4 hasta que se indique.
5. El sistema presenta el total.
6. El cajero le dice al cliente el total a pagar .
7. El cliente paga y el sistema gestiona el pago.
8. El sistema registra la venta completa y actualiza el
inventario.
9. El sistema presenta recibo.

75
 Extensiones (Flujos Alternativos):
A1: Identificador no válido
La secuencia A1 comienza en el punto 3.
4. El sistema señala el error y rechaza la entrada.
El escenario vuelve al punto 3.
A2: El cliente pide eliminar un artículo de la compra.
La secuencia A2 puede ocurrir entre los puntos 3-6.
1. El cajero introduce identificador a eliminar.
2. El sistema actualiza la suma.
El escenario continúa en el punto 6.
A3: Pago en efectivo
La secuencia A3 ocurre en el punto 7.
1. El cajero introduce la cantidad entregada por el cliente.
2. El sistema muestra cantidad a devolver.
El escenario continúa en el punto 8.
…

76
 Requisitos de Interfaz de Usuario:
- Pantalla táctil en un monitor de pantalla plana.
- El texto debe ser visible a un metro de distancia.
 Requisitos No-Funcionales:
- El identificador del producto podría ser cualquier
esquema de código de barras UPC, EAN-8, EAN-13, ...
- El tiempo de respuesta para autorizar el pago con la
tarjeta de débito o de crédito es de 30 segundos.
 Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a
servicios remotos.
- ¿Qué adaptaciones son necesarias en un TPV para
diferentes negocios?

77
 Hay consenso en considerar casos de
uso como esenciales para capturar
requisitos y guiar el modelado.
 Pero todavía existe mucha confusión
sobre cómo usarlos.
◦ ¿Cuál es el número de casos de uso apropiado
en un proyecto?
◦ ¿Qué casos de uso hay en el sistema?

78
 Diferente granularidad
◦ Casos de uso del negocio
 Procesos de Negocio: Objetivo estratégico de la empresa
 Ej. Vender productos
◦ Casos de uso del sistema
 Objetivo de un usuario
 Ej. Realizar una compra
◦ Casos de uso de inclusión
 Forman parte de otro, son como subfunciones
 Ej. Buscar, Validar, Login

79
 Especificar casos de uso no es una actividad de
dibujar diagramas sino de escribir con el detalle
necesario el flujo principal y los flujos alternativos:
“centrado en la escritura en vez del dibujo”.
 No hay que preocuparse demasiado por las
relaciones entre casos de uso ni entre actores.
 El objetivo inicial es identificar los actores y a partir
de sus objetivos encontrar los casos de uso, ya que
el diagrama de casos de uso es una ayuda visual.
 Los actores deben interactuar con el
sistema.

80
 No incluir como caso de uso las operaciones CRUD
sobre un objeto de negocio (alta, consulta, borrado,
actualización). CRUD es el acrónimo de Crear, Obtener,
Actualizar y Borrar (Create, Retrieve, Update y
Delete en inglés).
 La excepción es si se trata de operaciones relevantes para el
sistema, como “Registrar Cliente” en un sistema de venta por
Internet.
 Cuidado con el empleo de la relación “include”.
¡NO HACER UNA DESCOMPOSICION FUNCIONAL!
 Los casos de uso sólo consideran los requisitos
funcionales del proyecto, hay que añadir los no-
funcionales.

81
 UML
Diagrama de Secuencia

1
 Los Diagramas de Secuencias muestran la forma en
que un grupo de objetos se comunican (interactúan)
entre sí a lo largo del tiempo

Un Diagrama de Secuencia consta de objetos,

mensajes entre estos objetos y una línea de vida del
objeto representada por una línea vertical

pedro = new Persona()

Es importante recordar la diferencia

entre una clase y un objeto 2
¿Qué tiene que ver un diagrama de secuencias
con la fábula de los tres cerditos?
(Gracias Ken Howard)
http://kenhoward01.blogspot.com/2008/06/three-little-pigs-in-uml.html
Los diagramas
de Secuencias
“cuentan”
historias
 5
Fuente: http://kenhoward01.blogspot.com/2008/06/three-little-pigs-in-uml.html
 Actores
Involucrados

Recordar
Etiquetas

Ejecución en Instanciación
Objeto
Paralelo
Objeto
(Ejecución)
Línea de Vida
Activo
de un Actor
u Objeto

Separador de
las ejecuciones
concurrentes

Fuente: http://www.tracemodeler.com/articles/pimp-my-diagram-three-little-pigs/
 Comentario

Mensaje

Fin de la vida
de un objeto

Recordar
Etiquetas
Pila de Retorno
Llamada Explícito

Fuente: http://www.tracemodeler.com/articles/pimp-my-diagram-three-little-pigs/
 Ojo, aquí
hay un error

Fuente: http://www.tracemodeler.com/articles/pimp-my-diagram-three-little-pigs/
Flujo Normal:
1.- El actor pulsa sobre el botón para crear un nuevo mensaje.
2.- El sistema muestra una caja de texto para introducir el título del mensaje
y una zona de mayor tamaño para introducir el cuerpo del mensaje.
3.- El actor introduce el título del mensaje y el cuerpo del mismo. 4.- El
sistema comprueba la validez de los datos y los almacena.
5.- El moderador recibe una notificación de que hay un nuevo mensaje. 6.- El
moderador acepta y el sistema publica el mensaje si éste fue aceptado por el
moderador.
Flujo Alternativo:
4.A.- El sistema comprueba la validez de los datos, si los datos no son
correctos, se avisa al actor de ello permitiéndole que los corrija.

7.B.- El moderador rechaza el mensaje, de modo que no es publicado sino

devuelto al usuario.

9
 Mensaje
Distintos símbolos
a si mismo
usados para diferenciar
distintos tipos de
objetos

Recordar
Etiquetas

Numeración
(Orden) Mensaje
de los Asíncrono
Mensajes
10
protected void doPaint(Painter painter) {
painter.drawRect(x, y, width, height);

// Cause painting of shapes to be relative to this shape

painter.translate(x, y);

for (Shape s : shapes) { s.paint(painter);

}
}

Es posible utilizar un diagrama de secuencia para

modelar el método anterior
11
 Argumentos
del Mensaje

Origen del
Mensaje
Indeterminado

Destino del
Mensaje
Indeterminado

Repetición *
mientras / para
Recordar [condición]
Etiquetas 12
protected void doPaint(Painter painter, Config config) {
painter.drawRect(x, y, width, height);

// Cause painting of shapes to be relative to this shape

painter.translate(x, y);

for (Shape s : shapes) { Rectangle clip = s.getClip();

painter.setClip(clip); s.paint(painter);
}

// Restore graphics origin painter.translate(-x, -y);

}
 Lazo / Repetición
Explícito de Valor de
más de una Retorno
instrucción

Mientras / para
[condición]

Marco
Compuesto
Recordar
Etiquetas
protected void doPaint(Painter painter, Config config) {
painter.drawRect(x, y, width, height);

// Cause painting of shapes to be relative to this shape

boolean translate = config.needsTranslation();

if (translate) {
painter.translate(x, y);
}

for (Shape s : shapes) { s.paint(painter);

}
}
Condicional
[condición]
protected void doPaint(Painter painter, Config config) {
painter.drawRect(x, y, width, height);

// Cause painting of shapes to be relative to this shape

boolean translate = config.needsTranslation();

if (translate) { painter.setTransformsEnabled(true);
painter.translate(x, y);
}

for (Shape s : shapes) { s.paint(painter);

}
}
Condicional
(Opcional)
[condición]
protected void doPaint(Painter painter, Config config) {
painter.drawRect(x, y, width, height);

// Cause painting of shapes to be relative to this shape

boolean translate = config.needsTranslation();

if (translate) { painter.setTransformsEnabled(true);
painter.translate(x, y);
} else { painter.setTransformsEnabled(false);
painter.translate(0, 0);
}

for (Shape s : shapes) { s.paint(painter);

}
}

10
 Se pueden
Flujos tener todos los
Alternativos compartimientos
(if/else) que sean
[condición] necesarios

10
Identificación
del diagrama

10
Identificación
del diagrama

10
 Una referencia rápida de UML
http://www.holub.com/goodies/uml/

Tutorial de Diagramas de Secuencia (IBM)

http://www.ibm.com/developerworks/rational/library/3101.html

Tutorial de Diagramas de Secuencia (Trace Modeler)

http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/index.htm

10
Gra cias
Los diagramas de componentes ilustran las piezas
del software, controladores que conformaran un
sistema. Tiene un nivel más alto de abstracción que
un diagrama de clase.

Usualmente un componente se implementa por una

o más clases (u objetos) en tiempo de ejecución.
Representa la separación de un sistema
de software en componentes físicos (por
ejemplo archivos, cabeceras, módulos,
paquetes, etc.) y muestra las
dependencias entre estos componentes.
 Componentes
 Interfaces
 Relaciones de dependencia,
generalización, asociación y realización
 Paquetes o subsistemas
Las relaciones de dependencia se
utilizan en los diagramas de
componentes para indicar que un
componente se refiere a los servicios
ofrecidos por otro componente.
haber entre ellos relaciones de
dependencia como:
generalización
asociación
agregación
realización
Los componentes se representan como un
clasificador rectangular con la clave
«componente», opcionalmente el
componente se puede mostrar como un
rectángulo con un icono de componente en
la esquina derecha arriba.
El conector Ensamble une la interfaz
requerida del componente
(Componente1) con la interfaz
proporcionada de otro componente
(Component2).
Usar puertos con Diagramas de Componentes
permite que se especifique un servicio o
comportamiento a su entorno

así como también un servicio o

comportamiento que un componente
requiere.
Estos son útiles para entender los
diagramas de clases. Estos no
muestran nada diferente
en su
arquitectura a los diagramas de
secuencia, pero reflejan multiplicidad y
roles.
El elemento clase consiste de tres
partes, divididas en compartimientos de
nombres, atributos y operaciones.
 Control y Análisis
Interfaz deTerminal
Comme
Comme

Gestión deCuentas Acceso aBD

Rutinas de Coneccion
Comme Comme
Comme