El modelo de caso de uso

El modelo de caso de uso

Encontrar actores y casos de uso

Priorizar casos de uso

Detallar casos de uso

Prototipar la interfaz del usuario

Estructurar el modelo de casos de uso

Referencias

Descarga en PDF
Lección 1 de 8

El modelo de caso de uso

Los casos de uso proporcionan un medio intuitivo y sistemático para capturar

los requisitos funcionales poniendo énfasis en el valor agregado para cada
usuario individual o para cada sistema externo (Guardo y Sosa Tosello,
2018). La utilización de los casos de uso hace que los analistas deban pensar
en términos de quiénes son los usuarios y qué necesidad u objetivos de la
empresa pueden cumplir.

El principal esfuerzo de la etapa de requisitos es desarrollar un modelo del

sistema que se va a construir, y la utilización de los casos de uso es una
forma adecuada para ello, debido a que los requisitos funcionales se
estructuran naturalmente mediante los casos de uso; los requisitos no
funcionales suelen ser específicos de un caso de uso y pueden tratarse en
ese contexto.

Flujo de trabajo del modelado de casos de uso

Dentro del PUD (proceso unificado de desarrollo), el primer flujo de trabajo es

el de requisitos. Al igual que se irá haciendo con los restantes en las
siguientes unidades, mencionaremos los artefactos que se crean en este
flujo de trabajo, los trabajadores participantes y las actividades a realizar:

Artefactos
–
Los artefactos fundamentales que se utilizan en la captura de requisitos son:

modelo de casos de uso, que incluye los casos de uso y los actores;

descripción de la arquitectura;

glosario;

prototipo de la interfaz del usuario.

Trabajadores
–
Los trabajadores responsables por los artefactos que se producen en el
modelado de casos de uso son:

analista de sistemas;

especificador de casos de uso;

diseñador de interfaz de usuario;

arquitecto.

Actividades
–
Las actividades a realizar por los trabajadores para producir los distintos
artefactos son:

encontrar actores y casos de uso;

priorizar casos de uso;

detallar los casos de uso;

prototipar la interfaz del usuario;

estructurar el modelo de casos de uso.

El siguiente gráfico muestra los artefactos del modelado de casos de uso y

los trabajadores responsables de cada uno:

Figura 1. Artefactos del modelado de casos de uso y trabajadores

responsables de cada uno
 Fuente: Jacobson, Rumbaugh y Booch, 2000, p. 127.

La siguiente figura muestra un gráfico que indica el flujo de trabajo para la

actividad de requisitos en el PUD, incluyendo los trabajadores participantes y
sus actividades:

Figura 2. Flujo de trabajo para la actividad de requisitos en el PUD

 Fuente: Jacobson, Rumbaugh y Booch, 2000, p. 136.

A continuación, se realizará una descripción de cada uno de los artefactos,

poniendo énfasis en los principales, y luego se describirán las actividades
comprendidas en este flujo de trabajo de requisitos.

Artefactos del flujo de trabajo de requisitos

Modelo de casos de uso

–
El modelo de casos de uso permite que los desarrolladores y los clientes lleguen
a un acuerdo sobre los requisitos, es decir, sobre lo que debe cumplir el sistema,
y constituye la entrada principal para el análisis, el diseño y las pruebas.
El modelo de casos de uso es un modelo que contiene actores, casos de uso y
las relaciones entre estos. Si el modelo de casos de uso es grande, es decir, si el
número de ellos es elevado, es útil introducir paquetes en el modelo para tratar su
tamaño. Un paquete reunirá cierto número de casos de uso, agrupados por algún
criterio de homogeneidad (los que corresponden a un mismo actor, los que se
refieren a un mismo proceso, son los principales criterios).

Actor
–
Un actor es el rol que juega un usuario en un caso de uso. Normalmente, un actor
representa un rol, que es representado por una persona, un dispositivo de
hardware o, incluso, otro sistema al interactuar con nuestro sistema (Alarcón,
2000).
El modelo de casos de uso describe lo que hace el sistema para cada tipo de
usuario. Cada usuario puede representarse por uno o más actores. De la misma
forma, cada sistema externo que interactúa con el sistema en desarrollo puede
representarse por uno o más actores.
Cada rol (actor) define lo que hace un trabajador del negocio en un proceso
concreto. Cada vez que un usuario en concreto (un humano u otro sistema)
interactúa con el sistema, la instancia correspondiente del actor está
desarrollando ese papel. Una instancia de un actor es, por lo tanto, un usuario
concreto que interactúa con el sistema.
Podemos distinguir la siguiente clasificación de actores según el objetivo a
cumplir en relación a los casos de uso:

Actor primario: tiene un objetivo claro que debe ser tenido en cuenta y
concretado con la ayuda del sistema de información.

Actor secundario: es de quien el sistema necesita ayuda para cumplir con el

objetivo del actor primario.
Figura 3. Simbología
Fuente: Elaboración propia.

Glosario
–
Se puede utilizar un glosario para definir términos comunes importantes que los
analistas y otros desarrolladores utilizan al describir el sistema. Un glosario es
muy útil para lograr consenso en la definición de distintos conceptos y para
reducir el riesgo de confusiones.

Descripción de la arquitectura
–
La descripción de la arquitectura contiene una vista del modelo de casos de uso,
que representa los casos de uso significativos.
La vista de la arquitectura del modelo de casos de uso debería incluir los casos
de uso que describan alguna funcionalidad importante y crítica, o que impliquen
algún requisito importante que deba desarrollarse pronto, dentro del ciclo de vida
del software.
Esta vista de la arquitectura se utiliza como entrada cuando se priorizan los
casos de uso para su desarrollo dentro de cada iteración.

Figura 4. Descripción de la arquitectura

Fuente: Jacobson, Rumbaugh y Booch, 2000, p. 133.

Caso de uso
–
Un caso uso representa cada forma en que los actores usan el sistema. Los
casos de uso son fragmentos de funcionalidad que el sistema ofrece para
aportar un resultado de valor para sus actores (Sosa López, s. f.). Un caso de uso
especifica una secuencia de acciones que el sistema puede llevar a cabo
interactuando con sus actores (Hernández González, 2013).
Por lo expresado, un caso de uso es una “especificación”. Especifica el
comportamiento de “elementos” dinámicos, en este caso, instancias de casos de
uso. Una instancia de un caso de uso es la realización (o ejecución) de un caso
de uso.
Podemos establecer la categoría de los casos de uso como:

Esenciales: describen la funcionalidad principal o esencial que tiene que

cumplir el sistema. Comprenden los principales procesos que debe ejecutar
el sistema de información.
 De soporte: comprenden la funcionalidad que surge a partir de analizar
aquello que se necesita para que puedan funcionar los casos de uso
esenciales. También aquí se consideran los casos de uso del usuario, que
comprenden la funcionalidad requerida para administrar los datos de los
usuarios del sistema y los permisos asignados a estos.

Otra forma de clasificar los casos de uso es la siguiente:

Concreto: se le llama así al caso de uso que es iniciado por un actor y que constituye un flujo de
eventos completo.

Abstracto: es el caso de uso que no es iniciado nunca por un actor, sino que únicamente es
instanciado (iniciado) por otro caso de uso. Surge a partir de relaciones de extensión, inclusión o
generalización.

La descripción de un caso de uso puede incluir:

Diagramas de estados: especifican el ciclo de vida de las instancias de casos de uso.

Diagramas de actividad: describe el ciclo de vida con más detalle, indicando la secuencia temporal
de acciones que tienen lugar dentro de cada transición.

Diagramas de colaboraciones y de secuencia: describen las interacciones entre una instancia típica
de un actor y una instancia típica de un caso de uso.

El diagrama UML que modela los casos de uso es el diagrama de casos de uso.

Figura 5. Ejemplo
Fuente: elaboración propia

Prototipo de interfaz del usuario

–
“Los prototipos de interfaz del usuario nos ayudan a comprender y especificar
las interacciones entre actores humanos y el sistema durante la captura de
requisitos” (Torossi, s. f., p. 30). No solo nos ayuda a desarrollar una interfaz
gráfica mejor, sino a comprender mejor los casos de uso.
Para especificar la interfaz de usuario, pueden utilizarse modelos de interfaz
gráfica y esquemas de pantallas.
El tema de los prototipos de interfaz se amplía en el punto 3.5 de esta unidad.

Diagrama de casos de uso

Los diagramas de casos de uso son importantes para modelar el

comportamiento de un sistema o un subsistema. Estos diagramas facilitan
que los sistemas y subsistemas sean abordables y comprensibles al
presentar una vista externa de cómo pueden utilizarse estos elementos en
un contexto dado (Nader, s. f.).

Los diagramas de casos de uso contienen: casos de uso, actores, relaciones

de dependencia, generalización y asociación.

Los actores se conectan a los casos de uso a través de asociaciones. “Una

asociación entre un actor y un caso de uso indica que el actor y el caso de
uso se comunican entre sí y cada uno puede enviar y recibir mensajes”
(Booch, 2006, como se citó en “Las preguntas más frecuentes de cómo
elaborar un diagrama de casos de uso”, 4 de diciembre de 2015). La relación
de asociación entre un actor y un caso de uso se grafica para el caso en que
el actor sea el responsable de instanciar (iniciar) el caso de uso.

Simbología del diagrama de casos de uso

–
En la siguiente figura se muestran los distintos elementos que pueden estar
presentes en un diagrama de casos de uso.

Figura 6. Elementos que pueden estar presentes en un diagrama de casos de

uso
Fuente: elaboración propia.

Nombre de caso de uso

–
Cada caso de uso debe tener un nombre que lo distinga de los demás. Puede ser
un nombre simple (una simple cadena de texto) o un nombre de camino (path) en
el caso de que esté precedido por el nombre del paquete en que está incluido el
caso de uso.
Los nombres de casos de uso son expresiones verbales que describen algún
comportamiento del vocabulario del sistema que se está modelando. Se
aconseja que el nombre del caso de uso comience con un verbo en infinitivo.

Nombre de actor
–
El nombre del actor debe reflejar el rol que cumple un usuario al interactuar con el
caso de uso al que está conectado y no debe reflejar a un usuario en particular.

Relación de generalización entre actores

–
Pueden definirse categorías generales de actores y especializarlos a través de
relaciones de generalización. Los actores especializados (hijos) heredan el
comportamiento del actor padre.
Si un caso de uso es instanciado por el actor “padre”, puede ser instanciado por
cualquiera de sus hijos (Segovia, 2015). Ahora bien, podría haber casos de uso
que son instados por uno de los actores “hijo” en particular.

Figura 7. Ejemplo
Fuente: elaboración propia.
Relaciones entre casos de uso
–
Los casos de uso pueden organizarse especificando relaciones de
generalización, inclusión y extensión entre ellos. “Estas relaciones se utilizan
para:

factorizar el comportamiento común (extrayendo ese comportamiento de los

casos de uso en los que se incluye);

factorizar variantes (poniendo ese comportamiento en otros casos de uso

que lo extienden)” (Nader, s. f., p. 6);

simplificar un caso de uso extrayendo una parte compleja y ubicándola en

otro caso de uso.

Relación de generalización entre casos de uso

–
La generalización entre casos de uso es como la generalización entre clases. En
este contexto, significa que el caso de uso hijo hereda el comportamiento del
caso de uso padre. El hijo puede modificar y/o agregar comportamiento al
heredado.
La generalización se emplea para simplificar la forma de trabajo y la
comprensión del modelo de casos de uso y para reutilizar casos de uso
“semifabricados”. Un caso de uso “semifabricado” existe solamente para que
otros lo reutilicen.
Gráficamente, se indica, al igual que la herencia entre clases, con una línea
continua con punta de flecha vacía dirigida del caso de uso hijo hacia el padre.

Figura 8. Ejemplo de relación de generalización entre casos de uso

Ejemplos:
Fuente: elaboración propia.

Relación de inclusión entre casos de uso

–
Una relación de inclusión entre casos de uso significa que un caso de uso base
incorpora explícitamente el comportamiento de otro caso de uso en el lugar
especificado en el caso base. El caso de uso incluido nunca es instanciado por un
actor, sino que es instanciado por el/los caso/s de uso que lo incluyen. Por ello,
un caso de uso de inclusión es siempre un caso de uso abstracto.
La secuencia de comportamiento y los atributos del caso de uso incluido se
encapsulan y no pueden modificarse o accederse, solamente puede utilizarse el
resultado (o función) del caso de uso incluido. El caso de uso base llama al caso
de uso incluido, el cual se ejecuta, y luego el control vuelve al caso de uso base.
Una característica de la relación de inclusión es que el caso de uso base
siempre deberá invocar la ejecución del caso de uso incluido para completar su
objetivo; es decir, el caso de uso base no está completo si no se ejecuta la
funcionalidad del caso de uso de inclusión.
La relación de inclusión se usa para abstraer el comportamiento común entre
casos de uso, evitando describir el mismo flujo de eventos repetidas veces.
También se utiliza para apartar del caso de uso base una porción de funcionalidad
compleja o que complica la comprensión de este.
La inclusión se representa como una dependencia estereotipada con la palabra
include o en forma abreviada inc, dirigida desde el caso de uso base hacia el caso
de uso incluido.

Figura 9. Ejemplo de relación de inclusión entre casos de uso

Fuente: elaboración propia.
Relación de extensión entre casos de uso
–
Una relación de extensión entre casos de uso significa que un caso de uso base
incorpora implícitamente el comportamiento de otro caso de uso. El caso de uso
base puede ejecutarse aisladamente, pero, bajo ciertas condiciones, su
funcionalidad será extendida por la del caso de uso de extensión.

La extensión se puede ver como que el caso de uso de extensión

incorpora su comportamiento en el caso de uso base. Una relación
de extensión se utiliza para modelar la parte de un caso de uso que
el usuario puede ver como comportamiento opcional del sistema.
De esta forma, se separa el comportamiento opcional del
obligatorio. También puede utilizarse … para modelar un subflujo
separado que solo se ejecuta bajo ciertas circunstancias. (Nader, s.
f., p. 8).
El hecho de que la llamada al caso de uso de extensión sea opcional se debe a
que el caso de uso base es completo en sí mismo, es decir, puede cumplir con su
objetivo sin necesidad de llamar al caso de uso de extensión; solo que, a veces,
“extenderá” o “ampliará” su funcionalidad llamando a la ejecución del otro caso de
uso.
El caso de uso de extensión puede, en algunos casos, ser instanciado
directamente por un actor (en este caso, se considera un caso de uso concreto),
además de instanciarse para extender el comportamiento de un caso de uso
base. Si el caso de uso de extensión nunca es instanciado directamente por un
actor, entonces es un caso de uso abstracto.
La extensión se representa como una dependencia estereotipada con la palabra
extend o en la forma abreviada ext, dirigida desde el caso de uso de extensión
hacia el caso de uso base.

Figura 10. Ejemplo de relación de inclusión entre casos de uso

Fuente: elaboración propia.

Actividades del flujo de trabajo de requisitos

–
Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos.
Describimos un flujo de trabajo como una secuencia de actividades que están
ordenadas, de modo que una actividad produce una salida que sirve de entrada a
la siguiente (Espinoza Robles, s. f.). A pesar de ello, en el mundo real, no siempre
trabajamos estrictamente en secuencia. Se puede trabajar por múltiples vías que
producen un resultado final equivalente.
Una actividad puede ser retomada muchas veces (recordemos que estamos en
un proceso de desarrollo iterativo) y cada una de estas puede acarrear la
ejecución de un solo fragmento de la actividad. Por ejemplo, cuando retomamos
la actividad “Encontrar actores y casos de uso”, el nuevo resultado puede ser
solamente una identificación adicional de un caso de uso.
Las distintas actividades en el modelado de casos de uso adoptan diferentes
formas en diferentes fases del proyecto. Por ejemplo, cuando un analista de
sistemas ejecuta la actividad de “Encontrar actores y casos de uso” durante la
fase de inicio, identificará muchos actores y casos de uso nuevos. Pero cuando
la actividad se realice durante la fase de construcción, el analista hará,
principalmente, cambios secundarios en el conjunto de actores y casos de uso.
Se describen, a continuación, las actividades que se realizan en el flujo de trabajo
de requisitos.

C O NT I NU A R
Lección 2 de 8

Encontrar actores y casos de uso

La identificación de actores y casos de uso es la actividad más decisiva para

obtener adecuadamente los requisitos y es responsabilidad del analista de
sistemas.

Para realizar esta actividad, si se dispone de un modelo de negocio, se puede

obtener un borrador del modelo de casos de uso en forma bastante directa.
Otras veces se puede partir del modelo de dominio o, simplemente, de una
especificación de las características que se requieren del sistema.

Esta actividad puede descomponerse en cuatro pasos:

1 encontrar los actores;

2 encontrar los casos de uso;

3 describir brevemente los casos de uso;

4 describir el modelo de casos de uso completo.

Encontrar los actores
–
Hay dos criterios útiles a la hora de elegir los candidatos a actores:

Primero, debe ser posible identificar, al menos, un usuario que pueda

representar al actor candidato.

Segundo, debe existir una coincidencia mínima entre los roles que
desempeñan las instancias de los diferentes actores. No debemos tener dos
o más actores que cumplan los mismos roles: o son el mismo actor o se
realiza una generalización abstrayendo el comportamiento común.

Para encontrar actores, resulta útil preguntarnos, por ejemplo, quién va a utilizar
cierta información, quién va a usar una determinada funcionalidad, quién
actualizará algún dato en el sistema, con qué otros sistemas va a interactuar el
sistema que estamos modelando.
El analista de sistemas da nombre a los actores y describe brevemente los
papeles de cada actor. La descripción de cada actor debe esbozar sus
necesidades y responsabilidades (Espinoza Robles, s. f.).

Encontrar los casos de uso

–
El analista de sistemas identificará los casos de uso a través de los talleres con
los clientes y los usuarios. El analista de sistemas va repasando los actores de a
uno y piensa en qué forma pueden utilizar el sistema o qué necesitan del sistema,
proponiendo así casos de uso, que se consideran, en primera instancia,
“candidatos”. Algunos de los candidatos no llegarán a ser casos de uso por sí
mismos, sino que serán partes de otro.
Como ya mencionamos al hablar de las categorías de casos de uso, habrá casos
de uso a los que llamamos “esenciales” porque involucran actividades que
constituyen el núcleo del negocio y suelen ser los primeros en ser descubiertos; y
otros casos de uso a los que llamamos “secundarios” o “de soporte”, que
permiten realizar tareas tales como actualizar todas las clases que aparecieron
en el dominio del problema y las que irán apareciendo; más adelante (en las
últimas iteraciones), pueden aparecer casos de uso para administrar usuarios,
sesión de usuario, entre otros.
Se elige un nombre por cada caso de uso, que represente la secuencia de
acciones concreta que añade valor a un actor (produce algo de valor para el
actor). El nombre del caso de uso comienza con un verbo (preferentemente, en
infinitivo) y debe reflejar el objetivo de la interacción entre el actor y el sistema
(Jiménez López, 2003).

Describir brevemente cada caso de uso

–
A medida que se van descubriendo los casos de uso se suele ir registrando
algunas palabras explicándolos. Luego se procede a describir más formalmente
el caso de uso, en primera instancia con unas pocas frases, y más adelante se
hará una descripción detallada.

Describir el modelo de casos de uso completo

–
Esta tarea consiste en elaborar diagramas y descripciones para explicar el
modelo de casos de uso en totalidad.
No hay una regla estricta que indique qué se debe incluir en un diagrama
(considerando un sistema medianamente complejo en el que no se pueden incluir
todos los casos de uso en un solo diagrama). Podemos tener diagramas por
cada proceso de negocio, o reunir todos los casos de uso en los que interviene
un mismo actor.
El modelo de casos de uso puede organizarse en conjuntos de casos de uso,
conformando paquetes de casos de uso.
C O NT I NU A R
Lección 3 de 8

Priorizar casos de uso

El propósito de esta actividad es determinar cuáles casos de uso son

necesarios para el desarrollo en las primeras iteraciones y cuáles pueden
dejarse para más adelante.

Los resultados de esta actividad conforman la vista de la arquitectura del

modelo de casos de uso, que es revisada por el jefe de proyecto y se utiliza
como base para la planificación de una iteración.

C O NT I NU A R
Lección 4 de 8

Detallar casos de uso

El objetivo de esta actividad es detallar el flujo de sucesos en detalle,

incluyendo cómo comienza, termina e interactúan con los actores (Torossi, s.
f.).

Con el modelo de casos de uso como punto de partida, el especificador de un

caso de uso individual puede comenzar a describir cada caso de uso en
detalle, especificando la secuencia precisa de acciones.

Hay varias formas y herramientas con las que se puede realizar la

descripción de un caso de uso. Independientemente de la forma elegida para
describir el caso de uso, debe verificarse que la descripción siempre incluya
lo siguiente:

el estado inicial, como precondición;

cómo y cuándo comienza el caso de uso (es decir, la primera acción a

ejecutar);

el orden requerido en el que las acciones se deben ejecutar

(determinado en forma de secuencia numerada);
 cómo y cuándo terminan los casos de uso;

los posibles estados finales, como postcondiciones;

los caminos de ejecución que no están permitidos;

las descripciones de caminos alternativos que están incluidos junto

con la descripción del camino básico;

las descripciones de caminos alternativos que han sido extraídos de la

descripción del camino básico;

la interacción del sistema con los actores y qué cambios producen;

la utilización de objetos, valores y recursos del sistema;

la descripción explícita de lo que hace el sistema, separando las

responsabilidades del sistema de las acciones de los actores.

A continuación, mostramos una plantilla que cubre estos aspectos y resulta

muy útil para realizar una descripción detallada de un caso de uso,
incluyendo las referencias a los casos de uso con los que tiene relaciones de
extensión, inclusión, generalización.

Hay diferentes formatos que se pueden utilizar para una plantilla descriptiva
de caso de uso; el siguiente es simplemente una propuesta; mientras se
respeten los ítems esenciales que deben incluirse en la descripción, tal como
enunciamos en el párrafo anterior, se pueden agregar o quitar secciones
según las necesidades o preferencias del equipo de especificación.

Tabla 1. Plantilla para la descripción de casos de uso

Fuente: elaboración propia.

Fuente: elaboración propia.
 Fuente: elaboración propia.

Otras herramientas que pueden ayudar a mejorar la comprensión de los

casos de uso son:

Diagramas de estado: para describir los estados de los casos de uso y

las transiciones entre esos estados.

Diagramas de actividad: para describir las transiciones entre estados

con más detalle como secuencias de acciones.

Diagramas de interacción: para describir cómo interactúa una instancia

de caso de uso con la instancia de un actor. En este caso, el diagrama
de interacción muestra solo el caso de uso y el actor o actores
participantes.

C O NT I NU A R
Lección 5 de 8

Prototipar la interfaz del usuario

Hasta aquí, hemos desarrollado el modelo de casos de uso que especifica

qué usuarios hay y para qué necesitan usar el sistema. Ahora, hay que
diseñar la interfaz de usuario que le permita llevar a cabo los casos de uso de
manera eficiente.

Se comienza con los casos de uso, intentando determinar qué se necesita de

las interfaces de usuario para habilitar los casos de uso. Esto es hacer un
diseño lógico de la interfaz. Luego se realiza un diseño físico y se desarrollan
prototipos.

Como ya mencionamos anteriormente, el tema de los prototipos de interfaz

se amplía en el punto 3.5 de esta unidad.

C O NT I NU A R
Lección 6 de 8

Estructurar el modelo de casos de uso

El modelo de casos de uso se estructura para:

Extraer descripciones de funcionalidades generales y compartidas que

pueden ser utilizadas por descripciones más específicas (casos de
uso de inclusión).

Extraer descripciones de funcionalidad adicionales u opcionales que

pueden extender descripciones más específicas (casos de uso de
extensión).

En esta actividad, el analista de sistemas puede reestructurar el conjunto

completo de casos de uso para hacer que el modelo sea más fácil de
entender y de trabajar con él.

El analista debe buscar comportamientos compartidos y extensiones. Esto

se refleja en la determinación de relaciones de generalización, inclusión y
extensión entre casos de uso.
Cuando tratamos el tema de “Relaciones entre casos de uso”, se presentaron
varios ejemplos de cada una. En la siguiente figura mostramos un ejemplo de
un caso de uso cuya funcionalidad fue extraída de los casos de uso base y es
llamando “por extensión” o “por inclusión”, según sea el caso de uso base
llamador.

Figura 11. Ejemplo

Fuente: elaboración propia.

Figura 12. Ejemplo de diagrama de casos de uso de un sistema de
comercialización de discografía

Fuente: elaboración propia.

Para ampliar los conocimientos sobre la temática, te recomendamos leer los

siguientes artículos:
 M2 L3 Casos de Uso- Un Método Práctico para Explorar
Requerimientos.pdf
88.6 KB

Fuente: Ceria, S. (s.f.). Casos de uso. Un método práctico para explorar requerimientos. Ingeniería de Software I.

UBA. Recuperado de http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf Diagramas de

casos de uso: Ejercicios resueltos. Recuperado de www.ciens.ucv.ve

Diagrama de casos de usos.pdf

358.3 KB

Fuente: Diagramas de casos de uso: Ejercicios resueltos. Recuperado de

www.ciens.ucv.ve http://www.ciens.ucv.ve:8080/genasig/sites/ingenieria-del-software/archivos/ejemplos%20-

%20casos%20de%20uso.pdf

C O NT I NU A R
Lección 7 de 8

Referencias

Alarcón, R. (2000). Diseño orientado a objetos con UML. Recuperado de

https://informatica2011ulagos.files.wordpress.com/2011/03/diseno-
orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos.pdf

Espinoza Robles. (s. f.). Captura de los requisitos como casos de uso [PPT en
línea]. Recuperado de https://es.slideshare.net/juliopari/9-clase-captura-de-
los-requisitosa-9-10-243195

Guardo, A. A. y Sosa Tosello, M. B. (2018). Creación de un proceso de

desarrollo aplicando las mejores prácticas de la industria (Proyecto de grado,
Instituto Universitario Aeronáutico. Recuperado de
https://rdu.iua.edu.ar/bitstream/1234567 89/1783/1/TFG.pdf

Hernández González, A. (2013). Diagrama de casos de uso del negocio y del

sistema [PPT en línea]. Recuperado de
https://es.slideshare.net/123jou/actividad2-diagrama-de-casos-de-uso-del-
negocio-y-del-sistema

Jacobson, I., Rumbaugh, J. y Booch, G. (2000). El proceso unificado de

desarrollo de software. Madrid, ES: Addison Wesley.
Jiménez López, R. (2003). Análisis y Diseño Orientado a Objetos de un
Framework para el Modelado Estadístico con MLG (Tesis doctoral, Universitat
de les Illes Balears). Recuperado de
https://www.tdx.cat/bitstream/handle/10803/9442/ trjl1de1.pdf

Las preguntas más frecuentes de cómo elaborar un diagrama de casos de

uso. (4 de diciembre de 2015). Blog de Alejo. Recuperado de
http://partnerpau. blogspot.com/

Nader, J. (s. f.). Modelización con Diagramas de Casos de Uso [PPT en línea].
Recuperado de https://es.slideshare.net/duncan007/04-casos-de-uso

Segovia, A. L. E. (2015). Modelo de Casos de Uso [PPT en línea]. Recuperado

de https://es.slideshare.net/aleleoemaseg/casos-de-uso-55486364

Sosa López, D. (s. f.). Sistema para el control del USO de los softwares
educativos [Resumen de libro]. Recuperado de
https://www.eumed.net/libros-
gratis/2009c/585/Modelo%20de%20Casos%20de%20Uso%20del%20Sistem
a.htm

Torossi, G. (s. f.). El Proceso Unificado de Desarrollo de Software.

Recuperado de
http://dsc.itmorelia.edu.mx/~jcolivares/courses/pm10a/rup.pdf

C O NT I NU A R
Lección 8 de 8

Descarga en PDF

Mòdulo 2 - Lectura 3.pdf

873.9 KB