Casos de Uso

1 Tema: Casos de Uso
Casos de Uso
Ica-Perú Curso:
2018
Ingeniería de Software I
Ingeniería de Software I 1
DEDICATORIA
Este trabajo se lo dedicamos

a nuestros padres por su
apoyo y amor incondicional
a cada uno de nosotros y
por brindarnos su total
atención
TABLA DE CONTENIDOS
1 Introducción 4
2 Casos de Uso 5
2.1. ¿Cuándo Utilizar los Casos de Uso? 6
2.2. ¿Para que sirven los Casos de Uso? 6
2.3. ¿Qué es un Modelo de Caso de Uso? 6
3 Diagrama de Casos de Uso 7
3.1. Elementos 7
4 Documentacion de Casos de Uso 10
4.1. En Diagrama UML 10
4.2. En Documento 11
4.2.1. Resumido 12
4.2.2. Detallado 13
5 Priorizacion de Casos de Uso 14
6 Modelo de Analisis 15
7 Ejemplo Diagrama Caso de Uso 16
8 Conclución 19
9 Enlaces Informaticos 20
9.1. Casos de Uso 20
9.2. Diagrama de Casos de uso 20
9.3. Documentacion de Casos de Uso 20
9.4. Priorizacion de Casos de Uso 21
9.5. Modelo de Analisis 21
1. INTRODUCCION
El diagrama de Casos de Uso representa la forma en como un Cliente (Actor)

opera con el sistema en desarrollo, además de la forma, tipo y orden en
como los elementos interactúan (operaciones o casos de uso).
Dentro de un proyecto de software existen diferentes etapas, una de estas

independientemente de la metodología que se esté utilizando es la
comunicación con el cliente, ya que es fundamental para definir los
requerimientos de software porque muchas veces lo que se plantea no es lo
que el cliente espera, es por esto por lo que se definen formas de presentar al
cliente una perspectiva de lo que será el software una vez terminado.
Los casos de uso documentan el comportamiento del sistema (acción y

reacción) desde el punto de vista de usuario
Como <<Usuario>>se entiende cualquier cosa que ajena al sistema se

desarrolla y que interactúa con el mismo (persona, sistema de información,
dispositivo de hardware, etc.)
El modelado de caso de uso ayuda con tres de los aspectos más difíciles del
desarrollo. La captura de requisitos, la planificación de las iteraciones del
desarrollo, la validación de los sistemas.
A continuación, daremos una demostración de este tema
2. CASOS DE USO
Los casos de uso son una técnica de descubrimiento de requerimientos que se introdujo por
primera vez en el método Objectory (Jacobson et al., 1993). Ahora se ha convertido en una
característica fundamental del modelado de lenguaje unificado. En su forma más sencilla, un
caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de
interacción. Entonces, esto se complementa con información adicional que describe la
interacción con el sistema. La información adicional puede ser una descripción textual, o
bien, uno o más modelos gráficos como una secuencia UML o un gráfico de estado.
Los casos de uso se documentan con el empleo de un diagrama de caso de uso de alto
nivel. El conjunto de casos de uso representa todas las interacciones posibles que se
describirán en los requerimientos del sistema. Los actores en el proceso, que pueden ser
individuos u otros sistemas, se representan como figuras sencillas. Cada clase de interacción
se constituye como una elipse con etiqueta. Líneas vinculan a los actores con la interacción.
De manera opcional, se agregan puntas de flecha a las líneas para mostrar cómo se inicia la
interacción.
Ejemplo: (casos de uso para el sistema de información del paciente)
Los casos de uso identifican las interacciones individuales entre el sistema y sus usuarios u
otros sistemas. Cada caso de uso debe documentarse con una descripción textual. Entonces
pueden vincularse con otros modelos en el UML que desarrollará el escenario con más
detalle. Por ejemplo, una breve descripción del caso de uso Establece la consulta de la
figura sería:
El establecimiento de consulta permite que dos o más médicos, que trabajan en diferentes
consultorios, vean el mismo registro simultáneamente. Un médico inicia la consulta al elegir
al individuo involucrado de un menú desplegable de médicos que estén en línea. Entonces
el registro del paciente se despliega en sus pantallas, pero sólo el médico que inicia puede
editar el registro. Además, se crea una ventana de chat de texto para ayudar a coordinar las
acciones. Se supone que, de manera separada, se establecerá una conferencia telefónica

para comunicación por voz.
2.1. ¿Cuándo utilizar los casos de uso?
Los casos de uso son un tipo de requerimientos utilizados para especificar funcionalidad,
especialmente en sistemas con un alto grado de interacción hombre/máquina (y pueden ser
utilizados hasta en sistemas de batch). En esencia los casos de uso describen los
intercambios entre el sistema que se está describiendo y las personas o sistemas externos
que interactúan con el primero, por lo tanto, son muy útiles para describir funcionalidades a
varios tipos de usuarios y con muchas interfaces.
2.2. ¿Para qué sirven los casos de uso?
Los casos de uso son útiles para capturar requerimientos, ayudar a definir la arquitectura,
establecer las pautas para el diseño y las pruebas funcionales. Los CU son una guía de los
elementos que serán incluidos en los documentos de usuarios para las aplicaciones, así
como la forma en como éstos deben ser empleados. Los CU también establecen las bases
para los protocolos de comunicación entre aplicaciones y el diseño de las interfaces gráficas,
entre otros.
La validez de los casos de uso viene dada cuando los usuarios e involucrados del sistema
aceptan el funcionamiento propuesto en los CU, siempre que la redacción de los mismo sea
buena, no dejando cabida a ambigüedades.
Entonces los casos de uso deben ser útiles y ofrecer valor tanto al equipo de usuarios e
involucrados como a los desarrolladores del proyecto.
2.3. ¿Qué es un modelo de caso de uso?
Los casos de uso describen secuencias de acciones que realiza un sistema y que lleva a un
resultado de valor a un actor específico.
Un modelo de CU está compuesto por dos partes, un diagrama (gráfico) y una parte textual.
El diagrama muestra las relaciones entre actores y casos de uso, así como las relaciones
entre los CU y entre actores – en caso de que existan –. La parte textual muestra la
descripción escrita en lenguaje natural que narra los pasos y demás características del caso
de uso.
3. DIAGRAMA DE CASOS DE USO

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el
sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan
(operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
 Actor.
 Caso de Uso.
 Relaciones de Uso
 Sistema
3.1. Elementos
 Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que
un Actor no necesariamente representa a una persona en particular, sino más bien la
labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que

el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien
por el Jefe de Local.
Otro ejemplo: Un actor puede ser un empleado, pero también puede ser un cliente en
la tienda de la empresa. Incluso cuando es la misma persona en el mundo real, se
representa como dos símbolos distintos en un diagrama de caso de uso, ya que la
persona interactúa con el sistema en distintos roles.
 Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente
externo, sea desde una petición de un actor o bien desde la invocación desde otro caso
de uso.
 Relaciones de Uso:
o Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o

caso de uso a otra operación (caso de uso). Dicha relación se denota con
una flecha simple.
o Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relación se denota
con una flecha punteada.
o Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o
de Herencia (<<extends>>)
Este tipo de relación está orientado exclusivamente para casos de uso (y no

para actores).
º Extends: Se recomienda utilizar cuando un caso de uso es similar a otro

(características).
º Uses: Se recomienda utilizar cuando se tiene un conjunto de características

que son similares en más de un caso de uso y no se desea mantener
copiada la descripción de la característica.De lo anterior cabe mencionar que
tiene el mismo paradigma en diseño y modelamiento de clases, en donde

está la duda clásica de usar o heredar.
 Sistema
El rectángulo representa los límites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los límites del Sistema
4. Documentación de los Casos de Uso
Existen dos formas principales de documentar un caso de uso:

 En diagrama UML
 En un Documento
Documentar casos de usos no es una tarea fácil que se pueda dominar de un día para otro,
requiere de tiempo, disciplina y experiencia, sin embargo, podemos definir una serie de
pasos identificables para escribir los casos de uso.
Pasos para la documentación de los Casos de Uso
4.1. Diagrama UML
El lenguaje Unificado de Modelado UML provee de un grupo de elementos gráficos para

representar un Caso de Uso, de manera explícita, sucinta y esquemática. Utiliza un monito
para representar a los actores, una elipse con una leyenda para representar un caso y una
línea recta entre un actor y un caso de uso para representar la asociación entre ellos.
4.2. En Documento
 Como el resto de requisitos, los casos de Uso deben tener los siguientes atributos:
o Identificador, nombre, versión, autores, fuentes, dependencias, descripción,
importancia, urgencia y comentarios
 El nombre del caso de uso debe coincidir con el objetivo del actor principal, que es
normalmente el que comienza el caso de uso.
 La descripción usara el siguiente patrón lingüístico:
o El sistema deberá comportarse tal como se describe en el siguiente caso de
uso cuando <evento de activación>.
 El evento de activación es el evento de negocio que hace que los actores soliciten al
sistema un determinado servicio
 Específicamente, los casos de usos deben tener:
o Precondición: condiciones que describen en qué situación se debe encontrar
el sistema y su entorno para poder comenzar el caso de uso.
o Postcondición: condiciones que describen en qué situación debe quedar el
sistema y su entorno una vez que el caso de uso haya finalizado con éxito.
o Secuencia normal o Flujo de Eventos: secuencia de interacciones entre los
actores y el sistema que lleva a la finalización con éxito del caso de Uso
o Excepciones: Situaciones anómalas, y su tratamiento, que pueden darse
durante la secuencia normal
o Las Notas: Las notas son elementos opcionales muy importantes de los CU
pues reflejan el análisis y la comprensión del funcionamiento del sistema,
más allá de la descripción de las interacciones entre los usuarios. Las notas
en los CU se utilizan para plasmar explicaciones, detalles sobre la
información, formatos de archivos que ya se encontraban establecidos y
otros acuerdos con los que la aplicación debe cumplir. Es importante que
todas las notas se encuentren referenciadas con algún elemento del Caso de
Uso, ejemplo la descripción, el FB, el FA, las referencias justifican la existencia
de la nota.
 Ejemplo: Sacar dinero del cajero automático

o Precondición: El cajero automático este operativo y el usuario dispone de su
tarjeta
o Postcondición: El usuario ha obtenido el dinero solicitado, el banco del
usuario ha sido notificado de las transacciones y el cajero está listo para otra
operación.
o Secuencia normal: (Ya vista)
o Excepciones:
 Tarjeta ilegible
 Pin erróneo
 Conexión Imposible
 Saldo Insuficiente
 Etc.
Formato de la documentación de caso de uso para los actores que participen:

Documentación de los actores dentro de los Casos de Uso
SEGÚN LAS NECESIDAD, LOS CASOS DE USO PUEDEN ESPECIFICARSE CON DISTINTO
DETALLE:
4.2.1. Resumido: Se especifican pre y postcondiciones y la secuencia normal se resume

en la propia descripción. Ejemplo:
Nª. Caso de Uso Nombre del Caso de Uso

CU-001 Registrar Préstamo
Versión 1.0 (05/05/2018)
Actores Cantidad de Actores que influyen en el diagrama de CU,
Nombres, Pseudónimos
Bibliotecario, Usuario de la Biblioteca
Descripción Una breve descripción del sistema
El sistema deberá comportarse tal como se describe en el
diagrama de CU Ejemplo:
El usuario de la Biblioteca solicite al Bibliotecario sacar uno o
más libros en préstamo
Precondición El usuario de la biblioteca se ha identificado mediante un carné
de biblioteca y ha cogido los libros de la estantería.

Postcondición El usuario de la biblioteca se lleva los libros prestados y el
sistema ha registrado el préstamo del libro
Las Notas o El número de Préstamos simultáneos y la duración de los
Comentarios prestamos depende de la política de la biblioteca y puede
cambiar en el futuro.
SEGÚN LAS NECESIDADES, LOS CASOS DE USO PUEDEN ESPECIFICARSE CON DISTINTO
DETALLE:
4.2.2. Detallado: Se especifica la secuencia normal y las excepciones con detalle. Ejemplo:
Nª. Caso de Uso Nombre del Caso de Uso

Consultar Cliente
Versión 2.0 (05/05/2018)
Actores Cantidad de Actores que influyen en el diagrama de CU,
Nombres, Pseudónimos
Administrador, Analista, Auxiliar, Supervisor y Vendedor
Descripción Una breve descripción del sistema

El sistema deberá comportarse tal como se describe en el
diagrama de CU
Objetivo Consultar la información que posee el SI respecto al cliente

Precondición  El usuario y password son correctos
 Que el cliente Exista
Postcondición  El SI termina el proceso y vuelve al menú de opciones

1.-Ir al menú cliente -> Consultar
Actividades del Actor / 3.-Digitar el ID
Flujo Básico 6.-El usuario selecciona Aceptar
Flujo de Eventos
o 2.-SI solicita el ID del cliente
Secuencia Normal 4.-SI muestra la información del
Respuesta del Sistema/ cliente
Flujo Alterno 5.-SI muestra la opción para volver al
menú
Manejo de  SI el cliente no existe el sistema muestra un mensaje de

situaciones error
Excepcionales  SI muestra la opción para volver al menú
Las Notas o El número de Consultas depende de la política de la empresa y

Comentarios puede cambiar en el futuro.
5. Priorización de Casos de Uso
Priorización: Descubrir la importancia de cada requerimiento.

Es útil separar los requerimientos en:
 Requerimientos que deben ser absolutamente satisfechos
 Requerimientos que son muy deseables, pero no indispensables
 Requerimientos que son posibles, pero que podrían eliminarse
Determinar cuáles son necesarios para el desarrollo en las primeras iteraciones y cuáles
pueden dejarse para posteriores iteraciones
Cuestiones a tener en cuenta:
 CU con dificultad de desarrollo
 CU imprescindibles para la puesta en marcha del sistema
 Organización del desarrollo incremental
 Disponibilidad de equipo de desarrollo
Se revisa la priorización con el Jefe de Proyecto y se utiliza como entrada para la
planificación de cada iteración del proyecto.
Priorizar:
Es un trabajo realizado entre usuarios/clientes y desarrolladores
 Usuarios/clientes definen las funciones con mayores beneficios
 Desarrolladores definen costos, riegos técnicos, y dificultad de cada función
Todos los requerimientos pactados se implementarán, pero algunos no son tan esenciales
Escalas
 Tres valores
1. Alta – Media – Baja
2. Esencial – Condicional – Opcional
3. Critica – Importante – Útil
5.1. Alta – Esencial

 Requerimiento de misión critica
 El software no es aceptable sin el
5.2. Media – Condicional
 Operaciones de soporte del sistema
 Amplía la funcionalidad del software, pero se puede aceptar sin el al comienzo
5.3. Baja – Opcional

 Interesante tener esta funcionalidad o cualidad, si los recursos lo permiten
 Funciones que no son muy valiosas
La Prioridad de cada requerimiento debe ir en la especificación de los casos de uso o n la

especificación de los requerimientos
En un caso de uso con varias alternativas, algunas pueden tener mayor prioridad que otra
6. Modelo de Análisis
El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla
de formatos en texto y diagramas para representar los requisitos del software, las funciones
y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha
representación, ya que es posible examinar los requisitos desde diferentes puntos de vista
aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se
descubran descuidos.
 El propósito fundamental del modelo de análisis es resolver analizando los

requisitos con mayor profundidad, pero con la diferencia de que puede
utilizarse el lenguaje de los desarrolladores de proyectos para describir los
resultados
 En consecuencia, podemos razonar más sobre los aspectos internos del sistema,
y por tanto resolver aspectos relativos a la interferencia de casos de uso y
demás
 Podemos estructurar los requisitos de manera que nos facilite su comprensión,
su preparación, su modificación y su mantenimiento
 Se puede considerar como una primera aproximación al modelo de diseño y es
por tanto, una entrad fundamental cuando se da “forma al sistema en el diseño
y la implementación”
6.1. Objetivos generales del modelo de análisis
El modelo de análisis debe cumplir tres objetivos primarios:
1. Describir los que requiere el cliente

2. Establecer una base para la creación de un diseño de software
3. Definir un conjunto de
requisitos que pueda validarse una
vez construido el software.
6.2. Elementos del modelo de

análisis
7. Ejemplo Diagrama de Caso de Uso:

Como ejemplo está el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema
debe controlar y/o aceptar:
 Registrar el número de ítemes ingresados.

 Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
 El usuario/cliente presiona el botón de comienzo
 Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen de todo lo depositado
en el día.
 El operador debe además poder cambiar:
a. Información asociada a ítemes.
b. Dar una alarma en el caso de que:
i. Item se atora.
ii. No hay más papel.
Como una primera aproximación identificamos a los actores que interactúan con el sistema:
El modelo de análisis se
complementa de cuatro
elementos fundamentales. Estos
elementos sirven para clasificar
principalmente los diferentes
diagramas y otros derivados
conocidos en plataformas como
Luego, tenemos que un Cliente puede Depositar
sistemas de información e
Itemes y un Operador puede cambiar la información
ingeniería de software entre otros.
de un Item o bien puede Imprimir un informe:
Además, estos con clasificados en
elementos de escenario,
elementos de flujo, elementos de
clases y elementos de
comportamiento.
Además, podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de

depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del diagrama Use Case es:
8. CONCLUCION
 El modelo de Casos de Uso sirve como herramienta de comunicación

con los usuarios y otros expertos.
 Los Casos de Uso no son parte del diseño, sino parte del análisis.
 Son lo que hace el sistema desde el punto de vista del usuario. Es decir,
describen un uso del sistema y como este interactúa con el usuario
 Los Diagramas de casos de uso muestran las relaciones entre los casos
de uso de un sistema y sus actores
 En una relación <<extends>>, un actor que lleve a cabo el caso de uso
base puede realizar o no sus extensiones. Mientras, en una relación
<<include>> el actor que realiza el caso de uso base también realiza el
caso de uso incluido.
 Permite organizar los requerimientos del sistema.
 Permite identificar interacciones de los actores con el sistema.
 Permite identificar interfaces.
 Permite identificar iteraciones.
 Permite establecer el plan de pruebas del sistema.
9. Enlaces Informáticos
9.1. Casos de Uso:
 https://sites.google.com/site/alfonsoperezr/investigacion/estr
ucturacin-y-especificacin-de-casos-de-uos
 https://ingsotfwarekarlacevallos.wordpress.com/2015/06/04/u
ml-casos-de-uso/
 http://www.juntadeandalucia.es/servicios/madeja/contenido/r
ecurso/416
 https://www.infor.uva.es/~chernan/Ingenieria/Teoria/Tema3D
.pdf
 https://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
 https://es.wikipedia.org/wiki/Caso_de_uso
 https://sites.google.com/site/alfonsoperezr/investigacion/estr
ucturacin-y-especificacin-de-casos-de-uos
9.2. Diagrama de Casos de Uso:
 https://www.google.com/search?ei=1_ndWr3sCIH4zgKUwYbo
Dg&q=diagrama+de+caso+de+uso&oq=diagra&gs_l=psy-
ab.3.1.35i39k1l2j0i131i67k1j0i67k1l5j0i131i67k1j0i67k1.2624.3
695.0.6997.6.6.0.0.0.0.171.819.0j5.5.0....0...1c.1.64.psy-
ab..1.5.815...0i131k1.0.H0VaIVia7xg
 https://instintobinario.com/diagrama-de-casos-de-uso/
 https://es.slideshare.net/ElvinHernandez2/uml-diagrama-de-
caso-de-uso
9.3. Documentación de Casos de Uso
 http://www.lsi.us.es/docencia/get.php?id=2008
 http://pegasus.javeriana.edu.co/~PA111-01-
eVoto/docs/Documento%20final%20de%20casos%20de%20us
o%20y%20requerimientos.pdf
 https://es.slideshare.net/rcanalesmora/plantilla-de-caso-de-
uso?next_slideshow=1
 https://docs.google.com/presentation/d/1tlnIcuyIokcKUc9HfZp
pgAurpLyg2jFaeRJbx86CocA/edit#slide=id.i57
 https://www.youtube.com/watch?v=QYAh0AgqovE
9.4. Priorización de Casos de Uso
 https://www.google.com/search?ei=KPvdWoi4J-
eb5wKWmZiwAg&q=priorizar+de+caso+de+uso&oq=priorizar+
de+caso+de+uso&gs_l=psy-
ab.3...732255.732255.0.733334.1.1.0.0.0.0.165.165.0j1.1.0....0.
..1c.1.64.psy-ab..0.0.0....0.FtVt8lqhw3c
 https://lsi.ugr.es/~mvega/docis/casos%20de%20uso.pdf
 https://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/dvd
01/experiencia2000/modelo_de_proceso1/lineas_de_trabajo/r
equerimientos/R6.htm
 https://es.slideshare.net/guest4af293/priorizar-los-casos-de-
uso
9.5. Modelo de Análisis
 https://www.google.com/search?ei=u_3dWvjNG8XAzgKUr77Y
CA&q=modelo+de+analisis&oq=modelo+de+analisis&gs_l=psy-
ab.3..35i39k1j0i67k1j0l8.8800.8800.0.12615.1.1.0.0.0.0.630.63
0.5-1.1.0....0...1c.1.64.psy-ab..0.1.629....0.ggRn5ztDlfE
 https://synergix.wordpress.com/2008/07/12/ejemplo-de-
analisis-de-caso-de-uso/
 https://es.slideshare.net/SergioRios/unidad-4-mad-modelado-
analisis-casos-de-uso
 https://mundokramer.wordpress.com/2011/05/20/modelo-de-
analisis-software/

Casos de Uso

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Casos de Uso

Caricato da

Copyright:

Formati disponibili

1 Tema: Casos de Uso

Este trabajo se lo dedicamos

El diagrama de Casos de Uso representa la forma en como un Cliente (Actor)

Dentro de un proyecto de software existen diferentes etapas, una de estas

Los casos de uso documentan el comportamiento del sistema (acción y

Como <<Usuario>>se entiende cualquier cosa que ajena al sistema se

A continuación, daremos una demostración de este tema

Ejemplo: (casos de uso para el sistema de información del paciente)

acciones. Se supone que, de manera separada, se establecerá una conferencia telefónica

2.1. ¿Cuándo utilizar los casos de uso?

2.2. ¿Para qué sirven los casos de uso?

2.3. ¿Qué es un modelo de caso de uso?

3. DIAGRAMA DE CASOS DE USO

Un diagrama de casos de uso consta de los siguientes elementos:

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que

Es el tipo de relación más básica que indica la invocación desde un actor o

Este tipo de relación está orientado exclusivamente para casos de uso (y no

º Extends: Se recomienda utilizar cuando un caso de uso es similar a otro

º Uses: Se recomienda utilizar cuando se tiene un conjunto de características

tiene el mismo paradigma en diseño y modelamiento de clases, en donde

4. Documentación de los Casos de Uso

Existen dos formas principales de documentar un caso de uso:

4.1. Diagrama UML

El lenguaje Unificado de Modelado UML provee de un grupo de elementos gráficos para

 Ejemplo: Sacar dinero del cajero automático

Formato de la documentación de caso de uso para los actores que participen:

4.2.1. Resumido: Se especifican pre y postcondiciones y la secuencia normal se resume

Nª. Caso de Uso Nombre del Caso de Uso

de biblioteca y ha cogido los libros de la estantería.

Nª. Caso de Uso Nombre del Caso de Uso

Descripción Una breve descripción del sistema

Objetivo Consultar la información que posee el SI respecto al cliente

Postcondición  El SI termina el proceso y vuelve al menú de opciones

Manejo de  SI el cliente no existe el sistema muestra un mensaje de

Las Notas o El número de Consultas depende de la política de la empresa y

5. Priorización de Casos de Uso

Priorización: Descubrir la importancia de cada requerimiento.

5.1. Alta – Esencial

5.3. Baja – Opcional

La Prioridad de cada requerimiento debe ir en la especificación de los casos de uso o n la

 El propósito fundamental del modelo de análisis es resolver analizando los

6.1. Objetivos generales del modelo de análisis

El modelo de análisis debe cumplir tres objetivos primarios:

1. Describir los que requiere el cliente

6.2. Elementos del modelo de

7. Ejemplo Diagrama de Caso de Uso:

 Registrar el número de ítemes ingresados.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de

Entonces, el diseño completo del diagrama Use Case es:

 El modelo de Casos de Uso sirve como herramienta de comunicación

9.1. Casos de Uso:

9.2. Diagrama de Casos de Uso:

9.3. Documentación de Casos de Uso

9.4. Priorización de Casos de Uso

9.5. Modelo de Análisis

Potrebbero piacerti anche