Modelado de Requerimientos Funcionales del Sistema de Informacin con Use Cases

La lectura produce personas completas, la conversacin, personas dispuestas, y la escritura, personas precisas. Francis Bacon

Crdoba, Septiembre de 2001

Use Cases en el Sistema de Informacin

Tabla de Contenidos Diagrama de Use Case................................................................................................................... 3

Uso del Diagrama de Use Case........................................................................................................ 3 Componentes del Diagrama de Use Case......................................................................................... 3 Use case ...................................................................................................................................... 3 Actor ......................................................................................................................................... 10 Modelo de Use Case.......................................................................................................................... 13 Cmo evoluciona el Modelo de Use Case? .................................................................................. 13 Evitando la descomposicin funcional........................................................................................... 13 El dilema del qu versus el cmo................................................................................................... 14 Use Cases Concretos y Abstractos ................................................................................................. 14 Estructurando el Modelo de Use Case............................................................................................ 15 Estn los use case relacionados siempre a Actores?...................................................................... 17 El examen de la descripcin .......................................................................................................... 17 Relaciones de Inclusin ............................................................................................................. 18 Ejecutando la Inclusin............................................................................................................... 18 Relaciones de Extensin ............................................................................................................ 19 Relaciones de Generalizacin .................................................................................................... 22

Judith Meles

Pgina 2 de 24

Use Cases en el Sistema de Informacin

Diagrama de Use Case

Un diagrama de use cases muestra actores, use case, paquetes de use cases y sus relaciones. Los diagramas de use cases pueden organizarse en paquetes de use cases, mostrando slo lo que es relevante con un paquete particular. Uso del Diagrama de Use Case No hay reglas estrictas a cerca de cmo dibujar un diagrama de use case, pero los siguientes diagramas pueden ser de inters: o o o o o o o Actores que pertenecen al mismo paquete de use case. Un actor y todos los use cases con los que interacta. Use cases que manejan la misma informacin. Use cases usados por el mismo grupo de actores. Use cases que se ejecutan a menudo con la misma secuencia. Use cases que pertenecen al mismo paquete de use case. Los use cases ms importantes. Un diagrama de este tipo puede servir como un resumen del modelo. o Los use cases desarrollados junto, en el mismo incremento. o Un use case especfico y sus relaciones con actores y otros use cases.

Es recomendable incluir cada actor, use case y relacin en l menos uno de los diagramas. Si hace al modelo de use case ms claro, puede formar parte de varios diagramas y/o mostrarlos varias veces en el mismo diagrama. Componentes del Diagrama de Use Case Use case Un use case registra un contrato entre los involucrados del sistema acerca de su comportamiento, en varias circunstancias, organizndolo por los objetivos de los actores seleccionados. Una instancia de use case es una secuencia de acciones que realiza un sistema para alcanzar un resultado observable de valor para un actor en particular. Un use case define un conjunto de instancias de use cases. Hay varias palabras claves en esta definicin: INSTANCIA DE USE CASE: es realmente en flujo especfico de eventos a travs de un sistema, o una instancia. Muchos flujos de eventos son posibles y muchos de ellos son similares, para hacer el modelo ms comprensible se agrupan los flujos de eventos similares en un use case. Identificar y describir un use case realmente significa identificar y describir un grupo relacionado de flujos de eventos.

Judith Meles

Pgina 3 de 24

Use Cases en el Sistema de Informacin

EL SISTEMA REALIZA: significa que el sistema provee el use case. Un actor se comunica con una instancia de use case del sistema. RESULTADO OBSERVABLE DE VALOR: un use case debera asegurar que un actor puede realizar una tarea que tiene un valor identificable. Esto es importante al determinar el nivel correcto de granularidad para un use case. ACCIONES: una accin es un procedimiento algortmico o computacional. Invocado cuando el actor provee la seal al sistema o cuando el sistema obtiene un evento de tiempo. Una accin es atmica en el sentido que es ejecutada en forma completa o no es ejecutada. ACTOR PARTICULAR: el actor es clave para encontrar los use cases correctos, especialmente porque ayuda a que los use case no sean demasiado largos. La funcionalidad del sistema es definida por diferentes use cases, cada uno de los cuales representa en flujo de eventos especfico. La descripcin de un use case define que ocurre en el sistema cuando el use case es ejecutado. La coleccin de use cases constituye todas las maneras posibles de usar el sistema. Se puede obtener una idea de la tarea del use case simplemente observando su nombre.
Cmo Encontrar Use cases?

El siguiente conjunto de preguntas es til para identificar use cases: o o o o o o o Para cada actor identificado: cules son las tares en las cuales el sistema debera estar involucrado? Necesita el actor ser informado a cerca de ciertas ocurrencias en el sistema? Necesita el actor informar a cerca de cambios externos, repentinos? Provee el sistema al negocio con el comportamiento correcto? Pueden ejecutarse todos los aspectos por los use case que se han identificado? Qu use cases soportaran y mantendrn el sistema? Qu informacin debe ser modificada o creada en el sistema?

Los use cases que deben pasarse por alto, dado que no representan lo que comnmente son las funciones principales del sistema, pueden ser de las siguientes clases: o Inicio y finalizacin del sistema o Mantenimiento del Sistema. Por ejemplo: agregar nuevos usuarios, definir perfiles de usuarios. o Mantenimiento de los datos almacenados en el sistema, ejemplo: el sistema debe trabajar en paralelo con un sistema legado y los datos necesitan sincronizarse entre los dos. o Funcionalidad necesaria para modificar el comportamiento del sistema.
Cmo evoluciona un Use case?

En las primeras iteraciones durante la elaboracin se describen solamente unos pocos use case, los que son significativos para delinear la arquitectura. Primero se debera desarrollar una descripcin general del use case y luego continuar con los detalles. Siempre se debe comenzar por el flujo de eventos bsico. Una vez

Judith Meles

Pgina 4 de 24

Use Cases en el Sistema de Informacin

que se logr acuerdo sobre el flujo bsico, se pueden agregar los flujos alternativos, que deberan estar relacionado con el flujo bsico.
Todos los Use cases se describen en detalle?

Frecuentemente habr en los modelos de use cases algunos use cases que son tan simples que no necesitan una descripcin detallada del flujo de eventos, una descripcin general es suficiente. El criterio para tomar esa decisin es que no se vean desacuerdos entre las clases de usuarios que lo leern o en lo que le use case significa, y que los diseadores y testeadores estn cmodos con el nivel de detalle provisto por el formato general. Algunos ejemplos son los use cases que describen una entrada o recuperacin simple de datos del sistema.
El alcance de un use case

Frecuentemente, es difcil decidir si un conjunto de interacciones usuario-sistema, o dilogo, es uno o varios use cases. Si se considera el uso de una mquina recicladora, donde los clientes insertan tems de depsito (latas, botellas, cajas). Cuando termina de ingresar los tems, presiona un botn y se imprime un recibo. El cliente puede cambiar ese recibo por dinero. Es un use case insertar el tem de depsito y otro use case pedir el recibo? Es todo un nico use case? Son dos acciones, pero una sin la otra son de poco valor para el cliente. Por lo tanto, el dialogo completo, desde que se inserta el primer tem hasta que se obtiene el recibo es un nico use case. Adicionalmente, si se quiere mantener dos acciones juntas, para poder revisarlas al mismo tiempo, modificarlas y probarlas juntas, en general, administrarlas como una unidad, podrn considerase un nico use case.
Cmo son realizados los Use cases?

Un use case describe lo que pasa es el sistema cuando el actor interacta con el sistema. El use case no define como el use case internamente ejecuta sus tareas. En otras palabras, las instancias de use case corresponden a instancias de objetos implementados, comunicndose. A menudo los mismos objetos participan el realizaciones de ms de un use case. Es no significa que los use case se comuniquen, solo que usan el mismo objeto en su realizacin.
Un use case tiene mucha instancias posibles

Un use case puede seguir casi un ilimitado, pero numerable nmero de caminos. Estos cominos representan elecciones hechas a la instancia del use case en la descripcin de su flujo de eventos. El camino elegido depende de los eventos. Los tipos de eventos, incluyen: Entrada desde un actor: un actor puede decidir, de varias opciones, que hacer despus. (Ejemplo: al actor puede decidir ingresar otro tem o pedir el recibo) Un control de valores o tipos de un objeto o atributo interno: el flujo de eventos puede diferir si un valor es ms o menos grande que un cierto valor. (Ejemplo: en un use case de extraccin el flujo puede diferir si el actor pide ms dinero del que puede extraer de su cuenta).

Judith Meles

Pgina 5 de 24

Use Cases en el Sistema de Informacin

Concurrencia de las instancias del use case

Instancias de algunos use cases y varias instancias del mismo use case trabajan concurrentemente si el sistema lo permite. Se espera que el modelo de diseo resuelva este problema, debido a que el modelo de use case no describe como trabajan las cosas. Una manera de ver esto es asumir que solo una instancia de use case est activa al mismo tiempo y que ejecutar esa instancia es una accin atmica. En el modelo de use case se considera tecnologa interna perfecta, por lo que esto no representa un problema.
Definicin de use case y escenario desde el punto de vista de las interacciones

En el caso ms simple, una interaccin es simplemente el envo de un mensaje. "Hola, Jean" e "Impresin (valor)" son ejemplos de mensajes como interacciones simples. Una interaccin tambin podra ser una sucesin de interacciones. sta es una definicin de recursividad. El ultimo o ms bajo nivel consiste de mensajes. Se pretende concatenar una sucesin de mensajes en una sola interaccin algn da. Esto nos permite ahorrar espacio y esfuerzo. "Yo tena una interaccin con Jean en la cafetera, hoy." Nosotros nos referimos a una sucesin de interacciones con una declaracin: "Despus de que usted tiene sus interacciones con Jean esta tarde, llmeme con los resultados." Una sucesin no tiene ninguna bifurcacin o alternativa. Por consiguiente se describe el pasado o el futuro definido con condiciones declaradas. Semejante sucesin es conocida como un escenario. La "Sucesin de Interacciones" es un "escenario". Con el propsito de describir un sistema, necesitamos poder coleccionar todos los escenarios que podran ocurrir juntos durante una interaccin. "Escuche, cuando usted tiene esa interaccin con Jean hoy, aqu estn algunas situaciones alternativas que puede hacer..." o "Una interaccin con el cajero automtico puede consistir en los escenarios siguientes." Una coleccin de escenarios es un caso de uso. Escenarios y use-cases van hasta la concrecin del objetivo o el abandono.
Cmo sabe usted cundo dejar de escribir un escenario o un caso de uso?

Hay dos clusulas que tienen que ser hechas explcitamente para conseguir los lmites apropiados en un use case y un escenario. Para ambos casos las clusulas son las mismas: Clusula 1. Todas las interacciones se relacionan al mismo objetivo. Clusula 2. Las interacciones empiezan activando al evento y terminan cuando el objetivo se alcanza o se abandona, y el sistema completa sus responsabilidades con respecto a la interaccin. La Clusula 2 trae a colacin la nocin de tener una responsabilidad con respecto a la interaccin. Muchos sistemas tienen que anotar cada interaccin con un cliente (Ej. los sistemas de banco). Si la clusula no incluyera este requisito, el guin acabara sin esa responsabilidad.

Judith Meles

Pgina 6 de 24

Use Cases en el Sistema de Informacin

Cmo son realizados los Use cases? Un use case describe lo que pasa en el sistema cuando el actor interacta con l. El use case no define como internamente ejecuta sus tareas. En otras palabras, las instancias de use case corresponden a instancias de objetos implementados, comunicndose. A menudo los mismos objetos participan el realizaciones de ms de un use case. Es no significa que los use case se comuniquen, solo que usan el mismo objeto en su realizacin.
Nombre de un use case

Cada use case deber tener un nombre que indique lo que se alcanza por su interaccin con el actor. El nombre puede tener varias palabras, debe ser entendible. No puede haber dos use case con el mismo nombre. Ejemplos de Variaciones de los nombre podran ser: Extraer dinero Extrayendo dinero.

Descripcin de los use cases

El flujo de eventos de un use case contiene la informacin ms importante derivada del trabajo de modelado de use cases. El flujo debera presentar lo que el sistema hace, no cmo est diseado el sistema para ejecutar el comportamiento requerido. LINEAMIENTOS PARA EL CONTENIDO DEL FLUJO DE EVENTOS: Describir como inicia y termina el use case Describir que datos se intercambian entre el actor y el use case. No describir detalles de la interfaz del usuario, a menos que sea necesario para entender el comportamiento del sistema. Describir el flujo de eventos, no solo la funcionalidad, para reforzar esto comenzar cada accin con: Cuando el actor... Describir solo los eventos que pertenecen a ese use case, y no lo que pasa en otros use cases o fuera del sistema. Evitar terminologa vaga tal como por ejemplo etc informacin. Detalle en el flujo de eventos todos los que que deberan responderse, recuerde que los diseadores de pruebas usarn ese texto para identificar casos de prueba.

Si ha utilizado ciertos trminos en otros use cases, asegrese que se usen los mismos trminos en el use case que est describiendo y que su significado sea el mismo. Para manejar terminologa comn, utilice glosarios.

Judith Meles

Pgina 7 de 24

Use Cases en el Sistema de Informacin

Flujos de Eventos: Estructura

Las dos partes principales del flujo de eventos son: Flujo de eventos bsico: debera cubrir lo que normalmente ocurre cuando el use case es ejecutado. Flujos de eventos alternativos: cubren comportamiento de carcter excepcional u opcional en relacin al comportamiento normal, y tambin variaciones del comportamiento normal. Se puede pensar en los flujos alternativos como desviaciones del flujo bsico de eventos, algunos de los cuales terminarn la ejecucin del use case.

Ambos cursos (el bsico y los alternativos) deberan estructurarse en pasos o subflujos. El principal objetivo de esto es la legibilidad del texto. Un regla a considerar es que un subflujo debera ser un segmento de comportamiento que tenga un propsito claro y atmico en el sentido que deben hacer todas las acciones o ninguna de las descriptas. Puede tener varios niveles de subflujos , pero si se puede se debe evitarlo dado que hace al texto ms complejo y difcil de entender. Para evitar malentendidos se deber sealar si el orden de los subflujos es fijo o no. Estas consideraciones estn relacionadas frecuentemente a : Reglas del Negocio, ejemplo, el usuario debe estar autorizado antes que el sistema le de ciertos datos. Diseo de interfase de usuario: el sistema no debera forzar cierta secuencia de comportamiento que puede ser intuitiva para algunos usuarios y para otros no.

Para aclarar cuando un fluijo de eventos alternativo encaja en la estructura, se debe describir lo siguiente, para cada desviacin del flujo bsico de eventos: En que parte del flujo de evento bsico se insertar el comportamiento alternativo. La condicin que debe cumplirse para que el comportamiento alternativo inicie. Cmo y donde se termina el flujo de eventos bsico, o cmo termina el use case.

Podra ser tentador, si el flujo d eventos alternativo es muy simple, solo describirlo en el flujo bsico (usando una construccin del tipo IF-THEN-ELSE. Esto debera evitarse. Extrayendo partes del flujo de eventos y describindolas en forma separada, puede incrementar la legibilidad del flujo bsico de eventos y mejorar al estructura del use case y del modelo de use case. Se pueden extraer partes como: Un flujo de eventos alternativo del use case base, si es una variante simple, opcin o excepcin del flujo bsico de eventos. Como una inclusin explcita en el use case base (ver Relaciones de Inclusin), si es algo que se desea encapsular para que pueda reusarse por otros use cases. Como una inclusin implcita en el use case base (ver Relaciones de Extensin), si el flujo bsico de eventos del use case base es completo, es decir tiene un inicio y un fin definidos. La naturaleza del flujo extendido debera se tal que se prefiera ocultar ese flujo en la descripcin del use case base para hacer menos complejo. Un subflujo en el flujo de eventos bsico, si ninguna de las alternativas anteriores se aplica. Por ejemplo: Un use case de Mantenimiento de Informacin de Empleados, puede tener subflujos separados para agregar, borrar y modificar informacin de empleados.
Pgina 8 de 24

Judith Meles

Use Cases en el Sistema de Informacin

Flujos de Eventos: Estilos y Ejemplos

Pre- y Post- Condiciones

Puede ser til usar el concepto de las pre y post condiciones para clarificar como empiezan y terminan los flujos de eventos. Sin embargo, solo debe usarse cuando se perciba una incremento en el valor para la audiencia del use case.

Considere lo siguiente: Los estados descriptos por las pre y post condiciones deberan ser estados que el usuario pueda observar. Ejemplo: El usuario ha abierto el documento, El usuario ha ingresado el sistema. Una pre-condicin es una restriccin sobre cuando un use case puede empezar. No es el evento que inicia el use case. Una pre-condicin de un use case, no es una pre-condicin para un nico subflujo, aunque se pueda definir pre y post condiciones a nivel de subflujo. Una post-condicin para un use case debe ser verdadera, independientemente de cual flujo sea ejecutado, no debe ser verdadera slo para el flujo principal. Si algo puede fallar, debera cubrirse en la post condicin diciendo: La accin se ha completado o si algo ha fallado, la accin no se ha realizado, en lugar de decir La accin se ha completado. Cuando se usan poscondiciones junto con relaciones de extensin, se debe tener cuidado que los use case que extienden el use case base, no introduzcan un subflujo que viole la poscondicin del use case base. Las poscondiciones pueden ser una herramienta poderosa para describir use cases. Primero se define lo que se supone que el use case debe alcanzar, la poscondicin. Luego, se puede describir como alcanzar esa condicin (el flujo de eventos necesarios).

Judith Meles

Pgina 9 de 24

Use Cases en el Sistema de Informacin

Puntos de Extensin

Un punto de extensin abre al use case la posibilidad de una extensin. Tiene un nombre, y una lista de referencias a una o ms ubicaciones del flujo d eventos del use case. Un punto de extensin puede referenciar una nica ubicacin entre dos pasos del comportamiento del use case, o puede referenciar a un conjunto discreto de ubicaciones. Para usar puntos de extensin nombrados le ayudar separar lo especificacin del comportamiento del use case extendido de los detalles internos del use case base. Ejemplo de Punto de Extensin: Nombre: Mostrar Identidad Ubicacin: Despus de la seccin 1.9 Suena el timbre del telfono del receptor.

Actor
Una instancia de actor es algo o alguien fuera del sistema que interacta con el sistema. Una clase de actor define un conjunto de instancias de actor, en la cual cada instancia de actor juega el mismo rol en relacin con el sistema. Para comprender completamente el propsito del sistema, se debe saber para quin es el sistema. Un actor es cualquier cosa que intercambia datos con el sistema, puede ser un usuario, hardware externo u otro sistema. La diferencia entre un actor y un usuario individual del sistema es que el actor representa una clase particular de usuario ms que un usuario real. Varios usuarios pueden jugar el mismo rol, lo que significa que pueden ser uno y el mismo actor. En tal caso, cada usuario constituye una instancia de actor. El mismo usuario puede tambin actuar como varios actores, es decir, la misma persona puede tomar diferentes roles) Un actor primario es el que tiene un objetivo para la concrecin del cual requiere la ayuda del sistema. Un actor secundario es del que el sistema necesita ayuda para satisfacer su objetivo, es decir, el objetivo del actor primario.
Cmo encontrar actores?

El siguiente grupo de preguntas es til para tener en mente cuando se identifica actores: Quin proveer, usar o quitar informacin? Quin usar esta funcionalidad? Quin est interesado en cierto requerimiento? En que parte de la organizacin ser usado el sistema? Quin dar soporte y mantendr el sistema?

Judith Meles

Pgina 10 de 24

Use Cases en el Sistema de Informacin

Cuales son los recursos externos del sistema? Qu otros sistemas necesitarn interactuar con este sistema?

Existen algunos aspectos diferentes de los alrededores del sistema que deben representarse como actores separados: Usuarios que ejecutan las funciones principales del sistema Usuarios que ejecutan las funciones secundarias del sistema, tal como la administracin del sistema. Hardware externo que el sistema usa. Otros sistemas que interactan con el sistema.

Los actores ayudan a definir los lmites del sistema

Encontrar actores tambin significa que se establecen los lmites del sistema, lo que ayuda a entender el propsito y alcance del sistema. Solo aquellos que se comunican directamente con el sistema necesitan ser considerados actores. Si se estn incluyendo ms roles que los que estn alrededor del sistema, est intentando modelar el negocio en el cual el sistema ser utilizado, no el sistema en s mismo. Ejemplo: Si est construyendo un sistema para reservas areas, para ser usado por un agente de viajes, el actor ser el agente de viajes. El pasajero no interacta directamente con el sistema y por lo tanto no es un actor. Si est construyendo un sistema para reservas areas que permitir a los usuarios conectarse va Internet, el pasajero interactuar directamente con el sistema y por lo tanto ser un actor.
Breve descripcin de los actores

Una breve descripcin del actor debera incluir informacin a cerca de: A qu o quin representa el actor Porqu es necesario el actor Qu inters tiene el actor en el sistema.

Caractersticas del Actor

Las caractersticas del actor pueden influenciar como se desarrollar el sistema, y en particular como ser diseada ptimamente una interfase de usuario. Las caractersticas del actor incluyen: El alcance de la responsabilidad del actor El entorno fsico en el cual el actor usar el sistema. El nmero de usuarios representados por el actor. Este nmero es un factor relevante para determinar el incidencia del actor y de las interfaces que el actor usa.

Judith Meles

Pgina 11 de 24

Use Cases en el Sistema de Informacin

La frecuencia con la que el actor usar el sistema, lo que determinar cuanto de la interfaz del usuario se espera que el recuerde entre sesiones. El nivel de conocimiento del dominio que posee el actor. Esto determinar cuanta ayuda especfica del dominio ser necesaria y cuanta terminologa especfica del dominio debera usarse en la interfaz del usuario. El nivel general de experiencia del usuario en el uso de computadoras, lo que determinar el nivel de sencillez / sofisticacin de las tcnicas de interaccin que se utilizarn en la interfaz. Otras aplicaciones que el actor usa. Si se utilizan conceptos desde esas aplicaciones se acortar el tiempo de aprendizaje del actor y reducir su carga de memoria dado que el actor estar familiarizado con esos conceptos. Caractersticas generales de los actores, tales como nivel de expertez (educacin), implicaciones sociales (lenguaje), y edad. Estas caractersticas pueden influenciar detalles de la interfase de usuario, tal como fuente y lenguaje.

Estas caractersticas son utilizadas principalmente cuando se identifican las clases de interfaz y el prototipo, para asegurar la mejor usabilidad entre la comunidad de usuarios y el diseo de interfaz grfica.
Generalizacin de Actores

Una generalizacin de actor de un tipo de actor (descendiente) a otro tipo de actor (ancestro) indica que le descendiente hereda el rol que el ancestro puede jugar en un use case. Varios actores pueden jugar el mismo rol en un use case particular., por ejemplo los actores cobrador y contador heredan las propiedades del Supervisor de balance, dado que ambos controlar el balance de una cuenta.

Un usuario puede jugar varios roles en relacin con el sistema, lo que significa que un usuario puede corresponder a varios actores. Para hacer ms claro el modelo se puede representar al usuario por un actor que hereda a algunos actores. Cada actor heredado representa uno de los roles del usuario relativo al sistema.

Judith Meles

Pgina 12 de 24

Use Cases en el Sistema de Informacin

Modelo de Use Case

Es un modelo que describe los requerimientos del sistema en trminos de use cases. El modelo de use case es un modelo de las funciones esperadas del sistema y de sus alrededores y sirve como un contrato entre el cliente y los desarrolladores. Los use case sirven como un hilo a travs del desarrollo del sistema. El rol ms importante del modelo de use case es comunicar el comportamiento del sistema al cliente o usuario final. Consecuentemente el modelo debe ser fcil de entender.

Cmo evoluciona el Modelo de Use Case?

Tanto los actores como los use cases son encontrados usando los requerimientos de los clientes y potenciales usuarios como informacin vital. Conforme se encuentran, los actores y use case puede ser descriptos brevemente. Antes de describir en detalle los use cases, el modelo de use case debe ser revisado por el cliente para verificar que se han encontrado todos los actores y use cases y que juntos proveen lo que el cliente quiere. Luego se describen en detalle los use case. Estas descripciones muestran cmo el sistema interactan con los actores y lo que el sistema hace en cada caso individual. Finalmente, el modelo completo, incluyendo las descripciones de los use cases) es revisado, y los desarrolladores y clientes lo usan para acordar lo que el sistema debera hacer.

Evitando la descomposicin funcional

Es comn que el modelo de use case degenere en una descomposicin funcional del sistema. Para evitar esto, considere los siguientes sntomas: Use case pequeos, lo que significa que la descripcin del flujo de eventos es solamente una o unas pocas sentencias. Muchos use cases, lo que significa que el nmero de use cases es mltiplo de cien, en lugar de ser mltiplo de diez. Los nombres de los use case que son construcciones como hacer esta operacin en este dato particular.

Para evitar la descomposicin funcional, se debe asegurar que el modelo de use case ayuda a responder cuestiones como: Cul es el contexto del sistema? Por qu se construye el sistema? Qu quiere lograr el usuario usando el sistema? Qu valor agrega el sistema a los usuarios?

Judith Meles

Pgina 13 de 24

Use Cases en el Sistema de Informacin

El dilema del qu versus el cmo

Una de las cosas ms difciles de aprender es determinar a qu nivel de detalle los use cases deberan empezar y terminar. Dnde comienzan las aspectos y se inicia el use case y donde terminan los use cases y empieza el diseo? A menudo se dice que los use case o requerimientos de software deben determinar lo que hace el sistema y no cmo lo hace. Considere lo siguiente:

Dependiendo de las circunstancias, se usar un contexto diferente para decidir lo que se piensa que es el qu y lo que es cmo. Es necesario tomar esto en consideracin para determinar si un cierto detalle debera o no dejarse fuera del modelo de use case.

Use Cases Concretos y Abstractos

Un use case concreto es iniciado por un actor y constituye un flujo de eventos completo. Completo significa que una instancia de un use case ejecuta una operacin entera llamada por un actor. Un use case abstracto nunca se inicia por s mismo. Los use case abstractos son incluidos en, extienden o generalizan otros use cases. Cuando un use case concreto es iniciado, se crea una instancia de use case. Por lo tanto, no se crean instancias separadas de desde los use cases abstractos. La distincin entre los dos es importante, debido a que en los use case concretos los actores vern e iniciarn el sistema.

Judith Meles

Pgina 14 de 24

Use Cases en el Sistema de Informacin

En el grfico de ejemplo, el use case Crear Tarea nunca es ejecutado por s mismo, siempre es parte de Registrar Orden. Crear Tarea es por lo tanto un use case abstracto.

Estructurando el Modelo de Use Case

Hay tres razones principales para estructurar el modelo de use cases: Para hacer a los use cases ms fciles de entender. Para particionar comportamiento comn descripto en muchos use cases. Para hacer el modelo de use case ms fcil de mantener.

No hay forma de estructurar los use cases hasta que no se sabe un poco ms de su comportamiento, adems de una breve descripcin. Al menos se deber tener una descripcin un poco ms amplia para asegurar que las decisiones estn basadas en una comprensin suficientemente adecuada del comportamiento. Para estructurar use case se tienen tres clases de relaciones. El use case que representa la modificacin es llamado use case adicional. El use case modificado es llamado use case base. Si hay parte de un use case base que representa una funcin de la cual el use case solo depende del resultado, no del mtodo usado para producirlo, se la puede factorizar en un use case adicional. La adicin es explcitamente insertada en el use case base, usando una relacin de inclusin. Si hay una parte del use case base que es opcional, o no es necesaria para comprender el propsito principal del use case, se la puede extraer en un use case adicional para simplificar la estructura del use case base. La adicin es insertada implcitamente en el use case base, usando una relacin de extensin. Si hay use cases que tienen comportamiento y estructura comunes y similaridades en el propsito, las partes comunes pueden factorizarse a un use case base (padre) que es heredado por los use cases adicionales (hijos). Los use cases hijos pueden insertar nuevo comportamiento y modificar el existente en la estructura que heredan del use case padre.

Judith Meles

Pgina 15 de 24

Use Cases en el Sistema de Informacin

La siguiente tabla muestra una comparacin ms detallada de las tres relaciones entre use cases:

Pregunta

Extensin

Inclusin

Generalizacin

Cul es la direccin de El use case adicional El use case base El use case adicional la Relacin? referencia al use case referencia al use case (hijo) referencia al use base. adicional case base (padre). Tiene multiplicidad la Si, del lado del use case No. Si se quiere incluir No. relacin? adicional. el mismo segmento ms de una vez, es necesario que sea establecido en el use case base. Tiene una condicin la Si. relacin? No. Si se quiere expresar No. una condicin en la inclusin es necesario decirlo explcitamente en el use case base. Frecuentemente no, pero puede ser.

Es el use case adicional Frecuentemente si, pero Si. abstracto? no necesariamente. El use case base es La extensin modificado por el implcitamente modifica adicional? el comportamiento del use case base

La inclusin modifica Si el use case base explcitamente el efecto (padre) es instanciado, del use case base. no es afectado por el hijo. Para obtener los efectos de la adicin, el use case adicional (hijo) debe ser instanciado. Junto con las adiciones, Si es abstracto, no. si. No. Junto con el use case base (padre), si.

Tiene que ser el use Si. case base completo y significativo? Tiene que ser el use No. case adicional completo y significativo? Puede el use case Si. adicional acceder a atributos del use case base? Puede el use case base No. El use case base acceder a atributos del debe estar bien formado use case adicional? en ausencia de la adicin.

No. La inclusin es Si, por el mecanismo encapsulada y solo se normal de herencia. ve a s misma. No. El use case base solo conoce a cerca del efecto de la adicin. La adicin est encapsulada. No. El use case base (padre) debe es este sentido estar bien formado en ausencia del adicional (hijo).
Pgina 16 de 24

Judith Meles

Use Cases en el Sistema de Informacin

Otro aspecto para la organizacin del modelo de use case para una mejor comprensin es agrupar los use case en paquetes. El modelo podra organizarse jerrquicamente en paquetes de use cases, con hojas que son actores o use cases.

Estn los use case relacionados siempre a Actores?

La ejecucin de cada use case incluye la comunicacin con uno o ms actores. Una instancia de use case siempre es iniciada con un actor que le pide al sistema que haga algo. Esto implica que cada use case debera tener asociaciones de comunicacin con actores. La razn de esta regla es forzar al sistema a proveer solo la funcionalidad que los usuarios necesitan y nada ms. Tener use cases que nadie requiere es un indicador de que hay algo errneo en el modelo de use case o en los requerimientos. Sin embargo, existen algunas excepciones a esta regla: Si un use case es abstracto (no instanciable separadamente), su comportamiento puede no incluir interaccin con un actor. Un use case hijo en una relacin de generalizacin, puede no tener actor asociado, si el use case padre describe toda la comunicacin con el actor. Un use case base en una relacin de inclusin puede no tener un actor asociado, si el use case de inclusin describe toda la comunicacin con el actor. Un use case que es iniciado de acuerdo a una planificacin, lo que significa que el reloj es el iniciador. El reloj del sistema es un evento interno y el use case no es iniciado por un actor. Sin embargo, por claridad, se puede usar un actor ficticio Tiempo para mostrar como es iniciado el use case en los diagramas de use case.

El examen de la descripcin
La evaluacin de la descripcin del modelo de use case debera: Determinar cuales son los use case principales del sistema (la razn por la que se contruye). Resumir los aspectos tcnicos importantes del sistema. Resumir el entorno del sistema, por ejemplo, plataformas de destino y software existente. Describir cualquier secuencia en la cual los use case son ejecutados normalmente en el sistema. Especificar la funcionalidad que el modelo de use case no maneja.

Judith Meles

Pgina 17 de 24

Use Cases en el Sistema de Informacin

Relaciones de Inclusin
Una relacin de inclusin es una relacin desde un use case base a un use case de inclusin, especificando como el comportamiento definido en el use case de inclusin es explcitamente insertado en el comportamiento definido en el use case base. La relacin de inclusin conecta un use case base con un use case de inclusin. El use case de inclusin es siempre abstracto, y describe un segmento de comportamiento que es insertado en una instancia de use case que est ejecutndose en el use case base. El use case base tiene control de la relacin de inclusin y puede depender del resultado de la ejecucin de la inclusin, pero nunca ni el use case base ni la inclusin pueden acceder a los atributos del otro. La inclusin es en este sentido, encapsulada, y representa comportamiento que puede ser reusado en diferentes use case base. Se puede usar relacin de inclusin para: Factorizar comportamiento de un use case base que no es necesario para la comprensin del propsito primario del use case, slo el resultado de ese comportamiento es importante. Factorizar el comportamiento que es comn para dos o ms use cases.

Ejemplo: en un sistema de cajero Automtico, los use cases Extraccin de Efectivo, Depsito de Efectivo y Transferencia de Fondos, incluyen el use case Identificar Cliente

<<incluye>>

Identificar Cliente
<<incluye>>

<<incluye>>

Extraccin de Efectivo

Depsito de Efectivo

Transferencia de Fondos

Un use case base puede tener mltiples inclusiones. Un use case de inclusin puede incluirse en varios use cases base. Esto no determina una relacin entre los use cases base. Se puede tener mltiples relaciones de inclusin entre los mismos use case base y use case de inclusin en el sentido que la inclusin es insertada en diferentes ubicaciones del use case base. Un use case de inclusin puede a su vez ser base para otra inclusin. Dado que el use case de inclusin es abstracto (en el sentido de que no es instanciable por si mismo) no necesita tener un actor asociado a l. La asociacin de comunicacin con un actor es necesaria nicamente si el comportamiento en la inclusin explcitamente implica interaccin por ejemplo con un actor secundario. Ejecutando la Inclusin El comportamiento de la inclusin es insertado en una ubicacin en le use case base. Cuando una instancia del use case siguiendo la descripcin del use case base alcanza una ubicacin en el use case base donde est definida la relacin de inclusin, seguir la descripcin del use case de inclusin. Una vez que la inclusin es ejecutada, la instancia de use case continuar en el punto del use case base donde haba dejado.

Judith Meles

Pgina 18 de 24

Use Cases en el Sistema de Informacin

La relacin de inclusin no es condicional: si la instancia de use case alcanza la ubicacin del use case base donde est definida la inclusin, esta siempre es ejecutada. Si la instancia de use case nunca alcanza la ubicacin para la cual la relacin est definida, entonces esta no se ejecutar.

Ejemplo de uso Si hay un segmento de comportamiento en un use case donde se puede ver que el use case no es dependiente de cmo se hacen las cosas, pero es dependiente del resultado de esa funcin, se puede simplificar el use case extrayendo este comportamiento en un use case de inclusin. El use case de inclusin puede incluirse en varios use cases base, lo que significa que se permite reusar el comportamiento entre use cases del modelo.

Relaciones de Extensin
Una relacin de extensin es una relacin desde un use case de extensin a un use case base, especificando como el comportamiento definido en el use case de extensin puede ser insertado en el comportamiento definido por el use case base. Es implcitamente insertado en el sentido que la extensin no es mostrada en el use case base. La relacin de extensin conecta un use case de extensin con un use case base. Se define en el use case base, donde insertar la extensin haciendo referencia a los puntos de extensin. El use case de extensin es frecuentemente, abstracto, pero no necesariamente. Se puede usar relacin de extensin para: Mostrar una parte del comportamiento de un use case que es opcional o potencialmente opcional. En este sentido, se separa el comportamiento opcional del obligatorio en el modelo. Mostrar que un subflujo es ejecutado solo bajo ciertas condiciones (algunas veces excepcionales), tales como disparar una alarma. Para mostrar que puede haber un conjunto de segmentos de comportamiento de los cuales uno o varios pueden ser insertados en un punto de extensin de un use case base. El segmento de comportamiento que es insertado (y el orden en el cual es insertado) depender de la interaccin con los actores durante la ejecucin del use case base.

Judith Meles

Pgina 19 de 24

Use Cases en el Sistema de Informacin

La extensin es condicional, lo que significa que su ejecucin es dependiente de lo que ha pasado mientras se ejecuta le use case base. El use case base no controla las condiciones para la ejecucin de la extensinlas condiciones estn descriptas con la relacin de extensin. El use case base es implcitamente modificado por las extensiones. Se puede decir que el use case base define un entorno modular en el cual pueden agregarse las extensiones, pero el use case base no tiene visibilidad de las extensiones especficas. El use case base debe ser completo en s mismo, lo que significa que debera ser comprensible y significativo sin hacer ninguna referencia a las extensiones. Ejemplo:

El use case Hacer Llamada en Conferencia y Mostrar Identificador de Llamada son extensiones del use case base Hacer llamada. Los use case de extensin pueden consistir de uno o ms segmentos de insercin, cada uno de los cuales puede tener caminos alternativos. Estos segmentos de insercin modificar incrementalmente el comportamiento del use case base. Cada segmento de insercin es un use case de extensin que puede insertarse en ubicaciones separadas en el use case base. Esto significa que la relacin de extensin tiene una lista de referencias a puntos de extensin, igual en nmero al nmero de segmentos de insercin del use case de extensin. Cada punto de extensin debe ser definido en el use case base. Un use case base que consiste de varias relaciones de extensin, lo que significa que una instancia de use case puede seguir ms de una extensin durante su ciclo de vida. Un use case de extensin puede extenderse en varios use case base, pero esto no implica una dependencia entre los use cases base. Puede haber mltiples relaciones de extensin entre el mismo use case de extensin y el mismo use case base, insertando el use case de extensin en diferentes ubicaciones del use case base. Esto significa que las diferentes relaciones de extensin necesitan referirse a diferentes punto de extensin en el use case base. Un use case de extensin puede ser base de relaciones de extensin, inclusin o generalizacin. Ejecutando la Extensin Cuando una instancia de use case ejecutando el use case base alcanza una ubicacin donde se ha definido un punto de extensin, la condicin de la correspondiente relacin de extensin es evaluada. Si la condicin es verdadera, la instancia de use case seguir la extensin (o segmento de insercin que corresponda al punto de extensin). Si la condicin de la relacin de extensin es falsa, la extensin no se ejecuta.

Judith Meles

Pgina 20 de 24

Use Cases en el Sistema de Informacin

El use case de extensin puede, como cualquier use case, tener un flujo de eventos normal o base y flujos de eventos alternativos. Cual camino exacto seguir una instancia de use case depende del estado de la instancia y de la interaccin con los actores. Una vez que la instancia de use case ha ejecutado la extensin, continua ejecutando el use case base en el punto donde haba dejado. Un use case de extensin puede tener ms de un segmento de insercin, cada uno relacionado con un punto de extensin en el use case base. Si este es el caso, la instancia de use case volver al use case base y continuar hasta el siguiente punto de extensin especificado en la relacin de extensin. En ese momento se ejecutar el siguiente segmento de insercin del use case de extensin. Esto se repite hasta que el ltimo segmento de insercin ha sido ejecutado. Note que la condicin para la relacin de extensin es controlada nicamente en el primer punto de extensin, si la condicin en verdadera, la instancia de use case deber ejecutar todos los segmentos de insercin.

La multiplicidad de la relacin de extensin restringir el nmero de repeticiones que la extensin completa puede ocurrir. Es importante notar que es la extensin completa la que es repetida (y limitada por la multiplicidad), no solo un segmento de insercin.

Judith Meles

Pgina 21 de 24

Use Cases en el Sistema de Informacin

Relaciones de Generalizacin
Una generalizacin de use case es una relacin desde un use case hijo a un use case padre, especificando como el hijo puede especializar todo el comportamiento y caractersticas descriptas por el padre. Un use case padre puede especializarse en uno o ms use cases hijo que representan formas ms especficas del padre. Ni el padre ni los hijos son necesariamente abstractos aunque el padre en la mayora de los casos lo es. Un hijo hereda todo, estructura, comportamiento y relaciones del padre. El hijo puede modificar los segmentos de comportamiento heredados del padre, con el cuidar de preservar la intencin del padre. Tambin puede agregar comportamiento adicional insertando segmentos de comportamiento en el comportamiento heredado, o declarando relaciones de inclusin y/o extensin. La estructura del padre es preservada por los hijos, en el sentido que todos los segmentos, descriptos como pasos o subflujos del flujo de eventos del padre deben existir en el hijo, pero el comportamiento de estos segmentos de comportamientos pueden ser modificados por el hijo. La generalizacin es usada cuando se encuentran dos o ms use cases que tienen cosas en comn en su comportamiento, estructura y propsito. Cuando esto ocurre, se puede describir las partes en un use case nuevo, a menudo abstracto, que es entonces especializado por los use cases hijo. Ejemplo:

Los use cases Orden Telefnica y Orden por Internet son especializaciones del use case abstracto Tomar Orden. Si el use case padre es abstracto, puede tener segmentos de comportamiento incompletos. Los hijos debern entonces completar aquellos segmentos y hacerlos significativos para el actor. Un use case padre no necesita tener una relacin con un actor si es un actor abstracto. Ahora bien, si se desea agregar un empleado de registracin de rdenes que acte como cliente e inicie el use case Tomar Orden, en ese caso el use case Tomar Orden sera concreto y debera tener un flujo

Judith Meles

Pgina 22 de 24

Use Cases en el Sistema de Informacin

completo descripto para l.. Los use cases hijo pueden agregar comportamiento a la estructura que el use case padre provee y tambin modificar el comportamiento del padre.

Si dos use cases son especializaciones del mismo padre, las especializaciones son independientes unas de otras, lo que significa que son ejecutadas en instancias de use case separadas. Tanto la relacin de generalizacin como la de inclusin pueden usarse para reusar comportamiento entre los use case del modelo. La diferencia es que con los use case de generalizacin, la ejecucin del hijo es dependiente de la estructura y comportamiento del padre (la parte reusada), mientras que en una relacin de inclusin la ejecucin de un use case base depende solo del resultado de la funcin que el use case de inclusin (la parte reusada) realiza. Otra diferencia es que en una generalizacin el hijo comparte similaridades en propsito y estructura, mientras que en la relacin de inclusin los use cases base que estn reusando la misma inclusin pueden tener propsitos completamente diferentes, pero necesitan que la misma funcin sea ejecutada. Ejecutando el Use Case de Generalizacin Una instancia de use case ejecutando un use case hijo seguir el flujo de eventos descripto en el use case padre, insertando comportamiento adicional y modificando comportamiento como est definido en el flujo de eventos del use case hijo.

Judith Meles

Pgina 23 de 24

Use Cases en el Sistema de Informacin

En general, no se describe la relacin de generalizacin, en cambio, en el flujo de eventos del use case hijo, se especificar como se insertan los nuevos pasos en el comportamiento heredado, y como el comportamiento heredado es modificado.

Judith Meles

Pgina 24 de 24