MODELO DE CASOS DE USO

Transcripción

1 MODELO DE CASOS DE USO Muestra la funcionalidad del sistema como es percibida por actores externos. Para clientes y equipos de diseño, desarrollo, y prueba. Utiliza: Diagramas de Casos de Uso. Diagramas de Actividad (opcional). Su contenido conduce el proceso de desarrollo y verificación. Sirve para describir las interacciones del sistema con su entorno, identificando: Los Actores, que representan los diferentes roles desempeñados por los usuarios del sistema (Los actores no son solamente humanos, pudiendo ser también otros sistemas con los cuales el sistema en desarrollo interactúa de alguna manera). y los Casos de Uso, que corresponden a la funcionalidad que el sistema ofrece a sus usuarios, explicada desde el punto de vista de éstos. Los Casos de Uso se representan en 2 dimensiones, la primera es gráfica y ahí es cuando se habla de los diagramas de casos de uso. La segunda dimensión (la más importante) es textual y para cada caso de uso identificado hay que escribir una plantilla de casos de uso que puede ser en formato compacto (o de Alto Nivel) y posteriormente en formato extendido. En otras palabras, Modelo de Casos de Uso = Diagramas + Plantillas La siguiente figura muestra un Diagrama de Casos de Uso que describe parcialmente un sistema para la gestión de una biblioteca. El sistema tiene cuatro actores, representados por muñecos: el Lector, el Monitor, el Director y el SI_Administrativo. El primero de ellos (Lector) no interactúa directamente con el sistema en algunos casos de uso, pero se lo incluye para brindar mayor claridad a la descripción de su funcionalidad. 1

2 2

3 Los casos de uso se representan mediante óvalos, y describen lo que el sistema hace para sus usuarios. En el diagrama se muestran los que corresponden a: Las operaciones más relacionadas con el Monitor: Hacer Consulta: Buscar un recurso en la Biblioteca, con opción de reserva. Hacer Reserva: Asignar a un Lector un libro para que pueda retirarlo más tarde. Borrar Reserva: Eliminar la asignación un libro a un Lector. Prestar Ítem: Entregar un recurso a un Lector. Registrar Nuevo Lector: Registrar un nuevo Lector en el sistema y fijar sus atributos. Una operación que corresponde al Director: Gestionar Monitores: Dar de alta y de baja a los Monitores y administrar sus atributos. Una operación común a varios tipos de usuario: Control Acceso: Solicitar y verificar identificación (login) y clave (password). Una operación que corresponde a un actor no humano: Consultar Multas: Obtener información sobre las multas de los Lectores, con el fin de tenerlas en cuenta en las actividades de la administración (contabilidad, certificados de paz y salvo, etc.). Entre los actores y los casos de uso se establecen asociaciones, que se representan mediante una línea sólida e indican cuáles actores participan en un caso de uso. Todo caso de uso tiene siempre un actor (y sólo uno) que lo "dispara", denominado iniciador, siendo conveniente identificarlo en los casos de uso que tienen varios actores, ya sea etiquetando su asociación con la palabra "iniciador", o como en la figura, usando una flecha para representarla. En el caso de uso Registrar Nuevo Lector, está claro que el actor iniciador es el Monitor; el Director también participa en el caso de uso, pero sólo cuando recibe el nuevo carné del Lector, para su firma, luego de que el Monitor ha ingresado toda la información correspondiente. Entre los casos de uso también se pueden establecer relaciones, las cuales son de tres tipos: inclusión, extensión generalización. 3

4 La relación de Inclusión se representa con una flecha de línea discontinua etiquetada con el estereotipo «include». Una relación de Inclusión desde el caso de uso A hacia el caso de uso B, indica que el comportamiento descrito en el caso de uso B es incluido en el caso de uso A. Tal es la situación con el caso de uso Borrar Reserva del ejemplo, que se "ejecuta" cuando un Monitor cancela la reserva porque el Lector ya no requiere un título, y como parte del caso de uso Prestar Ítem, cuando el Monitor entrega un título reservado y debe cambiar su estado de "Reservado" a "Prestado". La relación de Extensión es representada también por una flecha discontinua, etiquetada con el estereotipo «extend». Una relación de Extensión desde un caso de uso C hacia un caso de uso D, indica que el caso de uso D puede incluir (condicionado al cumplimiento de condiciones específicas establecidas en la extensión) el comportamiento del caso de uso C. Esta es la situación para el caso de uso Hacer Consulta, que es extendido por el caso de uso Hacer Reserva cuando el Lector ha encontrado un libro disponible y desea reservarlo: cuando se cumple la condición Lector solicita reserva, Hacer Reserva es una extensión (posibilidad) desde Hacer Consulta. La relación de Generalización desde un caso de uso E hacia un caso de uso F indica que E es una especialización de F. Se representa mediante una flecha con la línea sólida y la cabeza cerrada y vacía (un triángulo), que es la notación de generalización. 4

5 Una vez identificados los actores y los casos de uso en el diagrama, se detallan estos últimos, utilizando una descripción textual aunque para casos de uso más complejos puede usarse un Diagrama de Actividad. La descripción de los casos de uso de un sistema no es homogénea ni en el tiempo ni en el espacio. Su nivel de detalle se incrementa a medida que se avanza en el proceso de desarrollo, y en un momento dado es posible tener un mayor nivel de detalle para ciertos casos de uso, los más críticos, mientras que otros menos importantes se dejan para más tarde. Se proponen dos clasificaciones para los casos de uso, según su nivel de detalle y el nivel de abstracción de su descripción: a) Casos de Uso de Alto Nivel. Describen las interacciones entre los actores y el sistema de manera muy breve, usando dos o tres frases. Se utilizan durante las fases iniciales de captura de requerimientos con el fin de obtener rápidamente una visión de la funcionalidad y el grado de complejidad del sistema. El siguiente ejemplo ilustra el formato para la descripción de los casos de uso de alto nivel: Caso de uso: Actores: Tipo: Descripción: Hacer Reserva Monitor (iniciador) Primario El Monitor solicita al sistema reservar un ítem solicitado por un Lector. El Sistema verifica la información del ítem y del Lector. El Sistema verifica e informa la disponibilidad del ítem solicitado. El Sistema modifica el estado del ítem, asignándolo al Lector. En el campo Actores deben incluirse todos los actores que están asociados al caso de uso, señalando cuál de ellos es el iniciador. El Tipo corresponde a una categoría asignada a los casos de uso dependiendo de su importancia, y que es la base para establecer un orden de prioridad en el momento de planificar su implementación. Los tipos son: - Primario. Representa una interacción principal y común en el sistema. - Secundario. Representa una interacción menor o de rara ocurrencia. - Opcional. Representa una interacción que puede no ser abordada. 5

6 b) Casos de Uso Extendidos. Describen las interacciones con mayor detalle que los de alto nivel, enumerando paso a paso los eventos que se presentan durante una ocurrencia típica del caso de uso. El siguiente ejemplo ilustra el formato para la descripción de los casos de uso extendidos: Información General Caso de uso: Actores: Propósito: Resumen: Tipo: Referencias cruzadas: Hacer Reserva Monitor (iniciador) Asignar a un Lector un libro para que pueda retirarlo más tarde. El Monitor ingresa la información del Lector y del libro solicitado. El Sistema verifica la información del ítem y del Lector, verifica e informa la disponibilidad del libro solicitado, y modifica el estado del ítem, asignándolo al Lector. Primario y abstracto. Requisitos: R1.1, R1.6. Casos de Uso: Control de Acceso, Hacer Consulta. Precondiciones El sistema debe contar con la siguiente información: - Información del Lector: Código, nombre, estado (Activo, Suspendido, etc.). - Información de los libros: Código, título, estado (Disponible, Reservado, etc.). El Monitor debe ejecutar el caso de uso Control de Acceso. Puede iniciarse con el caso de uso Hacer Consulta. Flujo Principal 1. Este caso de uso empieza cuando el Monitor elige en el menú principal del Sistema la opción Reserva. 2. El Sistema presenta al Monitor el Formulario de Reserva de la Figura 1, que solicita el código del Lector y el código del libro a reservar. 3. El Monitor captura total o parcialmente la información de reserva, y selecciona una de las opciones del final del formulario: Aceptar y Cancelar Si elige la opción Aceptar, Subflujo S1: Verificar Lector y Estado de un Libro Si elige la opción Cancelar, Subflujo S2: Cancelar la Reserva de un Libro. Figura 1. Formulario de Reserva. 6

7 Y aquí aparece un concepto clave: el concepto de ESCENARIO. Un caso de uso tiene como instancias los escenarios: situaciones concretas que deben recorrer total o parcialmente el caso de uso. Se deben considerar en lo posible todos los escenarios de modo que se pueda validar el caso de uso. La última comprobación consiste por tanto en asegurar que el caso de uso represente todos los escenarios. A veces se confunde el caso de uso con alguno de sus escenarios: Si aparecen muchos casos de uso puede que sea un síntoma de una mala descripción del sistema. Subflujos S1: Verificar Lector y Estado de un Libro. 1) El Sistema verifica el código del Lector (E1). 2) El Sistema verifica el código del libro solicitado (E2). 3) El Sistema consulta el estado del libro solicitado. 4) Si el libro solicitado está disponible, el Sistema modifica su estado a Reservado, lo asigna al Lector indicado al comienzo, y presenta al Monitor el cuadro de diálogo de la Figura X para informarle del éxito de la operación. Cuando el Monitor elige Aceptar el Sistema regresa al Menú Principal. 5) Si el libro solicitado está reservado o prestado, el Sistema presenta al Monitor el cuadro de diálogo de la Figura Y donde le informa la fecha en la que el libro estará disponible. Cuando el Monitor elige Aceptar el Sistema regresa al Menú Principal. 6) Si el libro solicitado está en proceso por parte del personal de la biblioteca (mantenimiento, clasificación, etc.), el Sistema presenta al Monitor el cuadro de diálogo de la Figura Z donde le informa que el libro está fuera de servicio. Cuando el Monitor elige Aceptar el Sistema regresa al Menú Principal. S2: Cancelar la Reserva de un Libro. 1) El Sistema despliega el mensaje de la Figura 1 solicitando confirmar la cancelación. 2) El Monitor presiona el botón Aceptar. 3) El Sistema regresa al Menú Principal. Flujos de excepción E1: Mensaje de error: código del Lector no es válido. 1) El Sistema despliega el mensaje de error de la Figura W informando que el código del Lector no es válido 2) El Monitor presiona el botón Aceptar. 3) El Sistema regresa al Menú Principal. E2: Mensaje de error: código del libro no es válido. 1) El Sistema despliega el mensaje de error de la Figura Z informando que el código del Libro no es válido 2) El Monitor presiona el botón Aceptar. 3) El Sistema regresa al Menú Principal. 7

8 Algunas observaciones sobre la descripción de los casos de uso extendidos: 1) En la información general, cuando se declaran los actores, debe señalarse cuál es el actor iniciador del caso de uso. 2) En el resumen puede usarse la descripción del caso de uso de alto nivel correspondiente. 3) Las referencias cruzadas indican con cuáles funciones del sistema y otros casos de uso existe relación. Las funciones se nombran utilizando la etiqueta que se les asigna en la Tabla de Funciones del Sistema, elaborada durante la captura de requerimientos. 4) El flujo principal debe comenzar con la frase "Este caso de uso empieza cuando el actor...", mencionando el iniciador. 5) Los Subflujos corresponden a diferentes caminos que sigue la interacción de manera normal. 6) Los flujos de excepción describen situaciones que se salen del funcionamiento normal del sistema. 7) Es conveniente acompañar la descripción con figuras mostrando las interfaces de usuario (GUI, listados, etc.), ya sea como maquetas, en los casos de uso abstractos, o con gráficos capturados en la pantalla y formatos finales de impresión, en los casos de uso reales. Los casos de uso extendidos pueden a su vez clasificarse de acuerdo a su nivel de abstracción, en dos categorías: a) Casos de Uso Abstractos. Describen las interacciones de manera ideal, abstrayendo los detalles de tecnología e implementación, especialmente aquellos relacionados con las interfaces de usuario. b) Casos de Uso Reales. Describen las interacciones en términos de su diseño real, incluyendo los detalles de las tecnologías empleadas en las entradas y salidas. Cuando se utilizan interfaces de usuario, se muestran imágenes capturadas de la pantalla y se discute el manejo de los elementos gráficos. 8

9 Y DE AQUÍ EN ADELANTE, CÓMO HACEMOS? Construcción de Casos de uso. Es un proceso iterativo. Se van descubriendo los escenarios desde el punto de vista del usuario, es decir los ACTORES. Para detectar los casos de uso es conveniente hacer las siguientes preguntas: Cuáles son las principales tareas de cada actor? Escribe/lee/modifica el actor alguna información del sistema? Informa el actor al sistema de los cambios externos? Desea el actor ser informado de cambios no esperados? Los casos de uso no pueden ser demasiado pequeños, ya que deben aportar algún valor al actor. La estructura del sistema debe decidirse teniendo en cuenta a los actores principales. Proceso de elaboración. Identificar a grandes trazos los casos de uso: Las principales etapas de cada caso de uso se describen en un par de frases. Se distingue un caso principal y se identifican los casos alternativos y excepciones. Se debe cuidar que: Exista una descripción breve que represente una real imagen del caso uso. Las condiciones de arranque y parada del caso de uso estén bien definidas. Los usuarios estén satisfechos de la secuencia de interacciones entre el actor y el caso de uso. El problema fundamental es encontrar el nivel de abstracción adecuado. En general si un caso de uso se hace demasiado grande, a medida que se va detallando es conveniente dividirlo en varios. Se pueden hacer preguntas como: Es posible ejecutar un paso de forma independiente a los otros o siempre va encadenado con ellos? Dos pasos que siempre se encadenan forman parte habitualmente del mismo caso de uso. Es lógico agrupar varios pasos para documentarlos, probarlos o modificarlos en conjunto? Si es así, deben formar parte del mismo caso de uso En las próximas páginas veremos algunos ejemplos para generar diagramas de casos de uso. 9

10 2. ALGUNOS EJEMPLOS PARA GENERAR DIAGRAMAS DE CASOS DE USO. EJERCICIO 1. GESTIÓN BÁSICA DE INMUEBLES Una empresa gestiona un conjunto de inmuebles, que administra en calidad de propietaria. Cada inmueble puede ser bien un local (local comercial, oficinas, etc.), un apartamento o bien un edificio que a su vez tiene pisos y locales. Como el número de inmuebles que la empresa gestiona no es un número fijo, la aplicación debe permitir tanto introducir inmuebles nuevos, así como darlos de baja, modificarlos y consultarlos. Asimismo, que una empresa administre un edificio determinado no implica que gestione todos sus apartamentos y locales, por lo que la aplicación también deberá permitir introducir nuevos apartamentos o locales, darlos de baja, modificarlos y hacer consultas sobre ellos. Cualquier persona que tenga una nómina, un aval bancario, un contrato de trabajo o venga avalado por otra persona puede alquilar el edificio completo o alguno de los apartamentos o locales que no estén ya alquilados, y posteriormente desalquilarlo. Por ello, deberán poder ser dados de alta, si son nuevos inquilinos, con sus datos correspondientes (nombre, DNI, edad, sexo,...), poder modificarlos, darlos de baja, consultarlos, etc. La aplicación ofrece acceso web para que un inquilino puede modificar o consultar sus datos, pero no darse de baja o de alta. Para la realización de cualquiera de estas operaciones es necesaria la identificación por parte del inquilino. Alquilar Edificio Alquilar Alquilar Local Alquilar Apartamento Gestor Inmobiliaria Mantener Inquilinos Alta Inquilinos Baja Inquilinos Consulta Inquilinos Des-alquilar Modificación Inquilinos Modificación Vía Web Inquilino Consulta Vía Web <Inc> <Inc> Validar Usuario Figura 1. Diagrama de Casos de uso Ejercicio 1. 10

11 EJERCICIO 2. Gestión Tienda de Productos de Informática. Se desea desarrollar una aplicación que permita gestionar una tienda de productos de informática a través de Internet. Para realizar un pedido, el sistema pregunta al usuario si es la primera vez que hace un pedido, en cuyo caso le pide sus datos personales; de lo contrario, el usuario introduce su nombre de usuario y su clave para acceder a sus datos. A partir del momento en que el usuario está registrado, el sistema le permite acceder a sus secciones en modo compra, pues ningún cliente no registrado puede realizar compras, sólo consultas de precios y operaciones sencillas. La aplicación ofrece al usuario una serie de pantallas a través de las cuales puede navegar, que representan las diferentes secciones de la tienda: ofertas, hardware, software, juegos para videoconsolas, etc. pudiendo seleccionar los artículos e incluirlos en su carro de compra. El usuario puede acceder en cualquier momento a los datos de su carro de compra, para por ejemplo modificar la cantidad elegida de un determinado artículo, eliminar un producto o simplemente listar por pantalla el contenido actual del carro y el subtotal acumulado en pesos. Cuando termina de elegir, el usuario pulsa un botón etiquetado como enviar que pone en marcha la generación del pedido y la correspondiente factura que se adjunta en el paquete que el usuario recibe en su casa. Cada artículo puede estar disponible o no, y en caso de no estarlo, tendrá un tiempo estimado de entrada en stock. Hay que tener en cuenta que en el caso de aquellos pedidos que incluyen artículos que no están disponibles, el envío se retrasa hasta que dichos productos estén disponibles, excepto cuando alguno de los artículos no disponibles va a tardar más de 15 días, en cuyo caso se envía en el momento un primer envío con los artículos disponibles y cuando entre en stock el o los artículos retrasados se manda un segundo envío al usuario. Los gastos de envío de un pedido van en función del tipo de artículos solicitados (el hardware es generalmente más caro), del número total de artículos encargados y de la distancia en kilómetros desde el centro más cercano hasta la casa del cliente (esto se calcula gracias al código postal del cliente). Los gastos de envío en ningún caso serán función del número de envíos necesarios. El cliente puede consultar siempre que lo desee el estado de sus pedidos actuales y pasados, con el nivel de detalle que desee según dos modalidades: Sencilla: incluye fecha del pedido, fecha de entrega de c/u de los envíos a que dio lugar (si aún no se ha servido algún artículo se muestra como pendiente), precio total de los artículos y precio total incluyendo gastos de envío. Completa: incluye fecha de pedido, fecha de entrega de c/u de los envíos, detalle de artículos por envío (incluyendo cantidad de c/u y precio unitario) (si aún no se ha servido algún artículo se muestra como pendiente), tarjeta a la que se cargó el pedido, fecha del cargo, precio total de los artículos y precio total incluyendo gastos de envío. Se deberá tener en cuenta que en el sistema deberán realizarse las operaciones de mantenimiento propias de una tienda de este tipo, como por ejemplo aquellas que permitan mantener el stock de productos al día, que actualicen los precios, etc. 11

12 Registrarse Usuario Consultar Precios Mantener Stock <I> Operar Carro de Compras <I> <I> Validar Usuario Actualizar Precios Gestor Pedidos Cliente Generar Pedido <I> <E> Consulta Completa Establecer Disponibilidad Artículos Consultar Pedido <E> Consulta Sencilla Figura 4. Diagrama de Casos de uso para el Ejercicio 3. 12

13 3. SOBRE LA RELACION <<EXTENDS>> Y LAS OPERACIONES CRUD (Create, Read, Update, Delete) Recordando ideas. Primero recordemos que cuando escribimos un caso de uso (la plantilla en formato extendido), lo primero que tenemos es una secuencia normal. Al escribir esa secuencia normal, es posible que nos demos cuenta que algunos de los pasos de dicha secuencia pueden tener variaciones, y aquí es cuando hablamos de los subflujos. Recordemos que cuando en un paso se debe tomar un curso de acción en función de una condición por la naturaleza propia del mismo problema o negocio (o sea, son normales), estos cursos alternativos serán identificados como subflujos. Ahora bien, al revisar los pasos del curso normal, se recomienda que nos preguntemos qué puede fallar en este paso? Y aquí es cuando hablamos de las excepciones. Una excepción se utiliza para describir funcionalidades indeseadas o excepcionales de un paso a causa de una condición no cumplida. Tanto los subflujos (variaciones normales del curso normal) como las excepciones se les denominan Alternativas (o Cursos Alternativos). O escrito de otra forma, las alternativas se dividen en: Subflujos (variaciones normales). Excepciones (variaciones indeseadas). Y lo recomendado es que se dibujen todas las alternativas como extensiones del caso de uso que estemos analizando La relación de <<extends>>. Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). En una relación <<extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Es decir, el caso de uso base no conoce los casos de uso de extensión, está completo (y debe estar completo) sin las extensiones. Para el caso de las operaciones CRUD (Create, Read, Update, Delete) conceptualmente está bien representar esto: Mantener Usuario <<extends>> <<extends>> Crear Usuario Actualizar Usuario Figura 5. Diagrama de Casos de Uso con operaciones CRUD. A lo que me refiero que está bien es la relación <<extends>> ya que Crear Usuario es una variación de Mantener Usuario, al igual que Actualizar Usuario. 13

14 Si lo escribimos, tenemos lo siguiente: Caso de Uso: Mantener Usuario Guía 4. Parte 2. Modelo de Casos de Uso. Secuencia Normal: 1. El caso de uso inicia cuando el Administrador accesa al sistema. El Administrador ingresa su nombre de usuario y su contraseña y el sistema valida al Administrador. 2. El sistema despliega las funciones disponibles al Administrador. Estas funciones son: Crear Usuario, Actualizar Usuario, Cancelar. 3. El Administrador selecciona una de las opciones disponibles: 3.1. Si elige Crear Usuario, se ejecuta el subflujo Crear Usuario Si elige Actualizar Usuario, se ejecuta el subflujo Actualizar Usuario Si elige Cancelar, ir al paso El Administrador indica que el proceso está completo. El Sistema valida la información y se la muestra al Administrador. 5. El Sistema guarda la información del usuario. 6. Fin del Caso de Uso. Figura 6. Plantilla con la Secuencia Normal del Caso de Uso Mantener Usuario. Como puede verse, el caso de uso está completo, y aunque simple, hay un camino que no necesita tomar subflujo alguno: Las operaciones CRUD. Se recomienda que el nombre del caso de uso que agrupa las operaciones CRUD sea Mantener X. De hecho, se trabaja así en muchas partes. Para no alargar el cuento, los panoramas son los siguientes: El primer panorama es el caso de usuarios Administrador, no veo más remedio con estos casos de uso CRUD, ya que esa es la labor de este usuario, la de hacerle mantenimiento (Mantener) la información importante de todo el sistema y que es la que afecta a todos los demás usuarios adscritos a dicho sistema. El segundo panorama es la del usuario normalito y otros usuarios (el caso de cualquiera de nosotros en un sistema como Hotmail o Facebook), en el que efectivamente es muy importante dibujar como caso de uso autónomo el Registrar Usuario, y que cuando uno ya está registrado ese sistema le permite agregar, modificar o eliminar información PERO QUE HACE PARTE DE OTRO PROCESO MÁS IMPORTANTE y que si el usuario agrega, modifica o elimina algo, solo afectará a ese usuario y a nadie más. A continuación, muestro un pequeño ejemplo de un Sistema de Registro de Cursos. En primer lugar, deben dibujarse los Casos de Uso (vista del usuario) a un nivel de funcionalidad alto, tal como lo describiría un usuario y no un ingeniero. Estudiante Registrarse en Curso Figura 7. Diagrama de Caso de uso Registrarse en Curso. 14

15 La plantilla puede ser así: Guía 4. Parte 2. Modelo de Casos de Uso. Caso de Uso: Registrarse en Curso Secuencia normal: 1. El caso de uso inicia cuando el Estudiante accesa al Sistema de Registro de Cursos. El Estudiante ingresa su nombre de usuario y su contraseña y el sistema valida al Estudiante. 2. El sistema despliega las funciones disponibles al Estudiante. Estas funciones son: Crear Horario, Modificar Horario, Eliminar Horario. El Estudiante elige Crear Horario. Ojo: aquí está la clave para este tipo de usuarios. Las operaciones CRUD, en este caso, tal como lo expresé antes, hacen parte de un proceso más grande. En este caso concreto la operación CRUD es Crear Horario que hace parte de un proceso más grande Registrarse en Curso. Como también puede verse, de entrada se deja escrito que el actor ya ha elegido una opción: Crear Horario, y es natural que de entrada sea la opción ofrecida, ya que se necesita Crear Horario para que sea posible modificarlo o eliminarlo. Ahora, para efectos de este ejemplo, el sistema permite al Estudiante que si solo crea el horario y cierra la sesión, cuando regrese podrá elegir Modificar Horario, y no tendrá necesidad de crearlo de nuevo. Y como veremos, más adelante si ya tiene un Horario creado, podrá borrarlo. Las demás opciones Actualizar Horario y Eliminar Horario se reseñarán en la sección de subflujos de la presente plantilla, y no hay necesidad de llamar esos subflujos como se hizo en los pasos 3.1. y 3.2 tal como aparecen en la Figura 10). 3. El Sistema recupera del Catálogo de Cursos un listado con los cursos disponibles y muestra ese listado al Estudiante. El Estudiante selecciona 4 cursos obligatorios y 2 cursos opcionales de la lista de cursos ofrecidos. El estudiante puede agregar o eliminar los cursos (*) que desee hasta que elija Enviar Horario. (*)(estas son operaciones simples, como lo es agregar o quitar un elemento de una lista. Esto es una operación y no un caso de uso) 4. El Estudiante indica que el Horario está completo. 5. El Sistema valida los cursos seleccionados y muestra el horario al estudiante. 6. El Sistema calcula un número de confirmación usando un algoritmo de hashing usando el código del estudiante. 7. El Sistema muestra el número de confirmación del horario. 8. El Sistema guarda la información del estudiante en la Base de Datos de Estudiantes. 9. Fin del caso de uso. Figura 8. Plantilla con la Secuencia Normal del Caso de Uso Registrarse en Curso. 15

16 Subflujos: Modificar Horario. 1. A partir del paso 2 de la Secuencia Normal, el Estudiante ya tiene grabado un horario en el Sistema. 2. El Sistema recupera y muestra al Estudiante su Horario y le permite usarlo como punto de partida de este proceso. 3. El Caso de Uso de reinicia en el paso 3 de la Secuencia Normal. Eliminar Horario. 1. A partir del paso 2 de la Secuencia Normal, el Estudiante ya tiene grabado un horario en el Sistema y elige borrarlo. 2. El Sistema recupera y muestra al Estudiante su Horario. 3. El Sistema solicita al Estudiante que confirme el borrado del Horario. 4. El Estudiante confirma el Borrado del Horario. 5. El Sistema borra el Horario. 6. Fin del caso de uso. Figura 9. Plantilla con los Subflujos del Caso de Uso Registrarse en Curso. De modo que el Diagrama de Casos de Uso puede ampliarse así (recordemos que cada subflujo representa una extensión): <<extends>> Modificar Horario Estudiante Registrarse en Curso <<extends>> Eliminar Horario Figura 10. Diagrama de Caso de uso Registrarse en Curso con extensiones FIN DEL DOCUMENTO 16