Gestionbasesdatos

Programación orientada a objetos y UML
Práctica
Gestión de un club deportivo
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.
Programación orientada a objetos y lenguaje unificado de modelado (UML) 1

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.
Puedes obtener el programa en la dirección web

http://staruml.sourceforge.net/en/
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).
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.

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

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 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.
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 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:
Preparació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.

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

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

Ejercicio 1.1
Identificació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.

Solución al Ejercicio 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.
Hemos decidido no representar el actor Socio

dado que no interviene directamente en la
interacción con el sistema. Por supuesto, es
¿ ?
Pero, y que hay necesario contar con su participación en la
de los socios del mayoría de los casos de uso –por ejemplo, para
club 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.
En este caso los actores son personas físicas, pero también 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.”
- edición de extras
“El usuario edita los datos de un extra concreto.”
- 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.”
1.1
Prueba a describir los casos de uso restantes, para la gestión

de reservas y cuentas de usuario.
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.
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.

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
visión general de un proceso sin entrar en detalles de
implementación.

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.

Analizando los requisitos está claro que el usuario
¿ Porqué no se
han incluído
iniciar sesión y
necesita iniciar sesión para realizar cualquier
gestión, sin embargo no consideramos en su
momento estos comportamientos como casos de
uso en sí.
finalizar sesión
En esta fase del análisis vemos que ese
como casos de
comportamiento es común a toda gestión y por
uso del sistema
tanto lo separamos como un caso de uso
?
en el ejercicio
específico que los demás incluyen.
anterior
Podemos volver atrás e incorporar esos casos de
uso a los obtenidos inicialmente.
El diseño de un sistema es cíclico en muchas de sus etapas.
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.
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.
Una vez modelado el diagrama de alto nivel, podemos descomponer cada

uno de los paquetes en otros diagramas más detallados.

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

Ejercicio 1.3
Descripció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

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 El usuario introduce sus datos de cuenta y pulsa el
1
botón “Iniciar sesión”
El sistema valida los datos del usuario e inicia
2
sesión para el mismo
Excepciones El sistema muestra un mensaje de error si los
2.1 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”
El sistema finaliza la sesión del usuario actual y
2
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 administrador introduce los datos de la nueva
1
cuenta y pulsa el botón “Crear cuenta”
El sistema comprueba que no falta ningún dato
2
requerido
El sistema comprueba que no existe una cuenta
3
que corresponda a los datos usuario/contraseña
El sistema crea la nueva cuenta en la base de
4
datos
El sistema confirma la creación de la cuenta al
5
usuario
Excepciones El sistema muestra un mensaje de error
2.1 informando de que faltan datos requeridos o hay
datos erróneos
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
Caso de uso consultar cuenta de usuario

Propósito Ver la información asociada a una cuenta de usuario
existente en el sistema
Encontrarse en la interfaz de consulta de cuenta
Poscondiciones
Flujo principal administrador elige la cuenta que desea consultar
1
del listado de cuentas y pulsa el botón “Ver cuenta”
El sistema muestra los datos actuales de la cuenta
2
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
Encontrarse en la interfaz de consulta de datos de una cuenta
Poscondiciones El sistema almacena los cambios realizados en la base de
datos
Flujo principal administrador modifica alguno o varios de los
1 campos asociados a la cuenta y pulsa el botón
“Actualizar cuenta”, “Guardar cambios” o similar
2 El sistema valida los datos requeridos
El sistema verifica que los valores (usuario,
3
contraseña) son únicos
El sistema almacena los cambios en la base de
4
datos
El sistema emite un mensaje de confirmación
5
indicando que los cambios han sido realizados
Excepciones El sistema muestra un mensaje de error
2.1 informando de que faltan datos requeridos o hay
datos erróneos
El sistema emite un mensaje de error si los valores
3.1
(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
Encontrarse en la interfaz de consulta de datos de una cuenta
Poscondiciones Se ha eliminado una cuenta de usuario de la base de datos
Flujo principal 1 administrador pulsa el botón “Eliminar cuenta”
2 El sistema elimina la cuenta de la base de datos
El sistema emite un mensaje de confirmación de
3
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.

1.3
Rellena un formulario como el anterior para los casos de uso que no

hemos presentado aquí.

Ejercicio 2
Análisis y diseño de las clases del sistema
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:
Diagramas de clases 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.

Ejercicio 2.1
Enumeración de clases y modelado del
diagrama de clases
- 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.
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.
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.

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

Ejercicio 2.2
Identificación de atributos 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.

Identificación de atributos 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)
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.
Establezcamos y justifiquemos, pues, los atributos y métodos de cada una

de las clases estudiadas.

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…) 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”

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

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

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.

Ejercicio 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_______________________________________________
Ten en cuenta que los diagramas de secuencia
¡ Mi diagrama no
se parece en
nada a esto
! (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.
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.
▪ 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.

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 En el diagrama de clases incluímos las clases

incluído clases que representaban la funcionalidad específica de
¡ como
conexiónBaseDatos
o Sistema en el
! nuestro sistema, abstrayéndonos a un nivel por
encima de la implementación real. En ésta,
habrá muchas otras clases requeridas para que
diagrama de clases 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.
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í.
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.

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

Ejercicio 4
Diagramas de actividades
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.
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.
Identificar estos flujos paralelos puede darnos pistas importantes sobre

cómo implementar correctamente en el sistema la actividad concreta que estamos
modelando.

Anexo:
Diagramas de actividades 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.)

Ejercicio 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.
4.1
Modela el resto de diagramas de actividades propuestos.
Envíalos al tutor para su corrección.

Gestionbasesdatos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Gestionbasesdatos

Hochgeladen von

Copyright:

Verfügbare Formate

Programación orientada a objetos y UML

Cómo realizar la práctica

La práctica se divide en ejercicios que debes desarrollar, cada uno dedicado

Tras una breve introducción inicial a cada ejercicio, se presenta una

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

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

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

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

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

Para elaborar las prácticas

Puedes obtener el programa en la dirección web

Durante el manejo del programa es probable que te

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

A lo largo de este documento encontrarás anexos que

Nota: cambiando el tipo de línea dibujada al enlazar elementos

Al trabajar con los diferentes tipos de diagramas en StarUML, observarás

StarUML representa estas relaciones, mensajes, etc. con líneas de diversos

Cuando añadas una de estas líneas de

Esta característica también puede establecerse globalmente en el cuadro de

Nota: desactivando el tamaño automático de los elementos___

Si al intentar modificar el tamaño de algún elemento

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

El proyecto de desarrollo de un sistema real suele incluir tanto

Requisitos funcionales de la aplicación Gestor de Club

En esta práctica realizaremos el análisis y diseño de una hipotética aplicación

En concreto, la aplicación permitirá la gestión de socios y de reservas de

Una aplicación real (tal y como las que se encuentran en el mercado)

A continuación enumeramos los requisitos funcionales del sistema:

- El sistema sólo permite una sesión de usuario activa en todo momento.

Usuarios del sistema

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

Gestión de cuentas de usuario

- La gestión de cuentas de usuario consistirá en la posibilidad de creación,

- La gestión de socios consistirá en la posibilidad de efectuar altas y bajas

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

- La gestión de reservas consistirá en la posibilidad de efectuar altas y

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

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

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

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

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

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

- Las pistas se denominarán por un nombre que permita tanto al usuario

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

- Es posible alquilar una serie de “extras” al hacer una reserva. Estos

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

- La gestión de extras consistirá en la posibilidad de dar de alta extras

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

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

- Al consultar un extra, el usuario podrá elegir el extra a consultar de una

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

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

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,

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

En un proyecto real, generalmente recibimos un documento que incluye los

Aunque existen distintas aproximaciones para realizar el análisis de un

Podríamos preguntarnos ¿para qué necesitamos los casos de uso, si

Una buena estrategia para discernir qué comportamientos podemos

En la preparación de los casos de uso debemos, pues, analizar la interacción

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