Modelado de casos de uso

Modelado de Casos de Uso
Curso: Ingeniería de Software
Profesor: Bell Manrique Losada
Fecha: Noviembre 2010
uc CdeU
Actor1
uc CdeU
Actor1
Caso de Uso1
Caso de Uso3
Caso de Uso4
uc CdeU
Actor1

ORIGEN:
La idea de casos de uso nace desde la década de los 80’s
con Ivar Jacobson, quien propuso una forma de describir
los requisitos funcionales que se identificaban a partir de las
necesidades de los usuarios. Años más tarde, Alistair
Cockburn propuso un modelo para materializar estas
descripciones, y definió qué son y cómo describirlos. Según
este autor, un caso de uso se puede describir como la
‘historia de uso de un sistema’ (Cockburn, 2006), por lo
cual es una excelente técnica para entender y describir
requerimientos.

OBJETIVO:
La esencia de los Casos de Uso es descubrir y
almacenar requerimientos funcionales,
escribiendo historias de uso de un sistema, y así
ayudar a lograr diferentes objetivos de los
participantes de un proyecto. Para lograr
entender el alcance y utilidades de los Casos de
Uso, es necesario hacer una serie de definiciones
formales.

ELEMENTOS ESTRUCTURALES:
Elemento específico con algún
comportamiento que lo caracteriza, tal como
una persona (identificada por un rol), un
sistema de cómputo, una organización, etc.
También se puede definir como ‘algo’ con un
comportamiento, de tal forma que se puede
decir que no son solo roles jugados por
personas, sino organizaciones, software y/o
máquinas.
uc CdeU
Actor1

 Actor Primario, quien tiene objetivos de
usuario que se logran a través del uso de
servicios.
 Actor de Soporte, proporciona un servicio al
sistema. Normalmente es un sistema de
cómputo, pero podría ser una organización o
persona.
 Actor OffStage, quien tiene un interés en el
comportamiento del Caso de Uso, pero no es
primario ni de soporte.
uc CdeU
Actor1

Es una secuencia detallada de acciones e
interacciones entre actores y el sistema. Es
también llamado una instancia de caso de uso.
Los escenarios son los que se conocen como
‘historias particulares de uso de un sistema’, o
una ruta a través del caso de uso.

Actor Primario: ______
Participantes e Intereses:____
Precondiciones:______
Postcondiciones (garantía de éxito): _____
Principales Escenarios Exito (o Flujo Básico):
1. _____
2. _____
…
Extensiones (o flujos alternativos):
a.
b.
…
Requerimientos Especiales: _____
Tecnología y Lista de Variaciones de Datos: _____
Frecuencia de Ocurrencia: ______
Temas Abiertos:
- _____

Colección de escenarios de éxito y escenarios fallidos,
que describen actores usando un sistema para lograr
un objetivo. Así, un caso de uso implica:
 Escenario de éxito principal, o Flujo Normal, donde
se describe la situación ideal que ocurre de
interacciones actores-sistema.
 Escenarios Alternativos, que describe las opciones
que puede tomar el escenario de éxito principal, si
se cumplen ciertas condiciones determinadas.
uc CdeU
Caso de Uso

ESPECIFICACIÓN DE CASOS DE
USO:
 Se le llama ‘especificación de casos de uso’ al
proceso mediante el cual se detalla
descriptivamente la historia de uso del sistema
(diferentes escenarios). Para este proceso, se han
propuesto una serie de formatos o plantillas que
permiten que la descripción se haga de forma
estándar.
 En la siguiente figura aparece un formato de
especificación, que puede servir de guía para su
utilización.

Revisar las siguientes plantillas o formatos para realizar esta
especificación. Ver:
 http://www.liderdeproyecto.com/uml/uml003.html, www.usecases.org
 http://code.google.com/p/openbox-reader/wiki/ECUTemplate
Actor Primario: ______
Participantes e Intereses:____
Precondiciones:______
Postcondiciones (garantía de éxito): _____
Principales Escenarios Exito (o Flujo Básico):
1. _____
2. _____
…
Extensiones (o flujos alternativos):
a.
b.
…
Requerimientos Especiales: _____
Tecnología y Lista de Variaciones de Datos: _____
Frecuencia de Ocurrencia: ______
Temas Abiertos:
- _____

RECOMENDACIONES PARA ESCRIBIR
CASOS DE USO:
y/o identificar los
.
(por cada
objetivo)
: Por ejemplo, si el objetivo o necesidad
identificada es ‘capturar o procesar un pedido’, el CdeU se
debe nombrar como: Procesar Pedido

CASOS DE USO:
. Para esto se
definen los límites y fronteras del sistema, y se
identifican aquellos actores que tienen objetivos
logrados a través del uso de los servicios del
sistema.
, para
revisar los pasos anteriores y
, identificando para cada pregunta los
objetivos de usuario (hacer listado Actor-Objetivo):

CASOS DE USO:
el sistema?
?
del sistema?
, debido a que el sistema
hace algo en respuesta a un evento del tiempo?
o el desempeño del sistema?
(loggin)?
que lo
reinicia?
del sistema?

CASOS DE USO:
6. A partir del listado Actor-Objetivo generado,
(procesar, registrar, comparar).
7. Finalmente,
e independientemente de la tecnología y
detalles de procedimientos relacionados con la Interfaz
Gráfica.

DISEÑO DE CASOS DE USO:
Define el Diagrama de Casos de Uso para ilustrar en un
modelo gráfico, los casos de uso, los actores y las
interrelaciones entre ellos.
Modelo de contexto visual del sistema, ilustrando los actores
externos y cómo ellos usan el sistema.
La utilidad principal radica en que se utiliza como una
herramienta de comunicación que resume el comportamiento de
un sistema y sus actores. Esta utilidad facilita la comunicación
con el cliente, en términos del sistema solución y sus
funcionalidades.

DISEÑO DE CASOS DE USO:
Permite realizar la especificación del alcance funcional del producto
software que se construye y de los actores, entes que interactúan con
el producto software, que requieren los diferentes casos de usos.
OMG UML 2.0 mantiene los conceptos fundamentales de OMG UML
1.x para este diagrama.
uc CdeU
Actor1
Caso de Uso1
Caso de Uso3
Caso de Uso4

RELACIONES DE CASOS DE USO:
Revisar el siguiente documento -Enlace de Ampliación-:
En el siguiente archivo encontrará un ejemplo práctico de un Diagrama
de Casos de Uso:

Conocida también como relación básica. 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 (CdeU).
Dicha relación se denota con una flecha simple. ( ).
uc CdeU
Actor1
Caso de Uso1
Caso de Uso2

Permite modelar aspectos de jerarquía y/o herencia entre CdeU.
Establece una jerarquía de herencia al nivel de los CdeU, donde el caso
de uso derivado adquiere toda la especificación del CdeU base.
Se denota con una línea con punta de flecha ( ).
Se modela desde el CdeU específico (hijo) hacia el CdeU general (padre).
uc CdeU
Actor1
Caso de Uso1
Caso de Uso3
Caso de Uso4

uc CdeU
Actor1
Actor2 Actor3

Esta relación estereotipada como <<include>>, permite incorporar el
flujo normal de un CdeU, dentro de un caso de uso base de la aplicación.
Se utiliza para incluir un comportamiento, común a varios CdeU.
Se denota con una línea con punta de flecha, con el nombre del
estereotipo <<include>> sobre ella. ( ).
Se modela desde el CdeU base hacia el CdeU que se incluye.
uc CdeU
Actor1
Caso de Uso1
Caso de Uso3
Caso de Uso2
«include»
«include»

Esta relación estereotipada como <<extend >>, permite incorporar el
flujo normal (funcionalidad) de un CdeU externo, dentro de un caso de
uso base de la aplicación, bajo la ocurrencia de una determinada
condición. Se utiliza para incluir un comportamiento externo, que no
afecta el escenario normal de la funcionalidad, asociada a la verificación
de una condición eventual.
Se denota con una línea con punta de flecha, con el nombre del
estereotipo <<include>> sobre ella. ( ).
Se modela desde el CdeU que se extiende hacia el CdeU base.
uc CdeU
Actor1
Caso de Uso1
Caso de Uso2
Caso de Uso4
«extend»

Revisar el siguiente documento -Enlace de Ampliación-:
En el siguiente archivo encontrará un resumen del tipo de relaciones que
usted puede aplicar para diseñar Casos de Uso:

RECOMENDACIONES DE MODELADO:
.
(sistemas de
computador) con una notación alternativa a la de
actores humanos.
.
.

.
:
 Cada uno de los actores del sistema
cuando usan el sistema,
 Modele partes dinámicas o de .
 Los casos de uso sean
que se utilice, y por lo tanto del
método de programación.

MODELADO EN HERRAMIENTAS
CASE
Revisar el video , como guía para el
correcto diseño de los diagramas de Casos de Uso en
una herramienta CASE como Enterprise Architect
Descargar versión de evaluación de

Bibliografía
Artículos / Texto Completo / Libros:
 (Fox, 2007) Fox, Christopher. Software Engineering Design: Processes, Principles and
Patterns with UML 2. Editorial Pearson, 2007.
 (Vilalta, 2004) Josep Vilalta Marzo. Taller de Requerimientos, Análisis y Diseño con
UML. Guía del Alumno TRAD UML101/ed.1-2004 Vico Virtual.
 (Bastarrica y Guerrero, 2004) Cecilia Bastarrica y Luis A. Guerrero. Curso CC61J.
Departamento de Ciencias de la Computación, Universidad de Chile
 (Booch, 1996). Grady Booch. Análisis y Diseño Orientado a Objetos. 2da edición. Ed.
Addison-Wesley / Díaz de Santos.
 (Pressman, 1998) Robert Pressman. Ingeniería de Software. 2007.
 (Stein, 2001) Ben Stein. Chapter 6. Use-case Model: Writing Requirements in Context.
2001. En: http://agamenon.uniandes.edu.co/~pfigueroa/soo/uml
Hipertexto: Guía Visual UML. En:
 http://www.vico.org/UMLguiaVisualpresentacion.htm
 (Cockburn, 2006) Alistar Cockburn. Use Case Fundamentals. Disponible en:
http://alistair.cockburn.us/Use+case+fundamentals

Modelado de casos de uso

Más contenido relacionado

La actualidad más candente

Similar a Modelado de casos de uso

Último

Modelado de casos de uso