Lineamientos Casos de Uso

Contenido

1. MODELO DE CASOS DE USO.............................................................................................................2

1.1 INTRODUCCIÓN.........................................................................................................................................2
1.2 ESTRUCTURA DEL MODELO DE CASOS DE USO.............................................................................................2
1.3 CASOS DE USO........................................................................................................................................2
1.3.1 Tipos de Casos de Uso..................................................................................................................2
1.4 ACTORES.................................................................................................................................................3
1.5 DIAGRAMA DE CASOS DE USO...................................................................................................................3
1.5.1 Asociaciones.................................................................................................................................3
1.5.2 Relaciones.....................................................................................................................................3
1.5.3 Generalización/Especialización...................................................................................................4
1.6 ESPECIFICACIÓN DE CASOS DE USO.............................................................................................................4
2 LINEAMIENTOS PARA LA ESPECIFICACIÓN DE CASOS DE USO..........................................5
2.1 IDENTIFICACIÓN DE ARTEFACTOS PARA EL MODELO DE CASOS DE USO............................................................5
2.2 ETIQUETAS DE ARTEFACTOS.......................................................................................................................5
2.3 LINEAMIENTOS PARA LA DEFINICIÓN DE CASOS DE USO..................................................................................5
2.4 LINEAMIENTOS PARA LA ESPECIFICACIÓN DE CASOS DE USO...........................................................................6
2.4.1 Sección de Descripción................................................................................................................6
2.4.2 Sección de Actores........................................................................................................................6
2.4.3 Sección de Precondiciones...........................................................................................................6
2.4.4 Sección de Poscondiciones...........................................................................................................7
2.4.5 Sección de Flujo de Eventos (Básico/Alternos)............................................................................7
2.4.6 Sección de Validaciones.............................................................................................................10
2.4.7 Sección de Reglas de Negocio....................................................................................................11
2.4.8 Sección de Mensajes del Sistema................................................................................................11
2.4.9 Requerimientos no Funcionales.................................................................................................11
2.4.10 Notas de Implementación.........................................................................................................12
2.4.11 Riesgos......................................................................................................................................12
2.4.12 Pantallas Asociadas.................................................................................................................12
2.4.13 Anexos.......................................................................................................................................12
1. Modelo de Casos de Uso

1.1 Introducción

El modelo de casos de uso, comprende un conjunto de artefactos y elementos que

especifican el comportamiento de un sistema como respuesta a las acciones de los
actores. Con este modelo se responden las preguntas: ¿Quiénes son los usuarios del
sistema? y ¿Cómo se usa el sistema?

1.2 Estructura del Modelo de Casos de Uso

El modelo de casos de uso consta de dos paquetes, que contendrán toda la información
requerida por el mismo. Su estructura será la siguiente:

Estructura del Modelo de Casos de Uso

1.3 Casos de Uso

Los casos de uso modelan el comportamiento requerido para soportar una funcionalidad del
sistema. En otras palabras, representan una colección de posibles secuencias de interacción
entre el sistema y sus actores, relativo a un objetivo determinado.

Se representan utilizando una elipse como se puede ver a continuación:

1.3.1 Tipos de Casos de Uso

Casos de uso Base:

- Modelan el comportamiento medular
- Los actores pueden accederlo de forma directa

Casos de uso Incluido

- Factorizan el comportamiento común a varios casos de uso.
- La ejecución de su comportamiento es siempre llevada acabo por el caso de uso que
lo incluye.
- Siempre está relacionado con otro caso de uso
- Los actores pueden accederlo de forma directa, si y solo si, no posee información en
precondiciones que sea producto del caso de uso que lo incluye.

Casos de Uso Extendido:

- Factorizan el comportamiento común a varios casos de uso
- La ejecución de su comportamiento esta condicionada por el caso de uso al que
extiende.
- Siempre está relacionado con otro caso de uso
- Los actores pueden accederlo de forma directa, si y solo si, no posee información en
precondiciones que sea producto del caso de uso al cual extiende.

1.4 Actores

Los Actores modelan a los humanos, servicios externos, sistemas externos, e inclusive el
tiempo, como entidades que interactúan de forma directa con el Sistema a desarrollar. Los
estereotipos validos para simbolizarlos son los siguientes:

1.5 Diagrama de Casos de Uso

Los diagramas de casos de uso modelan el comportamiento de nuestro sistema, de forma

que el cliente pueda comprender como utilizarlo y que los desarrolladores puedan
implementarlo. Al mismo tiempo, en los Diagramas de Casos de Uso, son mostrados un
conjunto de casos de uso, actores y sus relaciones y asociaciones.

1.5.1 Asociaciones
Representan la línea de comunicación entre los actores y los casos de uso. Se simbolizan de
la siguiente manera:

CU001 - Generar Reporte Costo Póliza

Cliente
(from Casos de uso)
(from Actores)

Asociaciones entre Actores y Casos de Uso

En toda asociación se utiliza una flecha sólida con la punta abierta, cuyo sentido indica quien
inició la comunicación.

1.5.2 Relaciones

Representan las relaciones que pueden existir entre dos casos de uso: relaciones de inclusión
y relaciones de extensión.
Las relaciones de inclusión se simbolizan con una flecha punteada y con la punta abierta,
estereotipada con <<include>>, cuyo objetivo es incluir de forma obligatoria, un
comportamiento de un caso de uso dentro de otro. En el siguiente ejemplo, el Caso de Uso A
incluye el comportamiento del Caso de Uso B:

Relación de <<Include>> entre casos de uso

Las relaciones de extensión son utilizadas para extender el comportamiento de un caso de

uso, en función de la evaluación de una condición. Se representan con una flecha punteada y
con la punta abierta, estereotipada con <<extend>>. En el siguiente ejemplo, el Caso de
Uso A extiende hacia el comportamiento del Caso de Uso B:

Relación de <<extend>> entre casos de uso

1.5.3 Generalización/Especialización

A través de este elemento, los actores podrán factorizar su comportamiento, definiéndose

entre ellos las generalizaciones y especializaciones a que tengan lugar. Su simbología es una
flecha sólida, con punta cerrada y vacía, que apunta hacia el Actor del cual se esté realizando
la especialización:

Generalización/Especialización entre Actores

1.6 Especificación de Casos de Uso

En la especificación de casos de uso, se narra de forma clara el “¿qué?” de cada uno de los
casos de uso identificados, desde la perspectiva del cliente.
Para ello se utilizará un formato adecuado que permita describir las acciones que debe
realizar tanto el Actor involucrado como el Sistema, de forma tal que se documente el
comportamiento correcto asociado a un caso de uso.

2 Lineamientos para la especificación de Casos de Uso

2.1 Identificación de Artefactos para el Modelo de Casos de Uso

A continuación se listan las diferentes nomenclaturas que serán utilizadas para identificar
cada uno de los artefactos generados en el modelo de casos de uso:

Artefacto Identificador

Casos de Uso CU<###> - <nombre del caso de uso>

Diagrama de Casos de DCU<###> - <nombre del diagrama de caso de

Uso uso>

Especificación de Caso de
ECU - <identificador del caso de uso asociado>
Uso

2.2 Etiquetas de Artefactos

Todos los artefactos que sean generados en Rose (diagramas), deben contener una nota,
ubicada en la esquina superior izquierda, donde se describa la siguiente información:

Etiqueta Valor

Sistema <nombre del sistema>

Tipo de Artefacto Definir el tipo de diagrama que aplique

Identificador del Definir el identificador siguiendo la nomenclatura

Artefacto descrita en el punto 1.1.

Fecha de Actualización <dd/mm/aaaa>

Autor <autor>

Ejemplo de la etiqueta:

Sistema: Autos Turista

Tipo de Artefacto: Diagrama de Casos de Uso
Identificador del Artefacto: DCU001 - Emitir Póliza
Fecha de Actualización: 01/06/2005
Autor: José Robledo

2.3 Lineamientos para la definición de Casos de Uso

 El nombre del caso de uso debe iniciar con un verbo en infinitivo, por ejemplo:
Imprimir, Generar, Capturar

 Todos los casos de uso deben contener lógica de negocio. En otras palabras, un caso
de uso debe modelar una tarea a ser realizada por un actor en un lugar y tiempo
 específico, en respuesta a un evento de negocio, el cual agrega valores de negocio
medibles y deja datos y estados consistentes.

 Los casos de uso no deben estar orientados a cubrir requerimientos no

funcionales.Por ejemplo: Guardar Datos, Captura de Datos, Verificar Conexión con
Base de Datos Validar existencia de Archivos, Generar Log, Autentificar Usuario.

2.4 Lineamientos para la Especificación de Casos de Uso

2.4.1 Sección de Descripción

 Se debe describir de forma clara y concisa la responsabilidad del caso de uso,

orientada al objetivo del mismo.

2.4.2 Sección de Actores

 Deben definirse, la lista de actores que interactúan con el caso de uso, por ejemplo:
roles y sistemas externos

 Para los casos de uso que sean incluidos <<include>> o extendidos <<extend>>,
ademas de definir sus actores directos, deben definirse todos aquellos actores del
caso de uso que lo incluye o del cual extienden.

Actores y Casos de Uso Extendidos e Incluidos

Los Actores que debe tener definido el caso de uso CU002 – Imprimir Reporte
General de Afiliados serán: Sucriptor, Agente y Promotor.

2.4.3 Sección de Precondiciones

 Las precondiciones definen, las condiciones de negocio que son premisa para
ejecutar la secuencia de pasos del caso de uso.

 Deben ser definidos todos aquellos datos externos y válidos, que serán utilizados
para desarrollar la lógica del negocio (cuando un caso de uso invoca a otro y le envia
información). Ejemplo:
Se encuentran disponibles los siguientes datos:
 Clave de Usuario
 Tipo de Vehículo
  Tipo de Servicio

2.4.4 Sección de Poscondiciones

 Las poscondiciones definen, las condiciones de negocio posteriores a la ejecución de

la secuencia exitosa de los pasos del caso de uso.

 Las poscondiciones deben modelar, los datos que serán utilizados para el intercambio
de información entre los diferentes casos de uso de nuestro sistema.

 Cuando un caso de uso genere información que será utilizada en otro caso de uso, se
debe describir claramente cuales son los casos de uso que la utilizarán, asi como la
información que quedará disponible para los mismos. Ejemplo:
Quedan disponibles para ser utilizados por los casos de uso: CU001-Emitir
Poliza, CU003-Seleccionar Cobertura, los siguientes datos:

 Tipo de Vehículo
 Tipo de Servicio
 Tipo de Uso

2.4.5 Sección de Flujo de Eventos (Básico/Alternos)

 En el Flujo Básico deber ser definida la secuencia de pasos inicial, que represente el
camino normal del comportamiento de nuestro caso de uso.

 Todo Flujo Básico debe indicar en su paso número 1 quién realizo la invocación.
Ejemplo:
Casos de uso invocados por actores:
El caso de uso inicia cuando el actor Agente solicita una nueva emisión de una
póliza.

Casos de uso invocados por otro caso de uso:

El caso de uso inicia cuando es invocado por el caso de uso CU001 – Emitir
Póliza.

 Cuando el caso de uso es invocado por varios actores y/o varios casos de uso, se
deben indicar cada uno de ellos de forma clara.

 En la columna del Actor será definido el comportamiento del Actor(es), de forma

clara y concisa, indicando el Actor que este involucrado. Ejemplo:
El actor Agente proporciona la información requerida

 En la columna del Sistema será definido su comportamiento, de forma clara y

concisa, indicando siempre que el Sistema realiza las acciones. Ejemplo:
El Sistema presenta los siguientes datos:

 Identificación del cliente

 Nombre del cliente

 Todas las refrencias a puntos específicos dentro de las narrativas (flujos alternos,
validaciones, excepciones, mensajes, anexos, reglas de negocio) debe incluir una
liga, y utilizar el siguiente formato: FA01 – Modificar Usuario

 Cada uno de los pasos debe ser numerados en forma secuencial, de izquierda a
derecha y de arriba hacia abajo. Ejemplo:
1.-…
1.1.-…
1.1.1.- ….
 Para la narrativa, no deben ser utilizados términos de implementación. Ejemplo:
tablas, registros, base de datos.

 Cuando el sistema solicite información al actor, ciertas validaciones serán denotadas

con la siguiente simbología entre paréntesis:

* obligatorio
c dato contenido en un catálogo
+ mayúscula
- minúscula
# numérico
A alfabéticos
? cualquier carácter
% fecha

Ejemplo: Número de Pólizas (*c)

 Todo los detalles adicionales de formatos y longitud con respecto a datos no

persistentes, podrán ser definidos en las notas de implementación y requerimientos
no funcionales. En los datos que sean persistentes, serán definidos en el modelo de
dominio, y su especificación.

 Para modelar las bifurcaciones en los Flujos, se deben definir Flujos Alternos, los
cuales deberán ser indicados a través de una liga hacia la definición del mismo en el
apartado de Flujos Alternos.

 Para indicar el llamado a un Flujo Alterno, deberá utilizarse el verbo “invocar” y el

identificador del Flujo Alterno. Ejemplo: El Sistema invoca el Flujo Alterno FA01 –
Modificar Usuario.

 Los Flujos Alternos y Excepciones, por su condición de ser invocados en función de la

evaluación de una condición, podrán ser definidos únicamente dentro de las
validaciones. Ejemplo:

VA01 – Acción a Invocar

Si <condición a evaluar>, el sistema invoca el flujo alterno FA01 –
Modificar Condición

 Solo debe existir un paso que finalice el caso de uso, el cual debe estar definido en el
Flujo Básico. Para ello debemos utilizar la siguiente oración: “Finaliza Caso de Uso”,
cualquier paso en cualquier punto de la especificación que requiera finalizar el caso
de uso, debe dirigir el flujo hacia este.

 Toda Excepción debe concluir en la finalización de un caso de uso, para ello se debe
definir como paso final que el flujo continúe en la finalización del caso de uso.
Ejemplo: Continua en el paso 10 del Flujo Básico.

 Para indicar el llamado a un caso de uso extendido <<extend>> o incluido

<<include>>, debe utilizarse el verbo “invocar” y el identificador del Caso de Uso.
Ejemplo: El Sistema invoca el Caso de Uso CU001 – Modificar Usuario.
  Cuando un caso de uso A requiere invocar a un segundo caso de uso B, se debe
especificar lo siguiente:
o En el Caso de Uso A (invocador)
El Sistema invoca el caso de uso B con los siguientes datos:
 Dato X1
 ...
 Dato Xn

El Caso de Uso B invocado, proporciona los siguientes datos (en el caso de

que se obtengan datos del caso de uso invocado):
 Dato Y1
 ...
 Dato Ym

o En el caso de uso B (invocado)

Precondiciones
 Se encuentran disponibles los siguientes datos (proporcionados por
el Caso de Uso A que lo invoca):
• Dato X1
• ...
• Dato Xn

Poscondiciones
 Quedan disponibles para ser utilizados por los casos de uso: Caso de
Uso A,, los siguientes datos:
• Dato Y1
• ...
• Dato Ym

 Cuando el Sistema requiera solicitar información del actor debe definirse de la

siguiente manera:
El Sistema solicita la siguiente información:
• Nombre del cliente (*)
• Domicilio (*)

 Cuando el Actor proporcione información, debe definirse de la siguiente manera:

El Actor Técnico proporciona la información solicitada

 Cuando el Sistema requiera alguna Confirmación por parte del Actor, debe apoyarse
en un Mensaje del Sistema. Para ello, debe definirse de la siguiente manera:

El Sistema solicita Confirmación presentando el mensaje MS01.

 La nomenclatura para la definición de los flujos alternos es: FA<##> - <Nombre

del Flujo Alterno>

 Para describir las interfaces entre el sistema y los actores: servicios o sistemas
externos, se debe seguir el patrón mostrado en el siguiente ejemplo:

Actor Sistema

4.- El Sistema solicita la ejecución del servicio

“Crear Póliza” con los siguientes datos:
• Número de póliza

5.- El actor Servicio Póliza ejecuta el servicio 6.- El Sistema valida la ejecución del servicio
solicitado solicitado según VA01 – Ejecución de
servicio crear póliza

0 7.- El Sistema solicita la siguiente información

 generada por el servicio solicitado:
• Número de folio

8.- El actor Servicio Póliza proporciona la 9.- El Sistema genera la siguiente información,
información solicitada según RN01 – Generar Costos de Póliza:
• Costos de póliza

0 10.- El Sistema proporciona la siguiente

información:
• Costos de póliza

11.- El actor Servicio Póliza captura la

información proporcionada
Fragmento del comportamiento del flujo básico de una especificación de caso de
uso para definir el comportamiento de una interfaz con un servicio externo

Siguiendo el ejemplo, a continuación se describe el comportamiento definido en cada

uno de los pasos involucrados:

 Paso 4: Solicitud de ejecución de un servicio externo por parte del sistema

fuente, con el envío de parámetros

 Paso 5: Ejecución del servicio solicitado por parte de un Actor, que posea
dicha responsabilidad.

 Paso 6: Validación de la ejecución del servicio por parte del sistema fuente.

 Paso 7: Solicitud de información por parte del sistema fuente al servicio

ejecutado.

 Paso 8: Pase de información del sistema o servicio externo, hacia el sistema

 Paso 9: Generación de información por parte del sistema fuente

 Paso 10: Envío de información por parte del sistema fuente hacia el servicio o
sistema externo

 Paso 11: Captura de la información enviada por el sistema fuente, por parte
del servicio o sistema externo (solo podrán recibir información de forma
explicita los actores automatizados)

2.4.6 Sección de Validaciones

 Las validaciones deben modelar la ejecución de una secuencia de pasos producto de

la evaluación de una condición.
 La nomenclatura para la definición de los mensajes es: VA<##> - <Nombre de la
Validación>
 Las validaciones deben reflejar la evaluación de condiciones de negocio, más no de
implementación. Ejemplo:

Validaciones correctas:
 Validaciones de Reglas de Negocio.
 Toma de decisiones para modificar el comportamiento del caso de
uso, en función de datos obtenidos en el mismo.

Validaciones incorrectas:
 Validaciones de formatos de campos.
 Validaciones de implementación.

 Siempre debe haber un comportamiento explicita para cada una de las condiciones
evaluadas.
 Las validaciones pueden ser invocadas desde diferentes pasos de la narrativa. En
 estos casos, para definir su retorno al paso que lo invoco será descrito de la
siguiente manera: "Continua en el paso siguiente al que lo llamó."

2.4.7 Sección de Reglas de Negocio

 Las Reglas de Negocio definen o restringen aspectos del negocio, influyendo de

forma directa en el comportamiento del caso de uso, ejemplo: políticas del negocio,
lineamientos y cálculos

 La nomenclatura para la definición de los mensajes es: RN<##> - <Nombre de la

Regla de Negocio>

2.4.8 Sección de Mensajes del Sistema

 Todo mensaje del sistema debe indicar claramente su intención: alerta, confirmación,
información.

 En la columna de acción, se debe definir la información que proporcionará el actor al

sistema por medio de ese mensaje. Ejemplo: Si/No, Aceptar, Continuar.

 La nomenclatura para la definición de los mensajes es: MS<##>

 Aquellos mensajes que requieran de algún parámetro para que se comporte de

forma dinámica, deben indicarlo de la siguiente manera:

o En la llamada del mensaje:

Actor Sistema

0 1.- El sistema presenta el mensaje MS01, donde

<param1> es: Identificación del Cliente.

o En la definición del mensaje:

Clave Descripción Acciones

MS01 0 Cliente <param1> no registrado. Por favor regístrese en el 0 Aceptar

sistema para solicitar esta información.

2.4.9 Requerimientos no Funcionales

 Definen las características y/o condiciones del sistema que no están relacionadas con
el comportamiento del negocio, y que son solicitados por el cliente. Ejemplo:

o Volumen de Procesamiento
o Concurrencia
o Paginación
o Puntos de Reinicio
o Distribución
o Transaccionalidad
o Accesos
o Funcionalidad Especial
 2.4.10 Notas de Implementación

 Representan las características y/o condiciones del sistema que no están

relacionadas con el comportamiento del negocio, y que son detectados y propuestos
por los analistas de negocio.

 Definen recomendaciones de implementación, por parte de los analistas, que podrán

servir de ayuda a los diseñadores y constructores para realizar sus artefactos.

2.4.11 Riesgos

 Los riesgos deben ir orientados hacia todas las condiciones que puedan interferir de
forma directa, en el comportamiento del caso de uso. Ejemplo: Fallas Tecnológicas,
Componentes de Terceros, Organizacionales (resistencia al cambio), Presupuesto,
Gente, Tiempo.

2.4.12 Pantallas Asociadas

 Se deben incluir todas las pantallas del prototipo asociadas con el caso de uso que se
este describiendo, en forma de referencia.

 Las pantallas desarrolladas, deben expresar el comportamiento del caso de uso

 Las pantallas deben ser generadas en formato HTML.

2.4.13 Anexos

 En esta sección se debe incluir información adicional no relacionada a las secciones

definidas en este documento, por ejemplo: Layouts de Reportes, Layouts de
Archivos, Tablas Complementarias de Información, Layouts de Cadenas de
Información, Información de Referencia.