Ejercicio Técnico para almundo.
Este es un proyecto que simula un call center. El sistema puede ser visto como un productor-consumidor con un buffer intermedio. Tiene las siguientes partes:
- Un Productor que genera llamadas y las deposita en una cola de llamadas.
- La cola de llamadas.
- Un conjunto de empleados que atienden llamadas.
Sin embargo, los empleados no toman autónomamente las llamadas de la cola: Existe un Dispatcher, encargado de asignar las llamadas a los empleados.
A continuación, analizaremos cada módulo.
El productor es uno solo, y ejecuta en su propio hilo al iniciar el call-center. Repite constantemente estos pasos:
- Genera una llamada.
- Deposita la llamada en la cola de llamadas.
- Espera un tiempo aleatorio entre 1 y 3 segundos (para simular un call center real).
La cola de llamadas puede almacenar hasta 10 llamadas. Luego, si se intenta agregar una nueva llamada, la misma será rechazada y descartada. Este es un caso excepcional. Si fuera un call center real, tendríamos una grabación que le diría al usuario "Todas nuestras operadoras están ocupadas. Por favor, intente más tarde". Es decir, están todos ocupados y, además, no podemos dejar su llamada en espera porque la cola está llena.
El Dispatcher es uno solo, y ejecuta en su propio hilo al iniciar el call-center.
Contiene tres colas: operadores, supervisores y directores. Sus tamaño son de 6, 3 y 1 respectivamente (y pueden modificarse).
Además, el dispatcher crea 10 hilos que escuchan si llega una llamada a la cola. Si esto sucede, se toma un empleado de la cola, se toma una llamada y se responde la misma. La reserva de un empleado y una llamada tiene que ser ejecutada atómicamente, ya que sino podría reservarse un empleado y tener que encolarlo nuevamente porque otro hilo le quitó la llamada.
¿Qué pasa si hay llamada pero no hay empleado? Simplemente se deja la llamada en la cola de espera hasta que haya algún empleado disponible.
El Dispatcher también actualiza un contador de hilos ocupados, para saber cuántos de ellos están gestionando una llamada.
Cada llamada tiene un ID para ser identificada y un tiempo autogenerado entre 5 y 10 segundos.
Todos los empleados tienen el mismo comportamiento sin importar su puesto. Es decir, todos atienden llamadas. Quien los diferencia es el Dispatcher al momento de enviarles llamadas.
Cada empleado tiene un ID, un puesto y conoce su cola, para que el dispatcher no tenga que analizar qué puesto tiene cuando haya que enviarlo de vuelta a su cola (polimorfismo en vez de ifs).
Para modelar a los empleados, se eligió composición en vez de herencia. A pesar de que esta última parecía más natural, no otorgaba mucha utilidad al momento de codificar el Dispatcher. Como todos los empleados son iguales, la opción más simple es que el puesto sea un atributo del empleado. Este atributo es un objeto de clase Puesto y tiene comportamiento propio. Esto podría verse parecido un patrón Strategy.
Al tomar decisiones de diseño y arquitectura, se pensó en estos principios:
- Prevenir condiciones de carrera.
- Prevenir Deadlocks.
- Administrar con justicia los hilos y pedidos (ej: prevenir starvation).
- Escribir código expresivo y respetar las buenas prácticas.
Se eligió la BlockingQueue por ser thread safe, organizar de forma justa las llamadas (FIFO) y elegir un empleado de forma justa (la colas de operadores, supervisores y directores se administran cada una con FIFO).
Ejecutar los siguientes comandos:
git clone git@github.com:gmazzei/CallCenter.git cd CallCenter mvn clean install mvn exec:java