Practica Uml

Programación orientada a objetos y lenguaje unificado de modelado (UML) 1

Programación or ientada a objetos y UML

Práct ica

Gest ión de un c lub deport ivo

Introducción a la práctica Para las práctica de este curso vamos a realizar el análisis y diseño inicial de una aplicación de gestión de un club deportivo.

Una aplicación de este tipo puede ser muy simple o muy compleja, dependiendo de los parámetros y características cuya gestión deseemos automatizar. En nuestro caso, simplificaremos bastante los supuestos para evitar elevar tanto la dificultad de la práctica, como el tiempo necesario para su desarrollo. Cómo realizar la práctica La práctica se divide en ejercicios que debes desarrollar, cada uno dedicado a un tema específico del curso. Estos ejercicios están planteados de forma secuencial e incremental: cada ejercicio se desarrolla sobre el resultado obtenido en el anterior.

Tras una breve introducción inicial a cada ejercicio, se presenta una explicación de la funcionalidad necesaria en StarUML, la aplicación que utilizamos para realizar los diagramas. A continuación, se presenta el enunciado del ejercicio seguido de la solución “parcial” a los ejercicios propuestos: no se presentan todos los diagramas, sino algunos que puedes utilizar como indicación para realizar el resto.

No obstante, es recomendable que realices los ejercicios por tu cuenta desde

el principio y a continuación compares tu resultado con el que se incluye en la solución de la práctica.

Tras la solución presentada para los ejercicios propuestos, se proponen otros

ejercicios cuya solución no viene incluída pero que deben resultarte más sencillos si has asimilado lo ejemplificado en los ejercicios resueltos.

Es muy recomendable que realices los ejercicios propuestos y, si lo

consideras conveniente, los envíes al tutor para que éste te dé su valoración.


La metodología empleada en el modelado de un sistema en UML puede cambiar mucho entre distintas empresas, usuarios o filosofías de trabajo. Ten en cuenta que otras aproximaciones distintas a la aquí presentada para el análisis y diseño del sistema que enunciaremos pueden producir resultados distintos, pero igualmente válidos.


Anexo:

Introducción a StarUML

Acerca de StarUML__________________________________

Para elaborar las prácticas hemos utilizado el programa de modelado de diagramas StarUML. Es un programa de código abierto gratuito de bastante calidad, y es recomendable que desarrolles las prácticas del curso sobre el mismo si no posees otra herramienta cuyo manejo ya domines. Ten en cuenta que sólo está disponible para Windows. Si trabajas con otro sistema operativo, deberás elegir alguna alternativa,

como ArgoUML.

La interfaz y la ayuda están en inglés, pero aún así hemos elegido StarUML frente a otras alternativas (como ArgoUML) en vista de las limitaciones que dichos programas alternativos imponían a la hora de realizar los diagramas (básicamente, muchas funcionalidades implementadas a medias).

Puedes obtener el programa en la dirección web http://staruml.sourceforge.net/en/

Durante el manejo del programa es probable que te topes con algunos escollos e incongruencias que no están bien resueltas, como la selección de elementos. Ten en cuenta que se trata de un programa gratuito que además está lejos de representar una versión definitiva.


Nota: cambiando el tipo de línea dibujada al enlazar elementos Al trabajar con los diferentes tipos de diagramas en StarUML, observarás que existen herrramientas para relacionar símbolos entre sí (diagrama de clases), enviar mensajes de un objeto a otro (diagramas de secuencia), etc.

StarUML representa estas relaciones, mensajes, etc. con líneas de diversos tipos. Existen dos modos de dibujo disponibles para estas líneas: oblicuas y rectilíneas. En los diagramas de este documento utilizamos la representación rectilínea, pues es más clara y ordenada que la oblicua.

Cuando añadas una de estas líneas de

conexión a un diagrama, puedes cambiar el modo en que es representada en el diagrama con la herramienta Line Style disponible en la barra de herramientas situada bajos los menús del programa. Esta característica también puede establecerse globalmente en el cuadro de diálogo Tools Options. Nota: desactivando el tamaño automático de los elementos___

Si al intentar modificar el tamaño de algún elemento ves que no es posible, prueba a desactivar la opción Auto Resize que está activada por defecto. De este modo, podrás cambiar el tamaño sin problemas, ajustándolo a las necesidades del diagrama.

Si te desenvuelves aceptablemente bien con el inglés, te recomiendo que consultes la documentación del programa para comprender mejor el uso de las herramientas. La documentación es concisa pero muy útil y muestra muchos atajos para crear diagramas de forma más eficiente.

A lo largo de este documento encontrarás anexos que describen el trabajo con StarUML. Ten en cuenta que sólo describiremos la funcionalidad necesaria para el modelado de nuestros diagramas.


Enunciado

Requis i tos del s istema

Requisitos funcionales de la aplicación Gestor de Club Deportivo En esta práctica realizaremos el análisis y diseño de una hipotética aplicación que permita gestionar algunos aspectos de un club deportivo privado. En concreto, la aplicación permitirá la gestión de socios y de reservas de instalaciones y extras para las reservas, tales como un árbitro, materiales (balones, petos…), etc. Esta gestión la llevarán a cabo los empleados del club destinados a tal efecto. Además, habrá un usuario administrador que gestionará las cuentas de usuario de estos empleados en el sistema.

Una aplicación real (tal y como las que se encuentran en el mercado) soportaría la gestión de otros aspectos, como el personal del club, la contabilidad, gestión de stock y materiales, etc. Como hemos comentario anteriormente, hemos simplificado en este sentido los requisitos para no dificultar en exceso la práctica, permitiendo que puedan realizarse en un tiempo razonable. A continuación enumeramos los requisitos funcionales del sistema: Sistema

- El sistema sólo permite una sesión de usuario activa en todo momento. Esto significa que para que el usuario actual debe finalizar su sesión para que otro usuario inicie sesión.

- Es necesario iniciar sesión como usuario del sistema antes de poder hacer uso de cualesquiera de sus funcionalidades.

- Al finalizar una sesión, el sistema mostrará la pantalla de inicio de sesión de nuevo.

- El sistema almacenará la siguiente información acerca de cada sesión: hora de inicio, hora de finalización y usuario.

- El sistema utilizará una base de datos para almacenar los datos de cuentas de usuario, socios, reservas y materiales.

El proyecto de desarrollo de un sistema real suele incluir tanto requisitos funcionales como requisitos no funcionales. La diferencia es que los primeros especifican como debe ser el comportamiento interno del sistema; los segundos representan requisitos que no se satisfacen añadiendo código al sistema, tales como utilizar un lenguaje o base de datos específico, etc. En ésta práctica sólo consideraremos los requisitos funcionales.


- El sistema emitirá un mensaje de confirmación siempre que la realización de alguna operación tenga éxito. En caso contrario, emitirá el mensaje de error correspondiente.

Usuarios del sistema

- El sistema soportará dos tipos de usuarios: usuarios normales y usuarios administradores.

- Los usuarios de tipo administrador podrán realizar la gestión de cuentas de usuario exclusivamente.

- Los usuario genéricos usuario podrán realizar la gestión de socios, gestión de reservas y gestión de materiales exclusivamente.

Gestión de cuentas de usuario

- La gestión de cuentas de usuario consistirá en la posibilidad de creación, consulta, edición y eliminación de cuentas de usuario.

- Desde la pantalla principal el administrador tendrá acceso a los comandos crear cuenta y consultar cuenta o similares.

- Al crear una cuenta de usuario se deberán facilitar al sistema los siguientes datos, como mínimo: nombre y apellidos del empleado, tipo de empleado, nombre de usuario y contraseña. En cualquier momento el administrador podrá salir de la interfaz de creación de cuentas o bien utilizar un botón “Crear cuenta” o similar.

- Al consultar una cuenta, se presentará una interfaz donde el administrador podrá elegir la cuenta a consultar de una lista de cuentas existentes. Para visualizar los datos de la cuenta elegida, pulsará sobre un botón “Ver datos cuenta” o similar.

- Las opciones de edición y eliminación de una cuenta estarán disponibles en la pantalla que muestre los datos de la cuenta, mediante botones “Guardar cambios” y “Eliminar cuenta” o similares. También existirá la opción “Salir” para volver al menú principal.

- Al editar los datos de una cuenta (tanto en la creación inicial de la cuenta como al cambiar algún dato de la misma) el sistema comprobará:

- que no falta ningún dato de los requeridos - que el conjunto usuario/contraseña no pertenece a los de otra

cuenta ya existente Gestión de socios

- La gestión de socios consistirá en la posibilidad de efectuar altas y bajas de socios, así como la consulta y edición de los datos de los mismos.

- El usuario del sistema tendrá acceso a los comandos alta de socio y consultar socio o similares.

- Al efectuar el alta de un socio, se deberán facilitar los siguientes datos como mínimo: nombre y apellidos del futuro socio, dirección, teléfono, NIF. Al socio se le asignará un número de socio identificativo.

- Al consultar un socio, el usuario podrá elegir el socio a consultar de una lista de socios existentes. Para visualizar los datos del socio elegido, pulsará sobre un botón “Ver datos socio” o similar.

- Las opciones de edición y eliminación de los datos de un socio estarán disponibles en la pantalla que muestre los datos del mismo, mediante botones “Guardar cambios” y “Eliminar socio” o similares.


- Al editar los campos de un socio (tanto en el alta inicial como al cambiar algún dato) el sistema verificará que no existe ningún socio con el mismo valor del NIF. El resto de campos puede ser idéntico.

Gestión de reservas

- La gestión de reservas consistirá en la posibilidad de efectuar altas y cancelaciones de reservas, así como la consulta y edición de los datos de las mismas.

- Una reserva tiene un coste asociado, que depende del tipo de pista y de

los extras reservados. - El usuario del sistema tendrá acceso a los comandos alta de reserva y

consultar reserva o similares. - Al efectuar el alta de una reserva, se deberán facilitar los siguientes

datos como mínimo: número de socio, fecha y hora, tipo de pista (baloncesto, tenis…). Además, se verificará que el usuario es socio del club (número de socio válido) y que hay una pista disponible del tipo solicitado en la fecha y hora solicitadas.

- Al consultar una reserva, el usuario podrá elegir la reserva a consultar de

un calendario que mostrará las reservas existentes. Para visualizar los datos de la reserva elegida, pulsará sobre un botón “Ver datos reserva” o similar.

- Las opciones de edición y cancelación de los datos de un reserva estarán

disponibles en la pantalla que muestre los datos de la misma, mediante botones “Guardar cambios” y “Cancelar reserva” o similares.

- Al editar los campos de una reserva (tanto en el alta inicial como al

cambiar algún dato) el sistema verificará que no existe conflicto entre la reserva actual y el resto de las reservas del sistema (es decir, que la reserva es posible por disponibilidad de pista, etc). También se verificará que los extras asociados están disponibles.

- Al editar una reserva, será posible a su vez añadir o eliminar extras

como balones, raquetas, etc. a la misma.

- Las pistas se denominarán por un nombre que permita tanto al usuario como al personal de las instalaciones hacer referencia a las mismas (por ejemplo: pista1 de baloncesto).


Gestión de extras

- Es posible alquilar una serie de “extras” al hacer una reserva. Estos serán: balones, petos, etc.

- Debe tenerse en cuenta que un extra puede no estar disponible si está

en reparación.

- La gestión de extras consistirá en la posibilidad de dar de alta extras (compra de nuevos balones, por ejemplo), bajas de extras (por rotura, por ejemplo), así como la consulta y edición de los datos de los mismos (por ejemplo, para marcar un material como no disponible por estar en reparación, un árbitro no está disponible por viaje o trabajo, etc).

- El usuario del sistema tendrá acceso a los comandos alta de extra y

consultar extra o similares. - Al efectuar el alta de un extra, se deberán facilitar los siguientes datos

como mínimo: tipo de extra, precio de alquiler, nombre del extra.

- Al consultar un extra, el usuario podrá elegir el extra a consultar de una lista que mostrará todos los extras existentes. Para visualizar los datos del extra elegido, pulsará sobre un botón “Ver datos extra” o similar.

- Las opciones de edición y eliminación de los datos de un extra estarán

disponibles en la pantalla que muestre los datos del mismo, mediante botones “Guardar cambios” y “Eliminar extra” o similares.


Anexo:

Preparac ión del proyecto en StarUML

Para crear un proyecto en StarUML…____________________

1. Elige el comando File New Project 2. Establece las propiedades básicas del proyecto en la ventana Properties:

3. Guarda el proyecto con un nombre adecuado, como práctica.uml,

gestión club.uml o similar.


Ejerc ic io 1

Casos de uso

Introducción_______________________________________

En un proyecto real, generalmente recibimos un documento que incluye los requisitos funcionales que debe satisfacer el sistema, en forma de una larga lista de características. En otras ocasiones, desde el primer momento se establece una comunicación entre el cliente y el desarrollador para determinar qué funcionalidad debe incluir el sistema. También es posible y muy común, recibir una especificación inicial de los requisitos, pero mantener simultáneamente conversaciones con el cliente y/o los potenciales usuarios del sistema, para determinar de la mejor forma posible qué características deben implementarse, y cómo. Aunque existen distintas aproximaciones para realizar el análisis de un sistema, el modelado de los casos de uso es un buen punto de partida. Los diagramas de casos de uso son muy útiles para realizar el modelado inicial de los requisitos del sistema, pues describen las interacciones típicas entre los usuarios y el sistema.

Otra razón por la cual los diagramas de casos de uso son excelentes para realizar el análisis y diseño inicial de un sistema, es que permiten realizar cambios importantes sin que esto implique un coste importante de trabajo o tiempo para remodelar los diagramas. Esto supone una ventaja importante respecto a otras alternativas, como comenzar el diseño modelando las clases o la secuencia de comportamiento del sistema, por ejemplo. Es por ello que comenzaremos nuestra aproximación al diseño del sistema modelando estos diagramas.

Podríamos preguntarnos ¿para qué necesitamos los casos de uso, si disponemos de los requisitos? La respuesta es que a menudo los requisitos muestran incongruencias, incompatibilidades, redundancias, etc. que pueden ser minimizadas con un análisis de casos de uso correcto. Una buena estrategia para discernir qué comportamientos podemos catalogar como casos de uso consiste en establecer escenarios de uso del sistema. Un escenario es una descripción de las acciones que el usuario acomete en el sistema, con objeto de conseguir cierto objetivo. Estudiando los escenarios típicos en los que interaccionarán usuario y sistema, obtendremos los casos de uso que debemos modelar.

En la preparación de los casos de uso debemos, pues, analizar la interacción usuario-sistema, considerando tanto los casos en los que se obtiene el resultado esperado (por ejemplo, alta de un socio en un club realizada correctamente) como los resultados negativos o erróneos (por ejemplo, el alta no es posible pues el socio ya está dado de alta).


Los casos de uso deben describirse siguiendo un formato que permita especificar su nombre, precondiciones y poscondiciones, pasos, excepciones, etc.

Al modelar los casos de uso, separaremos el comportamiento común a varios casos de uso como un nuevo caso de uso que puedan ser incluído por los primeros. Se utiliza la relación <<includes>> para representar el caso en que un caso de uso incluye el comportamiento de otro.

Asímismo, el comportamiento opcional pero de suficiente relevancia como para justificar un caso de uso propio, se factorizará en un nuevo caso de uso que extenderá a otros. Se utiliza la relación <<extends>> para representar el caso en que un caso de uso es extendido por otro.

Una vez enunciados los casos de uso y realizados los correspondientes diagramas, llegamos al momento en el que debemos describir más detalladamente cada caso de uso. Ten en cuenta que este paso se puede realizar de forma paralela a los anteriores, o incluso antes de realizar los diagramas, dependiendo de la metodología y el planteamiento considerados.

Una flecha <<include>> dirigida desde un caso de uso hacia otro indica que el comportamiento representado por el caso de uso del que sale la flecha siempre incluye la realización, al menos en una ocasión, del comportamiento representado por el caso de uso hacia el que apunta la flecha.

Una estrategia para detectar includes es considerar si cierto comportamiento es compartido por distintos casos de uso o si el comportamiento tiene la suficiente importancia o relevancia como para merecer un caso de uso por separado.

Una flecha <<extends>> dirigida desde un caso de uso hacia otro indica que el comportamiento representado por el caso de uso del que sale la flecha puede incluir o no la realización, en una o más ocasiones, del comportamiento representado por el caso de uso hacia el que apunta la flecha.


Para ello, describiremos:

- El nombre asignado al caso de uso - El objetivo del mismo - Las precondiciones: condiciones que deben satisfacerse para que el

caso de uso pueda tener lugar - Las poscondiciones: condiciones que se dan una vez ha finalizado el

caso de uso satisfactoriamente - Los actores que intervienen - El flujo principal o “ideal”: descripción de la situación en la que el

caso de uso finaliza con el actor habiendo conseguido su objetivo. - Los flujos alternativos o “excepciones”: situaciones alternativas,

erróneas, etc.

Es posible y/o necesario, según el tipo de proyecto o su magnitud, describir otras características, pero en nuestro caso nos ceñiremos a las aquí enunciadas.

Este paso es importante: ten en cuenta que los diagramas de interacción que modelaremos más adelante se basarán directamente en la descripción de los casos de uso.


Ejerc ic io 1 .1

Ident i f i cac ión de actores y casos de uso

- Identifica los actores que interactúan con el sistema. - Identifica los casos de uso fundamentales del sistema y enuméralos

asignando un título y una frase o párrafo descriptivo a cada uno de ellos.

…Por ejemplo, si se necesita que el sistema sea capaz de soportar la consulta de los datos de un socio, podemos considerar un caso de uso consulta de socio que incluya tales comportamientos: “El usuario efectúa la consulta de datos de un socio.”

- Agrupa en paquetes, si es posible, los casos de uso relacionados entre sí.

…de modo que más adelante podamos elaborar un diagrama de casos de uso global en el que representaremos dichos paquetes, para dar una visión global del sistema.


Soluc ión a l E jerc ic io 1 .1

Actores__________________________________

Tras analizar los requisitos del sistema, es evidente que serán necesarios dos actores en el modelado de los casos de uso: el usuario normal de la aplicación y el usuario administrador. El primero hace referencia al empleado del club que maneja la aplicación informática que gestiona las altas, reservas, etc. Por comodidad y simplicidad, nos referiremos a él como Usuario. El segundo hace referencia al usuario que hace las funciones de administrador. Le designaremos pues como Administrador.

¿

Pero, y que hay de los socios del

club ?

Hemos decidido no representar el actor Socio dado que no interviene directamente en la interacción con el sistema. Por supuesto, es necesario contar con su participación en la mayoría de los casos de uso –por ejemplo, para un alta de socio se necesita que el futuro socio proporcione sus datos- pero este comportamiento lo incorporaremos como precondiciones en los casos de uso, como veremos más adelante.

Casos de uso______________________________ Estudiando con detenimiento los requisitos del sistema, podemos establecer los siguientes casos de uso:

- alta de nuevos extras “El usuario da de alta un nuevo extra en el sistema.”

- baja de extras

“El usuario da de baja un extra del sistema.”

- consulta de extra “El usuario consulta los datos de un extra concreto.”

- edición de extras “El usuario edita los datos de un extra concreto.”

En este caso los actores son personas físicas, pero también pueden ser otros sistemas, hardware o software.


- alta de nuevos socios

“El usuario efectúa el alta de un nuevo socio en el sistema.”

- baja de socios “El usuario efectúa la baja en el sistema de un socio del club.”

- consulta de socios “El usuario consulta los datos de un socio del club.”

- edición de socios

“El usuario edita los datos de un socio concreto.”

Paquetes_________________________________ La separación en paquetes de los casos de uso anteriores es bastante sencilla, dado que están fuertemente relacionados entre sí por grupos:

- gestión de cuentas de usuario

alta de cuentas de usuario consulta de cuentas de usuario edición de cuentas de usuario baja de cuentas de usuario

- gestión de socios

alta de nuevos socios consulta de socios edición de socios baja de socios

- gestión de reservas

alta de reservas consulta de reservas edición de reservas baja de reservas

- gestión de extras

alta de nuevos extras consulta de extras edición de extras baja de extras

Podemos considerar cada uno de los tipos de gestión anteriores como un

paquete de funcionalidades que a su vez incluirá otros casos de uso.

Prueba a describir los casos de uso restantes, para la gestión de reservas y cuentas de usuario.

1.1


Anexo:

Diagramas de casos de uso en StarUML

Para añadir un diagrama de casos de uso…_______________ Haz clic con el botón derecho del ratón sobre la carpeta <<useCaseModel>> y elige la opción correspondiente:

Para añadir elementos al diagrama…____________________ Utiliza la ventana de herramientas UseCase situada en el Toolbox. Una breve explicación de las herramientas y cómo utilizarlas: (sólo comentamos las que consideramos necesarias para esta práctica) UseCase: utilízala para representar un caso de uso. Deberás asignarle un nombre una vez lo crees sobre el diagrama. Actor: para representar a un actor del sistema. Association: selecciona esta herramienta, haz clic sobre un actor y a continuación sobre un caso de uso que hayas dibujado para crear una asociación entre ambos. DirectedAssociation: Es un tipo especial de asociación que permite mostrar quién inicia la relación en una asociación. Por ejemplo, si un Usuario participa en un caso de uso Iniciar sesión podríamos utilizar esta herramienta para indicar que siempre es el usuario el que inicia el caso de uso, y no el sistema (sin la voluntad inicial del usuario, el sistema no inicia sesión por él automáticamente).


Generalization: Permite crear relaciones de tipo padre-hijo entre casos de uso y actores. Por ejemplo si tenemos un usuario Administrador que es un caso especial de un Usuario normal (una extensión del mismo), podemos representarlo con una relación de este tipo entre ambos actores. Include: Se utiliza para mostrar que un caso de uso incluye el comportamiento de otro, es decir, siempre que tiene lugar el primero, el caso incluído también tiene lugar. Extend: Se utiliza para mostrar que un caso de uso extiende el comportamiento de otro, es decir, cuando tiene lugar el primero, el caso extendido puede o no tener lugar. System Boundary: Permite dibujar recuadros para delimitar el sistema o subsistema modelado. Muy útil para separar los actores de los casos de uso, viene a representar el sistema o subsistema modelado en este caso.


Ejerc ic io 1 .2

Modelado de d iagramas de casos de uso

- Realiza el modelado de un diagrama de casos de uso global que englobe

a los paquetes designados en el ejercicio anterior. - Realiza el modelado de los diagramas de casos de uso encontrados en el

ejercicio anterior.

Considera la necesidad de hacer uso de inclusiones y extensiones en el modelado de los diagramas.

Los diagramas de casos de uso no deben utilizarse para mostrar el comportamiento ante errores o los pasos completos de un comportamiento concreto. Utiliza para ello los diagramas de secuencia. Recuerda que los casos de uso se utilizan para dar una visión general de un proceso sin entrar en detalles de implementación.


Soluc ión a l E jerc ic io 1 .2

Diagrama de casos de uso global_________________________________

Podemos ver como hemos representado cada uno de los “paquetes” de gestión. Además, hemos incluído los casos de uso iniciar sesión y finalizar sesión. Los casos de uso de gestión incluyen en inicio de sesión, es decir, necesitan que se haya iniciado sesión para poder tener lugar. Hemos visto que todo comportamiento común se puede factorizar en un caso de uso propio, que sea incluido por otros posteriormente. Pero ¿Son lo suficientemente importantes iniciar sesión y finalizar sesión como para considerarlos casos de uso en sí? Bueno, un usuario puede iniciar sesión y finalizarla a continuación, por ejemplo, sin realizar ninguna gestión. Este comportamiento ya serviría para justificar la existencia de estos casos de uso aparte; por otra parte, suponen comportamientos relevantes en el sistema. Lo cierto, no obstante, es que no siempre se representan estos comportamientos como casos de uso propios. Recordemos que debemos elegir un planteamiento y ceñirnos a él durante todo el proceso de modelado.


¿ Porqué no se han incluído

iniciar sesión y finalizar sesión como casos de uso del sistema en el ejercicio

anterior

?

Analizando los requisitos está claro que el usuario necesita iniciar sesión para realizar cualquier gestión, sin embargo no consideramos en su momento estos comportamientos como casos de uso en sí. En esta fase del análisis vemos que ese comportamiento es común a toda gestión y por tanto lo separamos como un caso de uso específico que los demás incluyen. Podemos volver atrás e incorporar esos casos de uso a los obtenidos inicialmente.

De forma general, es el usuario/administrador el que inicia la gestión en todos los casos, de modo que hemos utilizado la herramienta de StarUML DirectedAssociation para dibujar flechas en vez de líneas para las asociaciones de los actores con los casos de uso.

Una vez modelado el diagrama de alto nivel, podemos descomponer cada uno de los paquetes en otros diagramas más detallados.

Fíjate como no hemos utilizado la relación de generalización entre Usuario y Administrador. Administrador no puede considerarse una especialización de Usuario porque no incorpora los comportamientos de éste. Recordemos que un Administrador sólo puede gestionar las cuentas de usuario.

El diseño de un sistema es cíclico en muchas de sus etapas.


Gestión de cuentas de usuario___________________________________

Observa como en este diagrama no incluímos el inicio y finalización de sesión; es innecesario y resultaría redundante dado que este diagrama representa la gestión de cuentas de usuario y el diagrama global ya expresa la relación de dicho paquete con los casos de uso iniciar sesión y finalizar sesión. Fíjate asímismo como administrador puede realizar una consulta directamente y como los casos de uso editar y eliminar incluyen al caso consultar. Rcuerda que los requisitos especifican claramente que para acceder a las opciones de edición y eliminación es necesario efectuar una consulta previa de la cuenta.

Te propongo que realices el modelado de los diagramas de casos de uso para la gestión de socios, gestión de reservas y gestión de extras.

1.2


Ejerc ic io 1 .3

Descr ipc ión de los casos de uso

- Rellena el siguiente formulario para cada uno de los casos de uso modelados:

Caso de uso Nombre del caso de uso Propósito Objetivo del caso de uso Precondiciones Condiciones que deben ser satisfechas previamente a la

ejecución del caso de uso Poscondiciones Condiciones que se dan una vez finalizado el caso de uso

satisfactoriamente Actores Actores que intervienen en el caso de uso

Flujo principal 1 Paso 1 del caso de uso 2 Paso 2 del caso de uso … … n Paso n del caso de uso

Excepciones 1.1 Excepción o comportamiento anómalo del paso 1 … … n.1 Excepción o comportamiento anómalo del paso n


So luc ión a l E jerc ic io 1 .3

Inicio y finalización de sesión____________________________________

Caso de uso iniciar sesión Propósito Autenticarse como usuario del sistema para acceder a los

servicios del mismo Precondiciones El usuario se encuentra ante la pantalla de inicio de sesión del

sistema Poscondiciones El usuario ha iniciado sesión en el sistema Actores administrador, usuario

Flujo principal 1

El usuario introduce sus datos de cuenta y pulsa el botón “Iniciar sesión”

2 El sistema valida los datos del usuario e inicia sesión para el mismo

Excepciones 2.1

El sistema muestra un mensaje de error si los datos de usuario no corresponden a los de una cuenta del sistema

Caso de uso finalizar sesión Propósito Finalizar la sesión del usuario activo Precondiciones Haber iniciado sesión en el sistema Poscondiciones No hay sesiones activas en el sistema Actores administrador, usuario

Flujo principal 1 El usuario pulsa el botón “Finalizar sesión”

2 El sistema finaliza la sesión del usuario actual y presenta la pantalla de inicio de sesión


Gestión de cuentas de usuario___________________________________

Caso de uso crear cuenta de usuario Propósito Crear una nueva cuenta de usuario en la base de datos del

sistema Precondiciones Haber iniciado sesión como administrador en el sistema

Encontrarse en la interfaz de creación de nueva cuenta Poscondiciones El sistema ha almacenado en la base de datos una nueva

cuenta de usuario Actores administrador

Flujo principal 1

administrador introduce los datos de la nueva cuenta y pulsa el botón “Crear cuenta”

2 El sistema comprueba que no falta ningún dato requerido

3 El sistema comprueba que no existe una cuenta que corresponda a los datos usuario/contraseña

4 El sistema crea la nueva cuenta en la base de datos

5 El sistema confirma la creación de la cuenta al usuario

Excepciones 2.1

El sistema muestra un mensaje de error informando de que faltan datos requeridos o hay datos erróneos

3.1

El sistema muestra un mensaje de error si los datos de la cuenta (usuario, password) corresponden a los de otra cuenta ya existente

Caso de uso consultar cuenta de usuario Propósito Ver la información asociada a una cuenta de usuario

existente en el sistema Precondiciones Haber iniciado sesión como administrador en el sistema

Encontrarse en la interfaz de consulta de cuenta Poscondiciones Actores administrador

Flujo principal 1

administrador elige la cuenta que desea consultar del listado de cuentas y pulsa el botón “Ver cuenta”

2 El sistema muestra los datos actuales de la cuenta pertinente


Caso de uso editar cuenta de usuario Propósito Cambiar alguno o varios de los campos de una cuenta de

usuario existente en el sistema Precondiciones Haber iniciado sesión como administrador en el sistema

Encontrarse en la interfaz de consulta de datos de una cuenta Poscondiciones El sistema almacena los cambios realizados en la base de

datos Actores administrador

Flujo principal 1

administrador modifica alguno o varios de los campos asociados a la cuenta y pulsa el botón “Actualizar cuenta”, “Guardar cambios” o similar

2 El sistema valida los datos requeridos

3 El sistema verifica que los valores (usuario, contraseña) son únicos

4 El sistema almacena los cambios en la base de datos

5

El sistema emite un mensaje de confirmación indicando que los cambios han sido realizados

Excepciones 2.1

El sistema muestra un mensaje de error informando de que faltan datos requeridos o hay datos erróneos

3.1

El sistema emite un mensaje de error si los valores (usuario, contraseña) no son únicos

Caso de uso eliminar cuenta de usuario Propósito Eliminar una cuenta de usuario determinada de la base de

datos del sistema Precondiciones Haber iniciado sesión como administrador en el sistema

Encontrarse en la interfaz de consulta de datos de una cuenta Poscondiciones Se ha eliminado una cuenta de usuario de la base de datos Actores administrador

Flujo principal 1 administrador pulsa el botón “Eliminar cuenta” 2 El sistema elimina la cuenta de la base de datos

3 El sistema emite un mensaje de confirmación de cuenta eliminada

Los pasos 2 y 3 en los formularios crear cuenta y editar cuenta podrían unificarse en uno único y seguiría estando correcto.


Rellena un formulario como el anterior para los casos de uso que no hemos presentado aquí.

1.3


Ejerc ic io 2

Anál is is y d iseño de las c lases del s istema

Introducción_______________________________________________ El modelado de los casos de uso nos aporta información fundamental para establecer las clases del sistema y en menor medida, los atributos y operaciones de las mismas. En esta segunda fase pasaremos del análisis inicial del sistema a un diseño preliminar, dado que el examen de los casos de uso nos proporcionará, como hemos comentado, información sobre las clases que vamos a necesitar.

Recordemos de la parte teórica que se denomina responsabilidad a la obligación que posee una clase, el fin para el que fue creada. También se explicó que para determinar las responsabilidades de una clase debemos identificar todas las clases del sistema y estudiar como colaboran entre sí. Tendremos cuidado de no dar demasiadas responsabilidades a una única clase ni obtener clases con muy pocas responsabilidades, siguiendo lo explicado.


Anexo:

D iagramas de c lases en StarUML

Para añadir un diagrama de clases…_____________________ Haz clic con el botón derecho del ratón sobre la carpeta <<designModel>> y elige la opción correspondiente:


Para añadir elementos al diagrama…____________________ Utiliza la ventana de herramientas Class situada en el Toolbox. Una breve explicación de las herramientas y cómo utilizarlas: (sólo comentamos las que consideramos necesarias para los diagramas de esta práctica) Class: Para añadir una clase al diagrama. Association: Para añadir una relación entre clases del tipo asociación. Aggregation: Para añadir una relación entre clases del tipo agregación (recuerda que es un tipo particular de relación de asociación). Generalization: Para añadir una relación entre clases del tipo generalización. Para establecer la cardinalidad entre elementos …__________ Cuando utilices alguna de las herramientas de relación, puedes seleccionar la relación recién creada y modificar las cardinalidades de la misma con los campos Multiplicity que encontrarás en la ventana Properties.


Para establecer los métodos y atributos de una clase…______

Haz clic sobre la clase en cuestión y a continuación sobre el cuadro de edición anexo a las propiedades Attributes y/o Operations en la ventana Properties. Verás un icono con unos puntos suspensivos, si haces clic sobre él se abrirá la ventana de edición de atributos u operaciones, en su caso. Una vez abierta la ventana Collection Editor de la clase, podemos añadir, ordenar y eliminar atributos y operaciones como convenga.

Para establecer las propiedades de uno de estos elementos, debemos seleccionarlo y dirigirnos de nuevo a la ventana Properties, donde podremos asignar valores a campos como Visibility, Type y Name, entre otros.


Ejerc ic io 2 .1

Enumeración de c lases y modelado del d iagrama de c lases

- Enumera las clases fundamentales que deberá incorporar el sistema

basándote en los requisitos del mismo. - Modela el diagrama de clases del sistema enunciado, integrando las clases

recién elegidas. Elige y justifica el tipo de relación adecuado entre las mismas (dependencia, generalización, asociación). Establece la cardinalidad apropiada para cada una de las relaciones (uno a uno, uno a varios, etc.).



Elección de clases__________________________________________ ¿Cómo podemos identificar las clases del sistema? En principio, cualquier entidad que identifiquemos que sea lo suficientemente importante o relevante, o que tenga asociada información que debamos contemplar deberíamos tratarla como una clase. El resto de características pueden considerarse atributos de una de las clases identificadas. Por ejemplo, en nuestro sistema es evidente que deberá existir una clase Reserva, que contendrá la información asociada a una reserva (fecha, hora, número de socio…). Sin embargo, sabemos que toda reserva puede tener un árbitro vinculado a la misma. ¿Consideramos árbitro como clase, o como atributo de la clase Reserva? Podrían ser válidos los dos casos, pero si vamos a almacenar los datos del árbitro en nuestro sistema (teléfono, dirección…) es conveniente tener una clase Árbitro a la que podamos hacer referencia desde Reserva mediante la correspondiente relación. Es más, dado que en realidad un árbitro no es sino un extra añadido a una reserva, tal y como puede serlo un material, vamos a implementar una clase Extra que contenga la información básica acerca de todo extra asociado a una reserva. De esta clase descenderán Árbitro y Material para representar los extras.

Siguiendo un razonamiento parecido ¿Merece una pista ser considerada como una clase o como un atributo de Reserva, por ejemplo, nombrePista? Estudiando los requisitos del sistema, podemos ver que es necesario asignar un nombre a cada pista, y además, que una pista puede estar disponible o no por estar en reparación, tiene un precio asociado, etc. Esto justifica que tengamos una clase pista con tales atributos relacionada con la clase Reserva. Basándonos en las consideraciones anteriores para el resto de casos a considerar, hemos incorporado las siguientes clases: clase Reserva: representa una reserva de una pista determinada, efectuada por un socio determinado para una fecha y horario concretos. clase Pista: representa una de las pistas del centro deportivo.

Es justo reconocer que la clase Extra nos viene bien para representar relaciones de generalización en la práctica, pero podría obviarse e introducir Árbitro y Material por separado dado que, según la perspectiva con que acometas el diseño, es discutible que por ser ambos ‘extras’ deban descender de una clase base común.


clase Socio: representa a un usuario socio del club. clase Extra: representa un extra alquilado junto con la pista.

clase Material: representa un material (balón, peto, etc.) clase Árbitro: representa un árbitro.

Relaciones entre clases_________________________________________ Una vez establecidas las clases del sistema, estudiemos las relaciones que existirán entre las mismas.

Recordemos que existen tres tipos básicos de relaciones entre clases: asociaciones, dependencias y generalizaciones.

Consideramos necesario establecer las siguientes asociaciones:

▪ Reserva con Socio: una reserva debe ser ineludiblemente realizada por un socio. La asociación tendrá la cardinalidad

Reserva (0..*) --- (1) Socio

Es decir, una reserva necesita de un socio que la haya realizado, y un socio puede estar asociado a cero o más reservas. ▪ Reserva con Pista: una reserva siempre se realiza para una pista concreta. La asociación tendrá la cardinalidad

Reserva (0..*) --- (1) Pista

Es decir, una reserva siempre está asociada a una pista y una pista puede estar asociada a ninguna, una o varias reservas.

Una relación de asociación entre dos clases se da cuando una o ambas de las clases debe/n tener conocimiento de la otra para poder funcionar correctamente.

Una relación de agregación es un tipo especial de relación de asociación entre dos clases que se da cuando una de las clases contiene instancias de la otra clase.


Hemos establecido la siguiente agregación:

▪ Reserva con Extra: una reserva puede incluir o no extra. La asociación tendrá la cardinalidad

Reserva (0..*) --- (0..*) Extra

Es decir, una reserva puede incluir o no extras y un extra concreto puede estar asignado a ninguna, una o varias reservas distintas si no coinciden el mismo día a la misma hora.

Hemos establecido las siguientes generalizaciones:

▪ Extras con Árbitro: un árbitro es un Extra que además incorpora información de contacto del árbitro. ▪ Extras con Material: un material es un Extra que además incorpora información acerca de la fecha de revisión, etc.

Diagrama de clases____________________________________________

Una relación de generalización entre dos clases se da cuando las instancias de la clase especializada (descendiente) pueden sustituir a las instancias de la clase general (padre). El hijo hereda la estructura y funcionalidad del padre, extendiéndola con nuevos comportamientos.


Ejerc ic io 2 .2

Ident i f i cac ión de atr ibutos y operaciones

- Identifica los atributos y métodos fundamentales de cada una de las

clases descritas. - Elige el tipo de datos apropiado para cada atributo, así como la

cantidad, nombre y tipo de parámetros que recibirá cada método junto con el tipo de datos devuelto, si corresponde.

- Establece la visibilidad (pública, privada, etc) para cada uno de los

atributos y métodos de cada clase.



Ident i f i cac ión de atr ibutos y operaciones

Identificación de atributos y operaciones________________________ Recordemos que idealmente los atributos de una clase no deben ser directamente accesibles por el resto de objetos. Esto se conoce como encapsulación de datos y permite proteger los datos de accesos indebidos, verificar que los datos se encuentran entre los valores aceptables, etc. Para favorecer la encapsulación, consideraremos que la visibilidad de todos los atributos debe establecerse, pues, como private (símbolo – en el diagrama de clases).

Otra consideración es que para simplificar el diagrama de clases, no vamos a representar las operaciones que permiten obtener y establecer los atributos de la clase: los llamados getters y setters. Por ejemplo, si tenemos un atributo fecha con visibilidad private, deberíamos a su vez tener dos operaciones, getFecha() y setFecha(). Estas operaciones se presuponen si tenemos un atributo establecido como private. Finalmente, comentar que generalmente existirá una relación directa entre la visibilidad establecida en el diagrama de clases y la que existirá en la implementación del sistema: Si declaramos un atributo private, en principio se implementará con dicha visibilidad en el lenguaje elegido. (tener en cuenta que si trabajamos con un lenguaje de programación que soporte las propiedades, como C#, estos atributos tendrían visibilidad public)

Establezcamos y justifiquemos, pues, los atributos y métodos de cada una de las clases estudiadas.

Ten en cuenta que si bien existe una relación entre los diagramas de UML y el código final de la implementación, en general no es posible una transformación directa completa, y habrá que tener en cuenta múltiples consideraciones para pasar del modelado UML al código final.


clase Extra: - precioAlquiler: Integer Coste de alquilar el extra. - disponible: Boolean

Indica si el extra está disponible o no. Necesario dado que muchos elementos (balones, redes, marcadores…) podrían dañarse y necesitar un tiempo para ser reparados.

clase Material: - tipo: String Tipo de material: balón, red, peto… - fechaRevisión: String Fecha de la última revisión del material clase Árbitro: - nombre: String - apellidos: String - teléfono: String Información de contacto necesaria para localizar al árbitro.

clase Reserva: - fecha: String Fecha de la reserva - hora: String Hora de la reserva - getPrecio(): Integer Este método recorre el listado de extras asociado a la reserva sumando el valor precioAlquiler de cada uno de ellos para obtener el coste total de la reserva. clase Pista: - nombre: String Nombre con el que designamos a la pista: “Pista 1”, “Pista 2”, etc. - tipo: String Tipo de pista: “Tenis”, “Fútbol sala” o “Baloncesto”

Puedes asignar estos atributos y propiedades en el diagrama de StarUML o utilizar un documento aparte.


- disponible: Boolean Indica si la pista está disponible o no, por mal estado, reparaciones, etc. clase Socio: - nombre: String - apellidos: String - NIF: String - dirección: String - teléfono: String Información de contacto necesaria para localizar al socio. - fechaAlta: String Fecha de alta del socio en el club.

Fíjate como no hemos incluído los atributos que están representados por las relaciones, pues es redundante en este momento del diseño. Por ejemplo, Reserva necesita de un atributo idSocio que identifique al socio, pero este atributo ya está representado por la relación de asociación existente entre Reserva y Socio.

Como ves prácticamente no hemos incluído métodos y por tanto las clases no representan el ideal de una clase que incorpora funcionalidad propia. Sin embargo esto es común en los sistemas de gestión y similares, fuertemente orientados a los datos.


Ejerc ic io 3

Diagramas de secuencia

Introducción_______________________________________ Recordemos que los diagramas de secuencia muestran un conjunto de instancias de objetos y los mensajes que intercambian entre sí durante una actividad o caso de uso concretos.

Durante la etapa de modelado del diagrama de clases, identificamos las clases fundamentales del sistema e hicimos un diseño preliminar. Con los diagramas de secuencia profundizaremos un nivel más en el nivel de detalle del diseño, pues ahora identificaremos las operaciones necesarias y, si es necesario, efectuaremos las modificaciones correspondientes asignando las nuevas operaciones a las clases enunciadas anteriormente. Si hasta este punto establecimos “por encima” como se relacionarían las clases entre sí, ahora es el momento de detallar esa relación más detalladamente. Hagamos memoria y recordemos los componentes fundamentales de un diagrama de secuencia: objetos y mensajes. Los objetos se alinean horizontalmente y una línea de vida vertical muestra la “duración” del objeto o lo que es lo mismo, el paso del tiempo. Los objetos intercambian mensajes entre sí y los mensajes acontecen de arriba hacia abajo, de modo que debemos comenzar a leer el diagrama desde arriba. Adicionalmente, podemos tener actores, que son el mismo ente y tienen la misma función que los utilizados en el correspondiente diagrama de casos de uso. Por último, debemos debemos considerar la inclusión de las rutas alternativas -excepciones en la plantilla de descripción del caso de uso- con cuidado. Recuerda que en estos diagramas el objetivo es ejemplificar el funcionamiento y por tanto pueden omitirse detalles superfluos que serían evidentes de cara a la implementación. Lo más apropiado es basarnos en la relevancia de los distintos flujos de comportamiento a la hora de considerar su inclusión en los diagramas.

Elaboraremos un diagrama de secuencia por cada caso de uso que hayamos identificado.


Con estas nociones vamos a acometer el modelado de algunos de los casos de uso elaborados anteriormente.


Anexo:

Diagramas de secuencia en StarUML

Para crear un diagrama de secuencia…___________________ Haz clic con el botón derecho del ratón sobre <<implementationModel>> en la ventana Model Explorer y elige la opción SequenceDiagram:

Cambia a la vista Diagram Explorer y haciendo clic sobre el diagrama recién creado se mostrarán sus propiedades en la ventana Properties. Aquí podrás nombrar el diagrama con la propiedad Name, y activar o desactivar la numeración automática de los mensajes entre objetos con la propiedad ShowSequenceNumber (en los diagramas mostrados en este documento esta opción está desactivada). Además, la opción MessageSignature te permite establecer si se muestran los parámetros de los métodos empleados en los mensajes entre objetos en la vista del diagrama. Es recomendable dejarlo en TYPEONLY.


Para añadir elementos al diagrama… ____________________ Utiliza la paleta de herramientas Sequence situada en el lado izquierdo de la pantalla, en la ventana Toolbox: Object: Para añadir nuevos objetos al diagrama. Stimulus: Añade un mensaje de un objeto a otro. Para ello haz clic sobre el objeto que emite el mensaje y arrastra hasta el objeto que recibe el mensaje. SelfStimulus: Añade un mensaje enviado por un objeto a sí mismo. Haz clic sobre el objeto para añadirlo. Combined Fragment, Interaction Operand: Cuando estudies las descripciones de los casos de uso, verás que en ocasiones es necesario implementar alternativas (es decir, seguir distintos comportamientos según determinadas condiciones), bucles, etc. El estándar UML soporta la notación correspondiente para estos casos; en StarUML, podemos modelar estos comportamientos con las herramientas Combined Fragment e Interaction Operand. Sigue estos pasos para añadir un bucle o condición alternativa (if) a un diagrama:

1. Elige la herramienta Combined Fragment 2. Arrastra sobre el diagrama para crear un recuadro 3. Elige en el panel Properties el tipo de operador (InteractionOperator)

entre seq, alt, loop, etc. Puedes utilizar: alt para representar una alternativa (if) loop para representar un bucle Etc.

4. añade nuevas condiciones con la herramienta Interaction Operand. Para ello deberás seleccionar en primer lugar el Combined Fragment, elegir luego la herramienta Interaction Operand y hacer clic sobre el Combined Fragment.

5. teclea la expresión de guarda en el campo Guard:


Para configurar los mensajes entre objetos… _____________ Haz clic en el mensaje, accede al panel Properties y podrás configurar el mensaje: Nombre del mensaje

En Name puedes establecer el texto que mostrará el mensaje. Tipo de mensaje En ActionKind puedes establecer el tipo de mensaje, entre los siguientes: CALL llamada a un método del objeto SEND llamada a un método del objeto, de forma asíncrona RETURN devolución de un valor al objeto llamante CREATE creación de un objeto DESTROY destrucción de un objeto

Argumentos En Arguments podemos introducir los nombres de los argumentos del mensaje separados por comas. Valor de retorno En Return podemos establecer el nombre asignado al valor de retorno.


Ejerc ic io 3 .1

Diagramas de secuencia

- Realiza el modelado del diagrama de secuencia correspondiente a los

casos de uso contemplados anteriormente. Deberás representar la secuencia de pasos seguidos en el caso de uso en forma de mensajes entre los objetos del diagrama.

Recuerda que es más importante garantizar que el diagrama sea comprensible y asimilable que que represente una correspondencia exacta con la futura implementación de las interacciones descritas entre los objetos que aparecen en el mismo.



Inicio de sesión_______________________________________________

¡

Mi diagrama no

se parece en nada a esto

!

Ten en cuenta que los diagramas de secuencia (cualquier tipo de diagrama en UML en general) pueden realizarse de diversas maneras en función del enfoque con el que se acomete el modelado. Tu diagrama puede ser muy distinto y ser perfectamente válido, mientras sea consistente con el planteamiento que hayas elegido.

▪ Hemos considerado al usuario de la aplicación como un objeto, creando una línea de vida para él. (En general se le representa en estos casos con un muñeco, pero StarUML no permite tal representación). ▪ Representamos la interacción del usuario con la interfaz del sistema por medio de mensajes.

De este modo, iniciarSesión no es estrictamente un mensaje que manda Usuario a Sistema (evidentemente Usuario no es un componente software) sino que queremos representar la acción, por parte del usuario, de insertar un nombre y una contraseña y pulsar el botón “Iniciar sesión”. Estos pasos podríamos haberlos representado así:


Pero, con idea de simplificar los diagramas, hemos optado por no representar la interacción entre el usuario y la interfaz salvo para indicar la acción genérica.

También podríamos haber excluído el objeto Usuario y trabajar con el objeto

Sistema como objeto que se autoenvía mensajes, tal como iniciarSesión. Si establecemos que en tal caso, Sistema representaría la interfaz de la aplicación de cara al usuario, no habrá ningún problema.

▪ Al dibujar un valor de retorno desde Sistema hacia Usuario queremos representar un mensaje que el usuario recibe de forma visual en la interfaz del sistema. Por ejemplo, mensaje error en el diagrama de inicio de sesión representa un mensaje del tipo “Error, la cuenta indicada no existe” o similar. ▪ Utilizamos el objeto conexiónBaseDatos para representar el enlace existente entre Sistema –la aplicación- y la base de datos. En la implementación real del sistema, existirán una o varias clases que nos permitan obtener y almacenar información en la base de datos; pero en este momento del diseño, aún no sabemos como se implementará esta funcionalidad. Además, de éste modo podemos representar genéricamente la conexión mencionada haciendo más comprensible el diagrama.

Como ves es posible elegir distintos planteamientos a la hora de modelar los diagramas. Lo importante es ceñirte al planteamiento que elijas durante todo el modelado, es decir, que los diagramas sean consistentes unos con otros. Disponemos de libertad para representar las interacciones, siendo el objetivo fundamental que los diagramas simbolicen y ejemplifiquen el funcionamiento del sistema para un caso de uso determinado.

Sé consciente de que el modelado no tiene porqué ser una correspondencia directa con el comportamiento final del sistema. Lo fundamental, como hemos comentado, es simbolizar el comportamiento del sistema aunque luego la implementación real pueda ser distinta.


Otra opción válida sería utilizar un objeto Cuenta para representar las cuentas de la base de datos, por ejemplo. En general, no obstante, suele emplearse un objeto genérico que simboliza la conexión entre el sistema y la base de datos. Como hemos comentado repetidamente, cualquier opción elegida será válida si como consecuencia obtenemos diagramas comprensibles y coherentes.

¡

Pero no hemos incluído clases

como conexiónBaseDatos

o Sistema en el diagrama de clases

!

En el diagrama de clases incluímos las clases que representaban la funcionalidad específica de nuestro sistema, abstrayéndonos a un nivel por encima de la implementación real. En ésta, habrá muchas otras clases requeridas para que el sistema funcione.

▪ En getCuenta(usuario, contraseña) hemos especificado los argumentos para dejar claro que queremos obtener una cuenta con el nombre de usuario y contraseña facilitados por el usuario. ▪ Hemos empleado un CombinedFragment para representar una alternativa: si existe la cuenta continuamos con el inicio de sesión; en caso contrario, respondemos con un mensaje de error.

Fin de sesión_______________________________________________

▪ El sistema se comunica con la base de datos para finalizar la sesión y almacenar de este modo la hora de finalización de la misma.

Ahora que has visto como hemos representado la interacción del usuario con el sistema, y la comunicación entre el sistema y la base de datos, tal vez quieras remodelar el resto de diagramas que hayas modelado adaptándolos a este planteamiento, para comprobar después si tu resultado es similar al que mostramos aquí.


Crear cuenta de usuario________________________________________

▪ crearCuenta representa la acción del administrador de elegir el comando “Crear cuenta” una vez introducidos los datos de la misma. ▪ Fíjate como utilizamos un SelfStimulus de StarUML para representar la validación que hace el sistema de los datos facilitados para la cuenta. Almacenamos el resultado en la booleana VALIDOS para utilizarlo en la alternativa insertada a continuación. Si los datos no son válidos se emitirá un mensaje de error. ▪ Si los datos son válidos el sistema verifica si la cuenta ya está asociada a un Usuario. (Si existe una cuenta con los mismos valores de usuario y contraseña debe emitirse un error) ▪ Si la cuenta no existe, se crea la nueva cuenta en la base de datos y se emite una confirmación. ▪ Como ves, hemos representado en el diagrama todos los requisitos exigidos en la creación de cuentas, dejando constancia de su relevancia en el proceso de creación de una cuenta.


Consultar cuenta de usuario______________________________

▪ Recuerda que para consultar una cuenta, el administrador elige la cuenta de un listado que muestra las cuentas existentes en el sistema, por lo cual la cuenta obtenida siempre será válida; no necesitamos, pues, considerar la posibilidad de error. ▪ Fíjate como almacenamos la referencia a la cuenta obtenida de la base de datos en cuentaActual. Si recuerdas en los requisitos se establece que desde la pantalla de consulta de una cuenta, debe ser posible guardar cambios y eliminar la cuenta en sí. Para ello es conveniente mantener una referencia a la misma (aunque podríamos obtenerla de nuevo en caso necesario). Pero encontrarás una justificación extra en el diagrama de edición de cuenta de usuario.

Para obtener una representación visual como la que ves en el diagrama (cuentaActual:=cuenta), observa la representación de las propiedades del mensaje en StarUML:


Editar cuenta de usuario______________________________

▪ Este gráfico es bastante parecido al de creación de una cuenta, como puedes observar. Crear una cuenta consiste en el fondo en editar una cuenta que simplemente aún no existe en la base de datos. ▪ Al editar una cuenta, Administrador modifica ciertos campos y pulsa el botón “Actualizar cuenta”, “Guardar cambios” o similar. ▪ Fíjate como se comprueba de nuevo la validez de los datos –por ejemplo, que en el campo apellidos figure algún dato- y se emite error en caso de que éstos no sean válidos. ▪ Tras comprobar la validez de los datos se verifica que (usuario, contraseña) no coinciden con una cuenta que no sea la actual: Fíjate que la guarda

(cuenta = NULL) O (cuenta=cuentaActual)

Verifica:

(cuenta = NULL) no hay ninguna cuenta en la base de datos que utilice los valores (usuario, contraseña) actuales


O (cuenta=cuentaActual) sí hay una cuenta con esos valores, pero se trata de la cuenta actual.

De este modo, soportamos la posibilidad de cambiar los valores asignados a usuario y contraseña, pero haciendo las necesarias comprobaciones para que no exista conflicto del par (usuario, contraseña) con otras cuentas. En este caso, cuentaActual representa la cuenta que habremos obtenido anteriormente al consultar una cuenta y que se almacenaría como una variable en Sistema. Eliminar cuenta de usuario______________________________________

▪ De forma similar a como ocurría con el diagrama consultar cuenta de usuario, este diagrama es bastante sencillo, dado que la opción eliminar cuenta sólo está disponible, según los requisitos del sistema, desde la pantalla de consulta. Así, pasaremos a la base de datos la cuentaActual que habremos obtenido anteriormente al efectuar una consulta.

Fíjate como en los diagramas de gestión de cuentas de usuario no incluímos código para verificar que el usuario es administrador. Recuerda que en los requisitos se especifica que las opciones de gestión de cuentas de usuario sólo están disponibles una vez el usuario ha iniciado sesión como administrador. Además, hemos nombrado al objeto que inicia la interacción como Administrador.

Ahora que has visto cómo hemos realizado el modelado de la gestión de cuentas de usuario, te propongo que modeles diagramas de secuencia para la gestión de socios y la gestión de reservas, considerando cuidadosamente todos los requisitos que figuran en el enunciado del sistema. Envíalos al tutor si tienes alguna duda o si quieres recibir su opinión.

3.1


Ejerc ic io 4

Diagramas de act iv idades

Introducción_______________________________________ Los diagramas de actividades son muy similares a los conocidos diagramas de flujo de siempre, que se utilizaban –y se siguen utilizando claro está- para representar algoritmos o procesos en el diseño de un sistema. Podemos utilizarlos para estudiar casos de uso o actividades concretas de nuestro sistema. Una característica muy importante y diferenciadora de estos diagramas es que permiten modelar comportamientos paralelos, es decir comportamientos que pueden tener lugar en cualquier orden y de forma simultánea o no. Esto permite una mayor libertad a la hora de expresar flujos o procesos, facilitando además la comprensión del sistema.

Identificar estos flujos paralelos puede darnos pistas importantes sobre cómo implementar correctamente en el sistema la actividad concreta que estamos modelando.

Por ejemplo, en el proceso de emisión de una factura, es irrelevante, de cara al resultado obtenido, si imprimimos en primer lugar los datos del titular de la cuenta y luego los datos de la factura, o si lo hacemos al revés, o incluso si lo hacemos simultáneamente.


Anexo:

Diagramas de act iv idades en StarUML

Para crear un diagrama de actividades…_________________ Haz clic con el botón derecho del ratón sobre <<deploymentModel>> en la ventana de exploración de modelos y elige la opción Activity Diagram:


Para añadir elementos al diagrama… ____________________ Utiliza la paleta de herramientas Activity situada en el lado izquierdo de la pantalla, en la ventana Toolbox: Breve descripción de algunas herramientas: ActionState: Utilízalo para añadir acciones al diagrama. InitialState: Sirve para marcar el inicio de la actividad. FinalState: Sirve para marcar el final de la actividad. Synchronization: Sirve para designar un punto donde varias tareas confluyen. Al llegar al punto de sincronización, las tareas deben haber finalizado. Decision: Vital para insertar alternativas en el flujo del diagrama. Transition: Úsalo para enlazar actividades entre sí. Arrastra desde una actividad a la otra para crear la transición. Una vez seleccionada una transición, utiliza el campo GuardCondition que encontrarás en la ventana Properties para establecer la condición de guarda. Esto es fundamental en el caso de utilización de alternativas (herramienta Decision) y opcional en el resto de los casos. Swimlane: Muy útil para separar las actividades en función del objeto que las realiza (el usuario, el sistema, etc.)


Ejerc ic io 4 .1


- Modela los siguientes diagramas de actividades que representen el

comportamiento de las funcionalidades básicas del sistema, como:

- Inicio de sesión

- Fin de sesión

- Creación de una nueva cuenta

- Edición de una cuenta

- Alta de una reserva

- Consulta de una reserva

- Etc.




Iniciar sesión_________________________________________________

▪ Como ves, hemos utilizado swimlanes para que el diagrama muestre con claridad quién realiza qué en la actividad.

Considera variaciones que en este caso serían válidas, como unir “Introducir datos de usuario” y “Seleccionar ‘Iniciar sesión’” en un único ActionState, dado que la única opción disponible una vez introducidos los datos de usuario es seleccionar el comando de inicio de sesión. Se ha hecho así para que los diagramas sean consistentes entre sí.


Creación de cuenta de usuario___________________________________

▪ En este caso, al contrario que en el diagrama de secuencia correspondiente, hemos incluído la acción de elegir el comando “Crear cuenta” para acceder a la interfaz de creación de cuentas. Recuerda que en el diagrama de secuencia una precondición era encontrarse ya en la interfaz correspondiente. ▪ Fíjate como hemos utilizado sincronizaciones para actividades que tienen un punto de finalización común.

Modela el resto de diagramas de actividades propuestos. Envíalos al tutor para su corrección.

4.1

Documents

Practica Uml