APLICACIÓN WEB DE ADOPCIÓN DE MASCOTAS

CEDEÑO CASTRO KAREN VALERIA

CONTRERAS SÁNCHEZ CRISTINA
ESPINOZA LÓPEZ CRISTIAN PAÚL
GÓMEZ TORO EDUARDO RODRIGO
REA OCAÑA JUAN CARLOS
 1. REQUISITOS

CATÁLOGO DE REQUISITOS
En este punto se incluye una descripción del comportamiento del sistema que se va a
desarrollar.

Requisitos de Datos
Los requisitos de datos, también denominados requisitos de contenidos, requisitos
conceptuales o requisitos de almacenamiento de información responden a la pregunta de qué
información debe almacenar y administrar la aplicación.

REQ.D.001 Información sobre Mascotas

Datos Código
Nombre
Descripción
Tipo de Mascota
Raza o Grupo
Color
Historial Médico
Ubicación
Persona de Contacto

REQ.D.002 Información sobre Usuarios

Datos Identificación
Nombre Completo
Correo Electrónico
Teléfono de contacto
Celular de contacto
Información de domicilio
Información de preferencias de mascotas
Información de mascotas publicadas
Información de mascotas adoptadas
Usuario de inicio de sesión en la aplicación
Contraseña de inicio de sesión en la aplicación

REQ.D.003 Información sobre Adopciones

Datos Código o secuencia
Código de Mascota
Identificación de Usuario
Fecha de Solicitud
Fecha de Adopción
Nuevo nombre de mascota
Nueva Dirección de Mascota
Observaciones de la Adopción

REQ.D.004 Información sobre Administradores

Datos Nombre Completo
Correo Electrónico
Usuario de inicio de sesión en la aplicación
Contraseña de inicio de sesión en la aplicación
Requisitos de Aplicación
Los requisitos de aplicación o sistema especifican el entorno tecnológico y los componentes
hardware y software necesarios para la implantación y explotación de la aplicación.

REQ.A.001 Sistema de Código Libre

Descripción La aplicación Web debe basarse en componentes software disponibles
bajo licencia no comercial. Por ejemplo: sistema operativo Linux, gestor
de base de datos MySQL, bibliotecas de arquitectura Web en tres capas,
servidor de aplicaciones WildFly.

REQ.A.002 Plataforma Hardware

Descripción La plataforma hardware que soporte la aplicación debe ser un servidor capaz
de ejecutar el S.O. Linux.

Requisitos de Interfaz
Los requisitos de interfaz, también llamados requisitos de interacción de usuario responden a la
pregunta de cómo va a interactuar el usuario con la aplicación.

REQ.I.001 Diferentes Perfiles de Usuario

Descripción La aplicación debe gestionar de forma diferenciada los siguientes
perfiles de usuarios:
- Invitados.
- Usuarios.
- Administradores.
Cada perfil tendrá un determinado nivel de acceso a las diferentes
funcionalidades de la aplicación. Para cada funcionalidad se especificará
que perfiles pueden acceder.

REQ.I.002 Inicio de Sesión

Descripción Los usuarios de la aplicación deben realizar un inicio de sesión
previo a usar cualquier otra funcionalidad. De esta formar, siempre
podrá registrarse el autor de cada acción. El inicio de sesión de cada usuario
debe autenticarse mediante usuario y contraseña.
Adicionalmente puede autenticarse como invitado de forma que pueda
visualizar las mascotas disponibles para adopción sin poder registrar o
adoptar mascotas.

REQ.I.003 Cierre de Sesión

Descripción Una vez iniciada una sesión por un usuario, la sesión se cerrará bien por
la acción del usuario que la abrió o por un mecanismo automático
basado en un determinado tiempo de espera en inactividad.

REQ.I.004 Cliente Web o Browser

Descripción La aplicación podrá usarse al menos con los dos navegadores Web más
extendidos: Google Chrome y Firefox. No se requerirá la
instalación de ningún software adicional por parte de los usuarios.
Requisitos de Funcionales
Los requisitos funcionales especifican las funciones que ha de desempeñar la aplicación.

REQ.F.001 Creación de un nuevo usuario

Descripción Creación de un nuevo usuario que usará la aplicación.
Perfiles Usuario, Administrador
Comentarios Se exigirá el ingreso de datos obligatorios como identificación, nombres
completos, dirección, correo y ubicación, así como datos de usuario y
contraseña. Tendrá datos opcionales como fotografía o avatar, preferencia
de mascotas y una descripción de usuario.

REQ.F.002 Edición de usuario

Descripción Modificación de usuario existente en la aplicación.
Perfiles Usuario, Administrador
Comentarios Tendrá como opción para editar todos los datos de un usuario, excepto la
identificación y el usuario.

REQ.F.003 Creación de mascotas

Descripción Creación de nuevas mascotas del sistema.
Perfiles Usuario, Administrador
Comentarios Los usuarios pueden crear nuevas mascotas nuevas y se exigirá el ingreso de
datos obligatorios de la mascota como tipo de mascota, raza, nombre. La
mascota se obtendrá los datos de contacto del usuario que la publica y será
obligatorio por lo menos 3 fotografías de la mascota. El sistema generará
automáticamente un código que identificará en el sistema a cada una
mascota. Un usuario puede publicar varias mascotas.

REQ.F.004 Gestión de mascotas

Descripción Gestión de mascotas existentes en el sistema.
Perfiles Usuario, Administrador
Comentarios Los usuarios pueden gestionar las mascotas existentes para editar o eliminar
dichas mascotas. Para eliminar una mascota debe indicarse el motivo de
eliminación y no se eliminará el registro de la Base de Datos sino que será
marcada como eliminada.

REQ.F.005 Listado de Mascotas

Descripción Listado de mascotas disponibles para adopción
Perfiles Invitado, Usuario, Administrador
Comentarios Los usuarios y los invitados pueden visualizar todas las mascotas publicadas
por los diferentes usuarios, pudiendo filtrar los datos por ubicación, raza,
color.

REQ.F.006 Adopción de Mascota

Descripción Adopción de mascotas publicadas en el sistema
Perfiles Usuario, Administrador
Comentarios Una vez seleccionada la mascota del listado de mascotas o mediante una
búsqueda, es posible presionar la opción “Adoptar” y donde se seleccionará
el medio de contacto, se ingresará el nuevo nombre de la mascota, las
observaciones de adopción y esta se asociará a la cuenta del usuario que
realiza la adopción. Esta mascota se presentará como en adoptada en el
sistema y desaparecerá en el listado de mascotas.
 REQ.F.007 Notificación de Adopciones
Descripción Notificación por correo y sms de adopciones
Perfiles Usuario, Administrador
Comentarios La aplicación genera automáticamente notificaciones vía correo electrónico
y sms al momento de realizar una adopción, para lo cual notificará tanto a la
persona que adopta como a la persona que publicó la mascota para ser
adoptada.

REQ.F.008 Reporte de Mascotas

Descripción La aplicación ha de ofrecer un interfaz para exportar los siguientes datos:
- Nombre de Mascota.
- Tipo de Macota.
- Nombre de Mascota
- Persona de Publicación.
- Ubicación de la Mascota.
- Correo de Contacto
- Teléfono de Contacto
- Estado de la mascota (publicada, adoptada, eliminada)
- Tiempo publicado.
Perfiles Administrador
Comentarios

REQ.F.009 Activación de Usuarios

Descripción La aplicación ha de ofrecer un interfaz para generar un usuario y contraseña
automáticamente para todos los usuarios y enviarles un correo electrónico
con sus datos de recuperación de inicio de sesión.
Perfiles Administrador
Comentarios El usuario será la identificación y la contraseña será aleatoria

Requisitos de Rendimiento
Los requisitos de rendimiento especifican los recursos máximos que puede consumir la
aplicación.

REQ.R.001 Tiempo de Respuesta

Descripción El tiempo de respuesta de la interfaz Web de la aplicación debe ser inferior a
1 segundo (sin tener en cuenta retardos de red).

REQ.R.002 Carga Computacional

Descripción El conjunto del software necesario para la prestación del servicio debe poder
ejecutarse en un solo servidor con la capacidad de gestionar solicitudes
concurrentes.

Requisitos de Seguridad
Los requisitos de seguridad especifican las medidas necesarias de seguridad de la aplicación.

REQ.S.001 Registro de Acciones

Descripción Las acciones realizadas por los usuarios deberán quedar registradas en tablas
de auditoría con todos los datos de sesión necesarios.

REQ.S.002 Almacenamiento de Contraseñas

Descripción Las contraseñas serán almacenadas en la base de datos en un formato
cifrado.
 Tras las anteriores definiciones de requisitos podemos ver como se relacionan en el siguiente
diagrama:

custom Functional Requirements custom Non Functional Requirements

Requisistos de Datos Seguridad

+ REQ.D.001 Información sobre Mascotas + REG.S.001 Registro de Acciones

+ REQ.D.002 Información sobre Usuarios + REQ.S.002 Almacenamiento de Contraseñas
+ REQ.D.003 Información sobre Adopciones
+ REQ.D.004 Información para Administradores

Rendimiento
Requisitos de Aplicacion
+ REQ.R.001 Tiempo de Respuesta
+ REQ.A.001 Sistema de Código Libre + REQ.R.002 Carga Computacional
+ REQ.A.002 Plataforma Hardware

Requisitos de Interfaz

+ REQ.I.001 Diferentes Perfiles de Usuario

+ REQ.I.002 Inicio de Sesión
+ REQ.I.003 Cierre de Sesión
+ REQ.I.004 Cliente Web o Browser

Requisitos Funcionales

+ REQ.F.001 Creación de un nuevo usuario

+ REQ.F.002 Edición de usuario
+ REQ.F.003 Creación de mascotas
+ REQ.F.004 Gestión de mascotas
+ REQ.F.005 Listado de Mascotas
+ REQ.F.006 Adopción de Mascota
+ REQ.F.007 Notificación de Adopciones
+ REQ.F.008 Reporte de Mascotas
+ REQ.F.009 Activación de Usuarios
 CASOS DE USO
En el siguiente diagrama presentaremos los casos de uso que describen todas las interacciones
que tendrán los usuarios con el software.
uc Basic Use Case Model

Aplicación Web de Adopción de Mascotas

Registrar Mascota
Registrar Usuario «include»

Usuario

Usuario registrado
«include»

Adoptar Mascota

Listar Mascotas
«include»

«include»

Generar Notificaciones

Actualizar Catálogo de
Mascotas
«include»

«include»

Confirmar adopción
C.U.001 AUTENTICACIÓN DE USUARIO
Descripción El sistema requerirá que el usuario ingrese su nombre de usuario y
contraseña. Con estos datos autenticará al usuario y si es válido, la signará
el perfil que le corresponde y mostrará las opciones a las que tiene acceso.
Requisito REQ.D.002 – Información sobre Usuarios
Relacionado REQ.D.004 – Información sobre Administradores
REQ.I.001 – Diferentes Perfiles de Usuario
REQ.I.002 – Inicio de Sesión
REQ.S.002 – Almacenamiento de contraseñas
Precondición
Postcondición Autenticado el usuario se le asigna un perfil
Observaciones En caso de que el usuario no sea valido se le devolverá al formulario de
identificación.
Secuencia de
Paso Acción
Pasos
Este caso de uso se inicia cuando un usuario intenta acceder a la
1 aplicación. Se le mostrará un formulario para introducción de
usuario y contraseña.
2 El usuario introduce sus datos y acepta el formulario
3 El sistema valida el usuario contra la BD y le asigna el perfil.
4 Se le muestran las opciones a las que tiene acceso el usuario.
Secuencia de Paso Excepción
Excepciones Si el usuario no es válido se le devolverá al formulario de
3
identificación.

C.U.002 REGISTRAR USUARIO

Descripción El usuario introducirá como mínimo los datos necesarios para crear el
usuario en el sistema. Los datos se guardarán en la base de datos.
Requisito REQ.D.002 – Información sobre Usuarios
Relacionado REQ.F.001 – Creación de un nuevo usuario
REQ.I.001 – Diferentes perfiles de usuario
REQ.I.002 – Inicio de Sesión
REQ.S.002 – Almacenamiento de Contraseñas
Precondición
Postcondición Creado el usuario se le asigna un perfil
Observaciones En caso de que el usuario no sea válido se le devolverá al formulario de
identificación.
Paso Acción
El usuario introduce sus datos personales (nombre, apellido,
1
número de cédula, email, clave)
El sistema comprueba que no exista un usuario con el mismo
Secuencia de 2
número de identificación o el mismo nombre de usuario
Pasos
El sistema comprueba que los campos obligatorios hayan sido
3
ingresados
El sistema guarda los datos del nuevo usuario y el caso de uso
4
termina.
Paso Excepción
Si el usuario o la identificación ya existen muestra un mensaje de
2
Secuencia de error para que se realicen las modificaciones
Excepciones Si todos los campos obligatorios no fueron ingresados, marca
3
como error dichos campos en la interface
4 Si se produce un error en el guardado, conduce a la página de error
C.U.003 REGISTRAR MASCOTA
Descripción El usuario introducirá como mínimo los datos necesarios para registrar una
mascota en el sistema, todas sus características y las imágenes mínimas
necesarias para mostrar en el catálogo. Los datos se guardarán en la base
de datos e inmediatamente aparecerá en el listado de mascotas
disponibles para adopción.
Requisito REQ.D.001 – Información sobre Usuarios
Relacionado REQ.F.003 – Creación de mascotas
REQ.F.004 – Gestión de mascotas
Precondición El usuario debe estar registrado y autenticado en el sistema
Postcondición
Observaciones
Paso Acción
El usuario registrado registra la mascota: tipo (perro, gato, etc),
1
Secuencia de edad, descripción, ciudad, fotos.
Pasos 2 El sistema comprueba que todos los datos estén ingresados.
El sistema realiza el registro de la mascota y el caso de uso
3
termina.
Paso Excepción
Secuencia de Si todos los campos obligatorios no fueron ingresados, marca
2
Excepciones como error dichos campos en la interface
3 Si se produce un error en el guardado, conduce a la página de error

C.U.004 ADOPTAR MASCOTA

Descripción El usuario elegirá la mascota que desea adoptar desde el catálogo de
mascotas disponibles, visualizará la información de la misma y seleccionar
la opción “Adoptar” para iniciar todo el proceso de adopción.
Requisito REQ.D.003 – Información sobre Adopciones
Relacionado REQ.F.006 – Adopción de Mascota
Precondición El usuario debe estar registrado y autenticado en el sistema
Postcondición
Observaciones
Paso Acción
1 El usuario registrado selecciona la mascota que va a adoptar
El sistema recupera toda la información de la mascota
Secuencia de 2
seleccionada para adoptar y la muestra.
Pasos
3 El usuario registrado presiona el botón adoptar.
El sistema muestra una ventana de confirmación de la adopción y
4
el caso de uso termina.
Paso Excepción
Secuencia de Si todos los campos obligatorios no fueron ingresados, marca
2
Excepciones como error dichos campos en la interfaz.
3 Si se produce un error en el guardado, conduce a la página de error
C.U.005 GENERAR NOTIFICACIONES
Descripción El sistema notificará por correo electrónico y sms la adopción de la
mascota, tanto al dueño de la mascota como a la persona que desea
adoptar.
Requisito REQ.F.006 – Adopción de Mascota
Relacionado REQ.F.007 – Notificación de Adopciones
Precondición La adopción debe haberse realizado correctamente
Postcondición
Observaciones
Paso Acción
El sistema envía un correo con los datos de la adopción y de
1
contacto del usuario dueño de la mascota
Secuencia de
El sistema envía un sms de notificación al dueño de la mascota de
Pasos 2
que su mascota fue adoptada
El sistema envía un correo de notificación al dueño de la mascota
3
de que su mascota fue adoptada y el caso de uso termina
Secuencia de Paso Excepción
Excepciones

C.U.006 LISTAR MASCOTAS

Descripción Los usuarios invitados y los registrados y autenticados en el sistema
pueden visualizar en el sistema un catálogo con todas las mascotas
disponibles para adopción.
Requisito REQ.D.001 – Información sobre Mascotas
Relacionado REQ.F.005 – Listado de Mascotas
Precondición
Postcondición
Observaciones El caso está disponible para invitados como para usuarios registrados.
Paso Acción
Secuencia de
El sistema recupera todos los registros de mascotas y muestra en
Pasos 1
forma de catálogo y termina el caso de uso.
Secuencia de Paso Excepción
Excepciones

C.U.007 ACTUALIZAR CATALOGO DE MASCOTAS

Descripción Una mascota que haya sido adoptada debe ser actualizada en la BD como
adoptada y automáticamente refrescarse el catálogo de mascotas.
Requisito REQ.D.001 – Información sobre Mascotas
Relacionado REQ.F.006 – Adopción de Mascota
Precondición La adopción debe haberse realizado correctamente
Postcondición
Observaciones
Paso Acción
Secuencia de
El sistema recupera todos los registros de mascotas y muestra en
Pasos 1
forma de catálogo y termina el caso de uso.
Paso Excepción
Secuencia de
En caso de que se presente algún error, deberá notificar
Excepciones 1
internamente a los usuarios con perfil de administrador.
C.U.008 CONFIRMAR ADOPCIÓN
Descripción El usuario introducirá como mínimo los datos necesarios para crear el
usuario en el sistema. Los datos se guardarán en la base de datos.
Requisito REQ.D.001 – Información sobre Mascotas
Relacionado REQ.F.006 – Adopción de Mascota
Precondición La adopción debe haberse realizado correctamente
Postcondición
Observaciones Las mascotas adoptadas dejan de salir en el listado de mascotas
disponibles.
Paso Acción
Secuencia de
El usuario registrado confirma la adopción y el caso de uso
Pasos 1
termina.
Secuencia de Paso Excepción
Excepciones 1 Si se produce un error en el guardado, conduce a la página de error

C.U.009 CIERRE DE SESIÓN

Descripción El sistema cerrará la sesión del usuario.
Requisito REQ.I.003 – Cierre de Sesión
Relacionado
Precondición El usuario validado tendrá cualquier perfil
Postcondición Se cerrará la sesión del usuario
Observaciones Se le devolverá al usuario al formulario de identificación.
Paso Acción
Secuencia de 1 El usuario pulsa “Salir” de la aplicación
Pasos 2 El sistema cierra la sesión del usuario en la aplicación
3 Se le muestra al usuario el formulario de identificación
Paso Excepción
Secuencia de
Si se produce un error al cerrar la sesión se envía a la página de
Excepciones 2
error
 2. ANÁLISIS

MODELO DE CLASES
Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para
mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido
(diseño). El diagrama de clases de más alto nivel (main class diagram), será lógicamente un
dibujo de los paquetes que componen el sistema. A su vez cada paquete tendrá un main class
diagram que muestra las clases del paquete, ya en la parte del diseño.

Habiendo definido los requisitos que tiene que cumplir el sistema y también el funcionamiento
que debe tener, mediante el empleo de los casos de uso y los diagramas de actividad, toca ahora
realizar el modelo dinámico con el que contará la aplicación. Para eso, emplearemos en este
punto varios diagramas de clases de alto nivel en el que trataremos de abordar toda la
aplicación.

Diagrama de paquetes de alto nivel

Ya centrándonos más a fondo en la aplicación, diremos que estará principalmente basada en los
paquetes ec.edu.utpl.modelo (Capa Modelo), ec.edu.utpl.controlador (Capa Controlador) y
ec.edu.utpl.util que explicaremos en las siguientes tablas.

Tipo Package
Nombre ec.edu.utpl.modelo
Descripción Contendrá las clases que representan el mapeo entre la lógica de la
aplicación y una tabla que la represente en la base de datos. Estas clases
también realizarán todas las operaciones contra la base de datos para
almacenar, modificar, eliminar y obtener datos de esa tabla.

Tipo Package
Nombre ec.edu.utpl.controlador
Descripción Estas clases responden a eventos, usualmente acciones del usuario e
invoca cambios en el modelo y probablemente en la vista.
Contendrá las acciones, así como los beans que representan toda la
información que se muestra en las correspondientes páginas Web.

Tipo Package
Nombre ec.edu.utpl.util
Descripción Contendrá las funciones necesarias en las que se apoyan las acciones,
tales como obtención de variables de configuración, envío de correos,
cifrado de claves, importación y exportación de reportes, generación de
listas, envío de mensaje y/o errores, validación de datos

MODELO DE DATOS
Los puntos anteriores fueron dedicados a la definición de los distintos requerimientos de la
aplicación, así como describir, ya sea mediante distintas tablas como con diferentes diagramas,
el funcionamiento de la aplicación y los elementos que necesita esta para el correcto
cumplimiento de los requerimientos definidos.

En este punto, sin embargo, se pretende definir el modelo de datos que necesitará la aplicación
para almacenar toda la información con la que va a trabajar.

Para ello vamos a emplear un diagrama entidad relación. Los diagramas E-R son un lenguaje
gráfico para describir conceptos. Informalmente, son simples dibujos o gráficos que describen
la información que trata un sistema de información y el software que lo automatiza.

Realizaremos un diagrama en el que veremos principalmente las diferentes entidades que se

necesitarán y la interrelación entre ellas. También realizaremos una breve descripción de cada
entidad para posteriormente, en la documentación de diseño, hacer más hincapié en qué tablas
se necesitan construir y que campos tiene cada una de ellas.
class BD Adopción Mascotas

TPERSON
TUSUARIOS
TPERSONA
«column»
«column»
«column» *FK cpersona: INT
*PK cusuario: VARCHAR(12)
*PK cpersona: INT * tipodireccion: VARC
* password: VARCHAR(18)
* identificacion: VARCHAR(50) * direccion: VARCHA
*FK cpersona: INT
+IPK_TPERSONA * nombres: VARCHAR(50) * cpais: VARCHAR(4)
* fcreacion: DATE +IPK_TPERSONA
(cpersona = cpersona) * apeliidos: VARCHAR(50) * cprovincia: VARCH
activo: VARCHAR(1) (cpersona = cpersona)
* fnacimiento: DATE *FK cciudad: VARCHAR
0..* «FK» 1 * sexo: CHAR(1) «FK» referencia: VARCH
«FK» 1 0..*
+FK_TUSUPER telefono: VARCHAR(12)
+ FK_TUSUPER(INT)
celular: VARCHAR(12) +FK_TPERDIR «FK»
«index» fingreso: VARCHAR(50) + FK_TPERCPER(INT)
+ IDX_TUSUCPERSONA(INT) comentarios: VARCHAR(500) + FK_TPERDIR(INT)
«PK» + FK_TPERSONADIR
+ PK_TUSUARIOS(VARCHAR) «PK» «index»
+ IPK_TPERSONA(INT) +IPK_TPERSONA
+ IDX_TPERSCPER(IN
+PK_TUSUARIOS 1
1 + IXFK_TPERSONAD
+IPK_TPERSONA 1

(cusuario = cusuario)
(cpersona = cpersona)
«FK»
«FK»
(cpersona = cpersona)
«FK»
+FK_TUSUROL 0..*
+FK_TMASPER 0..*

TROLUSUARIO
TMASCOTA TADOP
«column» +FK_TADOPPER
«column» «column»
FK crol: INTEGER
*PK idmascota: INT
FK cusuario: VARCHAR(12) 0..* *PK idadopcion: IN
* nombre: VARCHAR(50)
*FK idmascota: IN
* tipomascota: VARCHAR(50) * cpersona_ado
«FK»
* raza: VARCHAR(50) * fadopción: DA
+ FK_TROLUSU(INTEGER)
* talla: VARCHAR(10)
+ FK_TUSUROL(VARCHAR) fentrega: DAT
* edad: INT (idmascota = idmascota) estado: VARC
«index» observaciones: VARCHAR(500)
+ IDX_TROLUSUROL(INTEGER) * comentarios:
historialmedico: VARCHAR(500) FK cpersona: INT
+ IDX_TROLUSUUSU(VARCHAR) fingreso: DATE 1 «FK» 0..*
estadoadopcion: VARCHAR(3) +PK_TMASCOTA +FK_TADOPMASC «FK»
+FK_TROLUSU 0..*
*FK cpersona: INT + FK_TADOPM
+ FK_TADOPPE
«FK»
+ FK_TMASPER(INT) «index»
(crol = crol)
+ IDX_TADOPE
«FK» «index» + IDX_TADOPM
+ IDX_TMASCPERS(INT)
«PK»
«PK» + PK_TADOPCIO
+ PK_TMASCOTA(INT)
+PK_TROLES 1

TROLES

«column» TAUD
*PK crol: INT
descripcion: VARCHAR(50) «column»
TSESIONES
administrador: CHAR(1) *PK idauditoria: I
freal: DATET
«column»
«PK» tipo: VARCHA
*PK idsession: INT
+ PK_TROLES(INT) +PK_TSESIONES accionusuari
cusuario: VARCHAR(12)
detalleaccion
crol: INT (idsession = idsession)
resultado: VA
finicio_session: DATE 1 «FK» 0..* FK idsession: IN
ffin_session: DATE
dispositivo: VARCHAR(100) +FK_TAUDITSESION
«FK»
+ FK_TAUDITS
«PK»
+ PK_TSESIONES(INT) «index»
+ IDX_TAUDIS
«PK»
+ PK_TAUDITO
 TPERSONADIRECCIONES

TCIUDADES
«column»
*FK cpersona: INT
* tipodireccion: VARCHAR(3) «column»
* direccion: VARCHAR(100) *PK cciudad: VARCHAR(3)
+FK_TPERSONADIRECCIONES nombre: VARCHAR(50)
* cpais: VARCHAR(4)
+IPK_TPERSONA FK cprovincia: VARCHAR(3)
* cprovincia: VARCHAR(3)
(cpersona = cpersona) (cciudad = cciudad) cpais: VARCHAR(4)
*FK cciudad: VARCHAR(3)
«FK» 0..* referencia: VARCHAR(500) 0..* «FK» 1
«FK»
+PK_TCIUDADES + FK_TCIUDPROV(VARCHAR)
+FK_TPERDIR «FK»
+ FK_TPERCPER(INT) «index»
+ FK_TPERDIR(INT) + IDX_TCIUDADES(VARCHAR)
+ FK_TPERSONADIRECCIONES(VARCHAR) «PK»
«index» + PK_TCIUDADES(VARCHAR)
IPK_TPERSONA
+ IDX_TPERSCPER(INT)
+ IXFK_TPERSONADIRECCIONES_TCIUDADES(VARCHAR) +FK_TCIUDPROV 0..*

(cprovincia = cprovincia)
«FK»
(cpersona = cpersona)
«FK»

+PK_TPROVINCIAS 1

TADOPCIONES TPROVINCIAS
+FK_TADOPPER
«column» «column»
0..* *PK idadopcion: INT *PK cprovincia: VARCHAR(3)
*FK idmascota: INT nombre: VARCHAR(50)
* cpersona_adopcion: INT FK cpais: VARCHAR(4)
* fadopción: DATE
fentrega: DATE «FK»
(idmascota = idmascota) estado: VARCHAR(50) + FK_TPAISES(VARCHAR)
* comentarios: VARCHAR(500) «index»
«FK» FK cpersona: INT + IDX_TPROVINCIAS(VARCHAR)
0..*
PK_TMASCOTA +FK_TADOPMASC «PK»
«FK»
+ PK_TPROVINCIAS(VARCHAR)
+ FK_TADOPMASC(INT)
+ FK_TADOPPER(INT) +FK_TPAISES 0..*
«index»
+ IDX_TADOPERSONA(INT)
(cpais = cpais)
+ IDX_TADOPMASC(INT)
«FK»
«PK»
+ PK_TADOPCIONES(INT)
+PK_TPAISES 1

TPAISES

TAUDITORIA «column»
*PK cpais: VARCHAR(4)
nombre: VARCHAR(50)
«column»
*PK idauditoria: INT
«PK»
freal: DATETIME(4)
+ PK_TPAISES(VARCHAR)
tipo: VARCHAR(12)
PK_TSESIONES accionusuario: VARCHAR(20)
(idsession = idsession) detalleaccion: VARCHAR(100)
resultado: VARCHAR(50)
«FK» 0..* FK idsession: INT
+FK_TAUDITSESION
«FK»
+ FK_TAUDITSESION(INT)
«index»
+ IDX_TAUDISESS(INT)
«PK»
+ PK_TAUDITORIA(INT)
Nombre TUSUARIOS
Descripción Entidad que sirve para mantener la información de cada uno de los
usuarios de la aplicación.

Nombre TPERSONA
Descripción Entidad que sirve para mantener la información de las personas de la
aplicación.

Nombre TMASCOTA
Descripción Entidad que sirve para mantener la información de cada una de las
mascotas registradas en el sistema.

Nombre TADOPCIONES
Descripción Entidad que sirve para mantener la información de las operaciones de
adopción de mascotas registradas en el sistema.

Nombre TPERSONADIRECCIONES
Descripción Entidad que sirve para mantener la información de las direcciones que
tiene una persona.

Nombre TROLUSUARIO
Descripción Entidad que sirve para mantener la información de la relación de roles y
sus respectivos usuarios.

Nombre TROLES
Descripción Entidad que sirve para mantener la información de los roles del sistema.

Nombre TSESSIONES
Descripción Entidad que sirve para mantener la información de las sesiones registradas
en el sistema.

Nombre TAUDITORIA
Descripción Entidad que sirve para mantener la información de auditoria para las
acciones de un usuario en una sesión.

Nombre TCIUDADES
Descripción Entidad que sirve para mantener la información de ciudades.

Nombre TPROVINCIAS
Descripción Entidad que sirve para mantener la información de provincias.

Nombre TPAISES
Descripción Entidad que sirve para mantener la información de países.
 1. DISEÑO

DEFINICIÓN DE LA ARQUITECTURA
Centrándonos más en el propio sistema, en este punto trataremos de dividir el sistema en las
diferentes capas que pueden distinguirse. Como ya se ha comentado, el sistema seguirá el
patrón MVC. Por consiguiente, aquí estamos estableciendo un mínimo de 3 capas.

En el diagrama vemos estas capas:

Capa 1: Será el diseño estético de la aplicación. En otras palabras, es la parte gráfica, la parte
que el usuario del sistema verá en su navegador web. Esta parte estará formada por las
páginas JSF de la aplicación.

Capa 2: Será el controlador. Todas las peticiones al sistema y respuestas del sistema pasarán
por este elemento. Él será el encargado de redirigir los diferentes mensajes entre las distintas
páginas JSF y Servlets.

Capa 3: Será la parte del sistema encargada del almacenamiento y recuperación de la

información de la base de datos

ESPECIFICACIÓN DE PRODUCTOS Y VERSIONES

Utilización Producto Empresa Versión

Servidor de Aplicaciones WildFly Red Hat Inc. 21.0.2 Final
JVM Java Oracle Corporation 8 update 181
API para Servlets JavaServer Faces Oracle Corporation 2.0.1
IDE Eclipse IDE Eclipse Foundation 2020-12
Servidor de BD MySQL Community Oracle Corporation 8.0.22
Gestión Software BD Hibernate Red Hat Inc. 5.4.25 Final
Biblioteca para Mail JavaMail Oracle Corporation 1.6.2 Final
Biblioteca de Log Log4j Apache Foundation 2.14.0
 DIAGRAMA DE DESPLIEGUE

deployment Starter Deployment Diagram

WORKSTATION WEB SERVER

OS: LINUX CENTOS 7

SERVER: WILDFLY 21.0.2 Final
JQUERY
PDF JAVA Mail Service

HTTP/JSON
HTML XML
Present Lawyer (Web Interface)

CSS BOOTSTRAP
DataBase Interface

TCP/IP

DATA BASE SERVER

OS: LINUX
MySQL DATABASE
 DISEÑO DE CLASES

▪ Paquete ec.edu.utpl.modelo.gestion

Agrupa a las clases que realizan operaciones de inserción, obtención y eliminación en

la base de datos, apoyándose en los beans de persistencia.

class Class Model

Borrar

- logger: Logger = Logger.getLogger();

+ borrarUsuario(int, String): void

+ borrarMascota(Session, int): void
+ borrarAdopcion(Session, int): void

Insertar Obtener

- logger: Logger = Logger.getLogger(); - logger: Logger = Logger.getLogger();

+ mascota(Hashtable, ActionForm): Integer + usuario(Integer): Usuario
+ persona(Hashtable, ActionForm): Integer + persona(Integer): Persona
+ usuario(String, String, int, String): Integer + mascota(Integer): Mascota
+ actualizar(Object): void + rol(Integer): Rol
+ adopcion(Hashtable, ActionForm): Integer + rolesUsuario(): List
+ registroAcciones(Hashtable, ActionForm): Integer + adopcionesUsuario(): List
+ usuarios(): List
+ personas(): List
 ▪ Paquete ec.edu.utpl.modelo.persistencia
Este paquete constará con todas aquellas clases (beans) que asocien los datos de una tabla de
la base de datos con un objeto lógico que vaya a emplearse en la aplicación, además de los
ficheros XML de configuración de cada una.

class System

Mascota
Adopcion
- idmascota: int Direccion Ciudad
- nombre: String - idAdopcion: int
- tipomascota: String - mascota: Mascota - referencia: String - cciudad: String
- raza: String - personaAdopcion: Persona - direccion: String - nombre: String
- talla: String - persona: Persona - tipodireccion: String - provincia: Provincia
- edad: int - fadopcion: Date - ciudad: Ciudad
- observaciones: String - estado: String + setCciudad(String): void
+ setReferencia(String): void + getCciudad(): String
- historial: String - comentario: String
+ getReferencia(): String + setNombre(String): void
- fingreso: Date
+ setIdadopcion(int): void + setDireccion(String): void + getNombre(): String
- estadoAdopcion: String
+ getIdadopcion(): int + getDireccion(): String + setProvincia(Provincia): void
+ setIdmascota(int): void + setMascota(Mascota): void + setTipodireccion(String): void + getProvincia(): Provincia
+ getIdmascota(): int + getMascota(): Mascota + getTipodireccion(): String
+ setNombre(String): void + setPersonaadopcion(Persona): void + setCiudad(Ciudad): void
+ getNombre(): String + getPersonaadopcion(): Persona + getCiudad(): Ciudad
+ setTipomascota(String): void + setPersona(Persona): void
+ getTipomascota(): String + getPersona(): Persona
+ setRaza(String): void + setFadopcion(Date): void
+ getRaza(): String + getFadopcion(): Date
Provincia
+ setTalla(String): void + setEstado(String): void
+ getTalla(): String + getEstado(): String - cprovincia: String
+ setEdad(int): void + setComentario(String): void - nombre: String
+ getEdad(): int + getComentario(): String - pais: Pais
+ setObservaciones(String): void
Persona + setCprovincia(String): void
+ getObservaciones(): String
+ setHistorial(String): void + getCprovincia(): String
- cpersona: int
+ getHistorial(): String - identificacion: String + setNombre(String): void
+ setFingreso(Date): void + getNombre(): String
- nombres: String
+ getFingreso(): Date + setPais(Pais): void
Usuario - apellidos: String
+ setEstadoadopcion(String): void + getPais(): Pais
- fnacimiento: Date
+ getEstadoadopcion(): String - cusuario: int - sexo: String
- password: String - telefono: String
- fcreacion: Date - celular: String
- activo: String - fingreso: Date
- rol: Rol - comentarios: String Pais

+ setCusuario(String): void + setCpersona(int): void - cpais: String

+ getCusuario(): String + getCpersona(): int - nombre: String
+ setPassword(String): void + setIdentificacion(String): void
+ setCpais(String): void
+ getPassword(): String + getIdentificacion(): String
Session + getCpais(): String
+ setFcreacion(Date): void + setNombres(String): void
+ setNombre(String): void
- idesession: int + getFcreacion(): Date + getNombres(): String
+ getNombre(): String
- usuario: Usuario + setActivo(String): void + setApellidos(String): void
- rol: Rol + getActivo(): String + getApellidos(): String
- finicio: Date + setFnacimiento(Date): void
- ffin: Date + getFnacimiento(): Date
- dispositivo: String + setSexo(String): void
+ getSexo(): String
+ getIdsession(): int + setTelefono(String): void
+ setIdSession(int): void + getTelefono(): String HibernateSessionFactory
+ getUsuario(): Usuario Rol + setCelular(String): void
+ setUsuario(Usuario): void + getCelular(): String - configuration: Configuration
+ getRol(): Rol - crol: int + setFingreso(Date): void - configFile: String
+ setRol(Rol): void - descripcion: int + getFingreso(): Date - sessionFactory: SessionFactory
+ getFinicio(): Date - isAdmninistrador: int + setComentarios(String): void
+ setFinicio(Date): void + closeSession(): void
+ getComentarios(): String
+ getCrol(): Integer + getConfiguration(): Configuration
+ getFfin(): Date
+ setCrol(int): void + getSession(): Session
+ setFfin(Date): void
+ setDescripcion(String): void + getSessionFactory(): SessionFactory
+ setDispositivo(String): void
+ getDescripcion(): String + setConfigFile(): void
+ getDispositivo(): String
+ isAdministrador(boolean): void + rebuildSessionFactory(String): void
+ getAdministrador(): boolean
 ▪ Paquete ec.edu.utpl.controlador

class System

NavegacionAction
CreacionPersona
- logger: Logger = Logger.getLogger();
- logger: Logger = Logger.getLogger();
NotificarAdopcion + execute(ActionMapping, ActionForm): ActionFoward
+ execute(ActionMapping, ActionForm): ActionFoward
- logger: Logger = Logger.getLogger();

+ execute(ActionMapping, ActionForm): ActionFoward

CreacionUsuario

ListadoMascotas MainAction - logger: Logger = Logger.getLogger();

- logger: Logger = Logger.getLogger(); - logger: Logger = Logger.getLogger(); + execute(ActionMapping, ActionForm): ActionFoward

+ execute(ActionMapping, ActionForm): ActionFoward + execute(ActionMapping, ActionForm): ActionFoward

GestionUsuario

AdopcionMascota - logger: Logger = Logger.getLogger();

- logger: Logger = Logger.getLogger(); + execute(ActionMapping, ActionForm): ActionFoward

InvalidSessionAction
+ execute(ActionMapping, ActionForm): ActionFoward
- logger: Logger = Logger.getLogger();

+ execute(ActionMapping, ActionForm): ActionFoward

CreacionMascota

- logger: Logger = Logger.getLogger();

+ execute(ActionMapping, ActionForm): ActionFoward

LoginAction

- logger: Logger = Logger.getLogger();

+ execute(ActionMapping, ActionForm): ActionFoward

 ▪ Paquete ec.edu.utpl.util

class Class Model

EnvioMail EnvioSms Notificacion

- asunto: String - url: String + getAlerta(String): void

- usuario: String - celular: String + getMensajeConfirmacion(String): void
- server: String - codigoMensaje: int + getMensajeError(String): void
- port: String - texto: String
- password: String
- smtp: boolean + getCelular(int): String
+ getMensaje(String): void
+ getPlantilla(int): void + sendMensaje(String, String, String): void
+ enviarMensaje(String, String, String): boolean + getUrl(): void
- getMensaje(String): String

ManageImagen Cifrado Util

- codigoImagen: int - algoritmo: String + generarPassword(String): String

- anchoImagen: int - password: String + getFechaString(Date): String
- altoImagen: int - salt: String + getDate(String): Date
- dpi: int - profundidad: String
- patImagen: String - padding: String

+ getImagen(int): String + cifrarDato(String): String

+ resizeImagen(int, int, int, int): String + descifrarDato(int): String

Propiedades Listas

- archivo: String + listaCiudades(): List<String[ ]>

- propiedad: String
+ getPropiedad(String, String): String
+ listaProvincias(): List<String[ ]>
+ listaPaises(): List<String[ ]>
+ listaTipoMascota(): List<String[ ]>
+ listaMascotas(): List<String[ ]>
+ listaPersonas(): List<String[ ]>