CASO DE USO INCLUDE

En términos muy simples, cuando relacionamos dos casos de uso con un “include”, estamos
diciendo que el primero (el caso de uso base) incluye al segundo (el caso de uso incluido).
Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podría
funcionar bien; pues no podría cumplir su objetivo. Para una venta en caja, la venta no puede
considerarse completa si no se realiza el proceso para cobrarla en ese momento. El caso
de uso “Cobrar Renta” está incluido en el caso de uso “Rentar Video”, o lo que es lo mismo
“Rentar Video” incluye (<<include>>) “Cobrar Renta”.

CASO DE USO EXTEND

La polémica al querer seleccionar una de las dos relaciones es que en el “extend” también
podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran uno sólo. Y
en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no se ejecutara la
extensión. Pero, una de las diferencias básicas es que en el caso del “extend” hay
situaciones en que el caso de uso de extensión no es indispensable que ocurra, y cuando lo
hace ofrece un valor extra (extiende) al objetivo original del caso de uso base. En cambio en
el “include” es necesario que ocurra el caso incluído, tan sólo para satisfacer el objetivo del
caso de uso base. Ejemplo: Puedes “Realizar Venta” sin “Acumular Puntos de Cliente VIP”,
cuando no eres un cliente VIP. Pero, si eres un cliente VIP sí acumularás puntos. Por lo
tanto, “Acumular Puntos” es una extensión de “Realizar Venta” y sólo se ejecuta para cierto
tipo de ventas, no para todas.
ACTOR (UML)

En el Lenguaje Unificado de Modelado (UML), un actor "especifica un rol jugado por un usuario o
cualquier otro sistema que interactúa con el sujeto.
Un actor modela un tipo de rol jugado por una entidad que interactúa con el sujeto (esto es,
intercambiando signos y datos), pero que es externo a dicho sujeto.1
Los actores pueden representar roles jugados por usuarios humanos, hardware externo, u otros
sujetos. Un actor no necesariamente representa una entidad física específica, sino simplemente una
faceta particular (es decir, un "rol") de alguna actividad que es relevante a la especificación de sus
casos de uso asociados. Así, una única instancia física puede jugar el rol de muchos actores diferentes
y, asimismo, un actor dado puede ser interpretado por múltiples instancias diferentes.
UML 2 no permite asociaciones entre Actores. A pesar de todo, esta restricción es usualmente
violada en la práctica, en la medida que la generalización/especialización de relaciones entre actores
es útil para el modelado de los comportamientos de superposición entre actores.

CASO DE USO
Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema
en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de
casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema
mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual , un
diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una
relación es una conexión entre los elementos del modelo, por ejemplo la relación y la
generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los
requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se
producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos:
un actor es una entidad externa al sistema que se modela y que puede interactuar con
él; un ejemplo de actor podría ser un usuario o cualquier otro sistema. Las relaciones
entre casos de uso y actores pueden ser las siguientes:  Un actor se comunica con un
caso de uso.  Un caso de uso extiende otro caso de uso.  Un caso de uso usa otro caso
de uso.
MODELOS DE CASO DE USO DEL SISTEMA
“El modelo de casos de uso permite que los desarrolladores del software y los clientes lleguen
a un acuerdo sobre los requisitos, es decir, sobre las condiciones y posibilidades que debe
cumplir el sistema. El modelo de casos de uso sirve como acuerdo entre clientes y
desarrolladores, y proporciona la entrada fundamental para el análisis, el diseño y las pruebas.”

“Un modelo de casos de uso es un modelo del sistema que contiene actores, casos de uso y sus
relaciones.”

“El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario.”

Actores del sistema.

Un actor no es más que un conjunto de roles que los usuarios de Casos de Uso desempeñan
cuando interaccionan con estos Casos de Uso. Los actores representan a terceros fuera del
sistema que colaboran con el mismo. Una vez identificado los actores del sistema, queda
identificado el entorno externo del sistema.
Actor Justificación

Usuario General Persona que puede registrarse en el sistema, puede ser: profesor o
administrador.

Profesor Es la persona interesada en conocer el comportamiento de un Estudiante en

un Software Educativo.

Administrador Es quien crea las cuentas de acceso al sistema, le asigna a cada usuario sus
permisos en dependencia al rol a desarrollar y cambia la contraseña.

Tabla 1 Actores del Sistema

Casos de Uso del Sistema.

“La forma en que los actores usan el sistema se representa con un caso de uso. Los casos de
uso son “fragmentos” de funcionalidad que el sistema ofrece para aportar un resultado de valor
para sus actores. De manera más precisa, un caso de uso especifica una secuencia de acciones
que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro
de la secuencia.”

Por el número de casos de uso se introducen paquetes al modelo de casos de uso del sistema
con el objetivo de disminuir la complejidad y así aumentar en comprensión.
 Paquete Paquete
Administrativo Reportes

Fig 2 Diagrama de Paquetes de Casos de Usos.

Diagramas de casos de uso del sistema.

El Paquete Administrativo (Figura 3) contiene los casos de usos referentes a la administración

del sistema:

1. Autenticar usuario.

2. Buscar usuario.

3. Editar permisos usuarios.

4. Habilitar/Inhabilitar usuario.

5. Asignar SE a asignatura.

6. Editar datos de SE.

7. Eliminar SE del sistema.

Auntenticar usuario
Usuario General
(from Actors ) Buscar usuario

Asignar SE a asignatura

Editar permisos usuarios

Editar datos de SE
Profesor Administrador
(from Actors )
(from Actors )

Habilitar/Inhabilitar usuario
Eliminar SE del sistema

Fig 3 Diagrama de caso de Uso del Sistema: Paquete Administrativo.

El Paquete Reportes (Figura 4) contiene los casos de usos referentes a la información que
podrá obtener el profesor a través del sistema, teniendo en cuenta el comportamiento
de los estudiantes en cada SE:
1. Consultar ayuda.

2. Visualizar listado de estudiantes que visitaron un SE por grupo.

3. Visualizar el contenido visitado por un estudiante en el SE.

4. Visualizar fecha de entrada y salida de un estudiante en un contenido de un SE.

5. Visualizar cantidad de visitas al SE.

6. Visualizar cantidad de visitas del estudiante al SE.

7. Visualizar el tiempo que estuvo un estudiante en un SE en un rango de fecha.

8. Visualizar evaluación de un estudiante por contenido de un SE.

9. Visualizar Respuesta de un estudiante por preguntas de un contenido de un SE.

10. Visualizar SSEE de una asignatura.

Consultar Ayuda
Visualizar SSEE de una asignatura Visualizar listado de estudiantes que
visitaron un SE por grupo

Visualizar el contenido visitado por

Visualizar Respuesta de un estudiante un estudiante en el SE
por preguntas de un contenido de...

Visualizar evaluación de un Visualizar fecha de entrada y salida de un

Profesor
estudiante por contenido de un SE estudiante en un contenido de un SE
( from Actors )

Visualizar el tiempo que estuvo un Visualizar cantidad de visitas al SE

estudiante en un SE en un rango...

Visualizar cantidad de visitas del

estudiante al SE

Fig 4 Diagrama de caso de Uso del Sistema: Paquete Reportes.

MODELO DE CASO DE USO DEL NEGOCIO

Una vez creado el nuevo proyecto que servirá para desarrollar la Modelación del
Negocio de una empresa hotelera. El primer paso es la determinación de los Actores del
Negocio que se hace por medio de la identificación de los procesos de la institución o
empresa, cada uno de los procesos identificados puede ser un Casos de Uso del Negocio.

Para desarrollar el Diagrama de Casos de Uso del Negocio se debe estudiar los
esteriotipos de Casos de Uso del Negocio y el de Actor del Negocio. Estos dos
esteriotipos son suficientes para la creación del Diagrama de Casos de Uso del Negocio.
La definición de estos estereotipos ya se ha visto en el anterior documento Introducción
al Modelo del Negocio.

El Modelo de Caso de Uso del Negocio implicará la determinación de los Actores y Casos
de Uso del Negocio, como se ha dicho anteriormente. Con ésta actividad se pretende:

§ Identificar los procesos en el negocio

§ Definir las fronteras del negocio que van a modelarse

§ Definir quién y qué interactuarán con el negocio

§ Crear diagramas del modelo de casos de uso del negocio

Un candidato a Actor del Negocio es cualquier individuo, grupo, organización o máquina

que interactúa con el negocio. Por tanto, éstos pueden ser:

§ Clientes o potenciales clientes

§ Socios

§ Proveedores

§ Autoridades

§ Propietarios

§ Sistemas de información externos al negocio

§ Otras parte de la organización, si la organización es grande

El término Actor del Negocio significa el rol que algo o alguien juega cuando interactúa
con el negocio. De acuerdo con esta idea un Actor del Negocio representa un tipo
particular de usuario del negocio más que un usuario físico, ya que varios usuarios físicos
pueden realizar el mismo papel en relación al negocio, o sea, ser instancias de un mismo
actor. Sin embargo, un mismo usuario puede actuar como diferentes actores.

REPORT THIS AD

El nombre de un Actor del Negocio debe hacerse de modo que exprese su rol dentro del
negocio.

Cada Actor del Negocio debe definirse brevemente con su responsabilidad y por qué
interactúa con el negocio.

Los Actores del Negocio interactúan con el negocio enviando y recibiendo mensajes, y
para conocer el papel del actor se debe precisar en qué procesos se involucra el actor.
Esto se muestra por la llamada asociación de comunicación entre el Actor del Negocio y
el Caso de Uso del Negocio que representa al proceso.

Un Caso de Uso del Negocio define qué debe ocurrir en el negocio cuando este se realiza,
describe el comportamiento de una sucesión de acciones que produce un resultado de
valor para un Actor particular del negocio. Es decir, un Caso de Uso del Negocio describe
una secuencia de acciones realizadas en el negocio que produce un resultado de valor
observable para un actor individual del negocio. Por tanto, desde la perspectiva de un
actor individual, un caso de uso del negocio define el flujo de trabajo completo que
produce los resultados deseados.

En un negocio se pueden identificar al menos tres tipos de procesos:

 Actividades comercialmente importantes, a menudo llamadas procesos del

negocio y constituyen la esencia o núcleo del negocio.
 Actividades que no son comercialmente importantes pero son necesarias para
que el negocio funcione. Ejemplo: actividades administrativas, de limpieza, de
seguridad, etc. Estos casos de uso del negocio tienen carácter de soporte.
 Actividades gerenciales. Ejemplo: monitorear los procesos, crear procesos.

Para encontrar los casos de uso primarios del negocio hay que considerar qué producto
o servicio espera el actor del negocio. Estos procesos responden a la pregunta: “¿Cuáles
son los servicios primarios que el consumidor recibe del negocio?”.

Antes de la creación del Diagrama de Casos de Uso del Negocio dentro de Rational Rose,
se debe crear distintas carpetas que permitan ordenar de manera adecuada el Modelo
de Casos de Uso del Negocio. Estas carpetas son las siguientes:

 Actores del Negocio. Contendrá a todos los actores que estén involucrados en la
Modelación del Negocio
 Casos de Uso. Contendrá a todos los Casos de Uso del Negocio que se identifiquen
con un proceso de la empresa
 Entidades. Contendrá a todos los objetos o entidades que se identifiquen por
medio del Diagrama de Actividad que se crea por cada Caso de Uso del Negocio.
La creación de un diagrama de actividad se verá más adelante en otro documento.
 Trabajadores del Negocio. Contendrá a todos los trabajadores que participan en
el flujo de información dentro de la empresa.
REPORT THIS AD
REPORT THIS AD
DIAGRAMA DE ACTIVIDADES
El Lenguaje Unificado de Modelado incluye varios subconjuntos de diagramas, incluidos
los diagramas de estructuras, los diagramas de interacción y los diagramas de
comportamiento. Los diagramas de actividades, junto con los diagramas de casos de
uso y los diagramas de máquina de estados, son considerados diagramas de
comportamiento porque describen lo que debe suceder en el sistema que se está
modelando.

Las partes interesadas tienen muchos asuntos que manejar, por lo que es importante
una comunicación clara y concisa. Los diagramas de actividades ayudan a que las
personas en las áreas de negocios y desarrollo de una organización se integren para
comprender el mismo proceso y comportamiento. Usarás un conjunto de símbolos
especializados —incluidos aquellos para pasos de inicio, finalización, fusión y recepción
en el flujo— para crear un diagrama de actividades, lo cual cubriremos con más detalle
dentro de esta guía de diagramas de actividades.

Beneficios de los diagramas de actividades

Los diagramas de actividades presentan una serie de beneficios para los usuarios.
Considera crear un diagrama de actividades para:

 Demostrar la lógica de un algoritmo.

 Describir los pasos realizados en un caso de uso UML.
 Ilustrar un proceso de negocios o flujo de trabajo entre los usuarios y el sistema.
 Simplificar y mejorar cualquier proceso clarificando casos de uso complicados.
 Modelar elementos de arquitectura de software, tales como método, función y
operación.

Componentes básicos de un diagrama de actividades

Antes de empezar a crear un diagrama de actividades, debes comprender primero su
composición. Algunos de los componentes más comunes de un diagrama de actividades
incluyen:

 Acción: Un paso en la actividad en el que los usuarios o el software realizan una

tarea dada. En Lucidchart, las acciones se representan a través de rectángulos
con aristas redondeadas.
 Nodo de decisión: Una rama condicional en el flujo que se representa con un
diamante. Incluye una sola entrada y dos o más salidas.
 Flujos de control: Otro nombre para los conectores que muestran el flujo entre
pasos en el diagrama.
 Nodo inicial: Simboliza el inicio de la actividad. El nodo inicial se representa con
un círculo negro.
 Nodo terminal: Representa el paso final en la actividad. El nodo terminal se
representa por medio de un círculo negro de contorno blanco.
Crear diagramas es rápido y sencillo con Lucidchart. Inicia una prueba gratuita hoy
mismo para empezar a crear y colaborar.

Símbolos de diagramas de actividades

Estos símbolos y figuras de diagramas de actividades son algunos de los más comunes
que encontrarás en los diagramas UML.

Símbolo Nombre Descripción

Representa el inicio de un proceso o flujo de

trabajo en un diagrama de actividades. Se
Símbolo de inicio
puede usar por sí solo o con un símbolo de
nota que explique el punto de inicio.

Indica las actividades que componen un

proceso modelado. Estos símbolos, que
Símbolo de
incluyen descripciones breves en la misma
actividad
figura, son los componentes principales de un
diagrama de actividades.

Muestra el flujo direccional o el flujo de

control de la actividad. Una flecha entrante
Símbolo de
inicia un paso de una actividad; una vez que
conector
se completa el paso, el flujo continúa con la
flecha saliente.

Combina dos actividades simultáneas y las

Símbolo de unión
vuelve a introducir en un flujo en el que solo
o barra de
ocurre una actividad a la vez. Representado
sincronización
con una línea vertical u horizontal gruesa.

Divide el flujo de una sola actividad en dos

Símbolo de actividades simultáneas. Se simboliza con
bifurcación múltiples líneas con flecha a partir de una
unión.

Representa una decisión y siempre tiene, al

menos, dos caminos que se separan con un
Símbolo de
texto de condición para permitir que los
decisión
usuarios vean las opciones. Este símbolo
representa la división o la fusión de varios
Símbolo Nombre Descripción
flujos, en los cuales el símbolo actúa como
marco o contenedor.

Permite que los creadores o los

colaboradores del diagrama comuniquen
Símbolo de nota mensajes adicionales que no caben en el
diagrama mismo. Deja notas para agregar
especificaciones y aportar claridad.

Símbolo de Indica que se está enviando una señal a una

enviar señal actividad receptora.

Demuestra la aceptación de un evento. Una

Símbolo de
vez que se recibe el evento, se completa el
recibir señal
flujo que proviene de esta acción.

Símbolo de
pseudoestado de Representa una transición que invoca el
historia último estado activo.
superficial

Permite que el creador modele una secuencia

Símbolo de bucle
repetitiva dentro del símbolo de bucle de
de opción
opción.

Representa el final de un flujo de

proceso específico. Este símbolo no debería
representar el final de todos los flujos en una
Símbolo de final
actividad; en ese caso, usarías el símbolo de
de flujo
finalización. El símbolo de final de flujo se
debe colocar al final de un proceso en un
flujo de una actividad individual.

Se coloca al lado de un marcador de decisión

Texto de
para indicarte bajo qué condición un flujo de
condición
actividad debe bifurcarse en esa dirección.

Marca el estado final de una actividad y

Símbolo de
representa la conclusión de todos los flujos
finalización
de un proceso.
Ejemplos de diagramas de actividades
Los diagramas de actividades trazan flujos de procesos de una forma que es sencilla de
entender. Considera los dos ejemplos siguientes cuando se trate de crear diagramas de
actividades UML.

Diagrama de actividades para una página de inicio de sesión

En muchas de las actividades que las personas desean realizar en línea —revisar el
correo electrónico, administrar las finanzas, hacer pedidos de ropa, etc.— se les pide
que inicien sesión en un sitio web. Este diagrama de actividades muestra el proceso de
inicio de sesión en un sitio web, desde el ingreso del nombre de usuario y la
contraseña, hasta el inicio de sesión exitoso en el sistema. Emplea diferentes figuras de
contenedores para actividades, decisiones y notas. Lucidchart es la herramienta ideal
para crear cualquier tipo de diagrama de flujo UML, ya sea un diagrama de actividades,
un diagrama de caso de uso o un diagrama de componentes. Lucidchart ofrece
herramientas de colaboración y publicación instantánea en la web desde el editor para
que puedas demostrar la funcionalidad de tu sistema a otras personas.
DIAGRAMA DE SECUENCIA

El diagrama de secuencia es un tipo de diagrama de interacción cuyo objetivo es

describir el comportamiento dinámico del sistema de informació n haciendo énfasis en
la secuencia de los mensajes intercambiados por los objetos.

DESCRIPCION

Un diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo y

el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior del
diagrama hacia la inferior. Normalmente, en relació n al tiempo só lo es importante la
secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podri ́a
introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden en
que se representan, aunque su colocació n deberi ́a poseer la mayor claridad posible.

Cada objeto tiene asociados una línea de vida y focos de control. La li ́nea de vida indica
el intervalo de tiempo durante el que existe ese objeto. Un foco de control o activació n
muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna
operación, ya sea directamente o mediante un procedimiento concurrente.

NOTACION

Objeto y línea de vida

Un objeto se representa como una li ́nea vertical discontinua, llamada li ́nea de vida, con
un rectángulo de encabezado con el nombre del objeto en su interior. También se puede
incluir a continuació n el nombre de la clase, separando ambos por dos puntos.

Si el objeto es creado en el intervalo de tiempo representado en el diagrama, la li ́nea

comienza en el punto que representa ese instante y encima se coloca el objeto. Si el
objeto es destruido durante la interacció n que muestra el diagrama, la li ́nea de vida
termina en ese punto y se señ ala con un aspa de ancho equivalente al del foco de
control.

En el caso de que un objeto existiese al principio de la interacción representada en el

diagrama, dicho objeto se situará en la parte superior del diagrama, por encima del
primer mensaje. Si un objeto no es eliminado en el tiempo que dura la interacció n, su
li ́nea de vida se prolonga hasta la parte inferior del diagrama.

La li ́nea de vida de un objeto puede desplegarse en dos o más li ́neas para mostrar los
diferentes flujos de mensajes que puede intercambiar un objeto, dependiendo de
alguna condición.

Foco de control o activación

Se representa como un rectángulo delgado superpuesto a la li ́nea de vida del objeto. Su
largo dependerá de la duració n de la acción. La parte superior del rectángulo indica el
inicio de una acció n ejecutada por el objeto y la parte inferior su finalizació n.

Mensaje

Un mensaje se representa como una flecha horizontal entre las li ́neas de vida de los
objetos que intercambian el mensaje. La flecha va desde el objeto que envi ́a el mensaje
al que lo recibe. Además, un objeto puede mandarse un mensaje a si ́ mismo, en este
caso la flecha comienza y termina en su li ́nea de vida.

La flecha tiene asociada una etiqueta con el nombre del mensaje y los argumentos.
También pueden ser etiquetados los mensajes con un nú mero de secuencia, sin
embargo, este número no es necesario porque la localización fi ́sica de las flechas que
representan a los mensajes ya indica el orden de los mismos.

Los mensajes pueden presentar también condiciones e iteraciones. Una condició n se

representa mediante una expresió n booleana encerrada entre corchetes junto a un
mensaje, e indica que ese mensaje só lo es enviado en caso de ser cierta la condición.
Una iteración se representa con un asterisco y una expresió n entre corchetes, que indica
el número de veces que se produce.

(Nota.- Esta notació n es la más habitual, pero MÉTRICA Versió n 3 no exige su utilización).

EJEMPLO

Diagrama de secuencia para el caso de uso: Prestar un ejemplar de una aplicación

encargada de los préstamos y reservas de una biblioteca: