EJEMPLOS DE

MODELOS CON EL
LENGUAJE UML
¿Qué es UML?
• El Unified Modeling Language (UML) es
una notación estándar desarrollada por
Grady Booch, Ivar Jacobson y Jim
Rumbaugh.
• La documentación se publica en
http://www.rational.com/uml

• Aunque se basa en la experiencia personal

de los autores, incorpora contribuciones
de otros metodólogos.
• Primera versión enviada al OMG (Object
Management Group) en enero de 1997
por Rational Software, Microsoft,
Hewlett-Packard, Oracle, Texas
Instruments, MCI Systemhouse y otros.
• Útil para el diseño de software, hardware,
redes y negocios.
 Arquitectura de un sistema

vocabulario, ensamble
funcionalidad del sistema,
administración
Vista diseño Vista implementación
de la
configuración

comportamiento Vista caso de uso

topología
Vista proceso Vista implantación del sistema,
desempeño, distribución,
escalabilidad, entrega,
throughput instalación
 Beneficios del UML

• Promueve un enfoque paso-a-paso para el desarrollo de

software de calidad
• Define un mapeo sin costuras (seamless) de la captura de
requerimientos —al análisis y diseño— a la construcción y a la
transición
• Define una notación expresiva y consistente
• Hace más fácil la comunicación con los demás
• Ayuda a detectar omisiones e inconsistencias
• Soporta el análisis y diseño tanto a pequeña como a gran escala
MODELOS DE CASO
DE USO
 Comportamiento de un sistema

• El comportamiento de un sistema es el modo como ese

sistema actúa y reacciona
• La actividad visible y comprobable de un sistema
• El comportamiento de un sistema se captura por medio
de un modelo de casos de uso
• Este modelo describe el sistema, su medio y las relaciones entre
el sistema y su medio
 ¿Qué es un modelo de casos de uso?

• Un modelo de casos de uso es un modelo de las funciones (casos de

uso) que provee o proveerá un sistema y su medio (actores)
• Los actores representan usuarios o cualquier otro objeto que
interactúe con el sistema que se está modelando
• El modelo de casos de uso sirve como un hilo que unifica muchas de
las tareas involucradas en el desarrollo de un sistema: análisis de
requerimientos, diseño y prueba
• La meta más importante de un modelo de casos de uso es comunicar
la funcionalidad y el comportamiento del sistema al cliente o al
usuario final
 Beneficios

• El modelo de casos de uso

• Se utiliza para la comunicación con los usuarios finales y los expertos
del dominio
• Apoya la “venta” del sistema en las primeras etapas de su desarrollo
• Asegura la mutua comprensión de los requerimientos
• Se utiliza para identificar
• Quién interactuará con el sistema y qué es lo que el sistema hará
• Qué interfaces deberá tener el sistema
• Se utiliza para verificar
• Que se han capturado todos los requerimientos
• Que los desarrolladores han comprendido los requerimientos
 Principales conceptos

 Un actor representa cualquier cosa que

interactúa con el sistema
Actor
 Un caso de uso es una secuencia de
transacciones realizadas por un sistema, la
cual produce resultados de valor para un
actor particular

caso de uso
 ¿Qué es un actor?
• Los actores no son parte del
sistema, sino que representan roles
que los usuarios del sistema pueden
tener
• Un actor puede intercambiar
activamente información con el
Actor sistema
• Un actor puede ser un consumidor
pasivo de información
• Un actor puede ser un proveedor de
información
• Un actor puede ser un humano, una
máquina u otro sistema
 Instancias de actores

insertar 1 2 3
tarjeta 4 5 6
Iván es un 7 8 9
actor * 0 #

Tomás es un
actor

Modelo de casos de uso

Operador imprimir reporte diario

 Un usuario, muchos actores

Juan como
insertar
tarjeta 1 2 3 operador
4 5 6
7 8 9
* 0 #

Juan Operador
Juan como
cliente
Cliente
 Actores y fronteras del sistema

Mantenimiento
de cajeros
¿Frontera
del sistema?
Cajero automático

Sistema
Cajero del banco
 ¿Qué es un caso de uso?

• Un caso de uso modela un diálogo

entre los actores y el sistema

caso de uso
• Un caso de uso es iniciado por un
actor para invocar una cierta
funcionalidad en el sistema
• Un caso de uso es un flujo completo
y significativo de eventos
• Tomados todos juntos, los casos de
uso constituyen la totalidad los
modos posibles en que el sistema
puede ser utilizado
 Fuentes para los casos de uso

• Especificación del sistema / planteamiento del problema

• Literatura relevante del dominio
• Entrevistas con expertos del dominio
• Conocimiento personal del dominio
• Sistemas legados
 El diagrama de casos de uso
• Puede dibujarse un diagrama de casos de uso para ilustrar qué
casos de uso y actores interactúan enviándose estímulos entre sí

realizar transacciones
Cliente Banco

obtener reportes

Mantenimiento de
cajeros

dar mantenimiento a cajeros

automáticos
 Relaciones entre casos de uso

• Una generalización <<include>> del caso de uso A al caso de uso B

indica que A hereda de B, lo cual significa que una instancia de A
puede realizar todo el comportamiento descrito por B
• B identifica comportamiento común a varios casos de uso, evitando la
repetición de la descripción del mismo flujo de eventos
• Una relación <<extend>> de un caso de uso B a un caso de uso A
indica que una instancia que ejecuta el caso de uso A puede en algún
momento dejar de obedecer ese caso de uso y comenzar a obedecer
al caso de uso B
• Cuando la instancia haya dejado de obedecer a B volverá a obedecer a A, de
modo que A y B juntos actúan como una especialización del caso de uso A
 Relaciones entre casos de uso

«extend»
colocar pedido tiene un punto (más pedidos)
de extensión para inserciones. solicitar catálogo sabe
dónde se invoca en
colocar pedido solicitar catálogo
colocar pedido, pero
colocar pedido no lo sabe.
Estas inserciones son
explícitas en colocar pedido. «include» «include» «include»

proporcionar datos del cliente pedir producto negociar forma de pago

generalización

Estos casos de uso son especies

de negociar forma de pago.

pago en efectivo pago con crédito

 Otro ejemplo
reservar

Agencia

pagar boleto

check in Empleado
«include» «extend» mostrador

asignar asiento documentar equipaje

Pasajero
Empleado tráfico

abordar

Sobrecargo
entregar equipaje
 Documentación

• Los casos de uso se documentan con

• Una breve descripción
• El propósito del caso de uso en unas cuantas líneas
• Un flujo detallado de eventos
• La descripción de los flujos primario y alternos de eventos que
ocurren cuando se ejecuta el caso de uso

• Ambos documentos se escriben en términos que el

usuario pueda entender
 Flujo de eventos
• Cada caso de uso
• Tiene una secuencia de transacciones normal, básica
• Puede tener varias secuencias alternativas de transacciones
• Normalmente tiene varias secuencias excepcionales de transacciones que
manejan situaciones erróneas
• Puede también tener pre/postcondiciones bien definidas
 Flujo de eventos

• Describir únicamente los eventos pertenecientes al caso de uso y no lo que

sucede en otros casos de uso
• Evitar términos vagos tales como “por ejemplo”, “etc.”, “información”
• El flujo de eventos debería de describir
• Cómo y cuándo inicia y termina el caso de uso
• Cuándo el caso de uso interactúa con los actores
• Qué información se intercambia entre un actor y el caso de uso
• No describir los detalles de la interfaz al usuario a menos que ella sea un requerimientos
importante
• El flujo básico de eventos
• Los flujos alternos de eventos
 Flujo de eventos

• Describir únicamente los eventos pertenecientes al caso de uso y no lo que

sucede en otros casos de uso
• Evitar términos vagos tales como “por ejemplo”, “etc.”, “información”
• El flujo de eventos debería de describir
• Cómo y cuándo inicia y termina el caso de uso
• Cuándo el caso de uso interactúa con los actores
• Qué información se intercambia entre un actor y el caso de uso
• No describir los detalles de la interfaz al usuario a menos que ella sea un requerimientos
importante
• El flujo básico de eventos
• Los flujos alternos de eventos
 Especificación de caso de uso
Caso de uso Asignar asiento
Resumen Un pasajero con una reservación en un vuelo requiere le sea asignado un asiento. El sistema obtiene información del
pasajero y luego intenta hacer una asignación. La asignación es dada al pasajero o el pasajero es informado de que
no hay asignación disponible
Actores Pasajero
Precondiciones El pasajero tiene una reservación en un vuelo de una aerolínea dada
Descripción Un pasajero requiere que le sea asignado un asiento en un vuelo. (Esto puede ser implícito como parte del registro
(checking in) o puede ser una petición explícita del pasajero). El sistema (en la forma de agente) pregunta por la
fecha del vuelo, el número de vuelo, el aeropuerto de salida y el nombre del pasajero. El pasajero suple la
información. En lugar de su nombre, el pasajero puede suministrar su número de viajero frecuente en la aerolínea.
[Excepción: Demasiado pronto para efectuar asignaciones.] El sistema obtiene la reservación. [Excepción: No se
encuentra la reservación.] Si la reservación ya tiene una asignación de asiento, se le ofrece al pasajero la
oportunidad de cambiar la asignación. Si no hay asignación ni el pasajero desea cambiarla, el sistema pregunta por
una preferencia de asiento (ventanilla o pasillo) y preferencia de fumar (sí o no). El sistema utiliza la información,
incluyendo el nivel de viajero frecuente para intentar obtener una asignación de asiento posible sujeta a las
asignaciones previas y a las políticas de la aerolínea. Si es necesario, el sistema hace preguntas adicionales:
¿aceptaría el pasajero un asiento que da al área de servicios o a una salida de emergencia? El sistema propone una
asignación de asiento. Si no pueden satisfacerse todas las preferencias del pasajero, entonces el sistema propone la
mejor opción que se pueda tener. [Excepción: No hay asignación posible.] El pasajero puede aceptar la asignación o
preguntar por cambios, en cuyo caso se intenta otra asignación. El caso de uso concluye cuando se hace una
asignación y se acepta.
Excepciones Demasiado pronto para efectuar asignaciones: Se alcanza si la fecha en curso es muy temprana, determinado con
base en el algoritmo que incluye la tarifa normal y el nivel de viajero frecuente. Se informa al pasajero cuándo se
podrán hacer asignaciones y el caso de uso termina.
No se encuentra la reservación: Se alcanza si la reservación no puede encontrarse. La información se rechequea y
se busca si es necesario para una confrontación parcial. Si sigue sin encontrarse, entonces se avisa al pasajero que
obtenga una y el caso de uso termina.
No hay asignación posible: Se alcanza si no hay asignación posible con base en la fórmula que incluye el número de
asientos no asignados, los días que faltan para la salida, la categoría del pasajero. Se avisa al pasajero de que
obtenga la asignación durante el registro. Si esto es parte del registro, el pasajero se coloca en espera para la hora
de salida. El caso de uso termina.
Postcondiciones Si es parte del registro, el pasajero tendrá asignado un asiento o estará en espera en la fila de salida. De otro modo,
el intento falla.
¿Quién lee la documentación?
• Cliente –aprobar lo que el sistema hará
• Usuarios –proveer la comprensión del
sistema
• Desarrolladores del sistema –
documentar el comportamiento del
sistema
• Revisores –examinar el flujo de eventos
• Analistas / diseñadores del sistema –
proporcionar la base para el análisis y el
diseño
• Probador del sistema – como una base
para los casos de prueba
• Líder del proyecto – planeación del
proyecto
• Escritor técnico – cuando escriba la guía
del usuario para los usuarios finales
 Resumen

• El comportamiento de un sistema es el modo como ese sistema actúa y reacciona

• El comportamiento de un sistema puede ser caraterizado por un conjunto de casos de
uso
• Un caso de uso es un conjunto de funciones realizadas por el sistema en respuesta a un
estímulo procedente de un actor externo
• Los casos de uso son un vehículo para capturar los requerimientos para un sistema desde el punto de vista
del usuario
• Un actor es alguien o algo que debe de interactuar con el sistema (a través de una
interfaz)
• Un diagrama de casos de uso es una representación gráfica de un sistema que muestra
sus actores y casos de uso
• Cada caso de uso en el modelo se documenta por medio de una breve descripción y un
flujo de eventos
 MODELOS DE
CLASES Y OBJETOS
 Objetos y clases
Análisis estructurado moderno
precio = $200
cantidadEnExistencia = 250
tasaRegalías = 25%
agotado = No
añoPublicación = 1989
Libro
Diseño estructurado precio
precio = $250
cantidadEnExistencia = 20 cantidadEnExistencia
tasaRegalías = 20% tasaRegalías
agotado = Sí agotado
añoPublicación = 1979 añoPublicación

Los ciclos de vida de los objetos

precio = $100
cantidadEnExistencia = 150
tasaRegalías = 15%
agotado = No
añoPublicación = 1992

Larry Constantine Sally Shlaer

saldoRegalías = $5,000 saldoRegalías = $2,000 Autor
saldoRegalías
Stephen Mellor Edward Yourdon
saldoRegalías = $4,000 saldoRegalías = $10,000
 Compartimentos
Libro Libro Libro
precio precio
cantidadEnExistencia cantidadEnExistencia calcularTiraje()
tasaRegalías tasaRegalías listarAutores()
agotado agotado listarEdiciones()
añoPublicación añoPublicación reexpresarPrecio()
calcularTiraje() c) Nombre y operaciones
listarAutores() b) Nombre y atributos
listarEdiciones()
reexpresarPrecio()

a) Completo
Libro Libro
e) Sólo nombre

d) Nombre y compartimentos
 Estereotipos de clases
«frontera» «entidad» «control»
Libro Libro Libro
precio precio precio
cantidadEnExistencia cantidadEnExistencia cantidadEnExistencia
tasaRegalías tasaRegalías tasaRegalías
agotado agotado agotado
añoPublicación añoPublicación añoPublicación
calcularTiraje() calcularTiraje() calcularTiraje()
listarAutores() listarAutores() listarAutores()
listarEdiciones() listarEdiciones() listarEdiciones()
reexpresarPrecio() reexpresarPrecio() reexpresarPrecio()

V
Libro Libro Libro
T

precio precio precio

cantidadEnExistencia cantidadEnExistencia cantidadEnExistencia
tasaRegalías tasaRegalías tasaRegalías
agotado agotado agotado
añoPublicación añoPublicación añoPublicación
calcularTiraje() calcularTiraje() calcularTiraje()
listarAutores() listarAutores() listarAutores()
listarEdiciones() listarEdiciones() listarEdiciones()
reexpresarPrecio() reexpresarPrecio() reexpresarPrecio()
 Necesidad de las relaciones

• Los sistemas están compuestos por muchos objetos

• Los objetos contribuyen al comportamiento del sistema
colaborando unos con otros
• La colaboración se realiza a través de relaciones
• Existen tres tipos importantes de relaciones que se establecen
entre los objetos durante la modelación:
• Asociación
• Agregación
• Composición
 Asociaciones
• Una asociación es una conexión entre clases
• Lo cual implica que existe una liga entre los objetos descritos por las clases asociadas
• Las asociaciones se representan sobre los diagramas de clases por medio de una línea que
conecta las clases asociadas
• Una asociación es una relación bidireccional
• Dada una instancia de Libro, existe un objeto Autor asociado
• Dada una instancia de Autor, existe un objeto Libro asociado
• La asociación puede hacerse unidireccional

Libro Autor

Libro Autor
 Nombre de la asociación
• A las asociaciones se les puede poner un nombre para hacer más
claro su significado
• El nombre se representa como una etiqueta colocada a lo largo
de la línea de la asociación, a medio camino entre los iconos de
las clases
• Un nombre de asociación es usualmente un verbo o una frase
verbal

Libro EscritoPor  Autor

 Definición de roles
• Un rol denota el propósito o la capacidad que tiene una clase al
asociarse con otra
• Los nombres de roles son usualmente sustantivos o frases
nominales
• Un nombre de rol se coloca a lo largo de la línea de la asociación
próximo a la clase que modifica
• Uno o ambos extremos de una asociación pueden tener nombres de roles

Persona autor Escribe  Libro

 Asociaciones múltiples
• Puede haber más de una asociación entre dos clases
• Si existe más de una asociación entre dos clases,
entonces ellas deben de tener un nombre
• Las asociaciones múltiples deberían de ser enfrentadas

Persona Escribe  Libro

Lee 
 Multiplicidad

• Multiplicidad es el número de instancias de una clase

relacionadas a UNA instancia de la otra clase
• Para cada asociación, hay dos decisiones de multiplicidad que
se deben de tomar: una para cada extremo de la asociación
• Por ejemplo, en la conexión entre Editorial con el rol de
publicante y Libro:
• Cada instancia de Editorial puede publicar muchos (es decir, cero o
más) Libro
• Para cada instancia de Libro, exactamente una Editorial lo publica
 Indicadores de multiplicidad
• Cada extremo de una asociación contiene un indicador
de multiplicidad que indica el número de objetos que
participan en la asociación
Muchos
*
Exactamente uno
1
Cero o más
0..*
Uno o más
1..*
Cero o uno
0..1
Rango especificado
2..4
 Ejemplo de multiplicidad

Editorial editor Publica  Libro

1 1..*

• Las decisiones de multiplicidad están expuestas a

muchos supuestos ocultos acerca del problema que
está siendo modelado:
• ¿Puede una editorial no tener libros publicados?
• ¿Puede un libro tener dos o más editores?
 ¿Qué significa la multiplicidad?

• La multiplicidad responde dos preguntas:

¿Es la asociación obligatoria u opcional?
¿Cuál es el número mínimo y cuál es el número máximo de instancias que
pueden ser ligadas a la otra instancia?

Curso Estudiante
0..* 3..15
 Agregación
• La agregación es una forma especializada de asociación en la
cual un todo se relaciona con alguna o algunas de sus partes
• La agregación es una relación “parte de”
• Una agregación se representa como una asociación con un
rombo pegado a la clase que denota el agregado (todo)
• La multiplicidad se representa del mismo modo que en las
asociaciones débiles

Catálogo Libro
1..*
 Agregación

ComputadoraPersonal

1 1 1 1

1..* 1 0..1 1
Monitor CajaSistema Ratón Teclado

1 1
1 1

1 1 0..* 0..1
Chasís Procesador RAM Ventilador
 Agregación
Ventana

1 1
1 1

1 1 0..2 1

BarraDeTítulo AreaCliente Bastidor Borde

1 1 1 1 1

1 1 0..* 2 1

BotónDeCerrar Título Partición Flecha Indicador

 Características de agregación

• ¿Puede utilizarse la frase “parte de” para describir la relación?

• Una Puerta es “parte de” un Carro
• ¿Algunas operaciones sobre el todo se aplican automáticamente a
sus partes?
• Al mover el Carro, movemos la Puerta
• ¿Algunos valores de atributos se propagan del todo a todas o algunas
de sus partes?
• El Carro es azul, la Puerta es azul
• ¿Hay una asimetría intrínseca en la relación, en el sentido de que una
clase está subordinada a la otra?
• Una Puerta ES parte de un Carro, un Carro NO ES parte de una Puerta
 ¿Asociación o agregación?
• Si dos objetos están fuertemente ligados por una relación todo-parte:
• La relación es una agregación
• Si dos objetos se consideran normalmente como independientes, aún
cuando frecuentemente estén enlazados:
• La relación es una asociación

Catálogo Libro Escrito-por Autor

1..* 0..* 3..10

Catálogo y Libro están

fuertemente acoplados –el Objetos independientes
Catálogo está “hecho de”
uno o más libros
 ¿Asociación o agregación?
Currículum

Currículum y Curso están fuertemente

acoplados —un Curso es “parte de” el
Currículum
1..*
Curso
0..*

0..*
Los objetos Curso y sus objetos Curso
Prerrequisito
prerrequisito son independientes
 Composición
CuerpoHumano
• Es una forma de agregación con una
fuerte apropiación y un ciclo vital
coincidente de las partes con el todo
1 1 0..4
• El cuerpo humano es un compuesto
Cabeza Tronco Extremidad
• La multiplicidad de la terminación en el
agregado no puede ser mayor que uno
(el agregado no puede ser compartido)
CuerpoHumano • Las partes con multiplicidad > 1 pueden
ser creadas después que el agregado,
1 Cabeza
pero una vez creadas viven y mueren
con él

1
• Prótesis
Tronco
• Estas partes pueden ser removidas del
agregado (señalado con un rombo
0..4 Extremidad relleno) antes de que muera
 Asociaciones reflexivas

• Una asociación reflexiva relaciona objetos descritos por

la misma clase
• Lo cual indica que múltiples objetos de la misma clase
colaboran entre sí de alguna manera

Autor
0..*

0..* EsCoautor

Un autor puede escribir en coautoría con muchos autores

Un autor puede ser coautor de muchos otros autores
 Agregados reflexivos
• Los agregados también pueden ser reflexivos
• Un problema clásico de este tipo es el de la explosión de
materiales
• Los agregados reflexivos establecen una relación
recursiva
Parte
0..1
Un objeto Parte “está compuesto de” uno o
1..* más objetos Parte
 DIAGRAMAS
DE ACTIVIDAD
Diagrama de actividad
• Es un caso especial de diagrama de
estados en el cual muchos (o todos) los
estados son estados acción y muchas (o
todas) las transiciones son disparadas por
la terminación de las acciones en los
estados fuente
• Cada diagrama está referido a una clase o
a la implementación de una operación o a
un caso de uso
• Se enfoca a flujos impulsados por procesos
internos (como opuesto a eventos
internos)
• Se emplean en situaciones donde muchos
(o todos) los eventos representan la
terminación de acciones internamente
generadas (es decir, flujo procedimental de
control)
Diagramas de Secuencia
/ Colaboración
 Diagramas de interacción

• Los escenarios se capturan típicamente en diagramas de

interacción más que vía texto
• Existen dos tipos de diagramas de interacción
• Diagramas de secuencia
• Diagramas de colaboración
• Cada uno de ellos proporciona una vista diferente de la misma
interacción
• En los diagramas de secuencia los eventos están ordenados por el
tiempo
• Los diagramas de colaboración pueden incluir flujo de datos así
como relaciones de descomposición de objetos
 Diagramas de secuencia
• Un diagrama de secuencia representa los mensajes intercambiados por un
conjunto de objetos durante un escenario
• Un diagrama de secuencia contiene:
• Objetos —dibujados como rectángulos con los nombres subrayados
• “Líneas de vida” de objetos —representadas por líneas descendentes de guiones
• Mensajes intercambiados entre los objetos en secuencia ordenada
• Foco de control (opcional)

cursos
disponibles
 Un diagrama de secuencia

formulario de formulario de cursos

Juan : Estudiante inscripción programa disponibles

1: captar identificación

2: validar identificación

3: semestre a cursar

4: crear nuevo programa

5: mostrar
6: tramitar cursos
7: inscribir
 Interacción de objetos
• La interacción de objetos se indica por medio de flechas horizontales dirigidas
desde la línea vertical que representa el objeto cliente a la línea que
representa al objeto proveedor
• Las flechas horizontales están rotuladas con mensajes
• La ordenación temporal de los eventos se indica por la posición vertical, de
modo que el primero aparece hasta arriba
• La numeración es opcional, puesto que el orden se basa en la posición vertical
formulario de cursos
programa disponibles

tramitar cursos
 Una llamada de emergencia
teléfono que línea telefónica teléfono que
llama recibe la llamada
iniciar llamada
emitir tono de marcar
recibir el dígito 9
finalizar tono de marcar
recibir el dígito 1
recibir el dígito 1
emitir señal de llamando sonar el teléfono
iniciar respuesta
terminar la señal de llamando terminar de sonar el teléfono
colgar
terminar la conexión terminar la conexión
colgar
 Foco de control
• El foco de control representa el tiempo relativo que el flujo de control se enfoca en un
objeto
• Representa el tiempo durante el que un objeto está dirigiendo mensajes
• Los diagramas de secuencia pueden mostrar el foco de control

formulario de formulario de cursos

inscripción programa disponibles
Juan : Estudiante
1: captar identificación

2: validar identificación

3: semestre a cursar

4: crear nuevo programa

5: mostrar

6: tramitar cursos
 Una computación
A B C

f()
crear
g()

h()

destruir
return
 Notas
• Se pueden añadir notas para agregar más información
al diagrama
cursos disponibles
para el semestre
seleccionado
formulario de cursos
programa disponibles

tramitar cursos
 Scripts
• Para escenarios complejos, los diagramas de secuencia pueden ampliarse mediante el
uso de scripts
• Los scripts se escriben en la parte izquierda de los diagramas de secuencia, con los
pasos del script alineados con las interacciones de los objetos
• Los scripts pueden escribirse en lenguaje ordinario o seudocódigo

formulario de un curso
programa

Procesar primeramente los listar prerrequisitos

cursos obligatorios, procesar
los cursos optativos
solamente si es necesario.
 Inscripción
formulario de formulario cursos un curso cursos matrícula calendario facturación
inscripción de programa disponibles disponibles de cursos
Juan : Estudiante
1: captar identificación

2: validar identificación

3: semestre a cursar
4: crear nuevo programa
5: mostrar
6: tramitar cursos
7: inscribir

8: procesar
9: listar prerrequisitos
10: prerrequisito tomado
11: matricular estudiante (Juan)
12: inscripción completada
13: imprimir
14: facturar
 Inscripción
2: validar identificación

calendario
1: captar identificación
3: semestre a cursar formulario de inscripción
4: crear nuevo programa
13: imprimir
registro estudiantil
7: inscribir 10: prerrequisito tomado
8: procesar 5: mostrar

14: facturar
Juan : Estudiante
12: inscripción completada formulario de programa facturación

9: listar prerrequisitos

11: matricular estudiante (Juan)

6: tramitar cursos un curso

cursos disponibles

matrícula de cursos
 Una llamada de emergencia
1: iniciar llamada
teléfono que llama 3: recibir el dígito 9
5: recibir el dígito 1
6: recibir el dígito 1
15: colgar

13: terminar la conexión

10: terminar la señal de llamando
7: emitir señal de llamando 8: sonar el teléfono
línea telefónica
4: finalizar tono de marcar 11: terminar de sonar el teléfono
2: emitir tono de marcar 14: terminar la conexión

12: colgar
9: iniciar respuesta

teléfono que recibe la llamada

 Resumen

• Un escenario puede ser representado gráficamente por medio de un

diagrama de secuencia o un diagrama de colaboración que muestre
la existencia de objetos y las interacciones entre los objetos
identificados
• Los objetos se representan con rectángulos y sus nombres
subrayados
• La “línea de vida” de un objeto se representa con una línea vertical
de guiones que desciende desde el objeto
• Los mensajes se indican por medio de flechas horizontales que se
dirigen del objeto cliente (emisor) al objeto proveedor (receptor)
• Las flechas horizontales se rotulan con el nombre del mensaje
• Se pueden agregar scripts para dar más detalle al diagrama