Guia Modelado Casos de Uso

Gua de Modelado de Casos de Uso Versin 1.
Gua Modelado Caso de Uso
REVISIN HISTRICA
Fecha 17/06/2004 Versin 1.0 Descripcin Versin inicial del documento Autor Jos Luis Crcamo y Cecilia Collazo
Catedral 1284, Santiago, Chile Fono: (56-2) 632 1240, Fax: (56-2) 696 5999 www.synapsis-it.com
TABLA DE CONTENIDOS
1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Referencias 1.4 Resumen Pautas Generales para el Modelado de Casos de Uso 2.1 Estilo General 2.2 Uso de << Communicates>> 2.3 Uso del <<Include>> y <<Extend>> en las relaciones 2.3.1 Uso de la relacin de inclusin: <<Include>> 2.3.2 Uso de la relacin de extensin: <<Extend>> 2.4 Generalizacin de Actores Cmo describir un Caso de Uso 3.1 Introduccin 3.2 Actores 3.2.1 Para Cada Caso de Uso concreto existir por lo menos un Actor 3.2.2 Nombre del Actor intuitivo y descriptivo 3.2.3 Uso consistente del nombre del Actor 3.3 Nombre del Caso de Uso 3.4 Caso de Uso: Breve descripcin 3.4.1 Al menos un prrafo 3.5 Uso de Glosario de Trminos 3.6 Prrafos separados por Actor y conducta del sistema 3.7 Flujos Alternativos 3.8 Pre-condiciones y Post-condiciones 3.9 Definicin y referencia a especificaciones suplementarias 3.10 Flujos excepcionales o alternativos 3.10.1 Qu puede salir mal? Actor 4.1 Estereotipo 4.2 Sntesis 4.3 Explicacin 4.3.1 Cmo encontrar Actores 4.3.2 Los Actores ayudan a definir los lmites del sistema 4.3.3 Breve Descripcin
2.
3.
4.
5 5 5 5 5 5 5 5 6 6 6 6 7 7 7 7 7 8 8 8 8 8 8 9 9 9 9 10 10 10 10 10 11 12 13
3
5. 6.
4.3.4 Caractersticas del Actor 4.4 Generalizacin 4.4.1 Introduccin 4.4.2 Estereotipo 4.4.3 Explicacin 4.4.4 Utilizacin 4.5 Extend 4.5.1 Introduccin 4.5.2 Problemas comunes 4.5.3 Estereotipo 4.5.4 Explicacin 4.6 Include 4.6.1 Introduccin 4.6.2 Estereotipo 4.6.3 Explicacin 4.6.4 Ejecucin de Inclusin 4.6.5 Describiendo la relacin 4.6.6 Ejemplo de uso Reglas de Negocio Pautas para completar el UCS segn su criticidad
14 15 15 15 15 16 16 16 17 17 17 19 19 19 19 21 21 22 23 26
GUA DE MODELADODE CASOS DE USO

1. 1.1 INTRODUCCIN Propsito El propsito de esta gua es asegurar la consistencia del Modelo de Casos de Uso y proveer un resumen de la bibliografa disponible sobre cmo documentar un Caso de Uso. As tambin, pretende servir de ayuda general a problemticas a menudo encontradas por el analista diseador. 1.2 Alcance La gua abarca los siguientes documentos: Modelo de Casos de uso, Especificacin de Casos de uso, Diagramas de Actividad y Diagramas de Secuencia. 1.3 1.4 Referencias
Buenas prcticas y ejemplos de Casos de Uso
Resumen Esta gua est organizada en dos secciones. La primera describe una forma de modelar los Casos de Uso y la segunda detalla las pautas para el contenido de un Caso de Uso.
2. 2.1
PAUTAS GENERALES PARA EL MODELADO DE CASOS DE USO Estilo General Los Casos de Uso sern documentados utilizando una plantilla o template personalizada para el proyecto.
2.2
Uso de << Communicates>> Una asociacin entre un Actor y un Caso de Uso indica que el Actor y el Caso de Uso se comunican entre s y cada uno puede enviar y recibir mensajes. Esta asociacin se llama Relacin de Comunicacin y se recomienda realizarla de manera uni -direccional. Utilizando esta estrategia de modelado, distinguiremos entre Actores Primarios y Actores Secundarios. Actor Primario El Actor es considerado Primario, cuando en un par Actor-Caso de Uso, el Actor inicia o activa la ejecucin del Caso de Uso. La flecha en la comunicacin apunta hacia el Caso de Uso. Actor Secundario El Actor es considerado Secundario, cuando en un par Actor-Caso de Uso, la comunicacin es iniciada por el Caso de Uso. La flecha en la comunicacin apunta hacia el Actor. La nocin de Actor Primario y Secundario, agrega valor al lector del Modelo de Caso de Uso. Los Actores pueden ser roles representados por individuos o sistemas externos o con los que nuestro sistema necesita comunicarse. Para que el Modelo de Casos de Uso sea legible, se sugiere representar al Actor en su rol de
Catedral 1284, Santiago, Chile Fono: (56-2) 632 1240, Fax: (56-2) 696 5999 www.synapsis-it.com 5
Actor primario (a la izquierda del modelo) y repetir el estereotipo para el Actor en algn rol secundario (a la derecha del modelo). 2.3 Uso del <<Include>> y <<Extend>> en las relaciones En primera instancia, se intenta modelar una solucin sin estas relaciones, pues el mal uso de las mismas, puede aadir complejidad al Modelo de Casos de Uso. En la prctica, lo mejor es evitar inicialmente este tipo de descomposicin y considerar el uso de estas relaciones en una fase posterior del proceso. Estas relaciones pueden ser usadas como: Factor comn de comportamiento: es comn a dos o ms Casos de Uso. (Include). Factor fuera del comportamiento del Caso de Uso: no es necesario para la comprensin del propsito primario del Caso de Uso, slo es importante el resultado. (Extend). Para demostrar que puede haber un sistema cuyo comportamiento se pueda segmentar en uno o varios puntos de extensin. (Extend). Slo deben ser usadas donde agreguen valor, ayudando a simplificar y manejar el Modelo de Casos de Uso. 2.3.1 Uso de la relacin de inclusin: <<Include>> La relacin de inclusin entre Casos de Uso describe un segmento del comportamiento. Esto significa que un Caso de Uso origen incorpora explcitamente el comportamiento de otro Caso de Uso en el lugar especificado. La inclusin se puede ver como que el Caso de Uso base toma el comportamiento del Caso de Uso proveedor. Esta relacin es similar a una subrutina y se utiliza para sacar el factor comn de comportamiento, evitando as repetir varias veces, la descripcin del mismo flujo de eventos. Se representa con el estereotipo <<include>>. 2.3.2 Uso de la relacin de extensin: <<Extend>> La relacin de extensin entre Casos de Uso es una de las relaciones ms difciles de utilizar. La relacin de extensin entre Casos de Uso significa que un Caso de Uso base incorpora implcitamente el comportamiento de otro Caso de Uso en el lugar especificado indirectamente por este ltimo. Esta relacin se puede utilizar para modelar un subflujo separado que slo se ejecuta bajo ciertas condiciones, para modelar un comportamiento opcional del sistema o tambin para varios flujos que se pueden insertar en determinado punto (controlados por la interaccin explcita con un actor). Se representa con el estereotipo <<extend>> 2.4 Generalizacin de Actores La generalizacin de Actores se puede usar para definir mejor los diferentes roles representados por los usuarios del Sistema a desarrollar. Se usa principalmente en aplicaciones con diferentes categoras de usuarios finales o en aquellas aplicaciones que poseen varios sectores de integracin presentando la funcionalidad relevante a cada categora de usuarios, controlando as los derechos de acceso basados en este agrupamiento. Regla: Cada Caso de Uso slo ser iniciado por un Actor. Esta regla puede ser superada por otra, en ese caso el Caso de Uso deber justificar la decisin. Ejemplo: University's Business Domain: Bibliotecaria y Profesor son ejemplos de dos roles existentes (Actores) en el Dominio de la Universidad. Estos roles tienen algunas tareas comunes y algunas
tareas que son propias a su rol. A continuacin se muestra la forma recomendada para modelar este ejemplo.
3. 3.1
CMO DESCRIBIR UN CASO DE USO Introduccin A continuacin se describen reglas y recomendaciones de los elementos que forman el modelo y la especificacin de un Caso de Uso.
3.2 3.2.1
Actores Para Cada Caso de Uso concreto existir por lo menos un Actor En Cada Caso de Uso concreto ser involucrado por lo menos un Actor? S. Un Caso de Uso que no interacta con un Actor es superfluo. Es vlido el uso de mltiples Actores en el Caso de Uso.
3.2.2
Nombre del Actor intuitivo y descriptivo Tienen que tener los Actores nombres intuitivos y descriptivos? S. Pueden los usuarios y clientes entender los nombres? Es importante que los nombres de los Actores correspondan a sus roles. Si esto no es as es necesario cambiarlos.
Debe referirse al modelo del Caso de Uso asegurndose de que se est usando el nombre correcto del Actor para cada Actor involucrado en su Caso de Uso. 3.2.3 Uso consistente del nombre del Actor La especificacin del Caso de Uso se deber escribir utilizando en forma consistente los nombres de los Actores. El nombre del Actor deber ser claro e identificarlo en forma inequvoca. No se refiera en forma general a El Actor, utilice el nombre empleado para identificar o definir al Actor. El nombre del Actor puede ser el rol que deber realizar en el juego de interacciones del sistema. 3.3 Nombre del Caso de Uso El nombre del Caso de Uso debe ser nico, intuitivo y explicativo, para que defina de manera clara e inequvoca el resultado observable de valor del Caso de Uso. Un buen chequeo del nombre del Caso de Uso es consultar a los clientes, representantes comerciales, analistas y desarrolladores, si entienden los nombres y descripciones de los Casos de Usos. Definicin: Se est definiendo un resultado observable de valor desde la perspectiva de los Actores. Cada nombre de los Casos de Uso describir la conducta del soporte del Caso de Uso. El nombre combinar tanto la accin como el elemento clave a ser Accionado. A menudo, ser un verbo simple, en tiempo presente. El Caso de Uso debe nombrarse desde la perspectiva del Actor que activa el Caso de Uso. Ejemplos: Registra un curso, Selecciona un curso. 3.4 3.4.1 Caso de Uso: Breve descripcin Al menos un prrafo El Caso de Uso contendr una breve descripcin. Esta descripcin ser de al menos un prrafo y no ms de tres de longitud. La descripcin contendr una explicacin del propsito, el valor de la proposicin y los conceptos del Caso de Uso. 3.5 Uso de Glosario de Trminos Todos los trminos utilizados en un Caso de Uso, deben ser definidos en el glosario del proyecto. Si un trmino de negocio existe en un Caso de Uso, pero no existe en el glosario, se deber: 1. Agregar el trmino al glosario, incluyendo una breve descripcin (mximo un prrafo). 2. Modificar el trmino en el Caso de Uso, para reflejar el trmino de negocio correcto definido en el glosario. 3.6 Prrafos separados por Actor y conducta del sistema Cada vez que la interaccin entre el Actor y el sistema cambia de enfoque, el segmento de comportamiento siguiente comenzar con un nuevo prrafo o punto del flujo. La frase debe comenzar con El <Actor-nombre> xxxxx, o El sistema xxxx. Siempre declare correctamente el nombre del Actor, evitando utilizar abreviaturas.
3.7
Flujos Alternativos Cada flujo alternativo deber explicar y definir claramente todos los posibles puntos de entrada en el flujo y concluir con todos los posibles puntos de salida del flujo. El flujo alternativo tambin declarar explcitamente el punto de salida y/o el punto de retorno dnde el Actor continuar, siempre que est finalizando o regresando a un paso especfico en el flujo principal. Si el flujo de eventos no resulta til por tener un comportamiento complicado o cuando un slo flujo excede una pgina de impresin en tamao, pueden utilizarse los flujos alternativos para darle claridad y manejar la complejidad. Los flujos alternativos deben ser escritos moviendo un grupo autnomo o de lgica de conducta detallada y haciendo referencia a esta conducta en el ttulo del flujo.
3.8
Pre-condiciones y Post-condiciones La especificacin del Caso de Uso incluir un juego de condiciones, que se espera sean cumplidas antes de comenzar el Caso de Uso (pre-condiciones) y despus de que el Caso de Uso finalice (post-condiciones). Los Casos de Uso pueden finalizar de varias maneras y cada postcondicin puede ser descripta en forma acorde.
3.9
Definicin y referencia a especificaciones suplementarias Los requerimientos suplementarios son requerimientos adicionales que no pueden describirse naturalmente durante el flujo de eventos. Aquellos que son especficos para un Caso de Uso, se definirn en la seccin de requerimientos especiales de la especificacin del Caso de Uso. Los requerimientos que son aplicables system-wide, especialmente aquellos no funcionales, sern definidos en uno o ms documentos de Especificaciones Suplementarias. Ejemplos: Confiabilidad: El Sistema debe estar disponible 7 x 24 hs. El Sistema debe correr por 48 hrs. Performance: El Sistema debe proveer una respuesta on-line que no debe exceder los 5 segundos bajo condiciones normales.
3.10
Flujos excepcionales o alternativos A continuacin, se enumeran algunas pautas para encontrar flujos de excepcin:
3.10.1 Qu puede salir mal? Para cada paso en el Caso de Uso, se debe considerar qu puede salir mal. Cada excepcin debe ser considerada como un flujo alternativo. En algunos Casos un solo flujo bsico o principal ser suficiente para el Caso de Uso. Ejemplo Time out. La informacin importante a capturar del requerimiento es cuando la excepcin ocurre, es decir, qu experiencia tienen los Actores cuando sucede una excepcin. 4. 4.1 ACTOR Estereotipo
4.2
Sntesis Una instancia del Actor es algo o alguien fuera del sistema que interacta con el mismo. Una Clase de Actor, define un juego de instancias del Actor, en donde el Actor ejecuta el mismo rol en relacin con el sistema.
4.3
Explicacin Para entender completamente el propsito del sistema, se debe conocer para quin es el sistema, qu es, quin lo usar. Los diferentes tipos de usuarios se representan como Actores. Un Actor es algo que intercambia datos con el sistema. Un Actor puede ser un usuario, un hardware externo, otro sistema o una componente interna de Heracles. La diferencia entre un Actor y un usuario individual del sistema es que un Actor representa una Clase particular de usuario en lugar de un usuario real. Varios usuarios pueden jugar el mismo rol, lo que significa que cada uno de ellos puede ser un Actor y particularmente el mismo Actor. En ese caso cada usuario constituye una instancia del Actor.
Ivan yMark son operadores de una mquina recicladora. Cuando ellos estn usando la mquina, cada uno es representado por una instancia del Actor Operador.
Sin embargo, en algunas situaciones, el rol modelado por un Actor es ejecutado por una sola persona. Por ejemplo, en un Sistema pequeo, una sola persona puede ejecutar el rol de administrador de sistemas. Un mismo usuario puede actuar como Actor, asumiendo diferentes roles.
Charlie, gerente de depsito, utiliza un sistema de manejo de depsito, pero algunas veces utiliza este mismo sistema con el rol de empleado. 4.3.1 Cmo encontrar Actores
Qu elementos en los ambientes del sistema se convertirn en Actores del Sistema? Comience pensando en los individuos que utilizarn el Sistema. Cmo se los puede categorizar? Es a menudo un buen hbito pensar en unos pocos individuos (dos o tres) y asegurarse de que los Actores que identific cubran sus necesidades. Las preguntas detalladas a continuacin, le sern de utilidad para cuando est identificando Actores: Quin proporcionar, usar o eliminar informacin? Quin utilizar esta funcionalidad? Quin est interesado en un cierto requerimiento? En qu parte de la organizacin es utilizado el sistema? Quin mantendr y realizar el soporte del sistema? Cules son los recursos externos del sistema? Qu otros sistemas necesitarn interactuar con ste? Hay varios aspectos diferentes del ambiente de un sistema que se representarn como Actores separados:
Usuarios que ejecutan las funciones principales del sistema. Ejemplo Para un sistema de manejo de depsito hay varias categoras de usuarios: personal del depsito, administrativos, gerente de depsito. Todas estas categoras, son roles especficos del sistema y cada uno se debe representar como un Actor separado. Usuarios que ejecutan las funciones secundarias del sistema como por ejemplo la administracin del mismo. Ejemplo En una mquina recicladora utilizada para reciclar botellas, latas y cartn, el cliente es el Actor principal. Para l se construy principalmente el sistema. Sin embargo, alguien tiene que manejar la mquina. Este rol es representado por el Actor operador. Hardware externo usado por el sistema. Ejemplo Un sistema de ventilacin que controla continuamente la temperatura de un edificio y mide los datos tomados de censores. El censor es por consiguiente un Actor. Otros sistemas que interactan con el sistema. Ejemplo Un cajero automtico debe comunicarse con el sistema central del banco que mantiene las cuentas bancarias. El sistema central es probablemente externo y debe ser por consiguiente un Actor. En una aplicacin basada en Internet, sus Actores principales sern en cierto sentido annimos. Se debe describir el rol que se espera que ellos desarrollen en su sistema. Ejemplo Sistemas que proveen informacin (como motores de bsqueda), tendrn Actores annimos que accedern a la aplicacin slo para buscar informacin sobre un tema en particular.
4.3.2
Los Actores ayudan a definir los lmites del sistema Al encontrar los Actores tambin se establecen los lmites del sistema que ayudan a conocer y entender el propsito y la magnitud del sistema. Slo aquellos que comunican directamente las necesidades del sistema sern considerados como Actores. Si se incluyen ms roles que stos en el ambiente del sistema, se estar intentando modelar el negocio en el cual el sistema ser utilizado y no el sistema en s mismo.
12
Ejemplo En el sistema de reserva de una aerolnea, qu o quin sera el Actor? Esto depender de, si se est construyendo un sistema de reserva para una aerolnea que ser usado por un agente de viajes que reservar un paquete de pasajes o si se est construyendo un sistema en el que el pasajero podr realizar l mismo la reserva de su pasaje a travs de Internet.
Si se est construyendo un sistema de reservas para una agencia de viajes, el Actor ser el agente de viajes. El pasajero no ser quien logre un objetivo propio a travs del sistema y por consiguiente no ser un Actor.
Si se est construyendo un sistema de reservas pensado para ofrecer el servicio directamente al pasajero, este ltimo ser un Actor. 4.3.3 Breve Descripcin La breve descripcin del Actor debe incluir informacin sobre: A qu o a quin representa el Actor? Por qu se necesita al Actor? Qu intereses tiene el Actor en el sistema? Ejemplo En el Modelo de Caso de Uso de una mquina recicladora, los tres Actores son brevemente descriptos como: Cliente: El cliente recolecta botellas, latas y cartn en la casa y lo lleva al negocio para conseguir un reintegro. Operador: El operador es el responsable del mantenimiento de la mquina recicladora.
13
Gerente: El gerente es el responsable de cuestiones relacionadas con el dinero y los servicios que la tienda brinda a sus clientes. 4.3.4 Caractersticas del Actor Las caractersticas de un Actor podran influir en el desarrollo de un sistema y en particular en cmo se forma visualmente una interface de usuario ptima. Notar que si en Modelo de Anlisis, los trabajadores comerciales corresponden a los Actores, algunas de las siguientes caractersticas pueden haber sido ya capturadas. Las caractersticas del Actor incluyen: El alcance de la responsabilidad del Actor. El ambiente fsico en el cual el Actor usar el sistema. Las desviaciones del caso ideal, en donde el usuario se sienta en una oficina silenciosa y sin distracciones, podran afectar. Por ejemplo: sonidos, tipos de dispositivo de entrada, teclado, touch screen, mouse y hotkeys. El nmero de usuarios representados por este Actor. Este nmero es un factor relevante que determinar la importancia del Actor y la importancia de las partes de la interface de usuario que el Actor utilizar. La frecuencia con que el Actor utilizar el sistema. Esta frecuencia determinar canto (de la interface usuario) se puede esperar que el Actor recuerde entre sesiones. En la mayora de los casos, una estimacin del nmero de usuarios y frecuencia de uso bastar. El desarrollo de la interface de usuario, no se ver afectada por una diferencia entre treinta y cuarenta usuarios pero s por una diferencia entre tres y treinta. Otras caractersticas del Actor incluyen: El nivel de conocimiento del dominio que tiene el Actor. Este nivel ayudar a determinar cunta ayuda especfica de dominio es necesaria y cunta terminologa especifica de dominio ser utilizada en la interface usuario. El nivel de experiencia general en computadoras que tiene el Actor. Este nivel ayudar a determinar el grado de sofisticacin apropiada contra tcnicas de interaccin simplista presentes en la interface usuario. Otras aplicaciones que utilice el usuario. Solicitando los conceptos de las interfaces de usuario de estas aplicaciones, acortaremos el tiempo de aprendizaje del Actor y disminuiremos la cantidad de conceptos que ste deber aprender, dado que el Actor ya se encuentra familiarizado con estos conceptos. Las caractersticas generales del Actor, tanto como el nivel de especializacin (conocimiento), las implicaciones sociales (lenguaje) y la edad. Estas caractersticas pueden influir en detalles de la interface de usuario, como en la letra y el lenguaje. Estas caractersticas se utilizan principalmente cuando identificamos las Clases Boundary o de Interface y el prototipo, para asegurar el ptimo uso entre la comunidad del usuario y el diseo de la interface de usuario.
14
Ejemplo: El siguiente, es un ejemplo de las caractersticas del usuario de correo. El Actor, entre otras cosas, interacta con el Caso de Uso Manage Incoming Mail Messages. El usuario de correo es un usuario de PC experimentado. El ambiente de trabajo del Usuario de correo, es una oficina tpicamente tranquila. La cantidad de usuarios de correo es de 500,000. 4.4 4.4.1 Generalizacin Introduccin Una generalizacin de Actor de un tipo de Actor (el descendiente) a otro tipo de Actor (el padre) indica que el descendiente hereda el rol que el ancestro ejecutaba en el Caso de Uso. 4.4.2 Estereotipo
4.4.3
Explicacin Varios Actores pueden ejecutar el mismo rol en un Caso de Uso. As, un cajero y un contador, verifican ambos, el balance de una cuenta y son vistos como la misma unidad externa por el Caso de Uso que hace la comprobacin. El rol compartido se modela como un Actor, Supervisor de Balance, heredado por los dos Actores originales. Estas relaciones se presentan como generalizacin de Actores.
El Actor cajero y el Actor contador, heredan todas las propiedades de un Supervisor de Balance. As, ambos Actores, pueden actuar como supervisores de balance.
15
4.4.4
Utilizacin Un usuario puede ejecutar varios roles con relacin al sistema y por consiguiente puede corresponder a varios Actores. Para simplificar el Modelo, se puede representar al usuario por un Actor, que hereda a varios Actores. Cada Actor heredado representa uno de los roles de usuarios relativos al sistema. Caso de Uso
4.5 4.5.1
Extend Introduccin Una relacin del tipo extend es una relacin de un Caso de Uso que extiende a un Caso de Uso base, Especificando cmo la conducta definida para el Caso de Uso extendido puede ser insertada en la conducta definida para el Caso de Uso base. Se inserta implcitamente en la conducta del Caso de Uso base. La relacin de extensin entre Casos de Uso es una de las relaciones ms difciles de utilizar. La relacin de extensin entre Casos de Uso significa que un Caso de Uso base incorpora implcitamente el comportamiento de otro Caso de Uso en el lugar especificado indirectamente por este ltimo. Esta relacin se puede utilizar para modelar un subflujo separado que slo se ejecuta bajo ciertas condiciones, para modelar un comportamiento opcional del sistema o tambin para varios flujos que se pueden insertar en determinado punto (controlados por la interaccin explcita con un actor). Se representa con el estereotipo <<extend>>. La relacin de extensin permiten que el use case model explicite y resalte comportamientos significativos que puedan ser agregados al caso de uso base. Las relaciones de extend ayudan a representar y estructurar comportamiento en el caso de uso base de forma tal que el mismo no se complique, ni aglutine comportamiento especfico en sus flujos. Pueden servir para que el caso de uso base no necesite ser enteramente reformulado cuando se agregan funcionalidades. Formalmente UML define a un punto de extensin como un lugar dentro de un caso de uso en el cual una secuencia de acciones de otros casos de uso, pueden ser insertadas. Asociado al punto de extensin se especifican un conjunto de condiciones que cuando se cumplen, producen la ejecucin del caso de uso extendido. Notar que el caso de uso baso no tiene por qu saber acerca del caso de uso que lo est extendiendo. Las relaciones de extend deben reservarse para la insercin de comportamientos agregados y no para comportamientos que son simplemente alternativas o excepciones que pueden no retornar al mismo punto desde el cual fueron disparados. Jacobson establece que estos comportamientos son agregados bajo ciertas condiciones a lo que se especifica en los flujos del caso de uso base y no reemplazan comportamiento existente en el flujo de eventos del caso de uso base. Mas bien extienden al caso de uso para mostrar procesamiento adicional que puede ser necesitado para realizar requerimientos adicionales asociados con el caso de uso pero que no son parte del flujo del caso de uso base. El resto de la ejecucin del caso de uso base es tal como era antes de la extensin y debera ser capaz de mantenerse funcionando correctamente si se quitase la extensin.
16
4.5.2
Problemas comunes Los flujos alternativos contienen comportamientos que fundamentalmente cambian el flujo de eventos en un caso de uso. Esto difiere de la definicin de extend. Modelar un flujo alternativo como un extend no es una alternativa ya que el flujo alternativo no retorna al punto en el cual se dispara. Esto viola la definicin de extend.
4.5.2.1 MODELAR FLUJOS ALTERNATIVOS COMO EXTEND
4.5.2.2 MODELAR EXCEPCIONES O MANEJO DE ERRORES COMO EXTEND
Las condiciones de error del tipo informacin incorrecta o faltante o de errores de negocio (cuenta bancaria con saldo insuficiente) son requerimientos que necesitan ser entendidos y documentados. Una excepcin puede no retornar al flujo del caso de uso base, y si lo hiciese, podra no retornar al punto del flujo en el que se produjo. Esto viola la semntica de caso de uso extend. Solamente podran manejarse excepciones como extend cuando se retorna al mismo punto en que se produjo, aunque conviene usar relaciones de extend para comportamientos felices solamente. 4.5.3 Estereotipo
<<extend>>
4.5.4
Explicacin Considere el siguiente Sistema telefnico:
El Caso de Uso Ubica la llamada en conferencia es una extensin del Caso de Uso Ubica la llamada. En este modelo, una simple representacin de un sistema de telefona familiar, el servicio de llamada bsico es descrito en el Caso de Uso Ubica la llamada. Los pasos del flujo principal de eventos seran as: Flujo Principal 1. El Usuario levanta el telfono.
2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
El sistema emite tono de llamada. El Usuario disca el primer dgito del nmero a llamar. El sistema apaga el tono de llamada. El Usuario ingresa el resto del nmero. El sistema analiza el nmero, determina las direcciones de red del receptor de la llamada. El sistema analiza el nmero, determina la localizacin en la red donde se encuentra el receptor. El sistema determina entonces que se puede establecer un circuito virtual. El sistema hace sonar el telfono del usuario receptor de la llamada y presenta el tono de llamada en curso en el telfono del usuario llamante. El Usuario receptor contesta la llamada. El sistema deshabilita el tono de llamada en curso en el telfono del usuario llamante, cesa de sonar el telfono del Usuario receptor y completa el circuito virtual. El sistema comienza un registro de la facturacin, grabando la hora de comienzo de la llamada, el fin apunta a la finalizacin de la llamada y la informacin del cliente llamante. El Usuario llamante o el Usuario receptor se desconecta de la comunicacin. El sistema graba el tiempo de finalizacin de la llamada y libera todos los recursos requeridos para soportar el circuito virtual.
Para agregar una funcionalidad a este sistema que permitira que el Usuario llamante o el receptor de la llamada, agregue un tercer usuario a la llamada (llamada en conferencia, se necesitar agregar la conducta al flujo de eventos. Una alternativa y la primera que consideraremos, es poner las diferencias directamente en el lugar de llamada. Nosotros podramos modelar estas diferencias utilizando flujos de eventos alternativos. Esta solucin trabaja para los agregados ms simples, donde la funcionalidad agregada no confundir o disimular el significado original del Caso de Uso. La otra alternativa es separar las diferencias en una extensin del Caso de Uso llamada Ubica llamada en conferencia que extiende el Caso de Uso base Ubica llamada. El Caso de Uso Ubica llamada tendr el siguiente agregado: Puntos de Extensin: Ubica la llamada en conferencia ocurrir despus del paso 12. Esto significa que extiende al paso 12.. El Caso de Uso extendido, Ubica llamada en conferencia, podra entonces describirse como:
18
Descripcin El Usuario llamante habilita una llamada en conferencia. Flujo Principal: 1. El Usuario llamante realiza el hang-up, link, o utiliza el botn flash. 2. El sistema genera tres bips cortos que identifican la llamada en conferencia. 3.-14.Estos pasos son idnticos a los pasos 3-1 del Caso de Uso base Ubica la llamada 15. El Usuario llamante es reconectado al Usuario receptor del Caso de Uso Ubica la llamada. Caso de uso extendido Ubica la llamada. Punto de extensin: El sistema comienza un registro de la facturacin, grabando la hora de comienzo de la llamada, el fin apunta a la finalizacin de la llamada y la informacin del cliente llamante. Condiciones de ejecucin Existe otra llamada destinada al Usuario llamante Actores adicionales Usuario receptor Repetir los pasos 3-14 que coinciden con los del Caso de Uso base es indeseable. Una manera de resolver esto es factorizar como un nuevo Caso de Uso de inclusin la parte comn. 4.6 4.6.1 Include Introduccin Una relacin include es una relacin entre un Caso de Uso base y un Caso de Uso de inclusin. Se especifica cmo se defini la conducta para el Caso de Uso de inclusin y se inserta explcitamente dentro de la conducta definida para el Caso de Uso base. 4.6.2 Estereotipo
<<include>>
4.6.3
Explicacin La relacin include conecta un Caso de Uso base a un Caso de Uso de inclusin. Esto describe un segmento del comportamiento que es insertado en una instancia del Caso del Caso de Uso base. El Caso de Uso base tiene el control de la relacin y puede depender del resultado de realizar la inclusin, pero nunca ni el Caso de Uso base ni la inclusin pueden acceder a cada uno de los otros atributos. La inclusin est, en este sentido, encapsulada y representa un comportamiento que puede ser reutilizada en diferentes Casos de Uso. Se debe utilizar la relacin include para: Factores fuera del comportamiento del Caso de Uso base que no son necesarios para el entendimiento del propsito primario del Caso de Uso, slo es importante el resultado del mismo. Factores fuera del comportamiento que son comunes para dos o ms Casos de Uso.
Ejemplo: En un sistema ATM, los Casos de Uso Extrae dinero,Deposita dinero,Transfiere fondos, necesitan incluir cmo el cliente se identifica en el sistema. Esta conducta puede extraerse a un nuevo Caso de Uso de inclusin llamadoIdentifica el cliente. Los Casos de Uso base son independientes del mtodo usado para la identificacin y esto es por consiguiente encapsulado en el Caso de Uso de inclusin. Desde la perspectiva de los Casos de Uso base, no importa si el mtodo para la identificacin es leer una tarjeta magntica bancaria o realizar un escaneo de la retina, slo es importante el resultado de la identificacin del cliente, que es la identidad del cliente. Y desde la perspectiva del Caso de Uso de identificacin del cliente, no importa cmo el Caso de Uso base utiliza la identidad del cliente o qu pas en ellos antes de que se ejecute la inclusin (el mtodo para la identificacin es exactamente el mismo).
En el sistema ATM, el Caso de Uso Extrae dinero, Deposita dinero y Transfiere fondos, todos incluyen el Caso de UsoIdentifica el cliente. Un Caso de Uso base puede tener mltiples inclusiones. Un Caso de Uso de inclusin puede ser incluido en varios Casos de Uso base, sin que exista alguna relacin entre los Casos de Uso base. Se puede tener mltiples relaciones include entre el mismo Caso de Uso y el Caso de Uso base con tal de que la inclusin sea insertada en diferentes puntos del Caso de Uso base. Todos los agregados pueden ser anidados y un Caso de Uso de inclusin puede servir como el Caso de Uso base para otra inclusin. Desde la inclusin un Caso de Uso no necesita tener un Actor asociado. Una asociacin a un Actor slo es necesaria si la conducta en la inclusin explcita incluye interaccin con un Actor Secundario.
20
4.6.4
Ejecucin de Inclusin El comportamiento de la inclusin es insertado en una ubicacin del Caso de Uso base. Cuando una instancia de un Caso de Uso sigue la descripcin de un Caso de Uso base y alcanza una ubicacin en el Caso de Uso en que una relacin include es definida, entonces, seguir con la descripcin del Caso de Uso de inclusin. Una vez que la inclusin es realizada, la instancia del Caso de Uso regresar al punto en donde sali del Caso de Uso base para continuar su ejecucin. Una instancia del Caso de Uso sigue la descripcin de un Caso de Uso base incluyendo esta inclusin. La relacin include no es condicional: si la instancia del Caso de Uso alcanza la ubicacin en el Caso de Uso base para la que se define, esto es siempre ejecutado. Si se quiere expresar una condicin, necesitar hacerla como parte del Caso de Uso base, a travs de un flujo alternativo. Si la instancia del Caso de Uso nunca alcanza la ubicacin para la cual est definida la relacin include, entonces sta no se ejecutar.
La instancia #1 del Caso de Uso alcanza la ubicacin en el Caso de Uso para que la relacin include sea definida y la inclusin sea realizada. La instancia #2 no alcanza esa situacin y la inclusin no se realiza como parte de la instancia. El Caso de Uso de inclusin es un segmento continuo de comportamiento, que est incluido con una ubicacin en el Caso de Uso base. Si tiene segmentos separados de conducta que necesitan ser insertados con ubicaciones diferentes, se debe considerar una relacin del tipo extend o una del tipo generalizacin. 4.6.5 Describiendo la relacin Para la relacin del tipo include, se debe definir la ubicacin dentro de la secuencia de ambiente del Caso de Uso base en donde se insertar la inclusin. La ubicacin puede ser definida refirindose a un paso particular del flujo bsico o un flujo alternativo del Caso de Uso base. Para clarificar, se debe mencionar la inclusin en el texto descriptivo del flujo de eventos del Caso de Uso base.
21
Ejemplo: En un sistema ATM, el Caso de Uso Extrae dinero incluye el Caso de Uso Identifica el cliente. La relacin include, puede ser descripta de la siguiente forma: Flujo bsico o alternativo del Caso de Uso Identifica el cliente El Cliente ingresa el monto a extraer El sistema Identifica el cliente El sistema pregunta la cantidad de dinero a extraer 4.6.6 Ejemplo de uso Si hay un segmento de conducta en un Caso de Uso donde se puede ver que el Caso de Uso no depende de lo que hacen las cosas, pero es dependiente del resultado, se debe simplificar el Caso de Uso extrayendo esta conducta a un Caso de Uso de inclusin. El Caso de Uso de inclusin puede ser incluido en varios Casos de Uso base. Considere el siguiente paso a paso de un Caso de Uso para un sistema telefnico simple: Ubica la llamada 1. El Usuario llamante levanta el telfono. 2. El sistema presenta el tono de llamada. 3. El Usuario llamante ingresa el primer dgito. 4. El sistema apaga el tono de llamada. 5. El Usuario ingresa el resto del nmero. 6. El sistema analiza el nmero y determina la direccin de red del Usuario receptor de la llamada. 7. El sistema establece un circuito virtual entre los dos usuarios. 8. El sistema asigna todos los recursos para el circuito virtual y establece la conexin. 9. El sistema hace sonar el telfono del usuario receptor de la llamada. 10. etc. Comienza el Sistema 1. El Operador activa el sistema. 2. El sistema realiza las pruebas de diagnstico en todos los componentes. 3. El sistema prueba las conexiones y todos los sistemas adyacentes. 4. El sistema establece un circuito virtual entre l y el sistema adyacente. 5. El sistema reserva todos los recursos para el circuito virtual y establece la conexin. 6. El sistema responde que est listo para la operacin. 7. etc Los textos resaltados en azul son muy similares, en ambos casos estamos realizando el mismo comportamiento aunque por razones diferentes. Esta similitud puede ser explotada y se podr extraer el comportamiento comn en un nuevo Caso de Uso Maneja el circuito virtual Una vez extrado el comportamiento comn el Caso de Uso resulta: Ubica la llamada
El Usuario llamante levanta el telfono. El sistema presenta el tono de llamada. El Usuario llamante digita el primer nmero. El sistema apaga el tono de marcado. El Usuario llamante, disca el resto del nmero. El sistema analiza el nmero discado y determina la direccin de red del Usuario receptor de la llamada. 7. El sistema Maneja el circuito virtual para establecer la conectividad con la red. 8. El sistema hace sonar el telfono del Usuario receptor de la llamada. 9. etc. Comienza el Sistema 1. El Operador activa el sistema. 2. El sistema realiza pruebas de todo el sistema. 3. El sistema realiza pruebas de las conexiones con todos los sistemas adyacentes. 4. El sistema Maneja el circuito virtual para establecer la conectividad con la red. 5. El Sistema responde que se encuentra listo para la operacin. 6. etc. En un diagrama de un Caso de Uso la relacin include que es creada ser ilustrada como a continuacin:
1. 2. 3. 4. 5. 6.
El Caso de Uso Ubica la llamada y Comienza el sistema, incluyen ambos la conducta del Caso de Uso Maneja el circuito virtual. 5. REGLAS DE NEGOCIO El artefacto de reglas de negocio pertenece al conjunto de artefactos de la disciplina Business Modeling, las actividades de esta disciplina se llevan a cabo tempranamente en el proceso. A medida que se avanza en el proceso de desarrollo de software, las reglas de negocio deben irse reflejando en los modelos que se vayan creando. Una regla de negocio es una declaracin de polticas o condiciones que deben ser satisfechas. Pueden ser regulaciones impuestas al negocio, pero tambin sirven para expresar la arquitectura de negocio elegida.
La totalidad del problema debiera poder ser expresada en trminos de casos de uso. En general los casos de uso no debieran invocar comportamiento encapsulado en reglas de negocio. Si el comportamiento que se pretende invocar est muy encapsulado, evaluar la posibilidad de escribir un caso de uso que resuelva el comportamiento apuntando a cumplir con un objetivo especfico del sistema (tpicamente casos de uso de validacin). Las reglas de negocio del tipo estmulo respuesta en general pueden ser modeladas como flujos alternativos en un workflow. Para los casos mas complejos, aquellos en los que: la problemtica es mas sencilla de modelar en un diagrama de actividades, podra anexarse este artefacto al caso de uso y escribirse el caso de uso en un nivel de granularidad mas alto. Pueden definirse de este mismo modo las reglas de negocio del tipo reglas de inferencia (ej: un Cliente es un Cliente Cumplidor si y slo si las facturas impagas del cliente tienen menos de 30 das). Ejemplo: Una regla del siguiente estilo: WHEN una Orden es Cancelada IF la Orden an no fue despachada THEN cerrar la Orden. Este tipo de regla de negocio es reflejada mostrando dos caminos alternativos en un workflow, y especificamente, usando una decisin y condiciones ante las cuales se ejecutan las transiciones.
24
Esta regla de negocio se tradujo a un diagrama de actividades. Este diagrama de actividades debiera quedar asociado a un caso de uso. Las reglas de negocio del tipo restriccin, a menudo pueden ser traducidas a precondiciones y postcondiciones, o bien a flujos alternativos. Podran tambin traducirse a un objetivo de performance o a un requerimiento no funcional. Ejemplo: Siempre debe cumplirse que: Todos los reclamos de los clientes deben ser respondidos dentro de las 24 horas de ser recibidos. Esta regla de negocio podra traducirse como un requerimiento no funcional del caso de uso Administra reclamos. Las reglas de negocio del tipo restricciones estructurales afectan las relaciones entre entidades. Deben traducirse en trminos de navegabilidad y restricciones de cardinalidad en modelo de clases de anlisis. Ejemplo: Siempre debe cumplirse que: Una orden tiene por lo menos 1 producto.
Esta regla de negocio se traduce en una asociacin con una multiplicidad de 1..*. Se pretende que en el artefacto de reglas de negocio solamente queden reglas que sean transversales a todos los componentes, de ah el nombre de reglas de negocio. Todas las validaciones que pertenezcan a un caso de uso especfico o que no sean reglas que puedan aplicarse fuera de la componente deben modelarse asociadas a casos de uso. Ejemplos de reglas aplicables a todo el negocio: El rut mdulo 11 da un nmero que debe coincidir con el dgito verificador (10 debe matchear con k).
25
6. PAUTAS PARA COMPLETAR EL UCS SEGN SU CRITICIDAD A continuacin se detallan los campos a completar segn el nivel de criticidad del requerimiento: ATRIBUTO PROPIEDAD Nombre del Caso de Uso Breve Descripcin Flujo Principal Flujo Alternativo Requerimientos no Funcionales Pre-Condicin Post-Condicin Puntos de Extensin Supuestos y dependencias Problemas y comentarios CRITICIDAD MEDIA S S S Obligatoria su identificacin S S S Si corresponde Optativo Optativo
ALTA S S S S S S S Si corresponde Optativo Optativo
BAJA S S No No No No No No Optativo Optativo
26

Guia Modelado Casos de Uso

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Guia Modelado Casos de Uso

Загружено:

Авторское право:

Доступные форматы

Gua de Modelado de Casos de Uso Versin 1.

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

GUA DE MODELADODE CASOS DE USO

Buenas prcticas y ejemplos de Casos de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

4.5.2.1 MODELAR FLUJOS ALTERNATIVOS COMO EXTEND

4.5.2.2 MODELAR EXCEPCIONES O MANEJO DE ERRORES COMO EXTEND

Explicacin Considere el siguiente Sistema telefnico:

Gua Modelado Caso de Uso

2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

Gua Modelado Caso de Uso

ALTA S S S S S S S Si corresponde Optativo Optativo

BAJA S S No No No No No No Optativo Optativo

Вам также может понравиться