Gestión de sociedad de cazadores

UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA GESTIÓN DE SOCIEDAD DE PROYECTO FIN DE CARRERA José Antonio Mancebo Requena María UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA GESTIÓN DE SOCIEDAD DE CAZADORES PROYECTO FIN DE CARRERA Autor: José Antonio Mancebo Requena Director: María Carmen Penades Gramage UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA GESTIÓN DE SOCIEDAD DE Julio - 2010 A mis padres, mi hermano y Mª José Agradecimientos Me gustaría dar las gracias a mis amigos de toda la vida, a mis amigos de la universidad y a mis compañeros de piso por preocuparse y preguntarme qué tal llevaba el proyecto aunque muchos de ellos no supieran en qué consistía. Por último quiero dar las gracias a mi tutora, por guiarme a lo largo del proyecto y darme siempre ánimos. Tabla de contenidos I Tabla de contenidos Tabla de contenidos .......................................................................................................... I Lista de figuras ................................................................................................................ III 1. Introducción ................................................................................................................. 1 1.1. Motivación ............................................................................................................ 1 1.2. Objetivos ............................................................................................................... 2 1.3. Estructura de la memoria...................................................................................... 3 2. Metodología ................................................................................................................. 5 2.1. Caso de estudio ................................................................................................... 10 3. Modelado Conceptual ............................................................................................... 15 3.1. Casos de uso ........................................................................................................ 16 3.2. Diagrama de clases.............................................................................................. 35 3.3. Diagramas de secuencia ...................................................................................... 38 4. Arquitectura del sistema ........................................................................................... 41 5. Diseño ………… ............................................................................................................. 47 5.1. Diseño de IGU...................................................................................................... 47 5.2. Diseño de clases .................................................................................................. 54 5.3. Diseño de base de datos ..................................................................................... 60 6. Implementación ......................................................................................................... 77 6.1. Tecnología ........................................................................................................... 77 6.2. Acceso a Datos: Escenario desconectado ........................................................... 80 6.3. Detalles de implementación por capas ............................................................... 82 6.3.1. Implementación del inicio de la aplicación .............................................. 82 6.3.2. Implementación de la creación de clases de comunicación de capas ..... 82 6.3.3. Implementación de carga del DataSet...................................................... 83 6.3.4. Implementación de la carga del sistema .................................................. 85 6.3.5. Implementación de consulta de modalidades ......................................... 88 6.3.6. Implementación de alta de modalidad de caza ........................................ 89 6.3.7. Implementación de modificación de modalidad de caza ......................... 92 6.3.8. Implementación de baja de modalidad de caza ....................................... 95 6.3.9. Implementación de actualizar la información de la base de datos ....... 97 7. Conclusiones .............................................................................................................. 99 7.1. Trabajo realizado ................................................................................................. 99 7.2. Valoración personal .......................................................................................... 100 7.3. Ampliaciones futuras ........................................................................................ 101 Tabla de contenidos II Bibliografía……… ........................................................................................................... 103 Anexo A: Plantillas de casos de usos ........................................................................... 105 Anexo B: Manual de instalación .................................................................................. 163 Anexo C: Manual de usuario ....................................................................................... 165 C.1. Gestión de ventana principal ................................................................. 166 C.1.1. Gestión de sociedad de cazadores .............................................. 166 C.2. Gestión de aspectos de administración ................................................. 167 C.2.1. Gestión del coto de caza .............................................................. 168 C.2.2. Gestión de tipos de socio ............................................................. 170 C.2.3. Gestión de modalidades de caza ................................................. 171 C.2.4. Gestión de especies cazables ....................................................... 172 C.2.5. Gestión de comisiones predefinidas ............................................ 173 C.3. Gestión de temporada ........................................................................... 174 C.3.1. Gestión de junta directiva que regirá la temporada .................. 174 C.3.2. Alta de temporada ...................................................................... 177 C.3.3. Configuración de cuotas y modalidades ..................................... 179 C.3.3.1. Gestión de cuotas ........................................................... 179 C.3.3.2. Gestión de Modalidades ................................................. 180 C.3.4. Inicio de temporada ..................................................................... 182 C.3.5. Gestión de temporada en curso .................................................. 183 C.3.5.1. Gestión de socios ............................................................ 183 C.3.5.2. Gestión de actividades .................................................... 189 C.3.5.3. Gestión de actuaciones en el coto. ................................. 194 C.3.5.4. Gestión de contabilidad .................................................. 195 C.3.6. Finalización de temporada........................................................... 196 C.4. Acceso al historial temporadas .............................................................. 198 Lista de figuras III Lista de figuras Figura 1. Estructura de RUP .......................................................................................................... 7 Figura 2. Prácticas de XP ............................................................................................................... 8 Figura 3. Comparativa de RUP y XP ............................................................................................... 9 Figura 4. Diagrama de contexto. ................................................................................................. 17 Figura 5. Diagrama inicial ............................................................................................................ 17 Figura 6. Diagrama de gestión de datos de sociedad de cazadores. .......................................... 18 Figura 7. Diagrama de gestión de aspectos de administración. ................................................. 18 Figura 8. Diagrama gestión de tipos de socio. ............................................................................ 19 Figura 9. Diagrama gestión de modalidades de caza. ................................................................. 19 Figura 10. Diagrama gestión de especies cazables. .................................................................... 21 Figura 11. Diagrama gestión de coto de caza. ............................................................................ 21 Figura 12. Diagrama gestión de temporadas. ............................................................................. 22 Figura 13. Diagrama gestión de datos temporada. ..................................................................... 22 Figura 14. Diagrama gestión de cuotas. ...................................................................................... 23 Figura 15. Diagrama gestión de modalidades de temporada. .................................................... 24 Figura 16. Diagrama gestión de actividades. .............................................................................. 24 Figura 17. Diagrama gestión de datos actividades...................................................................... 25 Figura 18. Diagrama gestión de clasificación de campeonatos. ................................................. 25 Figura 19. Diagrama gestión de participantes. ........................................................................... 26 Figura 20. Diagrama gestión de actuaciones. ............................................................................. 27 Figura 21. Diagrama gestión contable. ....................................................................................... 28 Figura 22. Diagrama gestión de vedas. ....................................................................................... 29 Figura 23. Diagrama gestión de asambleas. ................................................................................ 29 Figura 24. Diagrama gestión de socios. ....................................................................................... 30 Figura 25. Diagrama gestión de datos de socios. ........................................................................ 30 Figura 26. Diagrama gestión de temporadas de socios. ............................................................. 32 Figura 27. Diagrama gestión de juntas directivas. ...................................................................... 33 Figura 28. Diagrama gestión de composición de juntas directivas. ............................................ 33 Figura 29. Diagrama gestión de comisiones juntas directivas. ................................................... 34 Figura 30. Diagrama gestión de perros. ...................................................................................... 34 Figura 31. Diagrama de clases. .................................................................................................... 36 Figura 32. Clase Participante y Socio en detalle.......................................................................... 37 Figura 33. Fragmento de diagrama de clases. ............................................................................. 37 Figura 34. Diagrama de secuencia baja de modalidad de caza. .................................................. 38 Figura 35. Diagrama de secuencia alta de socio. ........................................................................ 39 Figura 36. Diagrama de secuencia modificación de modalidad de temporada. ......................... 40 Figura 37. Diagrama de secuencia consulta de clasificación de campeonato de cazadores. ..... 40 Figura 38. Arquitectura genérica de tres capas. ......................................................................... 43 Figura 39. Arquitectura de tres capas del caso de estudio. ........................................................ 44 Figura 40. Esquema de formulario. ............................................................................................. 49 Figura 41. Formulario gestión de modalidades de caza. ............................................................. 50 Lista de figuras IV Figura 42. Formulario de gestión de socios. ............................................................................... 51 Figura 43. Formulario gestión de modalidades de temporada. .................................................. 52 Figura 44. Formulario de gestión de campeonato de cazadores. ............................................... 53 Figura 45. Formulario principal. ................................................................................................ 166 Figura 46. Formulario Aspectos de Administración: Coto de caza............................................ 168 Figura 47. Formulario Aspectos de administración: Zona de caza. ........................................... 169 Figura 48. Formulario Aspectos de administración: Tipos de socios ........................................ 170 Figura 49. Formulario Aspectos de administración: Modalidades de caza. .............................. 171 Figura 50. Formulario Aspectos de administración: Especies cazables. ................................... 172 Figura 51. Formulario Aspectos de Administración: Comisiones predefinidas. ....................... 173 Figura 52. Formulario Juntas directivas. ................................................................................... 175 Figura 53. Formulario Juntas directivas: Asignar cargo. ........................................................... 176 Figura 54. Formulario Junta Directiva: Comisión nueva. .......................................................... 177 Figura 55. Formulario Temporadas: Nueva temporada. ........................................................... 178 Figura 56. Formulario Temporadas: Cuotas. ............................................................................. 179 Figura 57. Formulario Temporadas: Modalidades. ................................................................... 181 Figura 58. Formulario Temporadas: Inicio de temporada. ....................................................... 182 Figura 59. Formulario Socios. .................................................................................................... 183 Figura 60. Formulario socios: DNI socio existente. ................................................................... 185 Figura 61. Formulario socios: Datos nuevo socio erróneos. ..................................................... 186 Figura 62. Formulario Socio: Configuración de modalidades y cuota. ...................................... 187 Figura 63. Formulario Socio: Pago cuota................................................................................... 188 Figura 64.Formulario Temporadas: Actividades. ...................................................................... 189 Figura 65. Formulario Actividad: Edición de datos actividad de sociedad. ............................... 190 Figura 66. Formulario Actividad: Participantes. ........................................................................ 191 Figura 67. Formulario Actividad: Inscripción de participante. .................................................. 192 Figura 68. Formulario Actividad: Clasificación Campeonato. ................................................... 193 Figura 69. Formulario Temporadas: Actuaciones coto de caza. ............................................... 194 Figura 70. Formulario Temporadas: Nueva repoblación. ......................................................... 195 Figura 71. Formulario Temporadas: Contabilidad .................................................................... 196 Figura 72. Formulario Temporadas: Finalizar temporada actual. ............................................. 197 Figura 73. Formulario Socios. Eliminar socio. ........................................................................... 197 Figura 74. Formulario Temporadas: Acceso a historial. ........................................................... 198 Capítulo 1 Introducción 1 Capítulo 1: Introducción Este capítulo introductorio sirve para aclarar de forma concisa los aspectos generales del proyecto, tales como la motivación por la que se realiza este proyecto, los objetivos principales y la organización de la presente memoria comentando brevemente los apartados que la componen. 1.1. Motivación He decidido realizar este proyecto sobre la gestión de una sociedad de cazadores en primer lugar porque quería sentirme capacitado para realizar el proceso de desarrollo de software de una aplicación por mi mismo tras haber trabajado satisfactoriamente en grupo a lo largo de la carrera. Y en segundo lugar porque conozco familiares y amigos que practican la caza y sé que en las sociedades de cazadores donde participan no tienen informatizada su gestión y sé que dicha gestión no es tan simple como a priori parece. Deben llevar la Capítulo 1 Introducción 2 gestión de diversos aspectos a lo largo de las temporadas que organizan: las cuotas que van a pagar los socios, las asambleas que se convocan, las actividades y campeonatos que se realizan, los ingresos y gastos que se producen, etc. Por otro lado también tiene que llevar la gestión de los socios que participan en la sociedad: las modalidades de caza que practican en cada temporada, el estado del pago de las cuotas, etc. En definitiva me atraía el reto de lograr una gestión más sencilla y cómoda de la práctica de esta actividad tradicional que tanto a evolucionado en los últimos tiempos. 1.2. Objetivos El objetivo principal de este proyecto es el desarrollo de un sistema de información para la gestión y mantenimiento de una sociedad de cazadores. Centrándose en la gestión de los socios que componen la sociedad de cazadores así como la configuración y seguimiento de las diferentes temporadas que soporta. A continuación se especifican los objetivos más importantes establecidos. - Gestionar los datos que identifican la sociedad de cazadores. - Gestionar la información de los socios que han pertenecido a la sociedad, haciendo énfasis en la gestión de las cuotas y de las modalidades de caza que practica cada socio en las diferentes temporadas en las que participa. - Gestionar las actividades que se organizan por la sociedad las cuales se subdividen en actividades de sociedad, campeonato de cazadores y campeonato de perros. - Gestionar las actuaciones que se realizan en el coto de la sociedad. Dichas actuaciones pueden ser mejoras para conseguir un buen mantenimiento de las especies cazables o repoblaciones que se hagan de dichas especies por su precario número de población. - Gestionar la contabilidad de la sociedad, los ingresos y gastos que se producen a lo largo de cada temporada. - Gestionar las juntas directivas que administran la sociedad de cazadores, tanto su composición como las comisiones que establecen. A nivel académico, el objetivo del proyecto es realizar una aplicación de escritorio realizada bajo el entorno de desarrollo Visual Studio. Se contará con una Capítulo 2 Metodología 9 convenientes. De esta forma se evita perder tiempo desarrollando una aplicación que no sea la que el cliente esperaba. Este ciclo se va repitiendo una y otra vez hasta que el cliente se dé por satisfecho y cierre el proyecto. La tabla comparativa entre ambas metodologías es la siguiente. Figura 3. Comparativa de RUP y XP Tras haber estudiado las características de ambas metodologías y viendo como encajan en el proyecto. El proyecto se decide realizar siguiendo la metodología RUP por los siguientes motivos: - Cuando se comienza el proyecto ya se conoce los requisitos que va a tener que cubrir, no van a sufrir cambios a lo largo del proceso. Por lo que se puede definir la arquitectura del sistema de forma sólida en las primeras iteraciones del mismo. - Al trabajar una sola persona, es preferible que se te marque un camino a seguir mediante el cual conseguir una buena documentación en la que apoyarse. - El cliente, en este caso la directora del proyecto, no es parte del equipo de desarrollo sino que interactúa con el equipo de desarrollo, el autor del proyecto, mediante reuniones. En este proyecto se ha realizado un proceso RUP reducido mediante el cual se debe resolver el caso de estudio definido a continuación. RUP XP Cierta resistencia a los cambios Especialmente preparados para cambios durante el proyecto Proceso mucho más controlado, con numerosas políticas/normas Proceso menos controlado, con pocos principios El cliente interactúa con el equipo de desarrollo mediante reuniones El cliente es parte del equipo de desarrollo Más artefactos Pocos artefactos La arquitectura del software es esencial y se expresa mediante modelos Menos énfasis en la arquitectura del software Menor dificultad para delimitar el alcance del proyecto con nuestro cliente Mayor dificultad para delimitar el alcance del proyecto con nuestro cliente Capítulo 2 Metodología 10 2.1. Caso de estudio Se desea desarrollar un sistema informático para gestionar una sociedad de cazadores. Para hacer que dicho caso de estudio sea coherente se ha obtenido información del funcionamiento de sociedades de cazadores a través de internet, las principales fuentes han sido las páginas web de la sociedad de cazadores el Raigous (www.elraigosu.es), la sociedad de cazadores Ecija (www.cazaecija.com) y la sociedad de cazadores San Santurio (www.sociedadsansaturio.com). La especificación que se ha dado del problema es la que sigue. De la sociedad de cazadores se quiere mantener la siguiente información: CIF, nombre, logotipo, dirección, localidad, provincia y código postal donde se encuentra, así como la cuenta corriente donde se llevara a cabo la gestión contable. Dicha sociedad de cazadores quiere realizar un seguimiento de: - El mantenimiento de aspectos necesarios para administrar el resto del sistema. - Los socios que la integran. - Las personas no socias que participan en alguna actividad de la misma. - Los perros que utilizan los socios para cazar o bien los perros que participan en campeonatos organizados por la misma. - Las juntas directivas que la han regido. - Las diferentes temporadas que se han afrontado. Los aspectos que son necesarios para poder administrar el resto del sistema tienen como uno de los campos que lo define el campo estado, el cual puede ser “ACTUAL”, aspecto que está vigente en el sistema, o “HISTORIAL”, aspecto del que se quiere tener constancia aunque actualmente no es necesario. Dichos aspectos son los siguientes: - Los diferentes tipos de socios en los que la sociedad clasifica a sus socios. De cada tipo de socio se quiere conocer su nombre, descripción, en la que se puede definir el rango de edades que lo comprende así como los derechos y obligaciones que tienen. - Las modalidades de caza que los socios pueden practicar. Cada modalidad de caza está definida con un nombre, una descripción breve en la que se explique en qué consiste y el tipo de caza a la que pertenece, caza mayor y caza menor. - El coto de caza de la sociedad del cual se mantiene la siguiente información: el código, el nombre, el número de hectáreas que ocupa y la descripción del mismo, aspecto que no tiene el campo estado. De él también se quiere Capítulo 2 Metodología 11 saber las zonas en que se divide. De cada zona se quiere guardar su nombre, número de hectáreas, descripción así como el estado. - Las especies cazables que se pueden cazar. Dichas especies de caza están definidas por su nombre común, nombre científico (opcional), descripción y si se caza en caza menor o en caza mayor. De toda persona participante en la sociedad se quiere conocer su nombre y apellidos, DNI, teléfono y correo electrónico (opcional). Además de los socios se quiere conocer el número que lo va identificar dentro de la sociedad, la dirección, localidad, provincia y código postal donde vive, la fecha de nacimiento y el tipo de socio al que pertenece. Además se quiere saber si el socio tiene el pago de las cuotas domiciliado o no, si lo tiene, se debe guardar la información del número de la cuenta corriente donde se realizará. De cada socio también se quiere conocer el estado en el que se encuentra, “ACTUAL”, participa en la sociedad actualmente o, “HISTORIAL”, ha participado en la sociedad y si quisiera volver en un futuro no debería volver a pagar la cuota de entrada. Tanto de los socios como de los participantes no socios cuyos perros participan en la sociedad también se quiere llevar el control, de ellos se quiere guardar su número de identificación, su nombre, su especie, su raza, su sexo y su fecha de nacimiento. Los socios pueden formar parte de la junta directiva que rige la sociedad en los cargos de: presidente, vicepresidente, secretario, tesorero o vocal de una de las comisiones que existen en la sociedad. Una comisión se encargará de la gestión de uno de los apartados en los que se divide la gestión de la sociedad, la cual podrá tener como responsable a uno o más vocales que se pueden apoyar en la ayuda de otros socios denominados colaboradores. De cada una de las juntas directivas que han formado parte de la sociedad también se quiere conocer su fecha de constitución. Una junta directiva se encargara de gestionar un conjunto de temporadas. Una temporada se identifica por un nombre, por ejemplo, temporada 2009/2010, por su año inicio y el estado en que se encuentra, si esta “EN CONFIGURACIÓN”, quiere decir que es el periodo de la temporada en el que se establece las cuotas que los socios deberán pagar y las modalidades de temporada que van a practicar. Una vez finalizada esta etapa, el estado de la temporada cambiará a “EN CURSO”, etapa en la que se podrá gestionar las cuotas y modalidades de temporada que los socios eligen, las actividades y actuaciones que va realizar la sociedad así como los movimientos contables que genera la sociedad. Cuando la temporada ha finalizado su estado cambiara a “FINALIZADA”. Capítulo 2 Metodología 12 De cada cuota que se determina para la temporada se quiere conocer su nombre y los precios que tiene para cada uno de los tipos de socios actuales. Las cuotas se dividen en cuotas de entrada, de sociedad y de modalidad. Las cuotas de entrada son las que están obligadas a pagar los socios de nuevo ingreso. Toda temporada tiene que tener una cuota de entrada. Las cuotas de sociedad son las que hacen referencia al pago del alquiler del local de la sociedad, el mantenimiento del mismo, la derrama para hacer una reforma, etc. Todas las cuotas de sociedad que se determinan en una temporada son de obligado pago por los socios. Las cuotas de modalidad son las que se asocian a las modalidades que se establecen para cada temporada. De cada una de las modalidades de temporada se quiere conocer su nombre así como el conjunto de modalidades de caza que la componen. Una vez finalizada la etapa de configuración de la temporada el socio podrá determinar las modalidades que desea practicar. Cada socio tendrá cada temporada una cuota de socio, la cual estará compuesta por un conjunto de cuotas establecidas en dicha temporada. La cuota de entrada, si el socio es de nuevo ingreso, las cuotas de sociedad determinadas, así como las cuotas de modalidad que están relacionadas con las modalidades que el socio ha decidido practicar. El total de dicha cuota a pagar por un socio dependerá de su actual tipo de socio. Otra de las gestiones que se llevan a cabo en una temporada, es la gestión de las actividades. De cada actividad queremos guardar su nombre, fecha inicio, lugar de realización, descripción, periodo de preinscripción, la cuota que de inscripción del participante socio así como la cuota de inscripción para el participante no socio si se determina que pueden participar y el número máximo de participantes si existiera. Las actividades se dividen en actividades de sociedad, campeonatos de cazadores y campeonatos de perros. Las actividades de sociedad son las que están relacionadas con la realización de una jornada de tiro al pichón libre, una cena de los miembros de la sociedad o una excursión. De cada participante que se inscribe en una actividad se quiere conocer su D.N.I., nombre, apellidos, teléfono y correo electrónico (opcional). Los campeonatos de cazadores son las actividades que hacen referencia a competiciones entre cazadores de la cual se quiere gestionar su clasificación. De cada participante que se inscribe en un campeonato se quiere conocer su D.N.I., nombre, apellidos, teléfono, correo electrónico (opcional), dirección, localidad, provincia y código postal donde vive, fecha de nacimiento y si participan participantes no socios, Capítulo 2 Metodología 13 se quiere conocer el nombre de la sociedad de cazadores a la que pertenece (si pertenece alguna)y por supuesto la clasificación que logre. Los campeonatos de perros llevan una gestión similar a los campeonatos de cazadores, la diferencia es que la competición es entre perros, como puede ser un campeonato de carreras de galgos. De cada perro que participe se quiere conocer a parte los datos del participante dueño que se conocen en un campeonato de cazadores los datos identificativos del perro, número de identificación, nombre, raza, sexo, fecha nacimiento y la clasificación que logre. Tanto la decisión de que actividades se va a realizar como otras muchas decisiones se debaten y deciden en las asambleas que convoca la junta directiva a lo largo de la temporada, al menos debe convocar una para informar a los socios de cómo ha ido la gestión contable cuando finaliza la temporada, cada asamblea debe tener un nombre, fecha y lugar donde se va realizar y los puntos del día que se van a tratar, los cuales están definidos por un número y una descripción. Cada uno de los puntos tratados en la asamblea tendrá un acta en la cual se indicara los votos a favor, votos en contra, votos nulos y votos en blanco. También se quiere tener constancia de las actuaciones en el coto de caza que realiza la sociedad en una temporada. De cada actuación se quiere saber su número (generado por el sistema e identificador de ella), nombre y descripción, en qué consiste y si afecta al coto, a que zonas afecta en concreto. Una actuación puede ser de mejora, colocación de bebederos, suministro de alimentos para los animales o la colocación de cajas-nido. O puede ser una repoblación de una especie cazable, de la especie cazable a repoblar se quiere conocer el número de ejemplares. Además se quiere tener constancia de las vedas que las instituciones pertinentes establecen para la temporada, de ellas se quiere conocer su nombre, su fecha de inicio y de fin y su descripción. Para finalizar con la gestión que se realiza de cada temporada, se quiere mantener la información de los movimientos contables que ha generado la sociedad. Se quiere tener conocimiento de todos los gastos e ingresos que se van produciendo a lo largo de la temporada. Cada movimiento es definido por el concepto del gasto o ingreso, la fecha en que se realizó y el importe del mismo. Capítulo 3 Modelado Conceptual 15 Capítulo 3: Modelado Conceptual ¿Por qué modelamos? Porque necesitamos construir modelos para comprender mejor el sistema que estamos desarrollando, los modelos nos: - Visualizan como es o queremos que sea un sistema. - Especifican la estructura o el comportamiento de un sistema. - Proporcionan plantillas que nos guían a la construcción de un sistema - Documentan las decisiones que hemos adoptado. El modelado conceptual que se ha realizado es orientado a objetos (O.O.) que se define como “Un proceso que examina los requisitos desde la perspectiva de las clases y objetos encontrados en el vocabulario del dominio del problema” (Booch G. , 1994) , cuyas principales características son: - Próximo a los mecanismos cognitivos humanos. - Desarrollo incremental bajo una noción común de objeto. Capítulo 3 Modelado Conceptual 16 Las actividades del modelado nos van a permitir conseguir definir la estructura y comportamiento del sistema: - Definición del problema y recogida de datos. - Identificación de las clases y la estructura del dominio del problema. - Identificación del comportamiento de los objetos. - Identificación de los patrones de interacción entre objetos. - Integrar y revisar Diagramas (redefinir si es necesario). Este sistema se ha modelado atreves del lenguaje UML (Unified Modeling Language) el cual se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables (www.wikipedia.org). 3.1. Casos de uso Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por tanto los casos de uso determinan los requisitos funcionales del sistema. Se pueden usar durante las siguientes fases del desarrollo: - Captura de requisitos. - Planificación de iteraciones de desarrollo. - Validación del sistema. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente. Estos diagramas permiten una representación gráfica de las interacciones entre actores (usuarios o aplicaciones externas que podrán demandar la utilización de funciones ofrecidas por el sistema) y casos de uso (forma concreta de utilizar parte de la funcionalidad del sistema). A continuación se muestran los diagramas de casos de uso del proyecto desarrollados con la herramienta Rational Rose 98 (IBM Rational Rose). Además se Capítulo 3 muestran las plantillas de descripción de presente apartad o y el resto en el anexo A Diagrama de caso de uso de contexto Diagrama de caso de uso inicial Modelado Conceptual muestran las plantillas de descripción de los casos de uso, dos a modo de ejemplo en o y el resto en el anexo A . Diagrama de caso de uso de contexto Figura 4. Diagrama de contexto. inicial Figura 5. Diagrama inicial Modelado Conceptual 17 a modo de ejemplo en Capítulo 3 Diagrama de caso de uso de Figura 6 . Diagrama Diagrama de caso de uso del subsistema gestión de aspectos de administración Figura Modelado Conceptual Diagrama de caso de uso de l subsistema gestión de datos de sociedad de cazadores . Diagrama de gestión de datos de sociedad de cazadores . Diagrama de caso de uso del subsistema gestión de aspectos de administración Figura 7. Diagrama de gest ión de aspectos de administración Modelado Conceptual 18 de datos de sociedad de cazadores . Diagrama de caso de uso del subsistema gestión de aspectos de administración ión de aspectos de administración . Capítulo 3 Diagrama de caso de uso del subsistema Figura Diagrama de caso de uso del subsistema Figura 18. Modelado Conceptual del subsistema gestión de datos de actividades Figura 17. Diagrama gestión de datos actividades. del subsistema g estión de clasificación de campeonatos Diagrama gestión de clasificación de campeonatos. Modelado Conceptual 25 de actividades estión de clasificación de campeonatos Capítulo 3 Diagrama de caso de uso del subsistema Figura Modelado Conceptual del subsistema gestión de participantes Figura 19. Diagrama gestión de participantes. Modelado Conceptual 26 Capítulo 3 Diagrama de caso de uso del subsistema Figura Modelado Conceptual del subsistema gestión de actuaciones Figura 20. Diagrama gestión de actuaciones. Modelado Conceptual 27 Capítulo 3 Diagrama de caso de uso del subsistema Modelado Conceptual del subsistema gestión contable Figura 21. Diagrama gestión contable. Modelado Conceptual 28 Capítulo 3 Diagrama de caso de uso del subsistema Diagrama de caso de uso del subsistema Figura Modelado Conceptual del subsistema gestión de vedas Figura 22. Diagrama gestión de vedas. del subsistema gestión de asambleas Figura 23. Diagrama gestión de asambleas. Modelado Conceptual 29 Capítulo 3 Diagrama de caso de uso g Diagrama de caso de uso del subsistema g Figura Modelado Conceptual Diagrama de caso de uso g estión de socios Figura 24. Diagrama gestión de socios. del subsistema g estión de datos de socios Figura 25. Diagrama gestión de datos de socios. Modelado Conceptual 30 Capítulo 3 Modelado Conceptual 31 Caso de uso Alta de socio. Actores Secretario, Cazador. Propósito Crear un nuevo socio. Resumen El secretario solicita al nuevo socio los datos que se quieren conocer del mismo y lo guarda en el sistema. Precondiciones Postcondiciones Incluye Alta de cuota de socio. Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando un cazador desea hacerse socio de la sociedad. 2. El secretario solicita dar de alta un socio. 3. El secretario introduce el DNI que el cazador le indica. 4. Comprueba que no existe un socio o no socio con el DNI introducido. 5. Si no existe socio pero si no socio. 6. Introduce los datos que ya se conocen del nuevo socio. 7. El secretario introduce los datos de identificación que el cazador le indica. 8. Valida los datos introducidos. 9. Registra el alta del nuevo socio. 10. Se realiza el caso de uso Alta de cuota de socio. 11. Muestra un mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 4 el DNI del cazador introducido es de un socio antiguo, con estado “HISTORIAL”. 1.1. Muestra mensaje informando que fue socio anteriormente. 2. Si en 4 el DNI del cazador introducido es de un socio actual, con estado “ACTUAL”. 2.1. Muestra mensaje informando que es socio actual. 3. Si en 6 los datos introducidos son incorrectos. 3.1. Muestra mensaje de error. Extensiones asíncronas Ninguna. Capítulo 3 Diagrama de caso de uso del subsistema de g Figura Modelado Conceptual caso de uso del subsistema de g estión de temporadas de socios Figura 26. Diagrama gestión de temporadas de socios. Modelado Conceptual 32 de socios Capítulo 3 Diagrama de caso de uso subsis Figura Diag rama de caso de uso subsistema g Figura 28. Diagrama Modelado Conceptual Diagrama de caso de uso subsis tema gestión de juntas directivas Figura 27. Diagrama gestión de juntas directivas. rama de caso de uso subsistema g estión de composición de juntas directivas Diagrama gestión de composición de juntas directivas. Modelado Conceptual 33 estión de composición de juntas directivas Capítulo 3 Diag rama de caso de uso subsistema g Figura 29 . Diag rama de caso de uso subsistema g Modelado Conceptual rama de caso de uso subsistema g estión de comisiones de juntas directivas . Diagrama gestión de comisiones juntas directivas. rama de caso de uso subsistema g estión de perros Figura 30. Diagrama gestión de perros. Modelado Conceptual 34 estión de comisiones de juntas directivas Capítulo 4 Arquitectura del sistema 41 Capítulo 4: Arquitectura del sistema Este término tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad (Kruchten, November 1995). Capítulo 4 Arquitectura del sistema 42 La aplicación del presente caso de estudio se ha desarrollado bajo la arquitectura cliente/servidor de tres capas. Que una arquitectura es cliente/servidor significa que se modela como un conjunto de servicios que son proporcionados por los servidores y un conjunto de clientes que usan dichos servicios, siendo clientes y servidores procesos lógicos y distintos. Que es una arquitectura n-capas, en este caso tres en capas, quiere decir que el sistema es un conjunto ordenado de subsistemas, cada uno de los cuales está construido en términos de los que tiene por debajo, y proporciona la base de la implementación de aquellos que estén por encima de él. Es recomendable que los objetos de cada capa sean independientes, aunque es habitual que existan dependencias entre objetos de distintas capas ya que existe una relación cliente/servidor entre las capas inferiores que proporcionan servicios y las capas superiores que son consumidores de estos servicios. Las arquitecturas basadas en capas, pueden ser abiertas o cerradas según la dependencia que exista entre las capas: - Abierta: Una capa puede utilizar características de cualquier capa a cualquier nivel. - Cerrada: Una capa sólo utiliza características de la capa inmediatamente inferior. Normalmente es recomendable trabajar con arquitecturas cerradas pues así se reducen las dependencias entre niveles y esto permite que los cambios en la implementación de una capa no afecten al resto de capas. La arquitectura de 3 capas es la más básica de las arquitecturas de n-capas y en ella podemos distinguir los niveles de: - Presentación: Proporciona la interfaz visual que los clientes utilizarán para ver la información y los datos. Los componentes son responsables de solicitar y recibir servicios de otros componentes del mismo nivel o del nivel de negocio. - Negocio o Lógica: Como los servicios de usuario no pueden contactar directamente con el nivel de servicios de datos, es responsabilidad de los servicios de negocio hacer de puente entre estos. Los objetos de negocio proporcionan servicios que completan las tareas de negocio tales como verificar los datos enviados por el cliente. Antes de llevar a cabo una transacción en la B.D. Capítulo 4 Arquitectura del sistema 43 - Persistencia o Datos: Se encarga de las típicas tareas que realizamos con los datos: Inserción, modificación, consulta y borrado. La clave de este nivel es que los papeles de negocio no son implementados aquí. Aunque un componente de servicio de datos es responsable de la gestión de las peticiones realizadas por un objeto de negocio. El esquema genérico de la arquitectura cliente/servidor de 3 capas es el siguiente: Figura 38. Arquitectura genérica de tres capas (extraída de (ISG, Ingeniería del software de gestión, 2008/09)). Capítulo 4 La adaptación de dicha arquitectura a nuestro caso de estudio los componentes que se muestran en la figura 39 Figura 39. Arquitectura de tres capas del caso de estudio software de gestión, 2008/09). - En la capa de presentación más importante es es el punto de entrada a la aplicación, y por ello es responsabilidad de dicho formulario inicializar carga del sistema) creando los objetos necesarios para la correcta ejecución del programa. - En la capa de negocio clase ConexionBD La clase SociedadCazado resto de las clases de la capa negocio. Mediante ella se realiza la comunicación entre una de las instancias que se creen de los diferentes formularios s el atributo que corresponde al objeto de la clase La otra clase importante es que se realiza la persistencia , comunicando el ob el objeto creado de la clase Arquitectura del sistema La adaptación de dicha arquitectura a nuestro caso de estudio tendrá la estructura y que se muestran en la figura 39 : Arquitectura de tres capas del caso de estudio (adaptada de (ISG, Ingeniería de presentación entre todas las clases/formularios más importante es el formulario Formulario principal, una instancia de este, es el punto de entrada a la aplicación, y por ello es responsabilidad de dicho formulario inicializar el sistema (escenario típicamente conocido como carga del sistema) creando los objetos necesarios para la correcta ejecución negocio hay que destacar la clase SociedadCazadores ConexionBD . SociedadCazado res es la clase a través de la cual se accede al resto de las clases de la capa negocio. Mediante ella se realiza la comunicación entre la capa de presentación y la capa de negocio una de las instancias que se creen de los diferentes formularios s el atributo que corresponde al objeto de la clase SociedadCazadores La otra clase importante es ConexionBD ya que es la clase a través de la que se realiza la comunicación entre la capa de negocio y , comunicando el ob jeto creado de la clase SociedadCazadores el objeto creado de la clase SistemaCentral. Arquitectura del sistema 44 tendrá la estructura y (ISG, Ingeniería de las clases/formularios que existen la una instancia de este, es el punto de entrada a la aplicación, y por ello es responsabilidad de dicho sistema (escenario típicamente conocido como carga del sistema) creando los objetos necesarios para la correcta ejecución SociedadCazadores y la es la clase a través de la cual se accede al resto de las clases de la capa negocio. Mediante ella se realiza la negocio , en cada una de las instancias que se creen de los diferentes formularios s e asignara SociedadCazadores . ya que es la clase a través de la negocio y la capa de SociedadCazadores y Capítulo 4 Arquitectura del sistema 45 - En la capa de persistencia la única clase, que no por ello menos importante, es la clase SistemaCentral que es la clase mediante la cual se accede a la base de datos. Capítulo 5 Diseño 47 Capítulo 5: Diseño En este capítulo se muestran los diseños asociados a las tres capas de la arquitectura del sistema: - Diseño de IGU (capa de presentación). - Diseño de clases (capa de negocio o lógica de la aplicación). - Diseño de base de datos (capa de persistencia). 5.1. Diseño de IGU El diseño de la interfaz gráfica (IGU) de usuario es un factor muy importante en la realización de una aplicación debido a que es el medio de comunicación mediante el cual el usuario interactúa con la aplicación. Capítulo 5 Diseño 48 Por ello se ha intentado que nuestra aplicación haya logrado un diseño de interfaces eficaces que cumpla con los principios generales de diseño de las interfaces de usuario (Sommerville, 2002) que se definen a continuación: - Familiaridad del usuario. La interfaz debe utilizar términos y conceptos que se toman de la experiencia de las personas que más utilizan el sistema. - Consistencia. La interfaz debe ser consistente en el sentido de que operaciones similares se realizan o activan de la misma forma. - Mínima Sorpresa. El comportamiento del sistema no debe provocar sorpresa a los usuarios. - Recuperabilidad. La interfaz debe incluir mecanismos que permitan a los usuarios recuperarse de los errores. - Guía al usuario La interfaz debe proveer retroalimentación significativa y características de ayuda sensible al contexto. - Diversidad de Usuarios. La interfaz debe proveer características de interacción apropiada para los diferentes tipos de usuarios del sistema. Las interfaces, formularios, en nuestra aplicación se dividen en tres tipos: - Formulario padre. Es un formulario contenedor que se divide en dos paneles verticales, en el de la izquierda es donde se mostraran los formularios hijos. - Formulario hijo tipo A. Es un formulario dividido en dos paneles horizontales, en el superior se gestionan y se listan las instancias de un concepto, en el inferior se gestiona toda la información de una instancia concreta. - Formulario hijo tipo B. Es un formulario en el que se gestiona toda la información de una instancia concreta, cuando el volumen de información no cabe en el panel inferior de un formulario hijo tipo B. Capítulo 5 La organización de dichos formularios se muestra mejor compresión de dicha figura se acl abstraer a cualquiera de las gestiones que se identifican en el Diagrama inicial de los casos de uso que aparece al comienzo del apartado 3.1. La organización de dichos formularios se muestra en la figura 40 mejor compresión de dicha figura se acl ara que gestión de concepto abstraer a cualquiera de las gestiones que se identifican en el Diagrama inicial de los casos de uso que aparece al comienzo del apartado 3.1. Figura 40. Esquema de formulario. Diseño 49 en la figura 40 . Para una gestión de concepto es la forma de abstraer a cualquiera de las gestiones que se identifican en el Diagrama inicial de los Capítulo 5 Diseño 50 Para ver diseños concretos de los formularios de la aplicación y comprender como es la interacción con el usuario a se muestran los formularios asociados a los diagrama de secuencia que se mostraron en el apartado 3.3. Diagramas de secuencia. Baja de modalidad de caza En el formulario que se muestra en la figura 41 se realizan todas las operaciones asociadas a la gestión de las modalidades de caza. Figura 41. Formulario gestión de modalidades de caza. A continuación se explica de este formulario como el usuario realiza la operación de dar de baja una modalidad de caza, los pasos a seguir son los siguientes: 1. El usuario hace clic en el panel de la izquierda sobre Modalidades de caza. 2. El sistema muestra el formulario de gestión de modalidades de caza en el panel de la derecha. 3. El usuario selecciona la modalidad de caza que se quiere eliminar. 4. El usuario hace clic en el botón eliminar. 5. El sistema realiza e informa mediante un mensaje de la operación que ha realizado: - Dar de baja la modalidad de caza. - Establecer la modalidad de caza en el historial de modalidades de caza. - Denegar la operación de dar de baja debido a que la modalidad de caza forma parte de una modalidad de temporada actual. Capítulo 5 Diseño 57 public class Socio:Participante { //Declaración de atributos … //Constructores public Socio(int NISNuevo,string estadoNuevo,string cuentaCorrienteNueva, TipoSocio tipoSocioNuevo, string DNINuevo, string nombreNuevo, string apellido1Nuevo, string apellido2Nuevo,string direccionNueva, string localidadNueva, string provinciaNueva, string codigoPostalNuevo, string telefonoNuevo, string correoElectronicoNuevo, DateTime fechaNacimientoNueva) :base(DNINuevo, nombreNuevo, apellido1Nuevo, apellido2Nuevo, direccionNueva, localidadNueva, provinciaNueva, codigoPostalNuevo, telefonoNuevo, correoElectronicoNuevo, fechaNacimientoNueva) { NIS = NISNuevo; estado = estadoNuevo; cuentaCorriente = cuentaCorrienteNueva; tipoSocioPertenece = tipoSocioNuevo; tipoSocioPertenece.anyadirSocio(this); listaCuotasSocio = new List<CuotaSocio>(); listaModalidadesTemporadas = new List<ModalidadTemporada>(); listaTesoreroJuntasDirectivas = new SortedList<long, JuntaDirectiva>(); listaSecretarioJuntasDirectivas = new SortedList<long, JuntaDirectiva>(); listaVicepresidenteJuntasDirectivas = new SortedList<long, JuntaDirectiva>(); listaPresidenteJuntasDirectivas = new SortedList<long, JuntaDirectiva>(); listaVocalComisiones = new List<Comision>(); listaActividadesSociedad = new List<ActividadSociedad>(); listaCampeonatosSocio = new List<CampeonatoSocio>(); } //Consultores de atributos public string getCuentaCorriente() { return cuentaCorriente;} public TipoSocio getTipoSocio() { return tipoSocioPertenece;} public List<CuotaSocio> getListaCuotasSocio() { return listaCuotasSocio;} //Igual para el resto de atributos … //Modificadores de atributos public void setCuentaCorriente(string cuentaCorrienteNueva) { cuentaCorriente = cuentaCorrienteNueva;} public void setTipoSocio(TipoSocio tipoSocioNuevo) { tipoSocioPertenece = tipoSocioNuevo;} //Igual para el resto de atributos … } Capítulo 5 Diseño 58 public class Socio:Participante { //Declaración de atributos … //Constructores … //Consultores … //Modificadores … //Tratamiento de colecciones //Métodos añadir,borrar y buscar en la colección List listaCuotasSocios public void anyadirCuotaSocio(CuotaSocio cuotaSocioNueva) { bool existe = false; foreach(CuotaSocio cuotaSocioActual in listaCuotasSocio) { if(cuotaSocioActual.getTemporadaCuota().getNombre().Equals (cuotaSocioNueva.getTemporadaCuota().getNombre())) { existe = true; break; } } if(!existe) listaCuotasSocio.Add(cuotaSocioNueva); else throw new ElementoYaExistente("Ya existe la cuota del socio con los datos especificados."); } public void borrarCuotaSocio(CuotaSocio cuotaSocioBorrar) { bool existe = false; foreach(CuotaSocio cuotaSocioActual in listaCuotasSocio) { if(cuotaSocioActual.getTemporadaCuota().getNombre().Equals (cuotaSocioBorrar.getTemporadaCuota().getNombre())) { existe = true; break; } } if(existe) listaCuotasSocio.Remove(cuotaSocioBorrar); else throw new ElementoNoEncontrado( "No se ha encontrado la cuota del socio con los datos especificados."); } public CuotaSocio buscarCuotaSocio(string nombreTemporada) { foreach(CuotaSocio cuotaSocioActual in listaCuotasSocio) { if(cuotaSocioActual.getTemporadaCuota().getNombre().Equals(nombreTemporada)) return cuotaSocioActual; } throw new ElementoNoEncontrado("No se ha encontrado la cuota del socio de la temporada " + nombreTemporada + "."); } //Igual para el resto de colecciones List … } Capítulo 5 Diseño 59 public class Socio:Participante { //Declaración de atributos … //Constructores … //Consultores … //Modificadores … //Tratamiento de colecciones //Métodos añadir,borrar y buscar para la colección //SortedList listaTesoreroJuntasDirectivas public void anyadirTesoreroJuntaDirectiva(JuntaDirectiva juntaDirectivaNueva) { if (!listaTesoreroJuntasDirectivas.ContainsKey(juntaDirectivaNueva.getNumero())) listaTesoreroJuntasDirectivas.Add(juntaDirectivaNueva.getNumero(), juntaDirectivaNueva); else throw new ElementoYaExistente( "Ya existe el socio como tesorero de la junta directiva actual"); } public void borrarTesoreroJuntaDirectiva(JuntaDirectiva juntaDirectivaBorrar) { if (listaTesoreroJuntasDirectivas.ContainsKey(juntaDirectivaBorrar.getNumero())) listaTesoreroJuntasDirectivas.Remove(juntaDirectivaBorrar.getNumero()); else throw new ElementoNoEncontrado("No se ha encontrado el socio como tesorero de la junta directiva actual"); } public JuntaDirectiva buscarTesoreroJuntaDirectiva(long numeroJuntaDirectiva) { if (listaTesoreroJuntasDirectivas.ContainsKey(numeroJuntaDirectiva)) return listaTesoreroJuntasDirectivas[numeroJuntaDirectiva]; else throw new ElementoNoEncontrado( "No se ha encontrado el socio como tesorero de la junta directiva indicada"); } //Igual para el resto de colecciones SortedList … //Fin de clase } Capítulo 5 Diseño 60 5.3. Diseño de base de datos Los diseños orientados a objetos son eficientes, coherentes y menos proclives los problemas de actualización que aquejan a muchas otras técnicas de diseño de bases de datos. Pero, el modelo relacional ha ganado popularidad, por lo que se han incrementado sus ventajas en lo tocante a funcionalidad y flexibilidad. Además, a pesar de que las bases de datos orientadas a objetos tienen un aspecto prometedor, todavía no han alcanzado una amplia aceptación masiva por parte del mercado. El diagrama de clases se puede usar para implementar un diseño de una base de datos relacional, pero para traducir un diagrama de clases a tablas ideales, hay que proporcionar detalles que faltan en el diagrama, como la clave primaria y los candidatos a clave para cada tabla; así como si un atributo puede ser o no ser nulo y asignando un dominio a cada atributo. A partir del diagrama de clases del presente caso de estudio se obtiene el siguiente diseño lógico relacional de la base de datos en el cual se muestran las tablas surgidas ordenadas alfabéticamente. Actividad (nombre: tira (60), fechaInicio: fecha, id_Temporada: tira (20), fechaFin: fecha, lugar: tira(60), descripcion: tira(MAX), fechaInicioInscripcion: fecha, fechaFinInscripcion: fecha, cuotaInscripcionSocio: decimal, participaNoSocio: tira(2)(“SI”,”NO”), cuotaInscripcionNoSocio: decimal, maximoParticipantes: entero) Clave primaria: {nombre, fechaInicio, id_Temporada} Clave ajena: {id_Temporada} hace referencia a Temporada Valores no nulos: {fechaFin, lugar, descripcion, fechaInicioInscripcion, fechaFinInscripcion, participaNoSocio, maximoParticipantes} Capítulo 5 Diseño 61 ActividadSociedad (id_NombreActividad: tira (60), id_fechaInicioActividad: fecha, id_TemporadaActividad: tira (20)) Clave primaria: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} Clave ajena: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} hace referencia a Actividad ActividadSociedad-NoSocio (id_NombreActividad: tira (60), id_fechaInicioActividad: fecha, id_TemporadaActividad: tira (20), id_NoSocio: tira (9)) Clave primaria: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} Clave ajena: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} hace referencia a ActividadSociedad Clave ajena: {id_NoSocio} hace referencia a NoSocio ActividadSociedad-Socio (id_NombreActividad: tira (60), id_fechaInicioActividad: fecha, id_TemporadaActividad: fecha, id_Socio: tira (9)) Clave primaria: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} Clave ajena: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} hace referencia a ActividadSociedad Clave ajena: {id_Socio} hace referencia a Socio Capítulo 5 Diseño 62 Actuacion (nombre: tira (40), id_Temporada: tira (20), descripcion: tira (MAX)) Clave primaria: {nombre, id_Temporada} Clave ajena: {id_Temporada} hace referencia a Temporada Valor no nulo: {descripcion} Actuacion-Zona (id_NombreActuacion: tira (40), id_TemporadaActuacion: tira (20), id_NombreZona: tira (40), id_CotoZona: tira (20)) Clave primaria: {id_NombreActuacion, id_TemporadaActuacion, id_NombreZona, id_CotoZona} Clave ajena: {id_NombreActuacion, id_TemporadaActuacion} hace referencia a Actuacion Clave ajena: { id_NombreZona, id_CotoZona} hacer referencia a Zona Asamblea (nombre: tira (40), fecha: fecha, id_Temporada: tira (20), lugar: tira (60), id_JuntaDirectiva: entero) Clave primaria: {nombre, fechaInicio, idTemporada} Clave ajena: {idTemporada} hace referencia a Temporada Clave ajena: {idJuntaDirectiva} hace referencia a JuntaDirectiva Capítulo 5 Diseño 63 Valor no nulo: {lugar, idJuntaDirectiva} CampeonatoCazadores (id_NombreActividad: tira (60), id_fechaInicioActividad: fecha, id_TemporadaActividad: tira (20), estadoFinalizacion: tira (2)(“SI”,”NO”)) Clave primaria: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} Clave ajena: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} hace referencia a Actividad Valor no nulo: {estadoFinalizacion} CampeonatoCazadores-NoSocio (id_NombreActividad: tira (60), id_fechaInicioActividad: fecha, id_TemporadaActividad: tira (20), id_NoSocio: tira (9)). Clave primaria: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad, id_Nosocio}. Clave ajena: {id_NombreActividad, id_fechaInicioActividad, id_TemporadaActividad} hace referencia a Actividad Clave ajena: {id_NoSocio} hace referencia a NoSocio CampeonatoCazadores-Socio (id_NombreActividad: tira (60), id_FechaInicioActividad: fecha, id_TemporadaActividad: tira (20), id_Socio: tira (9)). Clave primaria: {id_NombreActividad, id_FechaInicioActividad, id_TemporadaActividad, Capítulo 5 Diseño 64 id_Nosocio} Clave ajena: {id_NombreActividad, id_FechaInicioActividad, id_TemporadaActividad} hace referencia a Actividad Clave ajena: {id_Socio} hace referencia a Socio CampeonatoPerros (id_NombreActividad: tira (60), id_FechaInicioActividad: fecha, id_TemporadaActividad: tira (20), estadoFinalizacion: tira(2)(“SI”,”NO”)) Clave primaria: {id_NombreActividad, id_FechaInicioActividad, id_TemporadaActividad} Clave ajena: {id_NombreActividad, id_FechaInicioActividad, id_TemporadaActividad} hace referencia a Actividad Valor no nulo: {estadoFinalizacion} CampeonatoPerros-PerroSocio (idNombreCampeonato: tira (60), idFechaInicioCampeonato: fecha, idTemporadaCampeonato: tira (20), idPerro: tira (20), idSocio: tira (9), puntuacion: entero) Clave primaria: {idNombreCampeonato, idFechaInicioCampeonato, idTemporadaCampeonato, idPerro, idSocio} Clave ajena: {idNombreCampeonato, idFechaInicioCampeonato, idTemporadaCampeonato } hace referencia a CampeonatoPerros Clave ajena: {idPerro, Capítulo 5 Diseño 65 idSocio} hace referencia a PerroSocio Valor no nulo: {puntuacion} CampeonatoPerros-PerroNoSocio (idNombreCampeonato: tira (60), idFechaInicioCampeonato: fecha, idTemporadaCampeonato: tira (20), idPerro: tira (20), idNoSocio: tira (9), puntuacion: entero) Clave primaria: {idNombreCampeonato, idFechaInicioCampeonato, idTemporadaCampeonato, idPerro, idNoSocio} Clave ajena: {idNombreCampeonato, idFechaInicioCampeonato, idTemporadaCampeonato } hace referencia a CampeonatoPerros Clave ajena: {idPerro, idNoSocio } hace referencia a PerroNoSocio Valor no nulo: {puntuacion} Comision (id_TipoComision: tira (40), id_JuntaDirectiva: entero). Clave primaria: {id_TipoComision, id_JuntaDirectiva} Clave ajena: {id_TipoComision} hace referencia a Actividad. Clave ajena: {id_JuntaDirectiva } hace referencia a JuntaDirectiva. Comision-Socio (id_TipoComision: tira (40), id_JuntaDirectiva: entero, id_Vocal: tira (9)) Capítulo 5 Diseño 66 Clave primaria: {id_TipoComision, id_JuntaDirectiva, id_Vocal} Clave ajena: {id_TipoComision, id_JuntaDirectiva} hace referencia a Comision. Clave ajena: {id_Vocal} hace referencia a Socio. Coto (codigo: tira (20), nombre: tira (40), superficie: decimal, descripcion: tira (MAX)). Clave primaria: {codigo} Valor no nulo: {nombre, superficie, descripcion} Cuota (nombre: tira (50), id_Temporada: tira (20)) Clave primaria: {nombre, id_Temporada} Clave ajena: {id_Temporada} hace referencia Temporada. CuotaEntrada (id_NombreCuota: tira (50), id_TemporadaCuota: tira (20)) Clave primaria: {id_NombreCuota, id_TemporadaCuota} Clave ajena: {id_NombreCuota, id_TemporadaCuota} hace referencia Cuota. CuotaModalidad (id_NombreCuota: tira (50), id_TemporadaCuota: tira (20)) Clave primaria: {id_NombreCuota, Capítulo 5 Diseño 73 idTemporadaAsamblea: tira (20), asunto: tira (MAX), votosFavor: entero, votosContra: entero) Clave primaria: {numero, idNombreAsamblea, idFechaAsamblea, idTemporadaAsamblea} Clave ajena: {idNombreAsamblea, idFechaAsamblea, idTemporadaAsamblea} hace referencia a Asamblea Valor no nulo: {asunto} Repoblacion (id_NombreActuacion: tira (40), id_TemporadaActuacion: tira (20)) Clave primaria: {id_NombreActuacion, id_TemporadaActuacion} Clave ajena: {id_NombreActuacion, id_TemporadaActuacion} hace referencia a Actuacion. Repoblacion-EspecieCazable (id_NombreActuacion: tira (40), id_TemporadaActuacion: tira (20), id_EspecieCazable: tira (30), numeroEjemplares: entero) Clave primaria: {id_NombreRepoblacion, id_TemporadaRepoblacion, id_EspecieCazable} Clave ajena: {id_NombreRepoblacion, id_TemporadaRepoblacion} hace referencia a Repoblacion Clave ajena: {id_EspecieCazable} hace referencia a EspecieCazable Valor no nulo: {numeroEjemplares} Capítulo 5 Diseño 74 SociedadCazadores (CIF: tira (9), nombre: tira (60), logotipo: imagen, direccion: tira (100), codigoPostal: tira (5), localidad: tira (40), provincia: tira (40), teléfono: tira (15), correoElectronico: tira (60), paginaWeb: tira (60), cuentaCorriente: tira (23) (X:1..9, “XXXX XXXX XX XXXXXXXXXX”)) Clave primaria: {CIF} Valor no nulo: {nombre, direccion, codigoPostal, localidad, provincia, telefono} Socio (id_Participante: tira (9), NIS: entero, cuentaCorriente: tira (23) (X:1..9, “XXXX XXXX XX XXXXXXXXXX”), id_TipoSocio: tira (30), estado: tira (10)(“ACTUAL”,“HISTORIAL”)) Clave primaria: {id_Participante} Clave ajena: {id_Participante} hace referencia a Socio Clave ajena: {id_TipoSocio} hace referencia a TipoSocio Único: {NIS} Valor no nulo: {NIS, id_TipoSocio, estado} Temporada (nombre: tira(20), Capítulo 5 Diseño 75 añoInicio: entero, estado: tira (20)(“EN CONFIGURACIÓN”,”EN CURSO”,”FINALIZADA”)) Clave primaria: {nombre} Valor no nulo: {año, estado} Temporada-JuntaDirectiva (id_Temporada: tira (20), id_JuntaDirectiva: entero) Clave primaria: {id_Temporada, id_JuntaDirectiva} Clave ajena: {id_Temporada} hace referencia Temporada Clave ajena: {id_JuntaDirectiva} hace referencia a JuntaDirectiva TipoComision (nombre: tira (40), descripcion: tira (MAX), estado: tira (10)(“ACTUAL”,”HISTORIAL”) Clave primaria: {nombre} Valor no nulo: {descripcion, estado} TipoSocio (nombre: tira (30), descripcion: tira (MAX), estado: tira (10)(“ACTUAL”,”HISTORIAL”)) Clave primaria: {nombre} Valor no nulo: {descripcion, estado} Veda (nombre: tira (40), idTemporada: tira(20), fechaInicio: fecha, fechaFin: fecha, descripcion: tira(MAX)) Capítulo 5 Diseño 76 Clave primaria: {nombre, idTemporada} Clave ajena: {idTemporada} hace referencia aTemporada Valor no nulo: {fechaInicio, fechaFin, descripcion} Zona (nombre: tira (40), id_Coto: tira (20), superficie: decimal, descripcion: tira(MAX), estado: tira (10)( “ACTUAL”,”HISTORIAL”)) Clave primaria: {nombre, id_Coto} Clave ajena: {id_Coto} hace referencia a Coto Valor no nulo: {superficie, descripcion, estado} Atreves de este diseño lógico relacional se ha desarrollado la base de datos BD_SC mediante la aplicación SQL Server Management Studio Express. Capítulo 6 Implementación 77 Capítulo 6: Implementación 6.1. Tecnología La aplicación del proyecto se desarrolla bajo la tecnología .NET por medio de Microsoft Visual Studio 2008 (Microsoft Visual Studio) y atreves del lenguaje C# (Lenguaje C#). La tecnología .NET es una plataforma de desarrollo de software desarrollada por Microsoft que hace énfasis en la transparencia de redes, orientado completamente a objetos, que es capaz de ejecutarse bajo cualquier plataforma y que permita un rápido desarrollo de aplicaciones, económico, a la vez que seguro y robusto. Capítulo 6 Implementación 78 .NET es la plataforma soportada por Visual Studio en esta aplicación Visual Studio 2008, entorno de desarrollo integrado para sistemas operativos Windows que soporta varios lenguajes de programación tales como visual C++, Visual C#, Visual J#, ASP.NET y Visual Basic.NET, aunque actualmente se han desarrollado las extensiones necesarias para muchos otros. Permite a los desarrolladores crear aplicaciones, sitios y aplicaciones web, así como servicios web. Así se pueden crear aplicaciones que se intercomuniquen entre estaciones de trabajo, páginas web y dispositivos móviles. El lenguaje que se ha elegido para implementar la aplicación ha sido C#, cuyos principales creadores son Scott Wiltamuth y Anders Hejlsberg, éste último también conocido por haber sido el diseñador del lenguaje Turbo Pascal y la herramienta RAD Delphi. C# (pronunciado en inglés “C Sharp” y en español “C almohadilla”) es el único lenguaje diseñado específicamente para ser utilizado en .NET, por lo que es mucho más sencillo e intuitivo que hacerlo con cualquiera de los otros lenguajes ya que C# carece de elementos heredados innecesarios en .NET. Por esta razón, se suele decir que C# es el lenguaje nativo de .NET, y de hecho gran parte de la librería de clases base de .NET ha sido escrito en este lenguaje. C# es un lenguaje orientado a objetos sencillo, moderno, amigable, intuitivo y fácilmente legible que ha sido diseñado por Microsoft con el ambicioso objetivo de recoger las mejores características de muchos otros lenguajes, fundamentalmente Visual Basic, Java y C++, y combinarlas en uno sólo en el que se unan la alta productividad y facilidad de aprendizaje de Visual Basic con la potencia de C++. Quizás el más directo competidor de C# es Java, lenguaje con el que guarda un enorme parecido en su sintaxis y características. En este aspecto, es importante señalar que C# incorpora muchos elementos de los que Java carece (sistema de tipos homogéneo, propiedades, indexadores, tablas multidimensionales, operadores redefinibles, etc.). Ahora se expondrán las principales características de C#: - Dispone de todas las características propias de cualquier lenguaje orientado a objetos: encapsulación, herencia y polimorfismo. - Ofrece un modelo de programación orientada a objetos homogéneos, en el que todo el código se escribe dentro de clases y todos los tipos de datos, incluso los básicos, son clases que heredan de System.Object. - Permite definir estructuras, que son clases un tanto especiales: sus objetos se almacenan en pila, por lo que se trabaja con ellos directamente y no referencias al montículo, lo que permite accederlos más rápido. Sin embargo, esta mayor eficiencia en sus accesos tiene también sus inconvenientes, fundamentalmente que el tiempo necesario para pasarlas como parámetros a métodos es mayor (hay que copiar su valor completo y Capítulo 6 Implementación 79 no sólo una referencia) y no admiten herencia (aunque sí implementación de interfaces). - Es un lenguaje fuertemente tipado, lo que significa se controla que todas las conversiones entre tipos se realicen de forma compatible, lo que asegura que nunca se acceda fuera del espacio de memoria ocupado por un objeto. Así se evitan frecuentes errores de programación y se consigue que los programas no puedan poner en peligro la integridad de otras aplicaciones. - Tiene a su disposición un recolector de basura que libera al programador de la tarea de tener que eliminar las referencias a objetos que dejen de ser útiles, encargándose de ello éste y evitándose así que se agote la memoria porque al programador olvide liberar objetos inútiles o que se produzcan errores porque el programador libere áreas de memoria ya liberadas y reasignadas. - Incluye soporte nativo para eventos y delegados. Los delegados son similares a los punteros a funciones de otros lenguajes como C++ aunque más cercanos a la orientación a objetos, y los eventos son mecanismos mediante los cuales los objetos pueden notificar de la ocurrencia de sucesos. Los eventos suelen usarse en combinación con los delegados para el diseño de interfaces gráficas de usuario, con lo que se proporciona al programador un mecanismo cómodo para escribir códigos de respuesta a los diferentes eventos que puedan surgir a lo largo de la ejecución de la aplicación. (pulsación de un botón, modificación de un texto, etc.) - Incorpora propiedades, que son un mecanismo que permite el acceso controlado a miembros de una clase tal y como si de campos públicos se tratasen. Gracias a ellas se evita la pérdida de legibilidad que en otros lenguajes causa la utilización de métodos Set() y Get() pero se mantienen todas las ventajas de un acceso controlado por estos proporcionada. - Permite la definición del significado de los operadores básicos del lenguaje (+, -, *, &, ==, etc.) para nuestros propios tipos de datos, lo que facilita enormemente tanto la legibilidad de las aplicaciones como el esfuerzo necesario para escribirlas. Es más, se puede incluso definir el significado del operador [] en cualquier clase, lo que permite acceder a sus objetos tal y como si fuesen tablas. A la definición de éste último operador se le denomina indizador, y es especialmente útil a la hora de escribir o trabajar con colecciones de objetos. - Admite unos elementos llamados atributos que no son miembros de las clases sino información sobre éstas que podemos incluir en su declaración. Por ejemplo, indican si un miembro de una clase ha de aparecer en la Capítulo 6 Implementación 80 ventana de propiedades de Visual Studio.NET, cuáles son los valores admitidos para cada miembro en ésta, etc. ¿Por qué esta tecnología? Porque nuestra aplicación se va a ejecutar bajo un entorno Windows y porque es una tecnología muy extendida y fácil de usar y además porque yo autor de este proyecto ya he trabajado con ella en otros trabajos. 6.2. Acceso a Datos: Escenario desconectado Para detallar cómo se ha implementado la aplicación hay que explicar que la implementación por un lado ha dependido de cómo se ha realizado el acceso a la base de datos relacional. El acceso a la base de datos se ha realizado mediante el escenario desconectado que proporciona ADO.NET. ADO.NET es un conjunto de componentes del software que pueden ser usados por los programadores para acceder a datos y a servicios de datos. Es una parte de la biblioteca de clases base que están incluidas en el Microsoft .NET Framework. Es comúnmente usado por los programadores para acceder y modificar los datos almacenados en un Sistema Gestor de base de datos Relacionales, aunque también puede ser usado para acceder a datos no relacionales. La aplicación se ha realizado bajo el escenario desconectado, que es el entorno en el que una parte de los datos del servidor central se copia localmente y puede luego ser consultada y actualizada sin contar con una conexión abierta. Luego si se desea puede establecerse una conexión con el servidor de base de datos para sincronizar los cambios efectuados sobre la copia local y actualizar los datos. El modelo de objetos que se han utilizado para llevar a cabo el escenario desconectado que accede a la base de datos Microsoft SQL Server utilizada por esta aplicación, son los que el proveedor de ADO.NET Data Provider For SQL Server nos proporciona a través de las clases que se encuentra en el namespace System.Data.SqlCient. En la figura que se muestra a continuación se definen los objetos utilizados por el escenario desconectado además de cómo interactúan entre ellos. Capítulo 6 Figura 45. Esquema del escenario desconectado de Software, 2008/09). El acceso a los datos a través de un escenario desconectado es el siguiente: 1. Abrir Conexión. 2. Llenar DataSet mediante 3. Cerrar Conexión 4. Procesar DataSet 5. Abrir conexión. 6. Actual izar fuente de datos mediante 7. Cerrar Conexión Después de explicar implementación teniendo en cuenta En momentos puntuales de la implementación en cómo se gestionan las modalidades de caza. Dichos detalles de implementación se pueden extrapolar para determinar cómo se realizan el resto de gestiones que soporta el sistema. Implementación Esquema del escenario desconectado extendida de (DSW, Técnicas Avanzadas para Desarr El acceso a los datos a través de un escenario desconectado es el siguiente: mediante DataAdapter. Cerrar Conexión . DataSet . izar fuente de datos mediante DataAdapter. Cerrar Conexión . Después de explicar el escenario desconectado, se mostrara detalles teniendo en cuenta los pasos que sigue. En momentos puntuales de la implementación , las explicaciones se centrarán modalidades de caza. Dichos detalles de implementación se pueden extrapolar para determinar cómo se realizan el resto de gestiones que soporta Implementación 81 (DSW, Técnicas Avanzadas para Desarr ollo El acceso a los datos a través de un escenario desconectado es el siguiente: se mostrara detalles de la , las explicaciones se centrarán modalidades de caza. Dichos detalles de implementación se pueden extrapolar para determinar cómo se realizan el resto de gestiones que soporta Capítulo 6 Implementación 82 6.3. Detalles de implementación por capas 6.3.1. Implementación del inicio de la aplicación En C#, el punto de entrada o inicio de una aplicación viene determinado por un método de clase (estático) con nombre Main. La plantilla para aplicaciones Windows Forms en Microsoft Visual Studio genera de forma automática una clase Program que implementa el método de Main(). Dentro de este método se invoca al método Run() de la clase Application, pasándole como argumento una instancia del formulario principal, en este caso una instancia de FormPrincipal. 6.3.2. Implementación de la creación de clases de comunicación de capas Mediante la siguiente implementación se crean las clases que nos permite la comunicación entre capa de presentación y capa de negocio así como la comunicación entre capa de negocio y capa de persistencia. static class Program { [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new presentacion.FormPrincipal()); } } Capa de presentación public partial class FormPrincipal : FormBase { // atributo herededado de FormBase private SociedadCazadores socCazadores socCazadores; public FormPrincipal(): base() { InitializeComponent(); negocio.ConexionBD conexionBDSC = new negocio.ConexionBD(); … } … } Capítulo 6 Implementación 89 6.3.6. Implementación de alta de modalidad de caza Tras haber solicitado dar de alta a una nueva modalidad de caza y haber introducido la información que identificará a dicha modalidad de caza la aplicación sigue la implementación que se muestra a continuación. Capa de presentación public partial class FormModalidadesCaza : FormListaDetalle { … // se ha hecho clic en el botón guardar private void btnGuardar_Click(object sender, EventArgs e) { // comprobar que se han introducido correctamente los datos if (!camposErroneos()) { if (tabDetalle.TabPages[0].Text.Equals("Nueva Modalidad de Caza")) guardarModalidadCaza(); else modificarModalidadCaza(); } } // comprobar que se han introducido correctamente los datos private bool camposErroneos() { bool camposErroneos = false; errorCampo.Clear(); if (txtNombre.Text.Equals("")) { // Indica que no se ha introducido el nombre de la modalidad de caza errorCampo.SetError(txtNombre, "¿Qué nombre tiene?"); camposErroneos = true; } return camposErroneos; } Capítulo 6 Implementación 90 Capa de presentación public partial class FormModalidadesCaza : FormListaDetalle { private negocio.ModalidadCaza modalidadCazaActual; … // guardar modalidad de caza private void guardarModalidadCaza() { // comprobar que no existe otra modalidad de caza con el mismo nombre(clave primaria) if (!nombreErroneo()) { // no existe modalidad de caza con el mismo nombre string nombre = txtNombre.Text.Trim(); string tipoCaza = ""; if (rbtnCazaMenor.Checked) tipoCaza = "Caza menor"; else tipoCaza = "Caza mayor"; // crear modalidad de caza socCazadores.crearModalidadCaza(nombre,tipoCaza); MessageBox.Show("Guardada la información de la modalidad de caza "+nombre+ ".", "Modalidad de Caza guardada", MessageBoxButtons.OK, MessageBoxIcon.Information); //actualizar el Datagrid dgModalidadesCaza.Rows.Add(nombre,tipoCaza); establecerInterfazActuales(); } else// existe modalidad de caza con el mismo nombre { // comprobar si la modalidad de caza existente es actual o es de historial if (modalidadCazaActual.getEstado().Equals("ACTUAL")) { MessageBox.Show("Existe la modalidad de caza " + txtNombre.Text + " como modalidad de caza actual.", "Modalidad de Caza existente", MessageBoxButtons.OK, MessageBoxIcon.Error); … } else { string nombreModalidadCaza = modalidadCazaActual.getNombre(); MessageBox.Show("Existe la modalidad de caza " + nombreModalidadCaza + "en el historial.","Modalidad de caza existente", MessageBoxButtons.OK,MessageBoxIcon.Information); … } } } // comprobar que no existe otra modalidad de caza con el mismo nombre(clave primaria) private bool nombreErroneo() { try { modalidadCazaActual = socCazadores.buscarModalidadCaza(txtNombre.Text.Trim()); return true; } catch { return false; } } Capítulo 6 Implementación 91 Capa de negocio public class SociedadCazadores { private ConexionBD conexionBDSC; static private persistencia.SistemaCentral sisCentral; private List<TipoSocio> listaTiposSocio; … // crear modalidad de caza public void crearModalidadCaza(string nombre,string tipoCaza) { // crear modalidad de caza ModalidadCaza modalidadCazaNueva = new ModalidadCaza(nombre,tipoCaza); // añadir la modalidad de caza a la sociedad de cazadores anyadirModalidadCaza(modalidadCazaNueva); // insertar la nueva fila de modalidad de caza en el DataSet sisCentral.insertarModalidadCaza(nombre, descripcion, tipoCaza,"ACTUAL"); } // buscar modalidad de caza public ModalidadCaza buscarModalidadCaza(string nombreModalidad) { foreach (ModalidadCaza modalidadCazaActual in listaModalidadesCaza) { if (modalidadCazaActual.getNombre().Equals(nombreModalidad)) return modalidadCazaActual; } throw new ElementoNoEncontrado("No se ha encontrado una modalidad de caza con nombre: " + nombreModalidad + "."); } Capa de persistencia public class SistemaCentral { private DataSetBD_SC dsSC; … // insertar la nueva fila de modalidad de caza en el DataSet public void insertarModalidadCaza(string nombre,string tipoCaza,string estado) { DataSetBD_SC.ModalidadCazaRow filaModalidadCaza = dsSC.ModalidadCaza.NewModalidadCazaRow(); filaModalidadCaza.nombre = nombre; filaModalidadCaza.tipoCaza = tipoCaza; filaModalidadCaza.estado = estado; dsSC.ModalidadCaza.AddModalidadCazaRow(filaModalidadCaza); } Capítulo 6 Implementación 92 6.3.7. Implementación de modificación de modalidad de caza Tras haber solicitado modificar la modalidad de cazada que se haya especificado y haber modificado la información que identificará a dicha modalidad de caza la aplicación sigue el siguiente código. Capa de presentación public partial class FormModalidadesCaza : FormListaDetalle { // se ha hecho clic en el botón guardar private void btnGuardar_Click(object sender, EventArgs e) { if (!camposErroneos()) { if (tabDetalle.TabPages[0].Text.Equals("Nueva Modalidad de Caza")) guardarModalidadCaza(); else modificarModalidadCaza(); } } private void modificarModalidadCaza() { bool correcto = true; // obtener la modalidad de caza a partir de su nombre string nombreActual = dgModalidadesCaza.SelectedCells[0].Value.ToString(); negocio.ModalidadCaza modalidadCazaModificar = socCazadores.buscarModalidadCaza(nombreActual); string nombreNuevo = txtNombre.Text.Trim(); // comprobar si se ha modificado el nombre de la modalidad de caza if(!nombreNuevo.Equals(modalidadCazaModificar.getNombre())) // comprobar que no existe otra modalidad de caza con el mismo nombre(clave primaria) if (nombreErroneo()) correcto = false; if(correcto) { string tipoCaza = ""; if (rbtnCazaMenor.Checked) tipoCaza = "Caza menor"; else tipoCaza = "Caza mayor"; // modificar datos de modalidad de caza socCazadores.modificarModalidadCaza(modalidadCazaModificar,nombreNuevo,tipoCaza); MessageBox.Show("Modificada la información de la modalidad de caza "+ txtNombre.Text+".","Información de Modalidad de caza modificada", MessageBoxButtons.OK, MessageBoxIcon.Information); // actualizar información del Datagrid dgModalidadesCaza.SelectedCells[0].Value = nombreNuevo; dgModalidadesCaza.SelectedCells[2].Value = tipoCaza; … } else // existe otra modalidad de caza con el mismo nombre(clave primaria) { // comprobar si la modalidad de caza existente es actual o es de historial if(modalidadCazaActual.getEstado().Equals("ACTUAL")) MessageBox.Show("Existe la modalidad de caza+modalidadCazaActual.getNombre() +" como modalidad de caza actual.","Modalidad de Caza existente", MessageBoxButtons.OK, MessageBoxIcon.Error); else MessageBox.Show("Existe la modalidad de caza "+ modalidadCazaActual.getNombre()+ " en el historial.", "Modalidad de Caza existente", MessageBoxButtons.OK, MessageBoxIcon.Information) } Capítulo 6 Implementación 93 Capa de negocio public class SociedadCazadores { static private persistencia.SistemaCentral sisCentral; … public void modificarModalidadCaza(ModalidadCaza modalidadCazaActual, string nombre,string tipoCaza) { string nombreActual = modalidadCazaActual.getNombre(); //comprobar si se ha modificado el nombre if (!nombre.Equals(nombreActual)) { //modificar el nombre modalidadCazaActual.setNombre(nombre); //modificar nombre de la fila de modalidad de caza del DataSet sisCentral.setNombreTipoSocio(nombreActual, nombre); } //comprobar si se ha modificado el tipo caza if (!tipoCaza.Equals(modalidadCazaActual.getTipoCaza())) { //modificar el tipo de caza de la capa de negocio modalidadCazaActual.setTipoCaza(tipoCaza); //modificar el tipo de caza de la capa de persistencia sisCentral.setTipoCazaModalidadCaza(nombre, tipoCaza); } } … } public class ModalidadCaza { private string nombre; private string tipoCaza; … //consultores public string getNombre() { return nombre;} public string getTipoCaza() { return tipoCaza;} //modificadores public void setNombre(string nombreNuevo) { nombre = nombreNuevo;} public void setTipoCaza(string tipoCazaNueva) { tipoCaza = tipoCazaNueva;} … } Capítulo 6 Implementación 94 Capa de persistencia public class SistemaCentral { private DataSetBD_SC dsSC; … //modificar nombre de la fila de modalidad de caza del DataSet public void setNombreModalidadCaza(string nombreActual, string nombreNuevo) { //encontrar la fila de la modalidad de caza mediante el nombre DataSetBD_SC.ModalidadCazaRow filaModalidadCaza = dsSC.ModalidadCaza.FindBynombre(nombreActual); filaModalidadCaza.nombre = nombreNuevo; } //modificar tipo de caza de la fila de modalidad de caza del DataSet public void setTipoCazaModalidadCaza(string nombre, string tipoCaza) { DataSetBD_SC.ModalidadCazaRow filaModalidadCaza = dsSC.ModalidadCaza.FindBynombre(nombre); filaModalidadCaza.tipoCaza = tipoCaza; } Capítulo 6 Implementación 95 6.3.8. Implementación de baja de modalidad de caza Tras haber solicitado eliminar la modalidad de caza que se haya especificado la implementación que se realiza para dar de baja una modalidad de caza es la siguiente. Capa de presentación public partial class FormModalidadesCaza : FormListaDetalle { private negocio.ModalidadCaza modalidadCazaActual; … //se ha hecho clic en el botón eliminar private void btnEliminar_Click(object sender, EventArgs e) { //comprobar si se ha seleccionado una modalidad de caza del Datagrid if (dgModalidadesCaza.SelectedRows.Count != 0) { //obtener la modalidad de caza a partir de su nombre DataGridViewRow filaSeleccionada = dgModalidadesCaza.SelectedRows[0]; string nombre = filaSeleccionada.Cells[0].Value.ToString(); modalidadCazaActual = socCazadores.buscarModalidadCaza(nombre); //comprobar que no se ha practicado en ninguna temporada if (modalidadCazaActual.getListaModalidadesTemporada().Count == 0) { //eliminar modalidad de caza; socCazadores.eliminarModalidadCaza(modalidadCazaActual); MessageBox.Show("Eliminada la modalidad de caza "+nombre, "Modalidad de caza eliminada", MessageBoxButtons.OK, MessageBoxIcon.Information); //actualizar Datagrid dgModalidadesCaza.Rows.Remove(filaSeleccionada); establecerInterfazActuales(); } else //se ha practicado la modalidad en alguna temporada { //comprobar si se practica en la temporada actual if (socCazadores.existeModalidadCazaTemporadaActual(modalidadCazaActual)) { //se practica en la temporada actual,no se puede eliminar MessageBox.Show("No se puede eliminar una modalidad de caza que se esta practicando en la temporada actual.", "Modalidad de Caza no eliminada", MessageBoxButtons.OK, MessageBoxIcon.Information); } else //no se practica en la temporada actual { //la modalidad de caza pasa a formar parte del historial socCazadores.modificarEstadoModalidadCaza(modalidadCazaActual,"HISTORIAL"); MessageBox.Show("Eliminada de las modalidades de caza actuales la modalidad de caza " + nombre + ".", "Modalidad de Caza en historial", MessageBoxButtons.OK, MessageBoxIcon.Information); dgModalidadesCaza.Rows.Remove(filaSeleccionada); establecerInterfazActuales(); } } } else MessageBox.Show("Haz clic en la modalidad de caza que desea eliminar.", "Modalidad de Caza no seleccionada", } MessageBoxButtons .OK, MessageBoxIcon .Information); Capítulo 6 Implementación 96 Capa de negocio public class SociedadCazadores { private ConexionBD conexionBDSC; static private persistencia.SistemaCentral sisCentral; private List<TipoSocio> ListaModalidadesCaza; … //eliminar la modalidad de caza del sistema public void eliminarModalidadCaza(ModalidadCaza modalidadCazaEliminar) { //eliminar la modalidad de caza de la capa de negocio borrarModalidadCaza(modalidadCazaEliminar); //eliminar la fila de modalidad de caza de la capa de persistencia sisCentral.eliminarModalidadCaza(modalidadCazaEliminar.getNombre()); } //modificar estado de la modalidad de caza del sistema public void modificarEstadoModalidadCaza(ModalidadCaza modalidadCazaActual,string estado) { //modificar estado de la modalidad de caza de la capa de negocio modalidadCazaActual.setEstado(estado); //modificar estado de la modalidad de caza de la capa de persistencia sisCentral.setEstadoModalidadCaza(modalidadCazaActual.getEstado(), estado); } //eliminar la modalidad de caza de la capa de negocio public void borrarModalidadCaza(ModalidadCaza modalidadCazaBorrar) { bool existe = false; foreach (ModalidadCaza modalidadCazaActual in listaModalidadesCaza) { if (modalidadCazaActual.getNombre().Equals(modalidadCazaBorrar.getNombre())) { existe = true; break; } } if (existe) listaModalidadesCaza.Remove(modalidadCazaBorrar); else throw new ElementoNoEncontrado( "No se ha encontrado una modalidad de caza con los datos epecificados."); } Capítulo 6 Implementación 97 6.3.9. Implementación de actualizar la información de la base de datos Tras haber manipulado con los datos de la aplicación y despues de solicitar el cierre de aplicación se actualiza los datos de la base de datos. Se realizan los ultimos tres pasos que especifica el escenario desconectado 1. Abrir conexión. 2. Actualizar fuente de datos mediante DataAdapter. 3. Cerrar conexión. Capa de persistencia public class SistemaCentral { private DataSetBD_SC dsSC; … //eliminar la fila de modalidad de caza del DataSet public void eliminarModalidadCaza(string nombre) { //encontrar la fila de la modalidad de caza mediante el nombre DataSetBD_SC.ModalidadCazaRow filaModalidadCaza = dsSC.ModalidadCaza.FindBynombre(nombre); filaModalidadCaza.Delete(); } //modificar el estado de la fila de modalidad de caza del DataSet public void setEstadoModalidadCaza(string nombre, string estado) { DataSetBD_SC.ModalidadCazaRow filaModalidadCaza = dsSC.ModalidadCaza.FindBynombre(nombre); filaModalidadCaza.estado = estado; } Capa de presentación //Para cualquier formulario que cierre la aplicación private void cerrarAplicacion() { //establecer conexión y actualizar la base de datos if (socCazadores.getConexionBDSC().actualizarBaseDatos()) this.Close(); else MessageBox.Show( "No se ha podido realizar la conexión con la base de datos BD_SC", "Conexión errónea", MessageBoxButtons.OK, MessageBoxIcon.Error); } Capítulo 6 Implementación 98 Capa de negocio public class ConexionBD { private persistencia.SistemaCentral sisCentral; private SociedadCazadores socCazadores; … //establecer conexión y actualizar la base de datos public bool actualizarBaseDatos() { //5.Abrir conexión if (sisCentral.conectarBaseDatos()) { //la conexión se ha realizado con éxito //6.Actualizar DataSet mediante DataAdapter sisCentral.actualizarBaseDatos(); //7.Cerrar conexión sisCentral.desconectarBaseDatos(); return true; } else return false; } Capa de persistencia public class SistemaCentral { private SqlConnection conexionBD; private DataSetBD_SC dsSC; private SqlDataAdapter daModalidadCaza; … //6.Actualizar DataSet mediante DataAdapter public void actualizarBaseDatos() { daModalidadCaza.Update(dsSC,"ModalidadCaza"); daModalidadCaza.Fill(dsSC); } Anexo A Plantillas de casos de usos 105 Anexo A: Plantillas de casos de usos En este apartado se muestran un alto número de las plantillas de los casos de uso del proyecto que se mostraron en el apartado 3.1. Anexo A Plantillas de casos de usos 106 Gestión de especies cazables Caso de uso Alta de especie cazable. Actores Secretario. Propósito Crear una nueva especie cazable. Resumen El secretario introduce los datos que se quieren conocer de la nueva especie cazable y lo guarda en el sistema. Precondiciones Poscondici ones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea incluir una nueva especie cazable. 2. El secretario i ntroduce los datos de identificación de la nueva especie cazable. 3. Valida los datos introducidos. 4. Comprueba que no existe una especie cazable con el mismo nombre común introducido. 5. Registra el alta de la nueva especie cazable. Extensiones síncronas 1. Si en 3 los datos introducidos son incorre ctos. 1.1. Muestra un mensaje de error. 2. Si en 4 el nombre común introducido coincide con el de otra especie cazable. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 107 Caso de uso Baja de especie cazable. Actores S ecretario. Propósito Dar de baja una especie cazable. Resumen El secretario da de baja una especie cazable. Precondiciones Se ha realizado el caso de uso Consulta de especies cazables mostrando las que son actuales. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea dar de baja una especie cazable. 2. El secretario selecciona la especie cazable a dar de baja. 3. El secretario solicita dar de baj a la especie cazable seleccionada. 4. Busca la especie cazable seleccionada. 5. Comprueba que la especie cazable no ha tenido ninguna repoblación. 6. Si no ha tenido ninguna repoblación, elimina la especie cazable del sistema. 7. Muestra mensaje info rmando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 5 la especie cazable ha tenido alguna repoblación. 1.1. Modifica el estado de la especie cazable a “HISTORIAL” y lo registra en el sistema. 1.2. Muestra mensaje de informa ción. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 108 Caso de uso Modificación de datos de especie cazable. Actores Secretario. Propósito Cambiar los datos que se quieren conocer de una especie cazable. Resumen El secretario modifica los datos de una especie cazable por nuevos datos. Precondiciones Se ha realizado el caso de uso Consulta de especies cazables mostrando las que son actuales. Poscondiciones Incluye Consulta de especie cazable. Extiende Hereda de Intenciones de usuario Obligaci ones del sistema 1. El caso de uso se inicia cuand o el secretario desea modificar los datos de identificación de una especie cazable. 2. El secretario selecciona la modalidad de caza a modificar. 3. El secretario solicita realizar la modificación de la especie cazable. 4. Se realiza el caso de uso Consulta de especie cazable. 5. El secretario modifica los datos de identificación de la especie cazable. 6. Valida los datos introducidos. 7. Comprueba que no existe una especie cazable con el mismo nombre común introducido. 8. Registra las modificaciones de los datos de la especie cazable en el sistema. 9. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 6 los datos introducidos son incorrectos. 1.1. Muestra un mensaje de error. 2. Si en 7 el nombre común introducido coincide con el de otra especie cazable. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 109 Caso de uso Restablecimiento de especie cazable de historial. Actores Secretario. Propósito Restablecer una especie cazable que está en el historial. Resumen El secretario restablece una especie cazable. Precondiciones Se ha realizado el caso de uso Consulta de especies cazables mostrando las que están en historial. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea restablecer una especie cazable. 2. El secretario selecciona la especie cazable a restablecer. 3. El secretario solicita restablecer la especie cazable seleccionada. 4. Busca la especie cazable seleccionada. 5. Modifica el estado de la especie cazable a “ACTUAL” y lo registra en el sistema. 6. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 110 Caso de uso Consulta de especie cazable. Actores Propósito Visualizar una especie cazable en detalle. Resumen El sistema muestra toda la información de una especie cazable. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. Busca la especie cazable seleccionada. 2. Muestra todos los datos de identificación de la especie cazable seleccionada con permiso de escritura. Extensiones sincronas Ninguna. Extensiones asíncronas Ninguna. Caso de uso Consulta de especies cazables. Actores Secretario. Propósito Visualizar las especies cazables. Resumen El secretario muestra las esp ecies cazables. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario solicita hacer la consulta de especies cazables. 2. El secretario int roduce una o varios campos de búsqueda. 3. Muestra la relación de especies cazables encontradas. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 111 Gestión de modalidades de caza Caso de uso Alta de modalidad de caza. Actores Secret ario. Propósito Crear una nueva modalidad de caza. Resumen El secretario introduce los datos que se quieren conocer de la nueva modalidad de caza y lo guarda en el sistema. Precondiciones Poscondiciones Incluye Extiende Hereda de Intencione s de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea incluir una nueva modalidad de caza. 2. El secretario i ntroduce los datos de identificación de la nueva modalidad de caza. 3. Valida los datos introducidos. 4. Comprueba que no existe una modalidad de caza con el mismo nombre introducido. 5. Registra el alta de la nueva modalidad de caza en el sistema. Extensiones síncronas 1. Si en 3 los datos introducidos son incorrectos. 2.1. Muestra mensaje de erro r. 2. Si en 4 el nombre introducido coincide con el de otra modalidad de caza. 2.1. Muestra mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 112 Caso de uso Baja de modalidad de caza. Actores Secretario. Propósito Dar de baja una modalidad de caza. Resumen El secretario da de baja una modalidad de caza. Precondiciones Se ha realizado el caso de uso Consulta de modalidades de caza mostrando las que son actuales. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Ob ligaciones del sistema 1. El caso de uso se inicia cuand o el secretario desea dar de baja una modalidad de caza. 2. El secretario selecciona la modalidad de caza a dar de baja. 3. El secretario solicita dar de baja la modalidad de caza seleccionada. 4 . Busca la modalidad de caza seleccionada. 5. Comprueba que la modalidad de caza no ha pertenecido a ninguna modalidad de temporada. 6. Si la modalidad de caza no ha pertenecido a ninguna modalidad de temporada, elimina la modalidad de caza del sistema. 7. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 5 la modalidad de caza ha pertenecido alguna modalidad de temporada. 1.1. Modifica el estado de la modalidad de caza a “HISTORIAL” y lo registra en el sistema. 1.2. Muestra mensaje de información. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 113 Caso de uso Modificación de datos de modalidad de caza. Actores Secretario. Propósito Cambiar los datos que se quieren conocer de una modalidad de caza. Resumen El secretario modifica los datos de una modalidad de caza por nuevos datos. Precondiciones Se ha realizado el caso de uso Consulta de modalidad de caza mostrando las que son actuales. Poscondiciones Incluye Consulta de modalidad de caza. Exti ende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuand o el secretario desea modificar los datos de identificación de una modalidad de caza. 2. El secretario selecciona la modalidad de caza a modificar. 3. El secretario solicita realizar la modificación de la modalidad de caza. 4. Se realiza el caso de uso Consulta de modalidad de caza. 5. El secretario modifica los datos de identificación de la modalidad de caza. 5. Valida los datos introducidos. 6. Comprueba que no existe una modalidad de caza con el mismo nombre introducido. 7. Registra las modificaciones de los datos de la modalidad de caza en el sistema. 8. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncro nas 1. Si en 6 los datos introducidos son incorrectos. 1.1. Muestra un mensaje de error. 2. Si en 7 el nombre introducido coincide con el de otra modalidad de caza. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 114 Caso de u so Restablecimiento de modalidad de caza de historial. Actores Secretario. Propósito Restablecer una modalidad de caza que está en el historial. Resumen El secretario restablece una modalidad de caza. Precondiciones Se ha realizado el caso de uso Consu lta de modalidades de caza mostrando las que están en historial. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea restablecer una modalidad de caza. 2. El secretario selecciona la modalidad de caza a restablecer. 3. El secretario solicita restablecer la modalidad de caza seleccionada. 4. Busca la modalidad de caza seleccionada. 5. Modifica el estado de la modalidad de caza a “ACTUAL” y lo registra en el sistema. 6. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 121 Caso de uso Restablecimiento de zona del coto de historial. Actores Secretario. Propósito Restablecer una zona del coto que está en el historial. Resumen El secretario restable ce una zona del coto. Precondiciones Se ha realizado el caso de uso Consulta de zonas del coto mostrando las que están en historial. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso s e inicia cuando el secretario desea restablecer una zona del coto. 2. El secretario selecciona la zona del coto a restablecer. 3. El secretario solicita restablecer la zona del coto seleccionada. 4. Busca la zona del coto seleccionada. 5. Modifica el estado de la zona del coto a “ACTUAL” y lo registra en el sistema. 6. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 122 Caso de uso Consulta de zona del c oto. Actores Secretario. Propósito Visualizar una zona del coto en detalle. Resumen El secretario muestra toda la información de una zona del coto. Precondiciones Se ha realizado el caso de uso Consulta de zonas del coto. Poscondiciones Incluye Ex tiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso uso se inicia cuando se desea realizar la consulta de una zona del coto. 2. El secretario selecciona la zona del coto a consultar. 3. El secretario solicita realizar la consulta de la zona del coto seleccionada. 4. Busca la zona del coto seleccionada. 5. Muestra todos los datos de identificación de la zona del coto seleccionada. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 123 Caso de uso Consulta de zonas del coto . Actores Secretario. Propósito Visualizar las zonas del coto. Resumen El secretario muestra las zonas de coto. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligacio nes del sistema 1. El caso de uso se inicia cuando el secretario solicita hacer la consulta de las zonas del coto. 2. El secretario introduce una o varios campos de búsqueda. 3. Muestra la relación de zonas del coto encontradas. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 124 Gestión de tipos de socio Caso de uso Alta de tipo de socio. Actores Secretario. Propósito Crear una nuevo tipo de socio. Resumen El secretario introduce los datos que se quieren conocer del nuevo tipo de socio y lo guarda en el sistema. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea incluir un nuevo tipo de socio. 2. El secretario i ntroduce los datos de identificación del nuevo tipo de socio. 3. Valida los datos introducidos. 4. Comprueba que no existe una tipo de socio con el mismo nombre introducido. 5. Registra el alta del tipo de socio. Extensiones síncro nas 1. Si en 3 los datos introducidos son incorrectos. 1.1. Muestra un mensaje de error. 2. Si en 4 el nombre introducido coincide con el de otro tipo de socio. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 125 Ca so de uso Baja de tipo de socio. Actores Secretario. Propósito Dar de baja un tipo de socio. Resumen El secretario da de baja un tipo de socio. Precondiciones Se ha realizado el caso de uso Consulta de tipos de socio mostrando los actuales. Poscondici ones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea dar de baja un tipo de socio. 2. El secretario selecciona el tipo de socio a dar de baja. 3. El secretar io solicita dar de baja el tipo de socio seleccionado. 4. Busca el tipo de socio seleccionado. 5. Comprueba que el tipo de socio no aparece en ninguna cuota de tipo de socio. 6. Si no ha aparecido en ninguna cuota de tipo de socio, elimina el tipo de socio del sistema. 7. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 5 el tipo de socio ha tenido alguna cuota de tipo de socio. 1.1. Modifica el estado del tipo de socio a “HISTORIAL” y lo registra en el sistema. 1.2. Muestra mensaje de información. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 126 Caso de uso Modificación de datos de tipo de socio. Actores Secretario. Propósito Cambiar los datos que se quieren conocer de un tipo de socio. Resumen El secretario modifica los datos de un tipo de socio por nuevos datos. Precondiciones Se ha realizado el caso de uso Consulta de tipos de socio mostrando los actuales. Poscondiciones Incluye Consulta de tipo de socio. Extiende Hereda de Intencion es de usuario Obligaciones del sistema 1. El caso de uso se inicia cuand o el secretario desea modificar los datos de identificación de un tipo de socio. 2. El secretario selecciona el tipo de socio a modificar. 3. El secretario solicita realizar la modificación del tipo de socio. 4. Se realiza el caso de uso Consulta de tipo de socio. 5. El secretario modifica los datos de identificación del tipo de socio. 6. Valida los datos introducidos. 7. Comprueba que no existe un tipo de socio con el mismo nombre introducido. 8. Registra las modificaciones de los datos del tipo de socio en el sistema. 9. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 6 los datos introducidos son incorrectos. 1.1. M uestra un mensaje de error. 2. Si en 7 el nombre introducido coincide con el de otro tipo de socio. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 127 Caso de uso Consulta de tipo de socio. Actores Propósito Visualizar un t ipo de socio en detalle. Resumen El sistema muestra toda la información de un tipo de socio. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. Busca el tipo de socio seleccionado. 2. Muestra todos los datos de identificación del tipo de seleccionado con permiso de escritura. Extensiones sincronas Ninguna. Extensiones asíncronas Ninguna. Caso de uso Consulta de tipos de socio. Actores Secretario. Propósito Visualizar los tipos de socio. Resumen El secretario muestra los tipos de socio. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario solicita hacer la consulta de los tipos de socio. 2. El secretario introduce una o varios campos de búsqueda. 3. Muestra la relación de tipos de socio encontrados. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 128 Gestión de datos de temporada Caso de uso Alta de temporada. Actores Secretario. Propósito Crear una nueva de temporada. Resumen El secretario introduce los datos de identificación de la nueva temporada y la guarda en el sistema. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario solicita crear una nueva temporada. 2. Registra el alta de la nueva temporada. 3. Muestra un mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 129 Caso de uso Baja de temporada actual. Actores Secretario. Propósito Dar de baja la temporada actual. Resumen El secretario da de baja la temporada a ctual. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario desea dar de baja la temporada actual. 2. El secretario solicita dar de baja l a temporada actual. 3. Elimina toda la información referente a la temporada: datos, cuotas, cuotas de socio, modalidades de temporada, actuaciones, actividades, movimientos y asambleas. 4. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 130 Caso de uso Inicio de gestión de temporada actual. Actores Secretario. Propósito Iniciar la gestión de la temporada tras haber configurado sus cuotas y modalidades. Resumen El secretario solicita el inicio de la gestión de la temporada actual. Precondiciones Se ha realizado el caso de uso Consulta de temporada actual. Poscondiciones Incluye Alta de cuota de socio. Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuand o el secretario solicita iniciar la temporada actual. 2. El secretario solicita iniciar la temporada. 3. Modifica el estado de la temporada actual a “EN CURSO” y lo registra en el sistema. 4. Para cada socio actual con pago de cuotas al corriente. 4.1. Registra el alta de la nueva cuota de socio. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 137 Caso de uso Baja de cuota de sociedad. Actores Secretario, Tesorero Propósito Dar de baja una cuota de sociedad establecida para la temporada actual. Resumen El secretario elimina la cuota de sociedad que el tesorero le indica. Precond iciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha realizado el caso de uso Consulta de cuotas de temporada. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se ini cia cuando el tesorero solicita al secretario dar de baja una cuota de sociedad. 2. El secretario selecciona la cuota de sociedad que el tesorero le indica. 3. El secretario solicita dar de baja la cuota de sociedad seleccionada. 4. Busca la cuota de s ociedad seleccionada. 5. Elimina la cuota de sociedad del sistema. 6. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 138 Caso de uso Baja de cuota de modal idad. Actores Propósito Dar de baja una cuota de modalidad establecida para la temporada actual. Resumen El sistema elimina la cuota de modalidad. Precondiciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha solicitado dar de baja la modalidad de la temporada actual a la que pertenece. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. Busca la cuota de modalidad de la modalidad de la temporada actual seleccionada para ser dada de baja. 2. Elimina la cuota de modalidad del sistema. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Caso de uso Modificación de datos de cuota. Actores Secretario, Tesorero. Propósito Cambiar los datos que se quieren conocer de una cuota de la temporada actual. Resumen El secretario modifica los datos de una cuota de temporada por los nuevos datos aportados por el tesorero. Precondiciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha realizado el caso de uso Consulta de cuotas de temporada. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 139 Caso de uso Modificación de datos de cuota d e entrada. Actores Secretario, Tesorero. Propósito Cambiar los datos que se quieren conocer de la cuota de entrada de la temporada actual. Resumen El secretario modifica los datos de la cuota de entrada por los nuevos datos aportados por el tesorero. P recondiciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha realizado el caso de uso Consulta de cuotas de temporada. Poscondiciones Incluye Consulta de cuota de entrada. Extiende Hereda de Intenciones de usuario Obligaciones de l sistema 1. El caso de uso se inicia cuando el tesorero solicita al secretario modificar los datos de la cuota de entrada. 2. El secretario selecciona la cuota de entrada. 3. El secretario solicita modificar la cuota de entrada. 4. Se realiza el ca so de uso Consulta de cuota de entrada. 5. El secretario modifica los datos de identificación de la cuota de entrada. 6. Valida los datos introducidos. 7. Registra las modificaciones de los datos de la cuota de entrada en el sistema. 8. Muestra mensaj e informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 6 los datos introducidos son incorrectos. 1.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 140 Caso de uso Modificación de datos de cuota de sociedad. Actores Secretario, Tesorero. Propósito Cambiar los datos que se quieren conocer de una cuota de sociedad de la temporada actual. Resumen El secretario modifica los datos de una cuota de sociedad por los nuevos datos aportados por el tesorero. Precondiciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha realizado el caso de uso Consulta de cuotas de temporada. Poscondiciones Incluye Consulta de cuota de sociedad. Extiende Hereda de Intenciones de usuario Obligacion es del sistema 1. El caso de uso se inicia cuando el tesorero solicita al secretario modificar los datos de una cuota de sociedad. 2. El secretario selecciona la cuota de sociedad que el tesorero le indica. 3. El secretario solicita modificar la cuota de sociedad seleccionada. 4. Se realiza el caso de uso Consulta de cuota de sociedad. 5. El secretario modifica los datos de identificación de la cuota de sociedad. 6. Valida los datos introducidos. 7. Comprueba que no existe una cuota con el mismo nombre introducido. 8. Registra las modificaciones de los datos de la cuota de sociedad en el sistema. 9. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 6 los datos introducidos son incorrectos. 1. 1. Muestra un mensaje de error. 2. Si en 7 el nombre introducido coincide con el de otra cuota. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 141 Caso de uso Modificación de datos de cuota de modalidad. Actores Secretario, Te sorero. Propósito Cambiar los datos que se quieren conocer de una cuota de modalidad de la temporada actual. Resumen El secretario modifica los datos de una cuota de sociedad por los nuevos datos aportados por el tesorero. Precondiciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha realizado el caso de uso Consulta de cuotas de temporada o el caso se uso Modificación de datos de modalidad de temporada. Poscondiciones Incluye Extiende Consulta de cuota de modalidad. Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el tesorero solicita al secretario modificar los datos de la cuota de modalidad o se ha seleccionado modificar la modalidad de temporada a la que pertenece dicha cuota. 2 . El secretario selecciona la cuota de modalidad que el tesorero le indica. 3. El secretario solicita modificar la cuota de modalidad seleccionada. 4. Se realiza el caso de uso Consulta de cuota de modalidad. 5. El secretario modifica los datos de identificación de la cuota de modalidad. 6. Valida los datos introducidos. 7. Registra las modificaciones de los datos de la cuota de modalidad en el sistema. 8. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1 . Si en 2 se ha solicitado modificar la modalidad de temporada a la que pertenece la cuota. 1.1. Saltar a la instrucción 5, realizando 6 y 7. 2. Si en 6 los datos introducidos son incorrectos. 2.1. Muestra un mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 142 Caso de uso Consulta de cuota. Actores Propósito Visualizar una cuota en detalle. Resumen El sistema muestra toda la información de una cuota. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuari o Obligaciones del sistema Extensiones sincronas Ninguna. Extensiones asíncronas Ninguna. Caso de uso Consulta de cuota de entrada. Actores Propósito Visualizar la cuota de entrada en detalle. Resumen El sistema muestra toda la información de la cuota de entrada. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. Obtiene la cuota de entrada. 2. Muestra todos los datos de identificación de la cuota de entrada con permiso de escritura. Extensiones sincronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 143 Caso de uso Consulta de cuota de sociedad. Actores Propósito Visualizar una cuota de sociedad en detalle. Resumen El sistema muestra toda la información de una cuota de sociedad. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. Busca la cuota de sociedad seleccionada. 2. Muestra todos los datos de identificación de la cuota de sociedad seleccionada con permiso de escritura. Extensiones sincronas Ninguna. Extensiones asíncronas Ninguna. Caso de uso Consulta de cuota de modalidad. Actores Propósito Visualizar una cuota de modalidad en detalle. Resumen El sistema muestra to da la información de una cuota de modalidad. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. Busca la cuota de sociedad seleccionada. 2. Muestra todos los datos de identificación de la cuota de modalidad seleccionada con permiso de escritura. Extensiones sincronas 1. Si se realizó el caso de uso Consulta de modalidad de temporada a la que pertenece a la cuota. 1.1. Muestra todos los datos de identificación de la cuota de modalidad seleccionada sin permiso de escritura. Extensiones asíncronas Anexo A Plantillas de casos de usos 144 Caso de uso Consulta de cuotas de temporada. Actores Secretario. Propósito Visualizar las cuotas de establecidas para una temporada. Resumen El secretario muestra información de tod as las cuotas establecidas en una temporada. Precondiciones Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario solicita hacer la consulta de las cuotas de temporada. 2. El secretario introduce uno o varios campos de búsqueda. 3. Muestra la relación de cuotas de temporada encontradas. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 145 Gestión de modalidades de temporada Caso de uso Alta de modalidad de temporada. Actores Secretario, Tesorero. Propósito Crear una nueva modalidad de temporada actual. Resumen El secretario con ayuda del tesorero crea una nueva modalidad de la temporada actual. Precondiciones Poscond iciones Incluye Consulta de modalidades de caza. Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario solicita crear una nueva modalidad temporada. 2. Se realiza el caso uso Consu lta de modalidades de caza mostrando las modalidades de caza actuales. 3. El secretario selecciona las modalidades de caza que componen la modalidad de temporada. 4. Comprueba que no existe otra modalidad de la temporada actual con el mismo nombre. 5. C omprueba que no existe otra modalidad de la temporada actual con las mismas modalidades de caza. 6 . Si no existe otra modalidad de temporada con las mismas modalidades de caza se realiza el caso uso Alta de cuota de modalidad. 7. Registra el alta de la nueva modalidad de temporada en el sistema. 8. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas 1. Si en 4 el nombre introducido coincide con el de otra modalidad de la temporada actual. 1.1. Muestra mensaje de er ror. 2. Si en 5 existe otra modalidad de temporada con el mismo conjunto de modalidades de caza. 2.1. Muestra mensaje de error. Extensiones asíncronas Ninguna. Anexo A Plantillas de casos de usos 146 Caso de uso Baja de modalidad de temporada. Actores Secretario. Propósito Dar de baja una modalidad de la temporada actual. Resumen El secretario elimina una de las modalidades de la temporada actual. Precondiciones El estado de la temporada actual es “EN CONFIGURACIÓN” y se ha realizado el caso de uso Consulta de modalidades de temporada. Poscondiciones Incluye Extiende Hereda de Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando el secretario quiere dar de baja una modalidad de la temporada actual. 2. E l secretario selecciona la mo dalidad de temporada que quiere dar de baja. 3. El secretario solicita dar de baja la modalidad de temporada seleccionada. 4. Busca la modalidad de temporada seleccionada. Por cada modalidad de caza que pertenece a la modalidad de temporada. 5. Elimin a la relación de la modalidad de caza con la modalidad de temporada del sistema. 6. Se realiza el caso de uso Baja de cuota de modalidad correspondiente 7. Elimina la modalidad de temporada del sistema. 8. Muestra mensaje informando que la operación ha sido satisfactoria. Extensiones síncronas Ninguna. Extensiones asíncronas Ninguna.