Enrique Muñoz

Documentación de Software
MODELADO DEL COMPORTAMIENTO

En los resúmenes anteriores hemos estado estudiando el UML a través de los Diagramas
Estructurales (Clases, Componentes, Paquetes, también incluimos el Modelo ER). La otra rama de
los diagramas del UML es la del Modelado del Comportamiento, que estudiaremos a
continuación.

Como se deduce de su nombre, aquí vamos a modelar cómo se comporta el programa, cómo
funciona, cómo se usa, quiénes participan, entre otras cosas, con respecto al sistema que
estamos documentando. Para eso igualmente utilizaremos elementos gráficos como fichas,
diagramas y dibujos.

Para este tipo de modelado, es necesario definir primero qué tipo de necesidades va a cubrir el
sistema, cuáles son los requerimientos, cuáles son los usos que se necesitará modelar. Ese tipo de
elementos los tomamos de los requerimientos del sistema y de los componentes y clases ya
modeladas en los diagramas estructurales.

Para continuar con el análisis, definamos Historias de Usuario. Esas Historias son ejemplos de
situaciones reales en las que los usuarios van a interactuar con el sistema. Aquí el detalle:

La Pila del Producto es una lista con todas las tareas actuales por desarrollar en un producto. Para
continuar, sigamos con el ejemplo de la App de la U que hemos venido desarrollando.
 Enrique Muñoz
Documentación de Software
Historias de Usuario

Para definir Historias de Usuario, pensemos en los requerimientos de la app (definidos en el

enunciado de la app). Por ejemplo, uno de los elementos más importantes de la App son las
publicaciones y sus respectivos comentarios, los demás elementos giran en torno a esa
funcionalidad.

1. “Como editor, necesito editar publicaciones acerca de las revistas de la U para que la
comunidad universitaria (y externa) reaccione a las revistas por medio de comentarios o
likes”.
2. “Como editor o visitante (estudiante), necesito crear comentarios acerca de las revistas
de la U, o responder otros comentarios, para mostrar mi opinión acerca de las
publicaciones”.

Secundarias a esas, otras Historias de Usuario son necesarias para definir el resto del contexto del
sistema:

3. “Como usuario, necesito registrarme (loguearse, crear cuenta) en la app para poder
usarla”.
4. “Como administrador, necesito editar otros elementos de como carreras, publicaciones,
comentarios y otros usuarios, para llevar un control administrativo de la app”.
5. “Como visitante, necesito consultar publicaciones para poder reaccionar”.
6. “Como editor, necesito consultar mis publicaciones para poder editarlas”.
7. “Como usuario, quiero poder modificar la información del perfil para corregir o cambiar
los datos”
8. “Como vigilante, el componente necesita identificar y eliminar comentarios con
improperios para colaborar con el bienestar y orden de la app”.

Podemos seguir sacando Historias de Usuario conforme vayamos detallando más el sistema. Por el
momento usemos esas 7 Historias básicas en el sistema de la app que estamos modelando. Con
esas Historias ya podemos ir modelando gran parte del comportamiento de la app con respecto a
la usabilidad del usuario y la interacción de los componentes internos de la app.

Es importante recalcar que, para la definición de Historias de Usuario, así como para la definición
de los próximos diagramas, se debe utilizar un lenguaje que evite al máximo las tecnicidades y que
aplique en su lugar un lenguaje natural, de usuario final o de experto en el área del conocimiento
al que pertenece el sistema que se está modelando.
 Enrique Muñoz
Documentación de Software
CASOS DE USO

Los Casos de Uso, como lo indica claramente su nombre, son casos de uso del sistema. Estos
Casos de Uso se definen a partir de un análisis del sistema, sobre cómo va a ser su usabilidad.
Estos escenarios representan casos de uso (acciones o actividades) establecidos entre un límite
lógico llamado Sujeto, Móvil o Límite (es como una sección del sistema), con los que un usuario o
componente del sistema, denominado Actor, interactúa y se desenvuelve para ejecutar esas
acciones o actividades.

En nuestra app, y de acuerdo a las Historias de Usuario definidas, podemos identificar los
siguientes Sujetos:
 Publicaciones: Parte del sistema encargado del funcionar de las publicaciones y comentarios.
 Administración: Parte del sistema encargado de las labores administrativas y de control del sistema.

Luego, identificamos los siguientes Actores:

 Usuario: Usuario general de la app.
 Editor: Usuario que puede editar publicaciones y realizar comentarios.
 Visitante (universitario): Usuario que puede comentar acerca de las publicaciones.
 Administrador: Usuario que administra los elementos de la app.

Los Actores, como ha de estar creyendo, no solamente serán usuarios físicos del sistema
(personas). También puede haber componentes automáticos (no personas) que utilicen el
sistema, o parte del el, por lo que estos componentes son tomados en cuenta como Actores. Por
ejemplo, imagine que existe un sistema o componente externo que se encargue de revisar
periódicamente los comentarios de las publicaciones en busca de malas palabras, o insultos, o
información extraña que no deba ser publicada o que deba ser eliminada. Podríamos tomar este
componente y agregarlo a la lista de actores:
 Viguilante: Elemento que revisa los comentarios de las publicaciones.

Y los Casos de Uso:

 Consultar publicaciones: Consultar el listado de publicaciones.
 Editar publicaciones: Editar (crear, actualizar, eliminar) alguna publicación en específico.
 Hacer comentarios: Hacer un comentario con respecto a una publicación.
 Registrarse/Loguearse en el sistema: Crear cuenta e ingresar en el sistema.
 Editar perfil: Modificar la información del perfil de usuario.
 Administrar sistema: Editar (consultar, crear, actualizar, eliminar) cualquier elemento del sistema.
 Revisar comentarios: Revisar y eliminar comentarios con improperios.

Se pueden especificar más Casos de Uso o detallar más los que ya tenemos. Por ejemplo, los Casos
de Uso de ‘Editar’ se pueden expresarse por separado para cada acción (crear, actualizar,
eliminar). Por ahora, usemos los que tenemos.
 Enrique Muñoz
Documentación de Software
Los Casos de Uso se especifican de dos maneras, una es por medio de una ficha técnica y otra es
por medio de diagramas, comencemos con las fichas técnicas. Los casos de uso en fichas tienen
tres formatos: el reducido, el intermedio y el expandido. Para nuestro curso, no ahondaremos
mucho en las diferencias de los tres formatos, simplemente utilizaremos la siguiente plantilla:

UC- <id> <nombre descriptivo>

Versión <número de la versión actual>
Actor(es) <personas o componentes que usan el sistema>
Descripción General <Breve descripción de lo que hace en resumen el caso de uso>
Tipo <Primario, Secundario>
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. <Acciones del 2. <Respuestas del Sistema>
Actor>
3. 4.
Curso Alternativo de Curso Alternativo:
Eventos Línea N: <Condición, Acción>
Línea N+2: <Condición Acción>
Importancia <Crítico, Importante, Deseable>
Urgencia <Inmediata, Puede Esperar>
Estado <En construcción, pendiente de negociación, pendiente de
verificación, pendiente de validación, validado>
Comentarios

Como hay poco que explicar, de una vez definimos los Casos de Uso que ya tenemos:
UC-1 Consultar publicaciones
Versión 1.0
Actor(es) Administrador, Editor, Visitante
Descripción General El usuario ingresa a la app para consultar (ver las publicaciones).
Tipo Primario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El usuario ingresa a la app 2. El sistema le solicita credenciales de ingreso
y solicita entrar (usuario y contraseña)
3. Ingresa los datos 4. Valida los datos y presenta la pantalla con la lista
solicitados de publicaciones
5. Elige una publicación en 6. Muestra el detalle de la publicación con todo y
específico comentarios
Curso Alternativo de Eventos Curso Alternativo:
Línea 1: Usuario sin cuenta, se le avisa al usuario sobre la opción de registrarse y se
cancela la operación actual
Línea 4: Datos no válidos, se avisa al usuario y se cancela la operación.
Importancia Crítico
Urgencia Inmediata
Estado Validado
Comentarios Esta funcionalidad de consultar publicaciones es esencial para otros Casos de Uso.
 Enrique Muñoz
Documentación de Software
UC-2 Editar publicaciones
Versión 1.0
Actor(es) Administrador, Editor
Descripción General El usuario ingresa a la app para editar una publicación.
Tipo Primario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El usuario ingresa a la 2. El sistema le solicita credenciales de ingreso
app y solicita entrar (usuario y contraseña)
3. Ingresa los datos 4. Valida los datos y presenta la pantalla con
solicitados la lista de publicaciones
5. Elige una publicación o 6. El sistema le presenta la pantalla de edición
crear una nueva de publicación
7. Consulta, inserta, 8. El sistema valida y devuelve una respuesta
modifica o elimina una de confirmación
publicación
Curso Alternativo de Eventos Curso Alternativo:
Línea 1: Usuario sin cuenta, se le avisa al usuario sobre la opción de
registrarse y se cancela la operación actual
Línea 4: Datos no válidos, se avisa al usuario y se cancela la operación.
Línea 8: Datos incorrectos, se solicita el cambio y se repite la acción
Importancia Crítico
Urgencia Inmediata
Estado Validado
Comentarios El administrador puede editar las publicaciones de todos, el editor solo las
propias.

UC-3 Hacer comentarios

Versión 1.0
Actor(es) Administrador, Editor, Visitante (universitario)
Descripción General El usuario ingresa a la app para hacer un comentario de una publicación.
Tipo Primario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El usuario ingresa a la 2. El sistema le solicita credenciales de ingreso
app y solicita entrar (usuario y contraseña)
3. Ingresa los datos 4. Valida los datos y presenta la pantalla con
solicitados la lista de publicaciones
5. Elige una publicación 6. El sistema le presenta el detalle de la
publicación y la lista de comentarios con una
casilla para comentar
7. Ingresa el comentario 8. Valida y devuelve una respuesta de
y lo envía confirmación
Curso Alternativo de Eventos Curso Alternativo:
Línea 1: Usuario sin cuenta, se le avisa al usuario sobre la opción de
registrarse y se cancela la operación actual
Línea 4: Datos no válidos, se avisa al usuario y se cancela la operación.
Línea 8: Datos incorrectos, se solicita el cambio y se repite la acción
Importancia Crítico
Urgencia Inmediata
Estado Validado
Comentarios Los únicos usuarios que no pueden realizar comentarios son los Visitantes de
tipo externo
 Enrique Muñoz
Documentación de Software
UC-4, UC-5 Registrarse/Loguearse
Versión 1.0
Actor(es) Usuario
Descripción General El usuario ingresa a la app para registrase o loguearse
Tipo Primario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El usuario ingresa a 2. El sistema le presenta la pantalla para
la app y solicita crear el ingreso de datos
una cuenta
3. Ingresa los datos 4. Valida y devuelve una respuesta de
solicitados confirmación
5. Se loguea en la app 6. El sistema le presenta la pantalla con la
lista de publicaciones
Curso Alternativo de Eventos Curso Alternativo:
Línea 1: Usuario sin cuenta, se le avisa al usuario sobre la opción de
registrarse y se cancela la operación actual
Línea 4: Datos incorrectos, se solicita el cambio y se repite la acción
Línea 6: Usuario sin cuenta, se le avisa al usuario sobre la opción de
registrarse y se cancela la operación actual
Importancia Crítico
Urgencia Inmediata
Estado Validado
Comentarios Los datos ingresado puede modificarse posteriormente.

UC-6 Editar perfil

Versión 1.0
Actor(es) Usuario
Descripción General El usuario modifica la información de su perfil
Tipo Primario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El usuario ingresa a 2. El sistema le solicita credenciales de
la app y solicita entrar ingreso (usuario y contraseña)
3. Ingresa los datos 4. Valida los datos y presenta la pantalla
solicitados con la lista de publicaciones
5. Elige la opción de 6. El sistema le presenta el detalle de los
Perfil datos del perfil con campos editables.
7. Edita los campos y 8. Valida y devuelve una respuesta de
guarda los cambios confirmación
Curso Alternativo de Eventos Curso Alternativo:
Línea 1: Usuario sin cuenta, se le avisa al usuario sobre la opción de
registrarse y se cancela la operación actual
Línea 4: Datos no válidos, se avisa al usuario y se cancela la
operación.
Línea 8: Datos incorrectos, se solicita el cambio y se repite la acción
Importancia Importante
Urgencia Puede esperar
Estado Validado
Comentarios Cada vez que modifique los datos, el sistema le solicitará que confirme
la contraseña.
 Enrique Muñoz
Documentación de Software
UC-7 Administrar sistema
Versión 1.0
Actor(es) Administrador
Descripción General El administrador ingresa a la app para administrar elementos del sistema
Tipo Primario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El usuario ingresa a la 2. El sistema le solicita credenciales de ingreso
app y solicita entrar (usuario y contraseña)
3. Ingresa los datos 4. Valida los datos y presenta la pantalla con
solicitados la lista de publicaciones
5. Elige cualquier 6. El sistema le presenta la pantalla respectiva
elemento de la app de edición de elemento
(Publicacion, comentario,
Carrera, Usuario) o crear
uno nuevo
7. Consulta, inserta, 8. El sistema valida y devuelve una respuesta
modifica o elimina un de confirmación
elemento
Curso Alternativo de Eventos Curso Alternativo:
Línea 1: Usuario sin cuenta, se le avisa al usuario sobre la opción de
registrarse y se cancela la operación actual
Línea 4: Datos no válidos, se avisa al usuario y se cancela la operación.
Línea 8: Datos incorrectos, se solicita el cambio y se repite la acción
Importancia Deseable
Urgencia Puede esperar
Estado Validado
Comentarios El administrador puede administrar todos los elementos del sistema aunque
no sea el autor directo.

UC-8 Revisar comentarios

Versión 1.0
Actor(es) Vigilante
Descripción General El vigilante consulta los comentarios de la app y elimina aquellos con improperios
Tipo Secundario
Curso Típico de Eventos Acción del Actor Respuesta del Sistema
1. El componente se conecta 2. La Base de Datos le solicita credenciales
a la Base de Datos de la app
3. Ingresa los datos 4. Valida los datos y presenta la información de los
solicitados comentarios
5. Revisa uno a uno los 6. El sistema valida y devuelve una respuesta de
comentarios y en caso de confirmación
encontrar un comentario
con improperio, lo eliminar
7. Continúa con el resto de 8. El sistema le sigue mostrando la información
comentarios hasta una
próxima iteración
Curso Alternativo de Eventos Curso Alternativo:
Línea 2: Datos no válidos, se avisa al componente y se cancela la operación
Línea 6: Operación no permitida, se informa al usuario y se repite la acción
Importancia Deseable
Urgencia Puede esperar
Estado Pendiente de Negociación
Comentarios El administrador puede administrar todos los elementos del sistema aunque no sea el
autor directo.
 Enrique Muñoz
Documentación de Software
DIAGRAMA DE CASOS DE USO

En los Diagramas de Casos de Uso exponemos el funcionamiento de los eventos o actividades del
sistema de una manera más gráfica, más visual. Los elementos se especifican con los siguientes
dibujos:

Los Actores se interactúan con los Casos de Uso y éstos a su vez pueden interactuar con otros
Casos de Uso, es por eso que definimos relaciones entre estos. En nuestros Casos de Uso,
utilizaremos solo dos tipos de relaciones, las relaciones entre Actor-Caso de Uso y las relaciones
entre Casos de Uso, aunque existen varias otras no menos importantes, pero que no veremos en
este curso.

Las relaciones entre Actor-Caso de Uso son expresadas mediante una línea continua (también
llamada asociación):
 Enrique Muñoz
Documentación de Software

Las relaciones entre Casos de Uso son más variadas. Por ejemplo, una generalización ( )
indica que un Caso de Uso que hereda y agrega propiedades a un Caso de Uso base. En nuestro
estudio, sólo veremos dos tipos de relaciones entre Casos de Uso, la inclusión y la extensión.

La inclusión de Casos de Uso se expresa

mediante una línea discontinua con
dirección.

Esta relación indica que un Caso de Uso A incluye o usa un Caso de Uso B. El caso incluido (Caso B)
es esencial para que el primero (Caso A) funcione, es decir, es estrictamente necesario. El término
<<include>> se puede encontrar en otras versiones como <<use>> (no se deben usar mezclados en
un mismo diagrama).

La extensión de Casos de Uso se

expresa también mediante una línea
discontinua con dirección.

Esta relación indica que un Caso de Uso B extiende o inserta comportamiento adicional un Caso
de Uso A. El caso extendido (Caso B) NO es esencial para que el primero (Caso A) funcione, es
decir, no afecta en nada al caso base, es opcional.

Sin encontrarle la quinta pata al gato, entrémosle de una vez al dibujo de los Diagramas de Casos
de Uso de la app de la U. Los siguientes diagramas especifican una visión muy básica de los
Diagramas de Casos de Uso, queda a responsabilidad del estudiante investigar más …
 Enrique Muñoz
Documentación de Software
El diagrama anterior muestra a los tres tipos de usuarios de la app en el momento o caso de
consultar publicaciones. Para esta actividad de consultar, se debe incluir la actividad de
registrarse o loguearse. Los Actores pueden especificarse a ambos lados del campo (Sujeto) de los
Casos de Uso, tal y como se muestra a continuación en el siguiente diagrama de editar
publicaciones:

Editar publicaciones infiere que en algún momento primero se tienen que consultar las
publicaciones hasta encontrar la que se quiere editar.

Otro de los escenarios importantes es cuando un usuario quiere comentar una publicación. En
este caso, la actividad de comentar es opcional, o sea, si quiere comente y si quiere no, por lo
tanto, este Caso de Uso de Comentar extiende o agrega comportamiento adicional las
publicaciones.
 Enrique Muñoz
Documentación de Software
El Caso de Uso más básico, y que ya ha aparecido, puede expresarse aisladamente indicando que
todos los usuarios, sin importar el tipo, deben pasar por esa actividad:

En la misma categoría de usuarios, podemos poner el Caso de Uso de editar Perfil:

En el Diagrama anterior pusimos include para recalcar que la relación que pesa más es la de “para
editar nuestro requerimos estar logueados”, en vez de la de “una vez logueados podemos editar
nuestro perfil” (es opcional, extends), aunque bien bien se puede poner como mejor sea posible,
como mejor le parezca.
 Enrique Muñoz
Documentación de Software
En el diagrama de administración de elementos anterior, note como se puede establecer más de
una relación del autor con los casos de uso en un solo diagrama, especialmente si están muy
conectadas entre sí esas relaciones.

Dijimos, además, que sería deseable tener un componente automático, externo al sistema de la
app, que fuese capaz de leer todos comentarios y que analice sus sintaxis en busca de improperios
para eliminarlos. Esta situación se puede representar de la siguiente manera:

Se pueden unir varios Diagramas de Casos de Uso en un solo diagrama para mostrarle al usuario
un panorama más amplio sobre cierta parte del sistema:

Eso sería todo lo que veríamos con respecto a Casos de Uso.