Descripción del problema
Vivimos en un mundo donde las transacciones monetarias se hacen gran parte por internet. Transferencias y compras a través de ella son acciones muy comunes. Cada banco posee un sistema de funcionamiento único con respecto a los demás bancos y el poder comunicar de manera correcta y única estas las transacciones es algo que Transbank maneja de muy buena manera.
Análisis y diseño de la solución
El proyecto se enfoca en la implementación de un Transbank: un servicio que permita la interacción entre 2 bancos. Estos pueden ser el mismo banco o bancos diferentes.
Un banco debe tener perfiles: la información bancaria del usuario. Cada perfil puede tener asociado cuatro diferentes tipos de cuentas: Cuenta corriente, Cuenta vista, Cuenta de ahorro y Chequera electrónica.
Mediante una interfaz gráfica (servidor web) el usuario debe poder iniciar sesión, visualizar el estado de sus cuentas y transferir dinero de alguna cuenta a otra. En la transferencia la cuenta de origen debe pertenecer al usuario registrado y la cuenta de destino debe pertenecer a alguna cuenta de un usuario existente. Esto quiere decir que un usuario puede mover dinero entre sus cuentas y depositar dinero a otro usuario.
Planteamiento de la solución
Para llevar a cabo la solución se crearán dos proyectos en Django: Bank y Transbank.
El proyecto Bank levantará un servidor web de un banco que permitirá al usuario realizar todas las acciones planteadas en el párrafo anterior mediante interfaz gráfica. En este proyecto se hará uso de la gallardía de Django. Es decir, el desarrollo de vistas y plantillas para mostrar la información mediante una GUI. Para levantar dos bancos bastará duplicar el proyecto Bank y cambiar sus configuraciones.
El proyecto Transbank levantará un servidor web que permitirá la comunicación entre dos servidores web distintos (bancos distintos) o la autocomunicación de un servidor web (mismo banco). En otras palabras, realizará todos los movimientos de dinero. No tendrá vistas, es decir, no tendrá una interfaz gráfica interactiva o que muestre información dado que su única función es hacer posible la transferencia del dinero.
Casos de uso
N°1: Iniciar sesión
- Nombre: Iniciar Sesión.
- Propósito: El usuario desea inciar sesión en el sistema.
- Actor: Usuario.
- Pre-condición: Existe el perfil del usuario en el sistema.
- Evento: El usuario inicia sesión en el sistema con su perfil.
- Post-condición: El usuario tiene acceso a su información y puede realizar operaciones que tiene permitido en el sistema.
- Tipo: Manual.
N°2: Revisar estado de cuentas
- Nombre: Revisar estado de cuentas.
- Propósito: El usuario desea revisar el estado de sus cuentas existentes en el sistema.
- Actor: Usuario.
- Pre-condición: Usuario autenticado.
- Evento: El usuario visualiza el estado de sus cuentas por pantalla.
- Post-condición: El usuario puede realizar 2 acciones en cada cuenta. Revisar los últimos movimientos y realizar una transferencia.
- Tipo: Manual.
N°3: Revisar últimos movimientos de una cuenta
- Nombre: Revisar los últimos movimientos de una cuenta.
- Próposito: Conocer el historial de giros y depósitos de la cuenta.
- Actor: Usuario.
- Pre-condición: Usuario autenticado y Cuenta existente.
- Evento: El usuario se informa con respecto al prontuario de su cuenta.
- Post-condición: Se muestra en pantalla la información solicitada.
- Tipo: Manual.
N°4: Transferir dinero
- Nombre: Transferir dinero
- Propósito: Mover dinero de una cuenta a otra.
- Actor: Usuario.
- Pre-condición: Usuario autenticado, ambas cuentas deben existir, la cuenta de origen contiene una cantidad de dinero mayor o igual al monto a transferir.
- Evento: El usuario transfiere dinero.
- Post-condición: La cantidad de suma al monto de la cuenta de destino y se resta al monto de la cuenta de origen.
- Tipo: Manual
Diagramas
Diagrama de Clases (UML)
Diagrama de secuencia
Pruebas, demostración y dificultades
Pruebas y demostración de casos de uso
Caso de Uso N°1
Usuario busca en el navegador la pagina del banco.
Actor se autentica.
El sistema procesa la solicitud y el actor entra al sitio web con su perfil
Caso de Uso N°2
El actor selecciona el enlace para ver el estado de cuentas.
El sistema despliega una pantalla con la información y operaciones asociadas a cada cuenta del usuario.
En caso de que el actor no tenga cuentas, el sistema muestra una tabla vacía.
El actor selecciona la opción "Ultimos movimientos" de una cuenta.
Caso de Uso N°3
El sistema despliega una tabla con la información solicitada acerca de los giros y depósitos.
El actor selecciona la opción "Transferir".
Caso de Uso N°4
El sistema despliega un formulario de transferencia.
El actor rellena el formulario y lo envía.
El sistema procesa la solicitud. La cantidad transferencia se resta a la cuenta de origen y se suma a la cuenta de destino. Envía un mensaje de operación exitosa.
Dificultades
La primera dificultad a la que nos tuvimos que enfrentar como grupo fue el aprender a ocupar el framework web Django. Como este framework está escrito, en gran parte, en el lenguaje de programación Python y como integrantes del grupo ya cursamos la asignatura IWI131 (Programación), se nos hizo muy llevadero el aprendizaje y fue bastante rápido.
Lo segundo fue la creación de los modelos o tablas que tendría la base de datos de los bancos. El diseño fue muy importante ya que un mal modelo de datos puede llevar a pésimos resultados. Se revisó que no existieran dependencias circulares entre tablas y lograr establecer la unicidad en la información que se almacenaría en la base de datos (gracias a las llaves primarias y foráneas del modelo).
Otro punto muy importante fue el aprender la sintaxis de Python para programación orientada a objetos. A diferencia de los lenguajes enseñados en la asignatura (Java y C++), Python es mucho más flexible en cuanto a declaración de atributos y métodos. La única manera que se tenía para ir aprendiendo esto fue ir descubriendo a punta de "prueba y error".