MedAuth

Avance del proyecto

Tras realizar el primer avance y el segundo avance, se debía avanzar el proyecto según el roadmap realizando las distintas operaciones de administración de autorizaciones y administración de citas médicas:

• Gestión de autorizaciones (requiere administración de usuarios, pólizas y autorizaciones)
  • Historias de usuario que se resuelven:
    • Como asegurado quiero consultar una autorización médica para ver el estado de la autorización: Método consultar_autorizacion y su test test_consultar_poliza.
    • Como asegurado quiero añadir una prescripción médica para poder solicitar una autorización de una prueba médica: Método subir_prescripcion y test test_subir_prescripcion.

Mejoras tras correcciones

Durante las correcciones previas se sugirieron las siguientes consideraciones:

1. Jerarquización de las clases de usuario: Se comentó que las clases UsuarioAdmin y UsuarioCliente poseían atributos en común, y los métodos de gestión de los mismos eran una clara repetición de código, por lo que se ha optado por hacer uso del polimorfismo, y crear una clase genérica Usuario, de la cual heredan información las clases UsuarioAdmin y UsuarioCliente.

   Además, para el almacenamiento de usuarios se ha optado por una lista de usuarios que engloba ambos tipos, en lugar de dos listas separadas para cada tipo.

   Por último, se han unificado los métodos crear_admin, crear_cliente, modificar_admin, modificar_cliente, eliminar_admin y eliminar_cliente en los métodos crear_usuario, modificar_usuario, eliminar_usuario.

2. Establecer formatos de atributos: Se comentó que en ningún momento se comprobaba que la información introducida siguiera un formato, por lo que se podía introducir un DNI, Email o IBAN incorrecto. Para ello, se han establecido comprobaciones mediante expresiones regulares para los siguientes elementos de la forma:

   • DNI: "[0-9]{8}-[A-Z]", la cual comprueba que el DNI posea 8 dígitos y una letra mayúscula.
   • Email: "([a-zA-Z0-9]+@[a-zA-Z]+\.)(com|es)", la cual comprueba que siga el formato usuario@dominio.com, permitiendo que existan números en la dirección, y de momento solo se contemplan los dominios terminados en .com o .es.
   • IBAN: "ES[0-9]{22}", la cual comprueba el formato de ES seguido de 22 dígitos, aunque en un supuesto más realista, supondría desglosar las diferentes partes del código, pero de momento ya se contempla un formato más aproximado.

3. Excepciones: Se comentó que no se contemplaban excepciones en ninguna parte del programa, por lo que se ha decidido implementar las siguientes excepciones de acuerdo a los requisitos del proyecto:

   • DNI incorrecto: 'DNI not valid.'
   • Email incorrecto:'Email not valid.'
   • Tipo de usuario incorrecto: 'Wrong user type.'
   • IBAN incorrecto:'IBAN not valid.'
   • Inexistencia de un elemento: 'User doesn´t exist.', 'Policy doesn´t exist.', entre otros, donde se comprueba que un determinado objeto exista en el sistema.
   • Existencia de un elemento: 'An user exists with DNI provided.' cuando se intenta crear un usuario con un DNI registrado, se puede ver aquí.
   • Asociaciones entre objetos: 'The prescription is not associated with the active policy.', 'The authorization is not associated with the active policy.', donde se comprueba que una prescripción o autorización se intenta crear con una póliza inactiva o inexistente.