P. 1
Definicion casos de Uso.docx

Definicion casos de Uso.docx

|Views: 23|Likes:
Publicado porneoreinaserenity

More info:

Published by: neoreinaserenity on Feb 13, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

03/27/2014

pdf

text

original

DEFINICIÓN.

Caso de uso es un documento narrativo que describe la secuencia de eventos de un ACTOR (agente externo) que utiliza el sistema para completar un proceso. Jacobson, 1992 Un CASO DE USO es una descripción de las INTERACCIONES y las RESPONSABILIDADES de un sistema, "objeto de debate " o "sistema en diseño”, con AGENTES EXTERNOS o ACTORES. Un actor puede ser una persona un grupo de personas o un sistema informático. El caso de uso es asociado con el OBJETIVO de un actor en particular, que es llamado el ACTOR PRINCIPAL del caso de uso. El caso de uso describe los distintos conjuntos de interacciones que pueden ocurrir entre diversos agentes externos o actores mientras que el actor principal está en la búsqueda de su objetivo. También se describen las responsabilidades del sistema bajo diseño sin tener en cuenta técnicas de implementación o componentes del sistema. Cada posible secuencia de interacciones es llamada ESCENARIO. El caso de uso agrupa juntos todos los escenarios relacionados con el objetivo del actor principal, incluyendo tanto los escenarios donde el objetivo es conseguido como los escenarios donde el objetivo debe ser abandonado. Cockburn, Alistair. 2000. Writing Effective Use Cases En la definición anterior, se resaltan en letra mayúscula algunos conceptos destacados, la definición original no resalta ningún concepto.

DESCRIPCIÓN DE UN CASO DE USO.
La descripción de un caso de uso se compone de dos partes principales, el diagrama que representa gráficamente el caso de uso y una descripción textual que aclara de forma literal el diagrama, en esta sección se explicara la descripción textual y en la siguiente sección se explicara el diagrama. 1. ENCABEZADO 1.1. Identificador del caso de uso Cada caso de uso tiene un único identificador numérico, también se pueden agrupar de forma jerárquica usando otras notaciones como X.Y o combinar un código numérico con un código alfabético como RF1, RNF1, etc. 1.2. Nombre del caso de uso El nombre debe ser conciso, debe estar orientado al resultado del caso de uso. Debe reflejar las tareas que el usuario necesita llevar a cabo para usar el sistema. El nombre debe llevar un verbo pues es una acción. Ejemplo. 1. Generar orden de compra 2. Registrar PIN. 1.3. Registro Histórico 1.3.1 Creado Por. En esa parte se pone el nombre de la persona “Autor” de ese caso de uso. 1.3.2 Fecha de creación En esta parte se pone la fecha de creación inicial del caso de uso.

1. Podría ser un evento de negocios externos o de sucesos del sistema que hace que el caso de uso pueda empezar. antes de que el caso de uso empiece.5. 2. 2.1. también podría ser el primer paso en el flujo normal. o una descripción de alto nivel de la secuencia de acciones y los resultados de la ejecución del caso de uso. 2. Deben ir numeradas. 1. El articulo queda registrado en la base de datos.3 Actualizado Por. Descripción Proporcionar una breve descripción de la razón y los resultados del caso de uso. Identifica el evento que inicia el caso de uso.4 Fecha de actualización.2 Flujos alternos. 2.3. DEFINICIÓN DE LOS CASOS DE USO. El usuario debe autenticar su identidad. Provee una descripción detallada de las acciones del usuario y las respuestas del sistema durante la ejecución normal del caso de uso. 2.2.6. Las precondiciones deben ser numeradas. también se pueden conservar los nombres de las personas que actualizaron previamente el caso de uso. 2.3. Esta secuencia de diálogo en última instancia conduce a lograr el objetivo expuesto en el nombre y la descripción de casos de uso. Se escribe la fecha de la última actualización.3. son las condiciones esperadas cuando el caso de uso se ejecuta sin contratiempos. tenga en cuenta que en un caso de uso o un conjunto de ellos pueden interactuar uno o muchos actores.1 Flujo norma de eventos. Se pone el nombre de la persona que realizo la última actualización. Para lograr una buena conformación del flujo normal se recomienda numerar las acciones de los usuarios y las respuestas del sistema a manera de pasos para llegar a la meta del caso de uso. 1. 1. . 2. 2.1. Actores En esta parte se ubican los nombres de los actores implicados en el caso de uso. Esta descripción puede ser escrita como una respuesta a la pregunta hipotética: ¿Cómo se pueden hacer cumplir las tareas que sugiere el nombre del caso de uso?.6.6. Precondiciones Lista todas las actividades que deben ser tenidas en cuenta o todas las condiciones que deben ser cumplidas. Trigger o Disparador. Escenarios 2. El precio del artículo queda actualizado en la base de datos.4. 2. Postcondiciones Describen el estado del sistema una vez terminada la ejecución del caso de uso.

2. Identificar quién va a resolver cada una. Supuestos Liste las suposiciones que se hicieron en el análisis de requerimientos que llevaron a plantear el caso de uso. Se enumeran igual que el flujo normal de eventos con las acciones del usuario y las respuestas del sistema. E indica excepción y Z es el numero de secuencia de las excepciones.12. 2. Lista de cualquier comentario adicional sobre el caso de uso o cualquier cuestión que quedara abierta o por determinar que debe ser resuelta. Excepciones.14. Lista todas las reglas de negocio que influencian el caso de uso.Documenta los escenarios que pueden ocurrir cuando el caso de uso no puede ser ejecutado completamente.Z”. de la forma “X. Es donde se establece en qué momento. 2.1 significa que el caso de uso 4. Reglas de negocio. que se abordarán durante el diseño o implementación de él. Y indica el flujo normal si es (0) o alternativo si es mayor que (0). 4. 2. debe indicarse alguna unidad de tiempo. la fecha de vencimiento. medio y bajo aun cuando usar escalas más amplias podría ayudar a mejorar la priorización y trazabilidad de los casos de uso. 2. llamados por el presente caso de uso. . Puntos de extensión.E. Estos pueden incluir requisitos de rendimiento u otros atributos de calidad.E. Includes Lista de todos los casos de uso de que son incluidos. 2.10.13. Además. se describe cómo el sistema ha de responder si la ejecución de casos de uso falla por alguna razón imprevista.9. 2.11. tales como los requisitos no funcionales que pueden necesitar para el caso de uso. En esta parte se indica la prioridad relativa de la implementación de la funcionalidad del caso de uso. y cuál será el resultado esperado. en su flujo normal presenta una excepción y que dicha excepción es la número 1. Por ejemplo. Prioridad. Requerimientos especiales Se incluyen los requisitos adicionales. Describir las condiciones de error que podrían ocurrir durante la ejecución del caso de uso y define cómo el sistema es responder a esas condiciones. puede usar una escala de 3 valores como alto. Las excepciones se pueden identificar en términos de una 4 tupla.8. del hilo de ejecución del caso de uso se va a extender a otro. donde X es el identificador del caso de uso.0.7.Y. 2.15. Notas y pendientes. 2. Frecuencia de uso Estimar el número de veces en que el caso de uso se llevará a cabo por los actores.

Es donde se establece en qué momento. PLANTILLA PARA DOCUMENTACIÓN DE CASOS DE USO. Por causas extraordinarias. . del hilo de ejecución del caso de uso se va a extender a otro. A continuación se presenta una plantilla base para la documentación de casos de uso.

La Extensión se representa con el estereotipo << Extend >> y una flecha que va desde el caso de uso extendido hasta el principal. Elemento Función en el diagrama El termino ACTOR. independientemente de que sea una persona o un sistema. extensiones.ELEMENTOS DEL DIAGRAMA DE CASOS DE USO. sistema informático). inclusiones o generalizaciones. Actor Asociación << Extends >> . A continuación se muestran algunos elementos visuales básicos del diagrama de casos de uso. inclusión o generalización. Sistema Asociación es la relación entre un actor un caso de uso. por lo general cuando se consideran circunstancias particulares por ejemplo Por ejemplo en una empresa de alimentos el caso de uso (clasificar tomates) puede extender a (descartar tomates).. siempre y cuando el tomate en cuestión no pase cierta validación. actores y casos de uso se relacionan por medio de asociaciones. Un Caso de Uso puede extender el comportamiento de otro. grupo de personas. en muchas herramientas de modelado la flecha no tiene dirección ya que se asume que parte desde el actor. Dentro del diagrama los casos de uso son representados por óvalos. o entre dos casos de uso en esta ultima relación se usa la extensión. externa al sistema que será modelado y que interactúa con uno o más casos de uso. se refiere a un tipo de estereotipo que representa una entidad (persona. casos de uso con casos de uso pueden relacionarse con asociaciones simples. La Asociación es representada por una línea solida que va desde el actor hasta el caso de uso. dentro del rectángulo deben estar los casos de uso y fuera de él los actores. Se representa por una figura humana. En este caso la flecha es punteada aunque algunas herramientas de modelado usan la flecha de generalización con el estereotipo << Extend >>. en el interior de ellos se ubica el nombre del caso de uso por ejemplo “registrar datos”. Caso de Uso En el diagrama el sistema es representado con un rectángulo.

. 2000. sin embargo es una práctica poco utilizada Generalización La generalizacion es representada en el diagrama con una flecha con punta triangular vacia. La Inclusion se representa con el estereotipo << include >> y una flecha que va desde el caso de uso principal hasta el que incluye. La generalización es una relación entre casos de uso que implica que el caso de uso hijo contiene todos los atributos. tarjeta debito y tarjeta crédito. En este caso la flecha es punteada aunque algunas herramientas de modelado usan la flecha de generalización con el estereotipo << Include >>. << Include >> o << Uses >> EJEMPLO DE REQUERIMIENTO. Un Caso de Uso puede ser incluido por uno o más casos de uso. que va desde el caso de uso hijo hasta el caso de uso principal. Cockburn. por lo que ayuda a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que son muchas veces utilizados de nuevo. cheque.Un caso de uso puede incluir la funcionalidad de otro como parte de su proceso normal. comportamiento y puntos de extensión definidos en el caso de uso padre y además participa en todas las relaciones de los casos de uso padres. Ejemplo de requerimiento Requerimiento: el sistema debe registrar pagos con los siguientes medios de pago efectivo. en general se asume que el caso de uso incluido se llama cada vez que el caso de uso base se ejecuta. Alistair. Writing Effective Use Cases También es posible utilizar la generalización con los actores. DIAGRAMA DE CASO DE USO Y DOCUMENTACIÓN.

.Ejemplo de plantilla para documentar caso de uso que refleja el requerimiento.

.Ejemplo del diagrama de casos de uso.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->