Este repositorio contiene un proyecto de ejemplo que utiliza MongoDB, Docker y Express.js para crear una aplicación CRUD (Crear, Leer, Actualizar, Eliminar) básica.
Antes de comenzar, asegúrate de cumplir con los siguientes requisitos:
- Docker instalado en tu sistema. Si no tienes Docker instalado, puedes seguir las instrucciones de instalación en este enlace.
Sigue estos pasos para configurar el proyecto en tu entorno de desarrollo:
- Clona este repositorio en tu máquina local:
- Navega hasta la carpeta del proyecto:
- Configura las variables de entorno necesarias. Puedes editar el archivo
.envy modificar los valores según sea necesario.
Sigue estos pasos para construir y ejecutar el contenedor de Docker:
- Ejecuta el siguiente comando para iniciar el contenedor:
Esto construirá y ejecutará el contenedor de Docker con la aplicación.
Una vez que el contenedor de Docker esté en ejecución, puedes utilizar la aplicación. A continuación, se muestran algunos ejemplos de las rutas y métodos HTTP disponibles:
GET /api/users: Obtiene todos los usuarios.GET /api/users/:id: Obtiene un usuario específico por su ID.POST /api/users: Crea un nuevo usuario.PUT /api/users/:id: Actualiza un usuario existente por su ID.DELETE /api/users/:id: Elimina un usuario por su ID.
Puedes utilizar herramientas como Postman o cURL para realizar las solicitudes HTTP correspondientes a estas rutas.
¡Las contribuciones son bienvenidas! Si deseas contribuir al proyecto, sigue estos pasos:
- Haz un fork de este repositorio.
- Crea una rama para tu contribución:
git checkout -b nombre-de-la-rama. - Realiza los cambios y realiza commits descriptivos.
- Envía una solicitud pull con tus cambios.
La universidad Digital de Antioquia necesita llevar el control de los equipos de cómputo (computadores (escritorio y portátiles), mouse, teclado, monitores, etc.), móviles (celulares, tabletas, parlantes, etc.), etc. Para ello requiere contar con una aplicación web en donde se registren los datos de los distintos equipos que tienen actualmente en su inventario para tener un mejor control de dichos equipos. El sistema deberá contar con los siguientes 4 módulos:
El sistema se compone de varios módulos, cada uno con su propia funcionalidad:
-
Tipo de Equipo: Este módulo permite al usuario gestionar diferentes tipos de equipos. Los usuarios pueden agregar, editar, eliminar y visualizar los tipos de equipos disponibles.
-
Estado de Equipo: Este módulo permite al usuario gestionar los diferentes estados en los que puede encontrarse un equipo. Los usuarios pueden agregar, editar, eliminar y visualizar los estados de los equipos.
-
Marca: Este módulo permite al usuario gestionar las diferentes marcas de los equipos. Los usuarios pueden agregar, editar, eliminar y visualizar las marcas de los equipos.
-
Equipo: Este módulo permite al usuario gestionar los equipos en inventario. Los usuarios pueden agregar, editar, eliminar y visualizar los equipos disponibles en el inventario.
mongo_docker_crud_express
│
├── Tipo de Equipo
│ ├── id: Identificador único del tipo de equipo.
│ ├── nombre: Nombre del tipo de equipo.
│
├── Estado de Equipo
│ ├── id: Identificador único del estado del equipo.
│ ├── nombre: Nombre del estado del equipo.
│
├── Marca
│ ├── id: Identificador único de la marca.
│ ├── nombre: Nombre de la marca.
│
├── Equipo
│ ├── id: Identificador único del equipo.
│ ├── descripcion: Descripción detallada del equipo.
│ ├── usuario_id: Identificador del usuario que tiene asignado el equipo.
│ ├── tipo_id: Identificador del tipo de equipo.
│ ├── estado_id: Identificador del estado del equipo.
│ ├── marca_id: Identificador de la marca del equipo.
│
└── Pago
├── id: Identificador único del pago.
├── monto: Monto del pago.
└── usuario_id: Identificador del usuario que realizó el pago.Este diagrama muestra la estructura general del sistema y cómo se comunican sus componentes. En este caso, se muestra cómo el frontend se comunica con el backend a través de una API, y cómo el backend interactúa con la base de datos y los diferentes módulos del sistema.
<!-- diseño de diagramas https://plantuml.com/es/ -->
@startuml
package "Cliente" {
[Frontend]
}
package "Servidor Linux" {
node "Backend" {
[API]
}
database "Base de Datos" {
[Usuarios]
[Marcas]
[Inventario]
[Tipos de Equipo]
[Estados de Equipo]
[Pagos]
}
package "Módulo de Usuarios" {
[Creación de Usuarios]
[Edición de Usuarios]
}
package "Módulo de Marcas" {
[Creación de Marcas]
[Edición de Marcas]
}
package "Módulo de Inventario" {
[Creación de Equipos]
[Edición de Equipos]
}
package "Módulo de Tipo de Equipo" {
[Creación de Tipos de Equipo]
[Edición de Tipos de Equipo]
}
package "Módulo de Estado de Equipo" {
[Creación de Estados de Equipo]
[Edición de Estados de Equipo]
}
package "Gestión de Pagos" {
[Realizar Pagos]
[Visualización de Facturas Pendientes]
[Historial de Pagos]
[Notificaciones de Confirmación de Pago]
}
}
"Frontend" --> "API" : Envía solicitudes
"API" --> "Frontend" : Responde a solicitudes
"Módulo de Usuarios" --> "Base de Datos" : Almacena/Recupera Usuarios
"Módulo de Marcas" --> "Base de Datos" : Almacena/Recupera Marcas
"Módulo de Inventario" --> "Base de Datos" : Almacena/Recupera Equipos
"Módulo de Tipo de Equipo" --> "Base de Datos" : Almacena/Recupera Tipos de Equipo
"Módulo de Estado de Equipo" --> "Base de Datos" : Almacena/Recupera Estados de Equipo
"Gestión de Pagos" --> "Base de Datos" : Almacena/Recupera Pagos
@enduml
Este diagrama muestra las diferentes acciones que un usuario puede realizar en el sistema. En este caso, las acciones incluyen registrar tipos de equipos, estados de equipos, marcas, equipos en inventario y gestionar pagos.
Diagrama de Secuencia: Este diagrama muestra cómo se realizan las interacciones entre los usuarios y los diferentes componentes del sistema en un orden secuencial. En este caso, muestra cómo un usuario registra tipos de equipos, estados de equipos, marcas, equipos en inventario y gestiona pagos.
@startuml
actor Usuario
usecase "Registrar tipo de equipo" as T
usecase "Registrar estado de equipo" as E
usecase "Registrar marcas" as M
usecase "Registrar equipos en inventario" as I
usecase "Gestionar pagos" as P
Usuario --> T
Usuario --> E
Usuario --> M
Usuario --> I
Usuario --> P
@enduml
Este diagrama muestra cómo se realizan las interacciones entre los usuarios y los diferentes componentes del sistema en un orden secuencial. En este caso, muestra cómo un usuario registra tipos de equipos, estados de equipos, marcas, equipos en inventario y gestiona pagos.
@startuml
actor "Usuario" as U
entity "Tipo de equipo" as T
entity "Estado de equipo" as E
entity "Marcas" as M
entity "Inventario" as I
entity "Gestión de Pagos" as P
U -> T : Registra tipo de equipo
U -> E : Registra estado de equipo
U -> M : Registra marcas
U -> I : Registra equipos en inventario
U -> P : Gestiona pagos
note right of U : Los usuarios tienen a cargo los equipos del inventario
note right of U : Los usuarios gestionan los pagos realizados por los clientes
@enduml
Este diagrama muestra los diferentes componentes del sistema y cómo interactúan entre sí. En este caso, muestra cómo los usuarios utilizan los diferentes módulos del sistema.
@startuml
package "mongo_docker_crud_express" {
[Tipo de equipo] as T
[Estado de equipo] as E
[Usuarios] as U
[Marcas] as M
[Inventario] as I
[Gestión de Pagos] as P
}
U ..> T : utiliza
U ..> E : utiliza
U ..> M : utiliza
U ..> I : utiliza
U ..> P : utiliza
@enduml
MER (Modelo Entidad-Relación) y MR (Modelo Relacional) son técnicas de modelado de datos que describen cómo los datos están organizados y cómo se relacionan entre sí.
Este es un Diagrama de Clases que representa la estructura del sistema en términos de sus clases, sus propiedades y las relaciones entre ellas. Aquí están las definiciones de las clases y sus relaciones:
-
Usuario: Esta clase representa a los usuarios del sistema. Cada usuario tiene un identificador único (
id), un nombre (nombre) y un correo electrónico (email). -
TipoDeEquipo: Esta clase representa los diferentes tipos de equipos que pueden existir en el sistema. Cada tipo de equipo tiene un identificador único (
id) y un nombre (nombre). -
EstadoDeEquipo: Esta clase representa los diferentes estados en los que puede encontrarse un equipo. Cada estado de equipo tiene un identificador único (
id) y un nombre (nombre). -
Marca: Esta clase representa las diferentes marcas de los equipos. Cada marca tiene un identificador único (
id) y un nombre (nombre). -
Inventario: Esta clase representa los equipos en el inventario del sistema. Cada equipo en el inventario tiene un identificador único (
id), una descripción (descripcion), y los identificadores del usuario que lo posee (usuario_id), su tipo (tipo_id), su estado (estado_id) y su marca (marca_id). -
GestionDePagos: Esta clase representa los pagos realizados por los usuarios. Cada pago tiene un identificador único (
id), un monto (monto) y el identificador del usuario que realizó el pago (usuario_id).
Las relaciones entre las clases se representan con líneas que conectan las clases. Por ejemplo, la línea entre Usuario e Inventario indica que un Usuario puede poseer muchos equipos en el Inventario. De manera similar, un Usuario puede realizar muchos GestionDePagos, un TipoDeEquipo puede clasificar muchos equipos en el Inventario, un EstadoDeEquipo puede describir muchos equipos en el Inventario, y una Marca puede identificar muchos equipos en el Inventario.
@startuml
class Usuario {
+id: Integer
+nombre: String
+email: String
}
class TipoDeEquipo {
+id: Integer
+nombre: String
}
class EstadoDeEquipo {
+id: Integer
+nombre: String
}
class Marca {
+id: Integer
+nombre: String
}
class Inventario {
+id: Integer
+descripcion: String
+usuario_id: Integer
+tipo_id: Integer
+estado_id: Integer
+marca_id: Integer
}
class GestionDePagos {
+id: Integer
+monto: Float
+usuario_id: Integer
}
Usuario "1" -- "many" Inventario : posee
TipoDeEquipo "1" -- "many" Inventario : clasifica
EstadoDeEquipo "1" -- "many" Inventario : describe
Marca "1" -- "many" Inventario : identifica
Usuario "1" -- "many" GestionDePagos : realiza
@enduml
Un mockup es una representación visual a escala completa de un diseño o interfaz, utilizado para demostrar la funcionalidad y apariencia de un producto antes de su fabricación o implementación. Los mockups son comúnmente utilizados en el diseño de productos y en el desarrollo de software para presentar propuestas de diseño, realizar pruebas de usuario y obtener retroalimentación.
En el contexto del desarrollo de software, un mockup puede es una representación estática de una página web o aplicación que muestra la disposición de los elementos de la interfaz de usuario, como botones, menús, barras de navegación, formularios, etc. Los mockups pueden ser de baja fidelidad (bocetos a mano o diagramas simples) o de alta fidelidad (representaciones detalladas que se asemejan al producto final).
Los mockups son una herramienta valiosa para los diseñadores y desarrolladores, ya que permiten visualizar cómo se verá y funcionará el producto final, facilitando la detección de problemas y la realización de cambios antes de que el desarrollo esté muy avanzado.
Implementar una plataforma de pagos como PSE (Pagos Seguros en Línea) implica una serie de pasos técnicos y regulatorios. Aquí te proporciono una descripción general de alto nivel de cómo se podría hacer esto:
-
Cumplimiento normativo: Antes de comenzar a desarrollar la plataforma, es importante entender y cumplir con todas las regulaciones financieras y de privacidad de datos aplicables en tu país. Esto puede incluir obtener licencias o permisos, cumplir con las normas de seguridad de datos y tener políticas claras de privacidad y uso.
-
Asociación con bancos y otras instituciones financieras: Para poder procesar pagos, necesitarás establecer relaciones con bancos y otras instituciones financieras. Esto puede implicar la negociación de tarifas, la configuración de cuentas comerciales y la integración con sus sistemas de pago.
-
Desarrollo de la plataforma: La plataforma de pagos necesitará una interfaz de usuario segura y fácil de usar, así como una robusta infraestructura de back-end para procesar las transacciones, manejar errores, emitir reembolsos, etc. Esto requerirá un equipo de desarrollo de software con experiencia en el desarrollo de aplicaciones financieras seguras.
-
Integración de la pasarela de pago: La plataforma necesitará integrarse con una pasarela de pago que pueda manejar el procesamiento de las transacciones de pago. Esto puede implicar la integración con múltiples pasarelas de pago para soportar diferentes métodos de pago.
-
Pruebas y seguridad: Antes de lanzar la plataforma, es crucial realizar pruebas exhaustivas para asegurarse de que funciona correctamente y de que es segura. Esto puede implicar pruebas de penetración, pruebas de carga y pruebas de usabilidad.
-
Lanzamiento y soporte: Una vez que la plataforma esté lista, puedes lanzarla al público. Sin embargo, el trabajo no se detiene ahí. Necesitarás proporcionar soporte al cliente, manejar disputas de pago y mantener y actualizar la plataforma de forma regular.
Este diagrama muestra los siguientes pasos:
- El usuario inicia una transacción en la plataforma de pagos.
- La plataforma de pagos solicita al usuario los detalles del pago.
- El usuario proporciona los detalles del pago a la plataforma.
- La plataforma envía una solicitud de pago a la pasarela de pago.
- La pasarela de pago solicita la autorización del pago al banco.
- El banco proporciona el estado de la autorización a la pasarela de pago.
- La pasarela de pago envía el estado de la autorización a la plataforma de pagos.
- La plataforma de pagos proporciona el estado de la transacción al usuario.
Este proyecto está bajo la licencia MIT.