sábado, 14 de diciembre de 2013

Diagramas de casos de uso - Parte 2 de 2





Diagramas de casos de uso en el proceso de análisis

Con el ejemplo dado y con el cual ha trabajado, aplicó directamente la simbología del caso de uso. Ahora nos regresaremos un poco y colocaremos los casos de uso en el contexto de un esfuerzo de análisis.

Las entrevistas al cliente deberán iniciar el proceso. Estas entrevistas producirán diagramas de clases que fungirán como las bases de su conocimiento para el dominio del sistema (el área en el cual resolverá los problemas). Una vez que conozca la terminología general del área del cliente, estará listo para hablar con los usuarios.

Las entrevistas con los usuarios comienzan en la terminología del dominio, aunque deberán alternarse hacia la terminología de los usuarios. Los resultados iniciales de las entrevistas deberán revelar a los actores y casos de uso de alto nivel que describirán los requerimientos funcionales en términos generales. Esta información establece los confines y ámbito del sistema.

Las entrevistas posteriores con los usuarios profundizarán en estos requerimientos, lo que dará por resultado modelos de casos de uso que mostrarán los escenarios y las secuencias detalladamente. Esto podría resultar en otros casos de uso que satisfagan las relaciones de inclusión y extensión. En esta fase, es importante confiar en su comprensión del dominio (a partir de los diagramas de clases derivados de las entrevistas con el cliente). Si no comprende adecuadamente el dominio, podría crear demasiados casos de uso y demasiados detalles (situación que podría, definitivamente, obstaculizar el diseño y el desarrollo).


Aplicación de los modelos de caso de uso

Para ayudarle a comprender con más profundidad los modelos de casos de uso y cómo aplicarlos, vamos a ver un ejemplo más complejo que una máquina de gaseosas. Suponga que deberá diseñar una red de área local (LAN) para una firma de consultoria, y que tendrá que comprender la funcionalidad para poder crearla. ¿Como empezana?

Una LAN es una red de comunicaciones que una organización utiliza en un ámbito limitado. Permite a los usuarios compartir recursos e información.


Comprensión del dominio

Empecemos con las entrevistas al cliente para crear un diagrama de clases que refleje cómo es la vida en el mundo de la consultoría. El diagrama de clases podría incluir las siguientes clases: Consultor, Cliente, Proyecto, Propuesta, Datos e Informe. La siguiente figura le muestra la forma en que podría lucir el diagrama.

Un diagrama de clases para el mundo de la consultoría.

Comprensión de los usuarios

Ahora que el dominio está a la mano, vuelva su atención a los usuarios debido a que el objetivo será entender los tipos de funcionalidad por crear en el sistema.

En el mundo real, entrevistaría a los usuarios. En este ejemplo, basará sus ideas en cierto conocimiento general de las LANs y del dominio. No obstante, tenga presente que en el análisis de sistemas del mundo real, nada puede sustituir a las entrevistas con las personas.

Un grupo de usuarios serán consultores, otros podrían ser oficinistas. Entre otros usuarios en potencia se encontrarán funcionarios corporativos, vendedores, administradores de red, administradores de oficina y administradores de proyectos. (¿Se le ocurren otros?) 

En este punto, sería conveniente a mostrar a los usuarios en una jerarquía de generalización, como se observa en la siguiente figura.


Comprensión de los casos de uso


¿Qué hay de los casos de uso? Hay algunas posibilidades: “Establecer niveles de seguridad”, “Crear una propuesta”, “Almacenar una propuesta", “Utilizar correo electrónico", “Compartir información de la base de datos”, “Realizar la contabilidad”, “Conectarse a la LAN desde fuera de ella", “Conectarse a Internet", “Compartir información de la base de datos”, “Indizar las propuestas”, “Utilizar propuestas previas” y “Compartir impresoras". De acuerdo con esta información, la figura siguiente le muestra el diagrama de casos de uso de alto nivel que hemos generado.

La jerarquía de usuarios que interactuarán con la LAN.
Este conjunto de casos de uso constituye los requerimientos funcionales de la LAN.


Profundización

Elaboremos uno de los casos de uso de alto nivel y generemos un modelo de caso de uso.
Una actividad extremadamente importante en una firma de consultoría es la generación de propuestas, así que examinemos el caso de uso “Crear una propuesta”.


Las entrevistas con los consultores probablemente le indicarán cuántos pasos se necesitan en este caso de uso. Para empezar, el actor inicial es un consultor. El consultor tiene que iniciar una sesión en la LAN y ser verificado como usuario válido. Luego tendrá que utilizar algún software integrado para oficina (procesador de textos, hoja de cálculo y gráficos) para escribir la propuesta. En el proceso, el consultor podría volver a utilizar porciones de propuestas previas. La firma de consultoría podría tener una directiva de que un funcionario corporativo y otros dos consultores revisen una propuesta antes de que llegue a manos del cliente. Para ello, el consultor almacena la propuesta en un área central accesible mediante la LAN, y envía a los correos electrónicos de los tres revisores un mensaje que indique que la propuesta se encuentra lista, así como su ubicación.

Luego de recibir los comentarios y hacer las modificaciones necesarias (nuevamente, con el software integrado para oficina), el consultor imprime la propuesta y la envía por correo al cliente. Cuando todo termina, el consultor se retira de la red. El consultor habrá completado una propuesta y es el actor que se beneficia del caso de uso.

Un diagrama de casos de uso de alto nivel que representa una LAN para una firma de consultoría.

En la secuencia anterior, es claro que ciertos pasos se repetirán de un caso de uso a otro, y ello le llevará a otros casos de uso (posiblemente incluidos) en los que tal vez no había pensado. Iniciar una sesión y ser verificado son dos pasos que pueden incluir varios casos de uso. Por ello, creará un caso de uso “Verificar usuario” que incluya “Crear una propuesta”. Otro par de casos de uso son “Utilizar software de oficina” y “Finalizar sesión de la red”.

Podrían aparecer otros detalles del proceso de una propuesta cuando vea que las propuestas elaboradas para los clientes nuevos son diferentes a las de los clientes constantes. En sí, las propuestas a los nuevos clientes probablemente incluyen información promocional de la empresa. Con los clientes constantes, no será necesario enviar tal información. Así pues, otro nuevo caso de uso, “Crear una propuesta para un cliente nuevo” extenderá a “Crear una propuesta". 

La figura siguiente le muestra el diagrama de casos de uso que resulta de este análisis del caso de uso “Crear una propuesta”.

El caso de uso "Crear una propuesta" en la LAN de una firma de consultoría.

Este ejemplo aterriza un punto importante, uno que había destacado anteriormente: El análisis del caso de uso describe el comportamiento de un sistema. No toca a la implementación. ¡Esto es particularmente importante en este caso, dado que el diseño de una LAN supera, por mucho, el alcance de este libro!


Dónde estamos

Este es un buen momento para verla estructura general del UML dado que ya ha avanzado en dos de sus principales aspectos: la orientación a objetos y el análisis de casos de uso. Ha visto sus fundamentos y simbología, así como explorado algunas aplicaciones.

En las horas 2 a la 7 ha trabajado con:

Clases
Objetos
Interfaces
Casos de uso
Actores
Asociaciones
Generalízaciones
Realizaciones
Agregaciones
Composiciones
Estereotipos
Restricciones
Notas
Paquetes
Extensiones
Inclusiones

Intentemos dividir este conjunto de elementos en categorías.

Elementos estructurales
Las clases, objetos, actores, interfaces y casos de uso son cinco de los elementos estructurales en el UML. Aunque tienen diversas diferencias (mismas que, como ejercicio, deberá indicar), son similares en el sentido de que representan partes ya sea físicas o conceptuales de un modelo. Conforme avance en la parte l, verá otros elementos estructurales.

Relaciones
La asociación, generalización, dependencia y realización, son las relaciones en el UML. (La inclusión y extensión son dos tipos de dependencias.) Sin las relaciones, los modelos UML no serían más que listas de elementos estructurales. Las relaciones conectan a tales elementos y de ese modo conectan los modelos con la realidad.

Agrupamiento
El paquete es el único elemento de agrupamiento en el UML, éste le permite organizar los elementos estructurales en un modelo. Un paquete puede contener cualquier tipo de elemento estructural, y diferentes tipos a la vez. 

Anotación
La nota es el elemento de anotación del UML; éstas le permiten adjuntar restricciones, comentarios, requerimientos y gráficos explicativos a sus modelos.

Extensión
Los estereotipos o clisés son dos estructuras que el UML proporciona para extender el lenguaje. Le permiten crear nuevos elementos además de los existentes, de modo que pueda modelar de fonna adecuada la sección de realidad en la que se centrará su sistema.

..y más
Además de los elementos estructurales, relaciones, agrupamientos, anotaciones y extensiones, el UML cuenta con otra categoría: elementos de comportamiento. Tales elementos le muestran la forma en que las partes de un modelo (como los objetos) cambian con el tiempo. Aún no sabe utilizarlos, pero los verá en la siguiente hora.


El panorama

Ahora ya tiene una idea de la forma en que el UML se organiza. La figura siguiente esquematiza esta organización por usted. Conforme vea las siguientes horas de la parte l, tenga esta organización en mente. Le hará adiciones conforme avance y este “panorama" le mostrará dónde agregar el nuevo conocimiento que adquiera.

La organización del UML, en términos de los elementos que ha utilizado hasta ahora.

Resumen

El caso de uso es una poderosa herramienta para obtener los requerimientos funcionales. Los diagramas de casos de uso agregan mayor poder: debido a que conciben los casos de uso, facilitan la comunicación entre los analistas y los usuarios, y entre los analistas y los clientes. En un diagrama, el símbolo del caso de uso es una elipse. El símbolo de un actor es una figura adjunta. Una línea asociativa conecta a un actor con el caso de uso. Los casos de uso están, por lo general, dentro de un rectángulo que representan el confín del sistema.

La inclusión se representa por una línea de dependencia con un estereotipo «incluir». La extensión se representa por una línea de dependencia con un estereotipo «extender». Las otras dos relaciones entre casos de uso son generalización, en la que un caso de uso hereda el sentido y acciones de otro, y el agrupamiento. mismo que organiza un conjunto de casos de uso. La generalización se representa por la misma línea que muestra la herencia entre clases. El agrupamiento se representa por el icono del paquete. 

Los diagramas de casos de uso figuran con fuerza en el proceso de análisis. Se empieza con entrevistas con los clientes para obtener diagramas de clases. Éstos proporcionan una base para entrevistar a los usuarios. Tales entrevistas dan por resultado un diagrama de casos de uso de alto nivel que muestra los requerimientos funcionales del sistema. Para crear los modelos de caso de uso. profundice en cada caso de uso de alto nivel. Los diagramas resultantes de caso de uso darán los fundamentos para el diseño y desarrollo.

Ahora que ha visto la orientación a objetos y los casos de uso, está listo para ver el panorama del UML. Los elementos que ha aprendido de las horas 2 a 7 se encuentran en estas categorías: elementos estructurales, relaciones, organización, anotación y extensión. En la siguiente hora verá un elemento de la categoría restante: elementos de comportamiento. 
Tenga en mente este panorama para que se le facilite el aprendizaje del UML.


Preguntas y respuestas

P: Me di cuenta que en el diagrama de casos de uso de alto nivel no mostró las asociaciones entre los actores y los casos de uso. ¿A qué se debe?

R: El diagrama de casos de uso de alto nivel surge en las etapas iniciales de las entrevistas con los usuarios. En este punto, esto es más o menos un ejercicio de recopilación de ideas y el objetivo es encontrar los requerimientos generales, ámbito y confines del sistema. Las asociaciones tendrán mayor sentido cuando posteriores entrevistas con los clientes le lleven a profundizar en cada requerimiento y que los modelos de casos de uso tomen forma.

P: ¿Por qué es importante tener en cuenta tal “panorama” del UML? ¿No bastaría con que sepa utilitar cada tipo de diagrama?

R: Si usted comprende la organización del UML, podrá manejar situaciones que no haya encontrado antes. Podrá reconocer cuando un elemento UML existente no haga el trabajo, y sabrá cómo construir uno nuevo. También sabrá cómo crear un diagrama híbrido si llegara a ser la única forma de presentar claramente un modelo.


Taller

En este taller continuará con el conocimiento obtenido en la hora 6 y lo usará como base para el conocimiento de la hora 7. El objetivo es utilizar su nuevo conocimiento para concebir los casos de uso y sus relaciones. Las respuestas aparecen en el Apéndice A, “Respuestas a los cuestionarios".


Cuestionario

l. Mencione dos ventajas de concebir un caso de uso.

2. Describa la generalización y el agrupamiento, las relaciones entre los casos de uso que ha visto durante esta hora. Mencione dos situaciones en las que usted agruparía los casos de uso.

3. ¿Cuáles son las similitudes entre las clases y los casos de uso? ¿Cuáles las diferencias?


Ejercicios

l. Bosqueje el diagrama de un modelo de caso de uso para un control remoto de una televisión. Asegúrese de incluir todas las funciones del control remoto como casos de uso para su modelo.

2. En el segundo ejercicio de la hora 6 indicó a los actores y casos de uso de un almacén de cómputo. Esta vez, dibuje un diagrama de casos de uso de alto nivel con base en el trabajo que realizó en tal ejercicio. Luego, genere un modelo de caso de uso para al menos uno de los casos de uso de alto nivel. En su trabajo, intente incorporar las relaciones «incluir» o «extender» que sean necesarias.


Espero haber ayudado en algo. Hasta la próxima oportunidad!






No hay comentarios:

Publicar un comentario en la entrada