Trabajo Práctico
Fecha de Entrega: 21 de Noviembre de 2023
Introducción
Nos encontramos desarrollando un software para una cadena de tiendas distribuida por todo el país. La misma tiene un sitio de e-commerce además de locales físicos.
En este caso estamos trabajando el módulo de manejo de stocks. Se pueden registrar compras en cada tienda física, así como también desde el e-commerce. El sitio de e-commerce reserva stock de producto de la tienda más cercana posible a la dirección de envío de la compra idealmente (modelar de forma aleatoria), pero puede potencialmente tomar el stock de cualquier local de ser necesario.
Objetivo
Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de stocks.
Requerimientos
- Una aplicación modelará el sitio de e-commerce, la cual generará ordenes según un archivo de pedidos simulado.
- Otra aplicación simulará las terminales de cobro en los locales, habiendo N instancias de esta aplicación (una por cada local). Cada terminal simulará los pedidos también desde un archivo de ordenes.
- En el caso de compras por e-commerce, el stock del producto se bloquea, pero no se descuenta hasta que el producto es efectivamente entregado.
- La entrega puede no realizarse a tiempo, con lo cual la compra se cancela y el stock se libera (modelar con un random).
- Debido a que las tiendas se encuentran por todo el pais, en algunos casos con muy mala conexión, los nodos de cada tienda pueden entrar y salir de la red espontáneamente.
- Mientras se encuentran fuera de red, los servidores pueden seguir actualizando stocks con ventas locales; no así con las de e-commerce.
- Al volver a conectarse, deben sincronizar los stocks
Requerimientos no funcionales
Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:
- El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
- Alguna de las aplicaciones implementadas debe funcionar utilizando el modelo de actores.
- No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, o autorizados expresamente por los profesores.
- El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
- El código deberá funcionar en ambiente Unix / Linux.
- El programa deberá ejecutarse en la línea de comandos.
- La compilación no debe arrojar warnings del compilador, ni del linter clippy.
- Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
- El código debe formatearse utilizando cargo fmt.
- Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.
Entrega
La resolución del presente proyecto es en grupos de tres integrantes.
La entrega del proyecto se realizará mediante Github Classroom. Cada grupo tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto. Se recomienda iniciar tempranamente y trabajar siguiendo un formato de commits pequeños que agreguen funcionalidad incrementalmente. Se podrán hacer commits hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.
Asi mismo el proyecto debe incluir un informe en formato Markdown en el README.md del repositorio que contenga una explicación del diseño y de las decisiones tomadas para la implementación de la solución, asi como diagramas de threads y procesos, y la comunicación entre los mismos; y diagramas de las entidades principales.
En el mismo archivo deberá proveerse cualquier explicación y/o set de comandos necesarios para la ejecución de los programas.
Evaluación
Principios teóricos y corrección de bugs
Los alumnos presentarán el código de su solución presencialmente, con foco en el uso de las diferentes herramientas de concurrencia. Deberán poder explicar desde los conceptos teóricos vistos en clase cómo se comportará potencialmente su solución ante problemas de concurrencia (por ejemplo ausencia de deadlocks).
En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.
Casos de prueba
Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.
Informe
El informe debe poder dar cuenta de todas las decisiones tomadas para implementar la solución, incluyendo diferentes diagramas y se debe poder utilizar como soporte para que el equipo presente su trabajo.
Organización del código
El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust.
Se prohibe el uso de bloques unsafe.
Tests automatizados
La entrega debe contar con tests automatizados que prueben diferentes casos. Se considerará en especial aquellos que pongan a prueba el uso de las herramientas de concurrencia.
Presentación en término
El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influirá negativamente en la nota final.