Caso de uso

Notacin de caso de uso

Un caso de uso es una descripcin de los pasos o las ac-tividades que debern realizarse para llevar a cabo algnproceso. Los personajes o entidades que participarn enun caso de uso se denominan actores. En el contexto deingeniera del software, un caso de uso es una secuenciade interacciones que se desarrollarn entre un sistema ysus actores en respuesta a un evento que inicia un actorprincipal sobre el propio sistema. Los diagramas de ca-sos de uso sirven para especicar la comunicacin y elcomportamiento de un sistema mediante su interaccincon los usuarios y/u otros sistemas. O lo que es igual, undiagrama que muestra la relacin entre los actores y loscasos de uso en un sistema. Una relacin es una conexinentre los elementos del modelo, por ejemplo la especiali-zacin y la generalizacin son relaciones. Los diagramasde casos de uso se utilizan para ilustrar los requerimien-tos del sistema al mostrar cmo reacciona a eventos quese producen en su mbito o en l mismo.Los ms comunes para la captura de requisitos funciona-les, especialmente con el desarrollo del paradigma de laprogramacin orientada a objetos, donde se originaron,si bien puede utilizarse con resultados igualmente satis-factorios con otros paradigmas de programacin.

1 Un poco de historia en la progra-macin

En 1986, Ivar Jacobson, importante contribuyente aldesarrollo de los modelos de UML y proceso unicado,cre el concepto de caso de uso.[1] Se han realizado mu-chas mejoras al concepto que se estableci entonces, peroprobablemente la ms inuyente y signicativa, en tr-

minos de denicin del trmino caso de uso, fue la deAlistair Cockburn en el libro Escribir casos de uso efecti-vos publicado en el ao 2000.Durante los aos 1990 los casos de uso se convirtieronen una de las prcticas ms comunes para la captura derequisitos funcionales, especialmente con el desarrollodel paradigma de la programacin orientada a objetos,donde se originaron, si bien puede utilizarse con resul-tados igualmente satisfactorios con otros paradigmas deprogramacin.

2 Deniciones bsicas

2.1 ActoresSe le llama actor a toda entidad externa al sistema queguarda una relacin con ste y que le demanda una fun-cionalidad. Esto incluye a los operadores humanos perotambin incluye a todos los sistemas externos, adems deentidades abstractas, como el tiempo.En el caso de los seres humanos se pueden ver a los ac-tores como deniciones de rol por lo que un mismo in-dividuo puede corresponder a uno o ms Actores. Suelesuceder sin embargo, que es el sistema quien va a tenerinters en el tiempo. Es frecuente encontrar que nuestrossistemas deben efectuar operaciones automticas en de-terminados momentos; y siendo esto un requisito funcio-nal obvio, resulta de inters desarrollar alguna forma decapturar dicho requisito en el modelo de caso de uso nal.

3 Tipos de relaciones Comunica (): Relacin (asocia-cin) entre un actor y un caso de uso que denota laparticipacin del actor en dicho caso de uso.

Usa () (o en la nueva versinde UML): Relacin de dependencia entre dos casosde uso que denota la inclusin del comportamientode un escenario en otro.

Extiende (): Relacin de dependenciaentre dos casos de uso que denota que un caso deuso es una especializacin de otro. Por ejemplo, po-dra tenerse un caso de uso que extienda la formade pedir azcar, para que permita escoger el tipode azcar (normal, diettico o moreno) y adems la

1

2 5 VENTAJAS

cantidad en las unidades adecuadas (cucharadas obolsas). Un posible diagrama se muestra en la gura

Se utiliza una relacin de tipo entre casosde uso cuando nos encontramos con un caso de uso simi-lar a otro pero que hace algo ms que ste (variante). Porcontra, utilizaremos una relacin tipo cuandonos encontramos con una parte de comportamiento simi-lar en dos casos de uso y no queremos repetir la descrip-cin de dicho comportamiento comn.En una relacin , un actor que lleve a caboel caso de uso base puede realizar o no sus extensiones.Mientras, en una relacin el actor que rea-liza el caso de uso base tambin realiza el caso de usoincluido.En general utilizaremos cuando se presen-ta una variacin del comportamiento normal, y cuando se repite un comportamiento en dos casosde uso y queremos evitar dicha repeticin.Por ltimo en un diagrama de casos de uso, adems delas relaciones entre casos de uso y actor (asociaciones)y las dependencias entre casos de uso ( y), pueden existir relaciones de herencia yasea entre casos de uso o entre actores.Llamamos modelo de casos de uso a la combinacin decasos de uso y sus correspondientes diagramas. Los mo-delos de casos de uso se suelen acompaar por un glo-sario que describe la terminologa utilizada. El glosarioy el modelo de casos de uso son importantes puntos departida para el desarrollo de los diagramas de clases.Por ltimo se debe tener en cuenta, que aunque cada casode uso puede llevar a diferentes realizaciones, es impor-tante reejar en cada representacin el motivo que nos hallevado a descartarla, si es el caso.Pasos para la Denicin de un Caso de Uso:

ID NOMBRE REFERENCIAS CRUZADAS CREADO POR ULTIMA ACTUALIZACION POR FECHA DE CREACION FECHA DE ULTIMA ACTUALIZACION ACTORES DESCRIPCION TRIGGER PRE-CONDICION POST-CONDICION

FLUJO NORMAL FLUJOS ALTERNATIVOS INCLUDES FRECUENCIA DE USO REGLAS DE NEGOCIO REQUERIMIENTOS ESPECIALES NOTAS Y ASUNTO

4 Normas de aplicacinLos casos de uso evitan tpicamente el lenguaje tcnico,preriendo la lengua del usuario nal o del experto delcampo del saber al que se va a aplicar. Los casos del usoson a menudo elaborados en colaboracin por los analis-tas de requerimientos y los clientes.Cada caso de uso se centra en describir cmo alcanzaruna nica meta o tarea. Desde una perspectiva tradicionalde la ingeniera de software, un caso de uso describe unacaracterstica del sistema. Para la mayora de proyectosde software, esto signica que quizs a veces es necesa-rio especicar decenas o centenares de casos de uso paradenir completamente el nuevo sistema. El grado de laformalidad de un proyecto particular del software y de laetapa del proyecto inuenciar el nivel del detalle reque-rido en cada caso de uso.Los casos de uso pretenden ser herramientas simples paradescribir el comportamiento del software o de los siste-mas. Un caso de uso contiene una descripcin textual detodas las maneras que los actores previstos podran traba-jar con el software o el sistema. Los casos de uso no des-criben ninguna funcionalidad interna (oculta al exterior)del sistema, ni explican cmo se implementar. Simple-mente muestran los pasos que el actor sigue para realizaruna operacin.Un caso de uso debe:describir una tarea del negocio que sirva a una meta denegocio tener un nivel apropiado del detalle ser bastantesencillo como que un desarrollador lo elabore en un nicolanzamientoSituaciones que pueden darse:Un actor se comunica con un caso de uso (si se trata deun actor primario la comunicacin la iniciar el actor, encambio si es secundario, el sistema ser el que inicie lacomunicacin). Un caso de uso extiende otro caso de uso.Un caso de uso utiliza otro caso de uso.

5 VentajasLa tcnica de caso de uso tiene xito en sistemas inter-activos, ya que expresa la intencin que tiene el actor (su

3usuario) al hacer uso del sistema.Como tcnica de extraccin de requerimiento permiteque el analista se centre en las necesidades del usuario,qu espera ste lograr al utilizar el sistema, evitando quela gente especializada en informtica dirija la funciona-lidad del nuevo sistema basndose solamente en criteriostecnolgicos.A su vez, durante la extraccin (elicitation en ingls), elanalista se concentra en las tareas centrales del usuariodescribiendo por lo tanto los casos de uso quemayor valoraportan al negocio. Esto facilita luego la priorizacin delrequerimiento.Aunque comnmente se asocian a la fase de Test de unaaplicacin, esta idea es errnea, y su uso se extiende ma-yormente a las primeras fases de un desarrollo.

6 LimitacionesLos casos de uso pueden ser tiles para establecer re-quisitos de comportamiento, pero no establecen comple-tamente los requisitos funcionales ni permiten determi-nar los requisitos no funcionales. Los casos de uso debencomplementarse con informacin adicional como reglasde negocio, requisitos no funcionales, diccionario de da-tos que complementen los requerimientos del sistema. Sinembargo la ingeniera del funcionamiento especica quecada caso crtico del uso debe tener un requisito no fun-cional centrado en el funcionamiento asociado.

7 Vase tambin

Requisito funcional

Diagrama de casos de uso

Puntos de casos de uso

8 Enlaces externos

Precise Use Cases

Use-Case Modeling

9 Herramientas de administracinde requerimientos

Open source requirement management tool

10 Referencias[1] Jacobson, I., P. Jonsson, M. Christerson and G. Over-

gaard, Ingeniera de Software Orientada a Objetos - Unacercamiento a travs de los casos de uso. Addison Wes-ley Longman, Upper Saddle River, N.J., 1992.

4 11 TEXTO E IMGENES DE ORIGEN, COLABORADORES Y LICENCIAS

11 Texto e imgenes de origen, colaboradores y licencias11.1 Texto

Caso de uso Fuente: http://es.wikipedia.org/wiki/Caso_de_uso?oldid=83252953 Colaboradores: Emijrp, Magister Mathematicae, Su-perzerocool, Yrbot, GermanX, Kelovy, The Photographer, Gothmog, Baneld, Pviojo, Cheveri, Lasneyx, Cad, BOTpolicia, CEM-bot,Alejandrosilvestri, Pablotortorella, -jem-, Jfrank~eswiki, Antur, Thijs!bot, Esoya, Alvaro qc, Tyrannosaurusreex, Nightwish, Gngora,Migp~eswiki, Mansoncc, Iulius1973, ZrzlKing, Plux, Manuel Trujillo Berges, VolkovBot, Snakeyes, Matdrodes, DJ Nietzsche, Tatvs,Muro Bot, Bucho, SieBot, Manw, Pascow, Belb, Tirithel, Jarisleif, Carlosdemoron, Nicop, Farisori, Veon, Qwertymith, Luis Arenal Kus-ter, Leonpolanco, Poco a poco, Ravave, AVBOT, LucienBOT, Vgrunberg, Diegusjaimes, Arjuno3, Andreasmperu, Jkbw, Rubinbot, Dreit-men, Botarel, Vihuarar, Hprmedina, Encvirtual, HUBOT, Nachetex, PatruBOT, EmausBot, Jorge123321, Grillitus, Khiari, MerlIwBot,KLBot2, Thehelpfulbot, Serchkat, Pccoronado, Invadibot, Justincheng12345-bot, Balles2601, Jarould, Matiia, David Condrey, Gargola123 y Annimos: 152

11.2 Imgenes Archivo:Commons-emblem-question_book_orange.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/1/1f/

Commons-emblem-question_book_orange.svg Licencia: CC BY-SA 3.0 Colaboradores: + Artista original: GNOME icon artists, Jorge 2701

Archivo:Notacion_Caso_de_Uso.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/9/9e/Notacion_Caso_de_Uso.svg Li-cencia: CC BY-SA 3.0 Colaboradores:

Notacion_Caso_de_Uso.png Artista original: Notacion_Caso_de_Uso.png: Wilfredo R. Rodriguez H. Archivo:Use_case_restaurant_model.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/1/1d/Use_case_restaurant_model.

svg Licencia: CC BY-SA 3.0 Colaboradores: Own work, redrawn of w:File:Restaurant Model.png Artista original: Kishorekumar 62 (re-drawn by Marcel Douwe Dekker)

11.3 Licencia de contenido Creative Commons Attribution-Share Alike 3.0

Un poco de historia en la programacin Definiciones bsicas Actores

Tipos de relaciones Normas de aplicacin Ventajas Limitaciones Vase tambin Enlaces externos Herramientas de administracin de requerimientos Referencias Texto e imgenes de origen, colaboradores y licenciasTextoImgenesLicencia de contenido