guía 4. parte 2. modelo de casos de uso. modelo de casos...

Guía 4. Parte 2. Modelo de Casos de Uso.

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.


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.


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.


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: Hacer Reserva

Actores: Monitor (iniciador)

Tipo: Primario

Descripción: 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.


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: Hacer Reserva

Actores: Monitor (iniciador)

Propósito: Asignar a un Lector un libro para que pueda retirarlo más tarde.

Resumen: 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.

Tipo: Primario y abstracto.

Referencias cruzadas: 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.

3.1. Si elige la opción Aceptar, Subflujo S1: Verificar Lector y Estado de un

Libro. 3.2. Si elige la opción Cancelar, Subflujo S2: Cancelar la Reserva de un Libro.

Figura 1. Formulario de Reserva.


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.


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.


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.


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.

Figura 1. Diagrama de Casos de uso Ejercicio 1.

Validar

Usuario

Alquilar

Des-alquilar

Mantener Inquilinos

Gestor

Inmobiliaria

Alquilar Edificio

Alquilar Local

Alquilar Apartamento

<Inc>

<Ext>

<Ext>

<Ext>

Alta Inquilinos

Modificación Inquilinos

Baja Inquilinos Consulta Inquilinos

<Ext>

<Ext> <Ext>

<Ext>

<Ext>

<Ext>

<Ext>

Inquilino

Modificación Vía Web

Consulta Vía Web

<Ext> <Ext>

<Inc>


11

EJERCICIO 2. GESTIÓN CALIFICACIONES. Enunciado. Se desea desarrollar una aplicación de gestión de las calificaciones de los alumnos para satisfacer las numerosas quejas de los profesores, por el uso del lápiz y papel. La aplicación deberá cubrir únicamente aquellos aspectos relacionados con dicho tema, y que se describen a continuación: El profesor recibe las actas en blanco de las asignaturas de las que es responsable, en formato electrónico. El acta contiene los siguientes datos de la asignatura (titulación, campus, curso académico, denominación de la asignatura, convocatoria y grupo) y la lista de alumnos matriculados (cédula, código, nombre y apellidos). Alguna de las acciones que puede hacer el profesor son: Completar un acta con las notas de los alumnos. Añadir o borrar un alumno de un acta. Integrar las actas de varios grupos de una misma asignatura en una sola acta. Otras de las opciones que se le exige a la aplicación, para satisfacer completamente las necesidades del profesor, son las siguientes: Permitir la consulta de la siguiente información de cualquier alumno seleccionado: Cédula, Código, Lista de asignaturas

en las que está matriculado el alumno (Código asignatura-Nombre asignatura).

Obtener una estadística de las calificaciones obtenidas por los alumnos en un determinado grupo de una asignatura. En esta estadística se tendrá para cada posible calificación: Número de personas con esa calificación, Porcentaje sobre

los presentados, Porcentaje sobre el total del grupo. Consultar el porcentaje de personas sobre el total del grupo que se han presentado y el de los que no se han presentado.

Poder visualizar un gráfico indicativo del número de personas que han obtenido una calificación entre 0-0.99, 1-1.99, 2-2.99, 3-3.99, 4-4.99, 5-5.99, 6-6.99, 8-8.99, 9-10; indicándose la nota media obtenida por la clase.

Disponer de una calculadora que permita realizar las operaciones de suma, resta, multiplicación, división. Esta calculadora se activará cuando se vayan a introducir las notas a algún alumno de forma que una vez realizada la

operación aritmética, pulsando un botón se vuelque el resultado en la casilla donde se están introduciendo las calificaciones, redondeándose a dos cifras decimales.

Permitir la importación y exportación de la lista de alumnos con sus calificaciones a un formato compatible con MS Excel. Imprimir las actas y la lista provisional de calificaciones.

Finalmente, como una ampliación extra, a la cual sólo podrá acceder quien se identifique inicialmente como administrador de la aplicación, se deben permitir: Gestión ABMC (Altas/Bajas/Modificación y Consulta) de los datos de un alumno y su matrícula en una asignatura

y a un grupo. Gestión de Asignaturas, teniendo en cuenta que una asignatura sólo se puede dar en un único curso (primero,

segundo, tercero...) y que cada curso está formado por los datos sobre el número máximo de alumnos, número mínimo de créditos troncales y número mínimo de créditos optativos. Algunos de los datos que vamos a poder

consultar de una asignatura son el nombre, número de créditos y cuatrimestre en el que se imparte. Gestión de Titulaciones, teniendo en cuenta que una titulación sólo se da en un campus determinado y los datos que

podemos consultar son el nombre, el número de créditos o carga lectiva global, si es de 1° o 2° ciclo, ... Gestión de grupos, en los que podemos consultar el número máximo de alumnos permitidos, si es un grupo de

mañana, de tarde o de noche, y cuál es el código empleado para identificar el grupo. Consultar aquellos alumnos que no se pueden matricular y el motivo de ello.

Consultar el historial académico de un alumno.

Solución. A continuación se muestra el diagrama de casos de uso en el que se representan al actor profesor junto con las tareas que requiere del sistema de gestión de calificaciones (ver Figura 2). Así tenemos que: El profesor será aquel que puede realizar una serie de operaciones relacionadas con el listado de alumnos que tiene matriculados en sus asignaturas, tales como introducir las notas de alumnos, consultar el historial de alguno de sus alumnos, introducir o eliminar algún alumno en el listado y tareas de estadística y de importación y exportación. Se ha intentado reflejar toda la funcionalidad del sistema asociada al actor profesor para poder mostrar qué es lo que se espera que haga el sistema de forma completa. Así pues, se tiene el caso de uso de Poner notas, el cual se extiende en el caso de uso de Operaciones Calculadora. Con ello se refleja que el profesor al introducir las notas puede en algún momento hacer uso de las operaciones que aporta una calculadora.


12

Por otra parte, el caso de uso de Gestión de alumno se ha relacionado con el caso de uso de Añadir y Borrar mediante un extend para identificar explícitamente cuáles son las acciones que se espera que permita el sistema y que o bien se puede realizar de forma individual o no, cuando el profesor utiliza el sistema. Otras de las funcionalidades que constituyen un caso de uso cada una son: Integrar grupos, Información alumno, Estadística, Gráfico, Importar y Exportar. De la misma forma que anteriormente hemos comentado, se ha realizado el proceso de identificación explícita de las operaciones que se pueden realizar cuando el profesor quiere Imprimir. Se ha expresado mediante el “extend” las formas de impresión que puede tener el profesor reflejando que cuando se imprime puede imprimir sólo las actas (Imprimir actas), sólo las listas (Imprimir Listas provisional) o ambas.

Figura 2. Casos de uso relacionados con el actor "Profesor". Finalmente se muestra que todos los casos de uso con los que se relaciona de forma directa el actor se relacionan con el caso de uso de Validar Usuario para mostrar que es necesaria la identificación del profesor en el sistema para poder realizar cualquier operación comentada anteriormente. En el siguiente diagrama se muestran todos los casos de uso relacionados con el actor administrador del sistema (ver Figura 3). El administrador será el responsable del mantenimiento de los datos que hay en el sistema respecto a las asignaturas y a los alumnos matriculados.

Imprimir Actas

Imprimir Listas

Provisionales

<Ext>

<Ext>

Gestionar Notas

Operar Calculadora

<Ext>

Listar Alumnos Acta

Añadir

<Ext>

Integrar Grupo

Consultar Información

Alumno

Manejar Estadísticas

Generar Gráficos

Imprimir

Importar Archivo

Exportar Archivo

Validar

Usuario

<Inc>

<Inc>

<Inc>

<Inc>

<Inc>

<Inc>

<Inc>

<Inc>

<Inc>

Profesor


13

Como podemos observar, se ha intentado expresar toda la funcionalidad del sistema y por ello se han desglosado al máximo todos los casos de uso hasta que cada uno refleja una funcionalidad del sistema. En la siguiente figura se muestran cuáles son de forma explícita las funcionalidades que conlleva la gestión de los alumnos (caso de uso Gestión ABMC Alumnos). Así pues, se ha expresado mediante la relación de “extend” las distintas posibilidades que ofrece la gestión de alumnos, mostrándose además que ninguna es excluyente y que se pueden realizar algunas de las operaciones o todas cuando el administrador gestiona a los alumnos (casos de uso Alta, Baja, Modificación, Consulta Historial Académico). El resto de funcionalidades que el administrador espera del sistema son las siguientes: Matriculas, que identifica a la capacidad del sistema para realizar la matricula de un alumno en las asignaturas,

titulaciones y grupos existentes.

Gestión de Asignaturas, que identifica la posibilidad que tiene el administrador para introducir, borrar, modificar y consultar las asignaturas. En este caso no se ha reflejado de forma explícita, ya que en el enunciado no aparece detallado

cuál es el alcance de la gestión de asignaturas.

<Inc>

Figura 3. Casos de uso relacionados con el actor "Administrador". Gestión de Titulaciones y Gestión de Grupos reflejan la posibilidad para que el administrador introduzca en el sistema los datos de titulaciones y Grupos. Como ocurría anteriormente, al no detallarse en el enunciado del problema cuál es el alcance real de estas operaciones sólo se reflejan estos casos de uso sin el detalle mostrado para la Gestión ABMC Alumnos. Resaltar el hecho de que el caso de uso de Validar Usuario esté relacionado, mediante la asociación de include, con todos los casos de uso con los que se relaciona directamente el actor administrador. De esta forma indicamos que cualquier administrador que tenga que realizar una tarea o función debe identificarse en el sistema. El caso de uso que aparece en el gráfico siguiente es el mismo que se identificó anteriormente.

<Inc>

<Inc>

Dar de Alta <Ext> Dar de Baja

<Ext>

Consultar Historial

Académico

<Ext>

Modificar

<Ext>

Validar

Usuario

<Inc>

<Inc>

Mantener Alumnos

Mantener Matrículas

Mantener Asignaturas

Mantener Titulaciones

Mantener Grupos

Administrador


14

EJERCICIO 3. 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.


15

Figura 4. Diagrama de Casos de uso para el Ejercicio 3.

Validar

Usuario

Consulta

Completa

Consulta

Sencilla

Gestor

Pedidos

Mantener

Stock

Actualizar

Precios

Establecer

Disponibilidad

Artículos

Usuario

Registrarse

Consultar

Precios

Cliente

Operar Carro de Compras

Generar

Pedido

Consultar

Pedido

<I>

<I>

<I>

<E>

<E>

<I>


16

3. SOBRE LA RELACION <<EXTENDS>> Y LAS OPERACIONES CRUD (Create, Read, Update, Delete).

3.1. 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. 3.2. 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:

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”.

Mantener Usuario

<<extends>>

<<extends>>

Crear Usuario

Actualizar Usuario


17

Si lo escribimos, tenemos lo siguiente:

Caso de Uso: Mantener Usuario 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. 3.2. Si elige Actualizar Usuario, se ejecuta el subflujo Actualizar Usuario.

3.3. Si elige Cancelar, ir al paso 6. 4. 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: 1 – 2 – 3.3 – 6. 3.3. 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.

Figura 7. Diagrama de Caso de uso “Registrarse en Curso”.

Registrarse en Curso Estudiante


18

La plantilla puede ser así: 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”.


19

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):

Figura 10. Diagrama de Caso de uso “Registrarse en Curso” con extensiones.

-------------------------------------------------------------FIN DEL DOCUMENTO

Registrarse en Curso

Estudiante

Modificar Horario

<<extends>>

Eliminar Horario

<<extends>>

guía 4. parte 2. modelo de casos de uso. modelo de casos...

Documents