DIAGRAMAS DE CASOS DE USO.pdf

14/08/14

DIAGRAMAS DE CASOS DE USO

CAPITULO 17 DIAGRAMAS DE CASOS DE USO

EN ESTE CAPÍTULO CAPÍTULO Modelando el contexto contexto de una una sistema si stema Modelando las necesidades de un sistema Ingeniería hacia delante e inversa.

Los diagramas de caso de uso son uno de los cinco tipos de diagramas en UML para modelar aspectos dinámicos de si stemas (diagramas (diagramas de actividad, diagramas de estados, diagramas de secuencia y diagramas de colaboración son otros cuatro tipos de diagramas en UML para modelar los aspectos dinámicos de un sistema). Los diagramas de casos de uso son importantes para modelar mode lar el comportamiento de un sistema, un subsistema o una una clase. C ada uno muestra un conjunto de casos de uso, actores y sus relaciones. Se aplican los diagramas de casos de uso para modelar las vistas de casos de uso de un sistema. sis tema. Para la mayor parte, esto involucra involucra el modelado el contexto contexto de un sistema, sis tema, subsistema, o clase, o modelar las necesidades del comportamiento de esos elementos. Los diagramas de casos de uso son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. elemento. Ellos hacen sistemas, sis temas, subsistemas, y clases entendibles entendibles para presentar una una vista exterior de cómo estos es tos elementos pueden ser usados dentro del contexto. contexto. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingen i ngeniería iería hacia adelante y para comprender sistemas sis temas ejecutables a través través de ingeniería inversa.

INICIANDO Supongamos que alguien nos entrega una caja. Sobre un lado de esta caja, hay algunos botones y un un pequeño pequeño panel pa nel LCD. La caja no tiene descripción descrip ción y no no sabemos sab emos como se s e usa. Pudimos aleatoriamente presionar los botones, pero has estado presionando os botones para saber que hace la caja o como se s e usa apropiadamente; apropi adamente; esto lo sabrás inv i nvirtiendo irtiendo mucho mucho tiempo en prueba prueba y error.

www.mcc.unam.mx/~ cur sos/Objetos/Cap17/cap17.html

1/9

14/08/14


Con UML, aplicas los diagramas de casos de uso para visualizar el comportamiento de un sistema, subsistema, o clase para que los usuarios puedan comprender como usar ese elemento, y por tanto que los desarrolladores puedan implementar esos elementos. Como muestra la figura 17-1, puedes proveer diagramas de casos de uso para modelar el comportamiento de esta caja – la cual puede llamarse teléfono celular.

FIGURA 17.1

www.mcc.unam.mx/~cursos/Objetos/Cap17/cap17.html

2/9

14/08/14


TERMINOS Y CONCEPTOS Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones.

PROPIEDADES COMUNES Un diagrama de casos de uso es simplemente un tipo especial de diagrama que comparten propiedades comunes con otros diagramas – un nombre y un contenido gráfico que estan dentro de un modelo. Lo que distingue un diagrama de casos de uso de los otros tipos es su particular contenido.

CONTENIDO Los diagramas de casos de uso comúnmente contienen: Casos de uso Actores Dependencias, generalización, y relaciones de asociación.

Igual que todos los diagramas, los casos de uso pueden contener notas y restricciones.

USOS COMUNES Se aplican los diagramas de casos de uso para modelar la vista estática de los casos de uso de un sistema. Esta primera vista soporta el comportamiento de un sistema – el alejamiento de los servicios visibles que el sistema provee en el contexto del medio ambiente. Cuando modelas la vista estática de un caso de uso de un sistema, podrás típicamente aplicar www.mcc.unam.mx/~cursos/Objetos/Cap17/cap17.html

3/9

14/08/14


diagramas de casos de uso de dos maneras diferentes:

1. Modelar el contexto de un sistema.

Modelar el contexto de un sistema implica dibujar una línea alrededor del sistema completo y afirmando con actores fuera del sistema e interactuando con este. Aquí podrás aplicar los diagramas de casos de uso para especificar los actores y el manejo de sus roles.

2. Modelar las necesidades de un sistema.

Modelar los requerimientos de un sistema implica especificar que es lo que hará el sistema (desde un punto de vista fuera del sistema), independientemente de cómo el sistema lo hará. Pudimos aplicar diagramas de casos de uso para especificar el comportamiento deseado del sistema. De esta manera, un diagrama de casos de uso nos da una vista del sistema completo como una caja negra; puedes ver que hay fuera del sistema y puedes ver como el sistema reacciona a cosas de fuera, pero no puedes ver como el sistema trabaja en su interior.

TÉCNICAS COMUNES DE MODELADO MODELANDO EL CONTEXTO DE UN SISTEMA Dado un sistema – cualquier sistema- algunas cosas pueden vivir dentro de este, y otras vivir fuera de este. Por ejemplo, en un sistema de validación de tarjeta de crédito, puedes encontrar algunas cosas como cuentas, transacciones, y agentes de detección de fraude dentro del sistema. Similarmente, podrás encontrar cosas como clientes de tarjeta de crédito e instituciones de venta fuera del sistema. Las cosas que viven dentro del sistema son responsables para llevar al exterior el comportamiento que suponen el sistema proporciona. Todas estas cosas en el exterior que interactuan con el sistema constituye el contexto del sistema. Este contexto constituye el medio ambiente en el cual el sistema vive. En UML, puedes modelar el contexto de un sistema con un diagrama de casos de uso, enfatizando los actores que rodean el sistema.

Para modelar el contexto de un sistema, Identificar los actores que rodean el sistema considerando cuales grupos requieren ayuda www.mcc.unam.mx/~cursos/Objetos/Cap17/cap17.html

4/9

14/08/14


del sistema para ejecutar sus tareas; cuales grupos son necesarios para ejecutar las funciones del sistema; cuales grupos interactuan con hardware externo u otros sistemas de software; y cuales grupos ejecutan funciones secundarias para administración y mantenimiento. Organizar actores que son similares a algún otro en una herencia generalización/especificación. Poblar un diagrama de casos de uso con estos actores y especificar el curso de la comunicación desde cada actor hacia los casos de uso del sistema.

FIGURA 17-2

Por ejemplo, la figura muestra el contexto de un sistema de validación de tarjeta de crédito, con un énfasis sobre los actores que rodean al sistema. Puedes encontrar Clientes, de los cuales hay dos tipos ( Clientes individuales y Clientes corporativos). Estos actores tienen los roles que lo humanos juegan cuando interactuan con el sistema. En este contexto, hay actores que representan otras instituciones, como son Institución de venta ( con el cual un Cliente ejecuta una transacción para comprar un artículo o un servicio) e Institución Financiera Patrocinadora. En el mundo real, estos últimos dos actores son parecidos a los sistemas de software-intensivo. Esta misma técnica se aplica para modelar el contexto de un subsistema. Un sistema en un nivel de abstracción es frecuentemente un subsistema de un gran sistema en un alto nivel de abstracción. Modelando el contexto de un subsistema es útil cuando estas construyendo sistemas de sistemas interconectados.


5/9

14/08/14


MODELANDO LAS NECESIDADES DEL SISTEMA. Un requerimiento es una característica de diseño, atributo, o comportamiento de un sistema. Con las necesidades de un sistema, se acuerda un pacto establecido entre las cosas fuera del sistema y el sistema por si mismo, cuando se declara que se espera que el sistema realice. En la mayor parte no se cuida como el sistema lo hace, solo se cuida que es lo que hace. Cuando se construye un sistema es importante iniciar con acuerdos acerca de que es lo que hará el sistema, aunque se podrá desarrollar el entendimiento de esos requerimientos conforme iterativa e incrementalemente se desarrolle el sistema. Los requerimientos pueden ser expresados en varias formas, desde texto hasta expresiones en un lenguaje formal, y cualquier cosa entre ellos. Muchos si no todos, de los requerimientos funcionales de un sistema pueden ser expresados como casos de uso, y los diagramas de casos de uso UML son esenciales para manejar estos requerimientos.

Para modelar los requerimientos de un sistema. Establecer el contexto de un sistema para identificando los actores que lo rodean. Para cada actor, considerar el comportamiento que se espera o necesita el sistema proporcione. Nombrar los comportamientos comunes como casos de uso. Modelar casos de uso, actores y sus relaciones en un diagrama de casos de uso. Adornar los casos de uso con notas.

La figura se expande sobre el diagrama de caso de uso anterior. El diagrama es valioso por que ofrece un inicio común para usuarios finales, expertos, y desarrolladores para visualizar, especificar, construir y documentar sus decisiones acerca de las necesidades funcionales del sistema. Por ejemplo, Detectar Fraude es un comportamiento importanete para ambos: una Institución Financiera e Institución de Ventas. Similarmente, Reporte del Estado de una Cuenta es un comportamiento requerido del sistema por varias Instituciones en su contexto. Las necesidades modeladas por el caso de uso Administrador de Red es un poco diferente de todos porque representa un comportamiento secundario del sistema.


6/9

14/08/14


FIGURA 17.3

INGENIERÍA HACIA ADELANTE E INVERSA La mayoría de los diagramas UML, incluyendo clases, componentes, y diagramas de estado, son claros candidatos para ingeniería hacia delante e inversa por que tienen una analogía en código ejecutable. Los diagramas de casos de uso describen como un elemento se comporta, no como es implementado, por esto no se le aplica directamente la ingeniería hacia delante o hacia atrás.

Ingeniería hacia delante. Proceso de transformar un modelo a código a través de un mapeo hacia un lenguaje de implementación. Un diagrama de casos de uso puede aplicársele ingeniería hacia delante para formas de prueba para el elemento para el cual aplica. Cada caso de uso en un diagrama de casos de uso especifica un flujo de eventos ( y variantes de esos flujos ), y estos flujos especifican como se espera se comporte el elemento. Un caso de uso bien estructurado podrá especificar pre y post condiciones que pueden ser usadas para definir un estado inicial para la prueba y las post-condiciones pueden ser usadas para definir un criterio exitoso. Para cada caso de uso en un diagrama, se pueden crear pruebas que puedes ejecutar cada vez que se libera una nueva versión del elemento, de este modo se confirma que el elemento trabaja como se necesita antes de confiar otros elementos a él.

Para aplicar ingeniería hacia delante en un diagrama de casos de uso Para cada caso de uso en el diagrama, identificar sus flujos de eventos. Dependiendo de que tan profunda se elija la prueba, generar un guión prueba para cada flujo, usando las precondiciones de flujo como un estado inicial de prueba y las www.mcc.unam.mx/~cursos/Objetos/Cap17/cap17.html

7/9

14/08/14


postcondiciones como criterio de éxito. Generar una prueba para representar cada actor que interactua con el caso de uso. Usar herramientas para correr las pruebas cada vez que se libera el elemento hacia el cual el diagrama de casos de uso aplica.

Ingeniería Inversa. Es el proceso de transformar código hacia un modelo a través de un mapeo desde un lenguaje específico de implementación. Automáticamente la ingeniería inversa en un diagrama de caso de uso esta mucho más allá del esto del arte. Simplemente por que hay una pérdida de información cuando se cambia de una especificación de cómo un elemento se comporta hacia como es implementado. Sin embargo, se puede estudiar el sistema existente y entender el comportamiento a mano; esto será lo que se colocará en forma de diagrama de casos de uso.

Para aplicar ingeniería inversa Identificar cada actor que interactua con el sistema. Para cada actor, considerar la manera en la cual el actor interactua con el sistema, cambia el estado del sistema o su medio ambiente, o responde a algún evento. Trazar el flujo de eventos en el sistema ejecutable relativo a cada actor. Iniciar con flujos primarios y después considerar rutas alternativas. Agrupar flujo relacionados declarando su correspondiente caso de uso. Proporcionar estos actores y casos de uso en un diagrama de casos de uso , y establecer sus relaciones.

SUGERENCIAS Cuando se crea un diagrama de casos de uso en UML, recuerda que cada diagrama de caso de uso es solo una presentación gráfica de la vista estática de un caso de uso de un sistema. No un simple diagrama de casos de uso necesita capturar cada cosa en la vista de casos de uso de un sistema. Colectivamente, todos los diagramas de casos de uso de un sistema representan la vista estática del sistema completo; individualmente , representan solo un aspecto.

Para una buena estructura de diagramas de casos de uso.

La estructura es enfocada sobre un aspecto de comunicación de la vista de un caso de uso de un sistema estático. Contiene solamente casos de uso y actores que son escenciales para entender el aspecto. Provee detalles de consistencia con los niveles de abstracción; exponiendo solo adornos que son esenciales para el entendimiento. www.mcc.unam.mx/~cursos/Objetos/Cap17/cap17.html

8/9

14/08/14


Cuando se dibuja un diagrama de casos de uso. Utilizar nombres representativos. Etiquetar los elementos con un mínimo de líneas cruzadas. Usar notas y colores para dibujar partes destacadas del diagrama. No demostrar demasiados tipos de relaciones. En general, si se incluyen complicadas y extensas relaciones, tomar esos elementos en otro diagrama.


9/9

DIAGRAMAS DE CASOS DE USO.pdf

Recommend Documents