Programacin orientada a objetos y UML Prctica Gestin de un club deportivo

Introduccin a la prctica
Para las prctica de este curso vamos a realizar el anlisis y diseo inicial de una aplicacin de gestin de un club deportivo. Una aplicacin de este tipo puede ser muy simple o muy compleja, dependiendo de los parmetros y caractersticas cuya gestin deseemos automatizar. En nuestro caso, simplificaremos bastante los supuestos para evitar elevar tanto la dificultad de la prctica, como el tiempo necesario para su desarrollo.

Cmo realizar la prctica

La prctica se divide en ejercicios que debes desarrollar, cada uno dedicado a un tema especfico del curso. Estos ejercicios estn planteados de forma secuencial e incremental: cada ejercicio se desarrolla sobre el resultado obtenido en el anterior. Tras una breve introduccin inicial a cada ejercicio, se presenta una explicacin de la funcionalidad necesaria en StarUML, la aplicacin que utilizamos para realizar los diagramas. A continuacin, se presenta el enunciado del ejercicio seguido de la solucin parcial a los ejercicios propuestos: no se presentan todos los diagramas, sino algunos que puedes utilizar como indicacin para realizar el resto. No obstante, es recomendable que realices los ejercicios por tu cuenta desde el principio y a continuacin compares tu resultado con el que se incluye en la solucin de la prctica. Tras la solucin presentada para los ejercicios propuestos, se proponen otros ejercicios cuya solucin no viene includa pero que deben resultarte ms sencillos si has asimilado lo ejemplificado en los ejercicios resueltos. Es muy recomendable que realices los ejercicios propuestos y, si lo consideras conveniente, los enves al tutor para que ste te d su valoracin.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

La metodologa empleada en el modelado de un sistema en UML puede cambiar mucho entre distintas empresas, usuarios o filosofas de trabajo. Ten en cuenta que otras aproximaciones distintas a la aqu presentada para el anlisis y diseo del sistema que enunciaremos pueden producir resultados distintos, pero igualmente vlidos.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Anexo: Introduccin a StarUML

Acerca de StarUML__________________________________
Para elaborar las prcticas hemos utilizado el programa de modelado de diagramas StarUML. Es un programa de cdigo abierto gratuito de bastante calidad, y es recomendable que desarrolles las prcticas del curso sobre el mismo si no posees otra herramienta cuyo manejo ya domines. Ten en cuenta que slo est disponible para Windows. Si trabajas con otro sistema operativo, debers elegir alguna alternativa, como ArgoUML.

Puedes obtener el programa en la direccin web http://staruml.sourceforge.net/en/

La interfaz y la ayuda estn en ingls, pero an as hemos elegido StarUML frente a otras alternativas (como ArgoUML) en vista de las limitaciones que dichos programas alternativos imponan a la hora de realizar los diagramas (bsicamente, muchas funcionalidades implementadas a medias).

Durante el manejo del programa es probable que te topes con algunos escollos e incongruencias que no estn bien resueltas, como la seleccin de elementos. Ten en cuenta que se trata de un programa gratuito que adems est lejos de representar una versin definitiva.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Si te desenvuelves aceptablemente bien con el ingls, te recomiendo que consultes la documentacin del programa para comprender mejor el uso de las herramientas. La documentacin es concisa pero muy til y muestra muchos atajos para crear diagramas de forma ms eficiente.

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

Nota: cambiando el tipo de lnea dibujada al enlazar elementos

Al trabajar con los diferentes tipos de diagramas en StarUML, observars que existen herrramientas para relacionar smbolos entre s (diagrama de clases), enviar mensajes de un objeto a otro (diagramas de secuencia), etc. StarUML representa estas relaciones, mensajes, etc. con lneas de diversos tipos. Existen dos modos de dibujo disponibles para estas lneas: oblicuas y rectilneas. En los diagramas de este documento utilizamos la representacin rectilnea, pues es ms clara y ordenada que la oblicua. Cuando aadas una de estas lneas de conexin 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 mens del programa. Esta caracterstica tambin puede establecerse globalmente en el cuadro de dilogo ToolsOptions.

Nota: desactivando el tamao automtico de los elementos___

Si al intentar modificar el tamao de algn elemento ves que no es posible, prueba a desactivar la opcin Auto Resize que est activada por defecto. De este modo, podrs cambiar el tamao sin problemas, ajustndolo a las necesidades del diagrama.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Enunciado Requisitos del sistema

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 aadiendo cdigo al sistema, tales como utilizar un lenguaje o base de datos especfico, etc. En sta prctica slo consideraremos los requisitos funcionales.

Requisitos funcionales de la aplicacin Gestor de Club Deportivo

En esta prctica realizaremos el anlisis y diseo de una hipottica aplicacin que permita gestionar algunos aspectos de un club deportivo privado. En concreto, la aplicacin permitir la gestin de socios y de reservas de instalaciones y extras para las reservas, tales como un rbitro, materiales (balones, petos), etc. Esta gestin la llevarn a cabo los empleados del club destinados a tal efecto. Adems, habr un usuario administrador que gestionar las cuentas de usuario de estos empleados en el sistema. Una aplicacin real (tal y como las que se encuentran en el mercado) soportara la gestin de otros aspectos, como el personal del club, la contabilidad, gestin de stock y materiales, etc. Como hemos comentario anteriormente, hemos simplificado en este sentido los requisitos para no dificultar en exceso la prctica, permitiendo que puedan realizarse en un tiempo razonable. A continuacin enumeramos los requisitos funcionales del sistema: Sistema El sistema slo permite una sesin de usuario activa en todo momento. Esto significa que para que el usuario actual debe finalizar su sesin para que otro usuario inicie sesin. Es necesario iniciar sesin como usuario del sistema antes de poder hacer uso de cualesquiera de sus funcionalidades. Al finalizar una sesin, el sistema mostrar la pantalla de inicio de sesin de nuevo. El sistema almacenar la siguiente informacin acerca de cada sesin: hora de inicio, hora de finalizacin y usuario. El sistema utilizar una base de datos para almacenar los datos de cuentas de usuario, socios, reservas y materiales.
5

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

El sistema emitir un mensaje de confirmacin siempre que la realizacin de alguna operacin 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 podrn realizar la gestin de cuentas de usuario exclusivamente. Los usuario genricos usuario podrn realizar la gestin de socios, gestin de reservas y gestin de materiales exclusivamente.

Gestin de cuentas de usuario La gestin de cuentas de usuario consistir en la posibilidad de creacin, consulta, edicin y eliminacin 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 debern facilitar al sistema los siguientes datos, como mnimo: nombre y apellidos del empleado, tipo de empleado, nombre de usuario y contrasea. En cualquier momento el administrador podr salir de la interfaz de creacin de cuentas o bien utilizar un botn 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 botn Ver datos cuenta o similar. Las opciones de edicin y eliminacin de una cuenta estarn disponibles en la pantalla que muestre los datos de la cuenta, mediante botones Guardar cambios y Eliminar cuenta o similares. Tambin existir la opcin Salir para volver al men principal. Al editar los datos de una cuenta (tanto en la creacin inicial de la cuenta como al cambiar algn dato de la misma) el sistema comprobar: - que no falta ningn dato de los requeridos - que el conjunto usuario/contrasea no pertenece a los de otra cuenta ya existente

Gestin de socios La gestin de socios consistir en la posibilidad de efectuar altas y bajas de socios, as como la consulta y edicin 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 debern facilitar los siguientes datos como mnimo: nombre y apellidos del futuro socio, direccin, telfono, NIF. Al socio se le asignar un nmero 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 botn Ver datos socio o similar. Las opciones de edicin y eliminacin de los datos de un socio estarn disponibles en la pantalla que muestre los datos del mismo, mediante botones Guardar cambios y Eliminar socio o similares.
6

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Al editar los campos de un socio (tanto en el alta inicial como al cambiar algn dato) el sistema verificar que no existe ningn socio con el mismo valor del NIF. El resto de campos puede ser idntico.

Gestin de reservas La gestin de reservas consistir en la posibilidad de efectuar altas y cancelaciones de reservas, as como la consulta y edicin 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 debern facilitar los siguientes datos como mnimo: nmero de socio, fecha y hora, tipo de pista (baloncesto, tenis). Adems, se verificar que el usuario es socio del club (nmero de socio vlido) 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 botn Ver datos reserva o similar. Las opciones de edicin y cancelacin de los datos de un reserva estarn 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 algn 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). Tambin se verificar que los extras asociados estn disponibles. Al editar una reserva, ser posible a su vez aadir o eliminar extras como balones, raquetas, etc. a la misma. Las pistas se denominarn por un nombre que permita tanto al usuario como al personal de las instalaciones hacer referencia a las mismas (por ejemplo: pista1 de baloncesto).

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Gestin de extras Es posible alquilar una serie de extras al hacer una reserva. Estos sern: balones, petos, etc. Debe tenerse en cuenta que un extra puede no estar disponible si est en reparacin. La gestin 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 edicin de los datos de los mismos (por ejemplo, para marcar un material como no disponible por estar en reparacin, 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 debern facilitar los siguientes datos como mnimo: 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 botn Ver datos extra o similar. Las opciones de edicin y eliminacin de los datos de un extra estarn disponibles en la pantalla que muestre los datos del mismo, mediante botones Guardar cambios y Eliminar extra o similares.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Anexo: Preparacin del proyecto en StarUML

Para crear un proyecto en StarUML____________________

1. 2. Elige el comando FileNew Project Establece las propiedades bsicas del proyecto en la ventana Properties:

3.

Guarda el proyecto con un nombre adecuado, como prctica.uml, gestin club.uml o similar.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

Ejercicio 1 Casos de uso

Introduccin_______________________________________
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 caractersticas. En otras ocasiones, desde el primer momento se establece una comunicacin entre el cliente y el desarrollador para determinar qu funcionalidad debe incluir el sistema. Tambin es posible y muy comn, recibir una especificacin inicial de los requisitos, pero mantener simultneamente conversaciones con el cliente y/o los potenciales usuarios del sistema, para determinar de la mejor forma posible qu caractersticas deben implementarse, y cmo. Aunque existen distintas aproximaciones para realizar el anlisis 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 tpicas entre los usuarios y el sistema. Otra razn por la cual los diagramas de casos de uso son excelentes para realizar el anlisis y diseo 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 diseo modelando las clases o la secuencia de comportamiento del sistema, por ejemplo. Es por ello que comenzaremos nuestra aproximacin al diseo del sistema modelando estos diagramas. Podramos 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 anlisis 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 descripcin de las acciones que el usuario acomete en el sistema, con objeto de conseguir cierto objetivo. Estudiando los escenarios tpicos en los que interaccionarn usuario y sistema, obtendremos los casos de uso que debemos modelar. En la preparacin de los casos de uso debemos, pues, analizar la interaccin 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 errneos (por ejemplo, el alta no es posible pues el socio ya est dado de alta).

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

10

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 comn a varios casos de uso como un nuevo caso de uso que puedan ser includo por los primeros. Se utiliza la relacin <<includes>> para representar el caso en que un caso de uso incluye el comportamiento de otro.

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 realizacin, al menos en una ocasin, del comportamiento representado por el caso de uso hacia el que apunta la flecha.

Una estrategia comportamiento comportamiento para merecer un

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

Asmismo, 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 relacin <<extends>> para representar el caso en que un caso de uso es extendido por otro.

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 realizacin, en una o ms ocasiones, del comportamiento representado por el caso de uso hacia el que apunta la flecha.

Una vez enunciados los casos de uso y realizados los correspondientes diagramas, llegamos al momento en el que debemos describir ms 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 metodologa y el planteamiento considerados.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

11

Este paso es importante: ten en cuenta que los diagramas de interaccin que modelaremos ms adelante se basarn directamente en la descripcin de los casos de uso.

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: descripcin de la situacin en la que el caso de uso finaliza con el actor habiendo conseguido su objetivo. Los flujos alternativos o excepciones: situaciones alternativas, errneas, etc.

Es posible y/o necesario, segn el tipo de proyecto o su magnitud, describir otras caractersticas, pero en nuestro caso nos ceiremos a las aqu enunciadas.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

12

Ejercicio 1.1 Identificacin de actores y casos de uso

Identifica los actores que interactan con el sistema. Identifica los casos de uso fundamentales del sistema y enumralos asignando un ttulo y una frase o prrafo 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 efecta la consulta de datos de un socio.

Agrupa en paquetes, si es posible, los casos de uso relacionados entre s. de modo que ms adelante podamos elaborar un diagrama de casos de uso global en el que representaremos dichos paquetes, para dar una visin global del sistema.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

13

Solucin al Ejercicio 1.1

Actores__________________________________ Tras analizar los requisitos del sistema, es evidente que sern necesarios dos actores en el modelado de los casos de uso: el usuario normal de la aplicacin y el usuario administrador. El primero hace referencia al empleado del club que maneja la aplicacin informtica 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. Hemos decidido no representar el actor Socio dado que no interviene directamente en la interaccin con el sistema. Por supuesto, es necesario contar con su participacin en la mayora 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 ms adelante.

Pero, y que hay de los socios del club

En este caso los actores son personas fsicas, pero tambin pueden ser otros sistemas, hardware o software.

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. edicin de extras El usuario edita los datos de un extra concreto.
14

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

alta de nuevos socios El usuario efecta el alta de un nuevo socio en el sistema. baja de socios El usuario efecta la baja en el sistema de un socio del club. consulta de socios El usuario consulta los datos de un socio del club. edicin de socios El usuario edita los datos de un socio concreto.

1.1
Prueba a describir los casos de uso restantes, para la gestin de reservas y cuentas de usuario.

Paquetes_________________________________ La separacin en paquetes de los casos de uso anteriores es bastante sencilla, dado que estn fuertemente relacionados entre s por grupos: gestin de cuentas de usuario alta de cuentas de usuario consulta de cuentas de usuario edicin de cuentas de usuario baja de cuentas de usuario gestin de socios alta de nuevos socios consulta de socios edicin de socios baja de socios gestin de reservas alta de reservas consulta de reservas edicin de reservas baja de reservas gestin de extras alta de nuevos extras consulta de extras edicin de extras baja de extras

Podemos considerar cada uno de los tipos de gestin anteriores como un paquete de funcionalidades que a su vez incluir otros casos de uso. Programacin orientada a objetos y lenguaje unificado de modelado (UML)
15

Anexo: Diagramas de casos de uso en StarUML

Para aadir un diagrama de casos de uso_______________

Haz clic con el botn derecho del ratn sobre la carpeta <<useCaseModel>> y elige la opcin correspondiente:

Para aadir elementos al diagrama____________________

Utiliza la ventana de herramientas UseCase situada en el Toolbox. Una breve explicacin de las herramientas y cmo utilizarlas: (slo comentamos las que consideramos necesarias para esta prctica) UseCase: utilzala para representar un caso de uso. Debers 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 continuacin sobre un caso de uso que hayas dibujado para crear una asociacin entre ambos. DirectedAssociation: Es un tipo especial de asociacin que permite mostrar quin inicia la relacin en una asociacin. Por ejemplo, si un Usuario participa en un caso de uso Iniciar sesin podramos 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 sesin por l automticamente).

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

16

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 extensin del mismo), podemos representarlo con una relacin 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 includo tambin 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.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

17

Ejercicio 1.2 Modelado de diagramas 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 visin general de un proceso sin entrar en detalles de implementacin.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

18

Solucin al Ejercicio 1.2

Diagrama de casos de uso global_________________________________

Podemos ver como hemos representado cada uno de los paquetes de gestin. Adems, hemos includo los casos de uso iniciar sesin y finalizar sesin. Los casos de uso de gestin incluyen en inicio de sesin, es decir, necesitan que se haya iniciado sesin para poder tener lugar. Hemos visto que todo comportamiento comn se puede factorizar en un caso de uso propio, que sea incluido por otros posteriormente. Pero Son lo suficientemente importantes iniciar sesin y finalizar sesin como para considerarlos casos de uso en s? Bueno, un usuario puede iniciar sesin y finalizarla a continuacin, por ejemplo, sin realizar ninguna gestin. Este comportamiento ya servira 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 ceirnos a l durante todo el proceso de modelado.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

19

Porqu no se han includo iniciar sesin y finalizar sesin como casos de uso del sistema en el ejercicio anterior

Analizando los requisitos est claro que el usuario necesita iniciar sesin para realizar cualquier gestin, sin embargo no consideramos en su momento estos comportamientos como casos de uso en s. En esta fase del anlisis vemos que ese comportamiento es comn a toda gestin y por tanto lo separamos como un caso de uso especfico que los dems incluyen. Podemos volver atrs e incorporar esos casos de uso a los obtenidos inicialmente.

El diseo de un sistema es cclico en muchas de sus etapas.

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

Fjate como no hemos utilizado la relacin de generalizacin entre Usuario y Administrador. Administrador no puede considerarse una especializacin de Usuario porque no incorpora los comportamientos de ste. Recordemos que un Administrador slo puede gestionar las cuentas de usuario. Una vez modelado el diagrama de alto nivel, podemos descomponer cada uno de los paquetes en otros diagramas ms detallados.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

20

Gestin de cuentas de usuario___________________________________

Observa como en este diagrama no inclumos el inicio y finalizacin de sesin; es innecesario y resultara redundante dado que este diagrama representa la gestin de cuentas de usuario y el diagrama global ya expresa la relacin de dicho paquete con los casos de uso iniciar sesin y finalizar sesin. Fjate asmismo 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 edicin y eliminacin es necesario efectuar una consulta previa de la cuenta.

1.2
Te propongo que realices el modelado de los diagramas de casos de uso para la gestin de socios, gestin de reservas y gestin de extras.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

21

Ejercicio 1.3 Descripcin de los casos de uso

- Rellena el siguiente formulario para cada uno de los casos de uso modelados: Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal Nombre del caso de uso Objetivo del caso de uso Condiciones que deben ser satisfechas previamente a la ejecucin del caso de uso Condiciones que se dan una vez finalizado el caso de uso satisfactoriamente Actores que intervienen en el caso de uso 1 Paso 1 del caso de uso 2 Paso 2 del caso de uso n Paso n del caso de uso 1.1 Excepcin o comportamiento anmalo del paso 1 n.1 Excepcin o comportamiento anmalo del paso n

Excepciones

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

22

Solucin al Ejercicio 1.3

Inicio y finalizacin de sesin____________________________________ Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal iniciar sesin Autenticarse como usuario del sistema para acceder a los servicios del mismo El usuario se encuentra ante la pantalla de inicio de sesin del sistema El usuario ha iniciado sesin en el sistema administrador, usuario El usuario introduce sus datos de cuenta y pulsa el 1 botn Iniciar sesin El sistema valida los datos del usuario e inicia 2 sesin para el mismo El sistema muestra un mensaje de error si los 2.1 datos de usuario no corresponden a los de una cuenta del sistema finalizar sesin Finalizar la sesin del usuario activo Haber iniciado sesin en el sistema No hay sesiones activas en el sistema administrador, usuario 1 El usuario pulsa el botn Finalizar sesin El sistema finaliza la sesin del usuario actual y 2 presenta la pantalla de inicio de sesin

Excepciones

Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

23

Gestin de cuentas de usuario___________________________________ Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal crear cuenta de usuario Crear una nueva cuenta de usuario en la base de datos del sistema Haber iniciado sesin como administrador en el sistema Encontrarse en la interfaz de creacin de nueva cuenta El sistema ha almacenado en la base de datos una nueva cuenta de usuario administrador administrador introduce los datos de la nueva 1 cuenta y pulsa el botn Crear cuenta El sistema comprueba que no falta ningn dato 2 requerido El sistema comprueba que no existe una cuenta 3 que corresponda a los datos usuario/contrasea El sistema crea la nueva cuenta en la base de 4 datos El sistema confirma la creacin de la cuenta al 5 usuario El sistema muestra un mensaje de error 2.1 informando de que faltan datos requeridos o hay datos errneos El sistema muestra un mensaje de error si los 3.1 datos de la cuenta (usuario, password) corresponden a los de otra cuenta ya existente consultar cuenta de usuario Ver la informacin asociada a una cuenta de usuario existente en el sistema Haber iniciado sesin como administrador en el sistema Encontrarse en la interfaz de consulta de cuenta administrador administrador elige la cuenta que desea consultar 1 del listado de cuentas y pulsa el botn Ver cuenta El sistema muestra los datos actuales de la cuenta 2 pertinente

Excepciones

Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

24

Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal

Excepciones

editar cuenta de usuario Cambiar alguno o varios de los campos de una cuenta de usuario existente en el sistema Haber iniciado sesin como administrador en el sistema Encontrarse en la interfaz de consulta de datos de una cuenta El sistema almacena los cambios realizados en la base de datos administrador administrador modifica alguno o varios de los 1 campos asociados a la cuenta y pulsa el botn Actualizar cuenta, Guardar cambios o similar 2 El sistema valida los datos requeridos El sistema verifica que los valores (usuario, 3 contrasea) son nicos El sistema almacena los cambios en la base de 4 datos El sistema emite un mensaje de confirmacin 5 indicando que los cambios han sido realizados El sistema muestra un mensaje de error 2.1 informando de que faltan datos requeridos o hay datos errneos El sistema emite un mensaje de error si los valores 3.1 (usuario, contrasea) no son nicos eliminar cuenta de usuario Eliminar una cuenta de usuario determinada de la base de datos del sistema Haber iniciado sesin como administrador en el sistema Encontrarse en la interfaz de consulta de datos de una cuenta Se ha eliminado una cuenta de usuario de la base de datos administrador 1 administrador pulsa el botn Eliminar cuenta 2 El sistema elimina la cuenta de la base de datos El sistema emite un mensaje de confirmacin de 3 cuenta eliminada

Caso de uso Propsito Precondiciones Poscondiciones Actores Flujo principal

Los pasos 2 y 3 en los formularios crear cuenta y editar cuenta podran unificarse en uno nico y seguira estando correcto.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

25

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

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

26

Ejercicio 2 Anlisis y diseo de las clases del sistema

Introduccin_______________________________________________
El modelado de los casos de uso nos aporta informacin fundamental para establecer las clases del sistema y en menor medida, los atributos y operaciones de las mismas. En esta segunda fase pasaremos del anlisis inicial del sistema a un diseo preliminar, dado que el examen de los casos de uso nos proporcionar, como hemos comentado, informacin sobre las clases que vamos a necesitar. Recordemos de la parte terica que se denomina responsabilidad a la obligacin que posee una clase, el fin para el que fue creada. Tambin 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.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

27

Anexo: Diagramas de clases en StarUML

Para aadir un diagrama de clases_____________________

Haz clic con el botn derecho del ratn sobre la carpeta <<designModel>> y elige la opcin correspondiente:

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

28

Para aadir elementos al diagrama____________________

Utiliza la ventana de herramientas Class situada en el Toolbox. Una breve explicacin de las herramientas y cmo utilizarlas: (slo comentamos las que consideramos necesarias para los diagramas de esta prctica) Class: Para aadir una clase al diagrama. Association: Para aadir una relacin entre clases del tipo asociacin. Aggregation: Para aadir una relacin entre clases del tipo agregacin (recuerda que es un tipo particular de relacin de asociacin). Generalization: Para aadir una relacin entre clases del tipo generalizacin.

Para establecer la cardinalidad entre elementos __________

Cuando utilices alguna de las herramientas de relacin, puedes seleccionar la relacin recin creada y modificar las cardinalidades de la misma con los campos Multiplicity que encontrars en la ventana Properties.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

29

Para establecer los mtodos y atributos de una clase______

Haz clic sobre la clase en cuestin y a continuacin sobre el cuadro de edicin anexo a las propiedades Attributes y/o Operations en la ventana Properties. Vers un icono con unos puntos suspensivos, si haces clic sobre l se abrir la ventana de edicin de atributos u operaciones, en su caso.

Una vez abierta la ventana Collection Editor de la clase, podemos aadir, 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.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

30

Ejercicio 2.1 Enumeracin de clases y modelado del diagrama de clases

Enumera las clases fundamentales que deber incorporar el sistema basndote en los requisitos del mismo. Modela el diagrama de clases del sistema enunciado, integrando las clases recin elegidas. Elige y justifica el tipo de relacin adecuado entre las mismas (dependencia, generalizacin, asociacin). Establece la cardinalidad apropiada para cada una de las relaciones (uno a uno, uno a varios, etc.).

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

31

Solucin al Ejercicio 2.1

Eleccin de clases__________________________________________ Cmo podemos identificar las clases del sistema? En principio, cualquier entidad que identifiquemos que sea lo suficientemente importante o relevante, o que tenga asociada informacin que debamos contemplar deberamos tratarla como una clase. El resto de caractersticas 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 informacin asociada a una reserva (fecha, hora, nmero 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? Podran ser vlidos los dos casos, pero si vamos a almacenar los datos del rbitro en nuestro sistema (telfono, direccin) es conveniente tener una clase rbitro a la que podamos hacer referencia desde Reserva mediante la correspondiente relacin. Es ms, dado que en realidad un rbitro no es sino un extra aadido a una reserva, tal y como puede serlo un material, vamos a implementar una clase Extra que contenga la informacin bsica acerca de todo extra asociado a una reserva. De esta clase descendern rbitro y Material para representar los extras.

Es justo reconocer que la clase Extra nos viene bien para representar relaciones de generalizacin en la prctica, pero podra obviarse e introducir rbitro y Material por separado dado que, segn la perspectiva con que acometas el diseo, es discutible que por ser ambos extras deban descender de una clase base comn. 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 adems, que una pista puede estar disponible o no por estar en reparacin, tiene un precio asociado, etc. Esto justifica que tengamos una clase pista con tales atributos relacionada con la clase Reserva. Basndonos 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. Programacin orientada a objetos y lenguaje unificado de modelado (UML)
32

clase Socio: representa a un usuario socio del club. clase Extra: representa un extra alquilado junto con la pista. clase Material: representa un material (baln, peto, etc.) clase rbitro: representa un rbitro. Relaciones entre clases_________________________________________ Una vez establecidas las clases del sistema, estudiemos las relaciones que existirn entre las mismas. Recordemos que existen tres tipos bsicos de relaciones entre clases: asociaciones, dependencias y generalizaciones.

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

Consideramos necesario establecer las siguientes asociaciones: Reserva con Socio: una reserva debe ser ineludiblemente realizada por un socio. La asociacin 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 ms reservas. Reserva con Pista: una reserva siempre se realiza para una pista concreta. La asociacin 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 relacin de agregacin es un tipo especial de relacin de asociacin entre dos clases que se da cuando una de las clases contiene instancias de la otra clase.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

33

Hemos establecido la siguiente agregacin: Reserva con Extra: una reserva puede incluir o no extra. La asociacin 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 da a la misma hora.

Una relacin de generalizacin 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, extendindola con nuevos comportamientos.

Hemos establecido las siguientes generalizaciones: Extras con rbitro: un rbitro es un Extra que adems incorpora informacin de contacto del rbitro. Extras con Material: un material es un Extra que adems incorpora informacin acerca de la fecha de revisin, etc. Diagrama de clases____________________________________________

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

34

Ejercicio 2.2 Identificacin de atributos y operaciones

Identifica los atributos y mtodos 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 parmetros que recibir cada mtodo junto con el tipo de datos devuelto, si corresponde. Establece la visibilidad (pblica, privada, etc) para cada uno de los atributos y mtodos de cada clase.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

35

Solucin al Ejercicio 2.2 Identificacin de atributos y operaciones

Identificacin 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 encapsulacin de datos y permite proteger los datos de accesos indebidos, verificar que los datos se encuentran entre los valores aceptables, etc. Para favorecer la encapsulacin, consideraremos que la visibilidad de todos los atributos debe establecerse, pues, como private (smbolo en el diagrama de clases). Otra consideracin 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, deberamos 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 relacin directa entre la visibilidad establecida en el diagrama de clases y la que existir en la implementacin 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 programacin que soporte las propiedades, como C#, estos atributos tendran visibilidad public)

Ten en cuenta que si bien existe una relacin entre los diagramas de UML y el cdigo final de la implementacin, en general no es posible una transformacin directa completa, y habr que tener en cuenta mltiples consideraciones para pasar del modelado UML al cdigo final.

Establezcamos y justifiquemos, pues, los atributos y mtodos de cada una de las clases estudiadas.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

36

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

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) podran daarse y necesitar un tiempo para ser reparados. clase Material: - tipo: String Tipo de material: baln, red, peto - fechaRevisin: String Fecha de la ltima revisin del material clase rbitro: - nombre: String - apellidos: String - telfono: String Informacin de contacto necesaria para localizar al rbitro. clase Reserva: - fecha: String Fecha de la reserva - hora: String Hora de la reserva - getPrecio(): Integer Este mtodo 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, Ftbol sala o Baloncesto Programacin orientada a objetos y lenguaje unificado de modelado (UML)
37

- disponible: Boolean Indica si la pista est disponible o no, por mal estado, reparaciones, etc. clase Socio: nombre: String apellidos: String NIF: String direccin: String telfono: String Informacin de contacto necesaria para localizar al socio.

- fechaAlta: String Fecha de alta del socio en el club.

Fjate como no hemos includo los atributos que estn representados por las relaciones, pues es redundante en este momento del diseo. Por ejemplo, Reserva necesita de un atributo idSocio que identifique al socio, pero este atributo ya est representado por la relacin de asociacin existente entre Reserva y Socio.

Como ves prcticamente no hemos includo mtodos y por tanto las clases no representan el ideal de una clase que incorpora funcionalidad propia. Sin embargo esto es comn en los sistemas de gestin y similares, fuertemente orientados a los datos.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

38

Ejercicio 3 Diagramas de secuencia

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

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

Durante la etapa de modelado del diagrama de clases, identificamos las clases fundamentales del sistema e hicimos un diseo preliminar. Con los diagramas de secuencia profundizaremos un nivel ms en el nivel de detalle del diseo, 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 relacionaran las clases entre s, ahora es el momento de detallar esa relacin ms detalladamente. Hagamos memoria y recordemos los componentes fundamentales de un diagrama de secuencia: objetos y mensajes. Los objetos se alinean horizontalmente y una lnea de vida vertical muestra la duracin 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 funcin que los utilizados en el correspondiente diagrama de casos de uso. Por ltimo, debemos debemos considerar la inclusin de las rutas alternativas -excepciones en la plantilla de descripcin 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 seran evidentes de cara a la implementacin. Lo ms apropiado es basarnos en la relevancia de los distintos flujos de comportamiento a la hora de considerar su inclusin en los diagramas.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

39

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

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

40

Anexo: Diagramas de secuencia en StarUML

Para crear un diagrama de secuencia___________________

Haz clic con el botn derecho del ratn sobre <<implementationModel>> en la ventana Model Explorer y elige la opcin SequenceDiagram:

Cambia a la vista Diagram Explorer y haciendo clic sobre el diagrama recin creado se mostrarn sus propiedades en la ventana Properties. Aqu podrs nombrar el diagrama con la propiedad Name, y activar o desactivar la numeracin automtica de los mensajes entre objetos con la propiedad ShowSequenceNumber (en los diagramas mostrados en este documento esta opcin est desactivada). Adems, la opcin MessageSignature te permite establecer si se muestran los parmetros de los mtodos empleados en los mensajes entre objetos en la vista del diagrama. Es recomendable dejarlo en TYPEONLY.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

41

Para aadir elementos al diagrama ____________________

Utiliza la paleta de herramientas Sequence situada en el lado izquierdo de la pantalla, en la ventana Toolbox: Object: Para aadir nuevos objetos al diagrama. Stimulus: Aade 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: Aade un mensaje enviado por un objeto a s mismo. Haz clic sobre el objeto para aadirlo. Combined Fragment, Interaction Operand: Cuando estudies las descripciones de los casos de uso, vers que en ocasiones es necesario implementar alternativas (es decir, seguir distintos comportamientos segn determinadas condiciones), bucles, etc. El estndar UML soporta la notacin correspondiente para estos casos; en StarUML, podemos modelar estos comportamientos con las herramientas Combined Fragment e Interaction Operand. Sigue estos pasos para aadir un bucle o condicin 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. aade nuevas condiciones con la herramienta Interaction Operand. Para ello debers seleccionar en primer lugar el Combined Fragment, elegir luego la herramienta Interaction Operand y hacer clic sobre el Combined Fragment. 5. teclea la expresin de guarda en el campo Guard:

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

42

Para configurar los mensajes entre objetos _____________

Haz clic en el mensaje, accede al panel Properties y podrs 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 mtodo del objeto SEND llamada a un mtodo del objeto, de forma asncrona RETURN devolucin de un valor al objeto llamante CREATE creacin de un objeto DESTROY destruccin 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.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

43

Ejercicio 3.1 Diagramas de secuencia

Realiza el modelado del diagrama de secuencia correspondiente a los casos de uso contemplados anteriormente. Debers representar la secuencia de pasos seguidos en el caso de uso en forma de mensajes entre los objetos del diagrama.

Recuerda que es ms importante garantizar que el diagrama sea comprensible y asimilable que que represente una correspondencia exacta con la futura implementacin de las interacciones descritas entre los objetos que aparecen en el mismo.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

44

Solucin al Ejercicio 3.1

Inicio de sesin_______________________________________________

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 funcin del enfoque con el que se acomete el modelado. Tu diagrama puede ser muy distinto y ser perfectamente vlido, mientras sea consistente con el planteamiento que hayas elegido.

Hemos considerado al usuario de la aplicacin como un objeto, creando una lnea de vida para l. (En general se le representa en estos casos con un mueco, pero StarUML no permite tal representacin). Representamos la interaccin del usuario con la interfaz del sistema por medio de mensajes. De este modo, iniciarSesin no es estrictamente un mensaje que manda Usuario a Sistema (evidentemente Usuario no es un componente software) sino que queremos representar la accin, por parte del usuario, de insertar un nombre y una contrasea y pulsar el botn Iniciar sesin. Estos pasos podramos haberlos representado as:

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

45

Pero, con idea de simplificar los diagramas, hemos optado por no representar la interaccin entre el usuario y la interfaz salvo para indicar la accin genrica. Tambin podramos haber excludo el objeto Usuario y trabajar con el objeto Sistema como objeto que se autoenva mensajes, tal como iniciarSesin. Si establecemos que en tal caso, Sistema representara la interfaz de la aplicacin de cara al usuario, no habr ningn problema.

Como ves es posible elegir distintos planteamientos a la hora de modelar los diagramas. Lo importante es ceirte 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 implementacin real pueda ser distinta.

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 sesin representa un mensaje del tipo Error, la cuenta indicada no existe o similar. Utilizamos el objeto conexinBaseDatos para representar el enlace existente entre Sistema la aplicacin- y la base de datos. En la implementacin real del sistema, existirn una o varias clases que nos permitan obtener y almacenar informacin en la base de datos; pero en este momento del diseo, an no sabemos como se implementar esta funcionalidad. Adems, de ste modo podemos representar genricamente la conexin mencionada haciendo ms comprensible el diagrama. Programacin orientada a objetos y lenguaje unificado de modelado (UML)
46

Otra opcin vlida sera utilizar un objeto Cuenta para representar las cuentas de la base de datos, por ejemplo. En general, no obstante, suele emplearse un objeto genrico que simboliza la conexin entre el sistema y la base de datos. Como hemos comentado repetidamente, cualquier opcin elegida ser vlida si como consecuencia obtenemos diagramas comprensibles y coherentes. Pero no hemos includo clases como conexinBaseDatos o Sistema en el diagrama de clases En el diagrama de clases inclumos las clases que representaban la funcionalidad especfica de nuestro sistema, abstrayndonos a un nivel por encima de la implementacin real. En sta, habr muchas otras clases requeridas para que el sistema funcione.

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

Ahora que has visto como hemos representado la interaccin del usuario con el sistema, y la comunicacin entre el sistema y la base de datos, tal vez quieras remodelar el resto de diagramas que hayas modelado adaptndolos a este planteamiento, para comprobar despus si tu resultado es similar al que mostramos aqu. Fin de sesin_______________________________________________

El sistema se comunica con la base de datos para finalizar la sesin y almacenar de este modo la hora de finalizacin de la misma.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

47

Crear cuenta de usuario________________________________________

crearCuenta representa la accin del administrador de elegir el comando Crear cuenta una vez introducidos los datos de la misma. Fjate como que hace el resultado en continuacin. utilizamos un SelfStimulus de StarUML para representar la validacin sistema de los datos facilitados para la cuenta. Almacenamos el la booleana VALIDOS para utilizarlo en la alternativa insertada a Si los datos no son vlidos se emitir un mensaje de error.

Si los datos son vlidos el sistema verifica si la cuenta ya est asociada a un Usuario. (Si existe una cuenta con los mismos valores de usuario y contrasea debe emitirse un error) Si la cuenta no existe, se crea la nueva cuenta en la base de datos y se emite una confirmacin. Como ves, hemos representado en el diagrama todos los requisitos exigidos en la creacin de cuentas, dejando constancia de su relevancia en el proceso de creacin de una cuenta.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

48

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 vlida; no necesitamos, pues, considerar la posibilidad de error. Fjate 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 podramos obtenerla de nuevo en caso necesario). Pero encontrars una justificacin extra en el diagrama de edicin de cuenta de usuario. Para obtener una representacin visual como la que ves en el diagrama (cuentaActual:=cuenta), observa la representacin de las propiedades del mensaje en StarUML:

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

49

Editar cuenta de usuario______________________________

Este grfico es bastante parecido al de creacin de una cuenta, como puedes observar. Crear una cuenta consiste en el fondo en editar una cuenta que simplemente an no existe en la base de datos. Al editar una cuenta, Administrador modifica ciertos campos y pulsa el botn Actualizar cuenta, Guardar cambios o similar. Fjate como se comprueba de nuevo la validez de los datos por ejemplo, que en el campo apellidos figure algn dato- y se emite error en caso de que stos no sean vlidos. Tras comprobar la validez de los datos se verifica que (usuario, contrasea) no coinciden con una cuenta que no sea la actual: Fjate 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, contrasea) actuales Programacin orientada a objetos y lenguaje unificado de modelado (UML)
50

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 contrasea, pero haciendo las necesarias comprobaciones para que no exista conflicto del par (usuario, contrasea) con otras cuentas. En este caso, cuentaActual representa la cuenta que habremos obtenido anteriormente al consultar una cuenta y que se almacenara como una variable en Sistema. Eliminar cuenta de usuario______________________________________

De forma similar a como ocurra con el diagrama consultar cuenta de usuario, este diagrama es bastante sencillo, dado que la opcin eliminar cuenta slo est disponible, segn 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.

Fjate como en los diagramas de gestin de cuentas de usuario no inclumos cdigo para verificar que el usuario es administrador. Recuerda que en los requisitos se especifica que las opciones de gestin de cuentas de usuario slo estn disponibles una vez el usuario ha iniciado sesin como administrador. Adems, hemos nombrado al objeto que inicia la interaccin como Administrador.

3.1

Ahora que has visto cmo hemos realizado el modelado de la gestin de cuentas de usuario, te propongo que modeles diagramas de secuencia para la gestin de socios y la gestin de reservas, considerando cuidadosamente todos los requisitos que figuran en el enunciado del sistema. Envalos al tutor si tienes alguna duda o si quieres recibir su opinin.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

51

Ejercicio 4 Diagramas de actividades

Introduccin_______________________________________
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 diseo de un sistema. Podemos utilizarlos para estudiar casos de uso o actividades concretas de nuestro sistema. Una caracterstica 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 simultnea o no. Esto permite una mayor libertad a la hora de expresar flujos o procesos, facilitando adems la comprensin del sistema.

Por ejemplo, en el proceso de emisin 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 revs, o incluso si lo hacemos simultneamente.

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

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

52

Anexo: Diagramas de actividades en StarUML

Para crear un diagrama de actividades_________________

Haz clic con el botn derecho del ratn sobre <<deploymentModel>> en la ventana de exploracin de modelos y elige la opcin Activity Diagram:

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

53

Para aadir elementos al diagrama ____________________

Utiliza la paleta de herramientas Activity situada en el lado izquierdo de la pantalla, en la ventana Toolbox: Breve descripcin de algunas herramientas: ActionState: Utilzalo para aadir 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 sincronizacin, 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 transicin. Una vez seleccionada una transicin, utiliza el campo GuardCondition que encontrars en la ventana Properties para establecer la condicin de guarda. Esto es fundamental en el caso de utilizacin de alternativas (herramienta Decision) y opcional en el resto de los casos. Swimlane: Muy til para separar las actividades en funcin del objeto que las realiza (el usuario, el sistema, etc.)

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

54

Ejercicio 4.1 Diagramas de actividades

Modela los siguientes diagramas de actividades que representen el comportamiento de las funcionalidades bsicas del sistema, como: Inicio de sesin Fin de sesin Creacin de una nueva cuenta Edicin de una cuenta Alta de una reserva Consulta de una reserva Etc.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

55

Solucin al Ejercicio 4.1 Diagramas de actividades

Iniciar sesin_________________________________________________

Como ves, hemos utilizado swimlanes para que el diagrama muestre con claridad quin realiza qu en la actividad.

Considera variaciones que en este caso seran vlidas, como unir Introducir datos de usuario y Seleccionar Iniciar sesin en un nico ActionState, dado que la nica opcin disponible una vez introducidos los datos de usuario es seleccionar el comando de inicio de sesin. Se ha hecho as para que los diagramas sean consistentes entre s.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

56

Creacin de cuenta de usuario___________________________________

En este caso, al contrario que en el diagrama de secuencia correspondiente, hemos includo la accin de elegir el comando Crear cuenta para acceder a la interfaz de creacin de cuentas. Recuerda que en el diagrama de secuencia una precondicin era encontrarse ya en la interfaz correspondiente. Fjate como hemos utilizado sincronizaciones para actividades que tienen un punto de finalizacin comn.

4.1
Modela el resto de diagramas de actividades propuestos. Envalos al tutor para su correccin.

Programacin orientada a objetos y lenguaje unificado de modelado (UML)

57