stau.space
AECC database project.
docs: Update README.md
+73
-37
+73
-37
README.md
+73
-37
README.md
···
4
4
5
5
Este sistema organiza la informacion relacionada a las transacciones de la
6
6
Asociacion de Estudiantes de Ciencia de Computos (AECC) de la Universidad de
7
-
Puerto Rico, Recinto de Rio Piedras. Este sistema tiene 5 tipos de datos
7
+
Puerto Rico, Recinto de Rio Piedras. Este sistema tiene 4 tipos de datos
8
8
fundamentales para su uso:
9
9
- productos
10
10
- transacciones
11
11
- miembros de la AECC
12
-
- miembros de directiva
13
12
- actividades hechas por la AECC
14
13
14
+
Un concepto implicito con el uso de este sistema es que todas estas
15
+
transacciones ocurren desde la perspectiva de la cuenta de banco de la AECC.
16
+
Entonces, por ejemplo, una transaccion registrada como debito, es un gasto de
17
+
dinero por parte de la AECC.
18
+
15
19
### Productos
16
20
17
-
Un producto es una entidad de
21
+
Un producto es una entidad que tiene un costo, en centavos USD, y una
22
+
descripcion. Por ejemplo, un producto podria ser: la membresia de la AECC,
23
+
tendra un costo de 500 centavos y descripcion como "Membresia anual de la AECC."
24
+
25
+
### Transacciones
26
+
27
+
Una transaccion tiene 3 partes importantes:
28
+
- el iniciador de la transaccion
29
+
- el registrador de la transaccion
30
+
- la metadata de la transaccion
31
+
32
+
#### Iniciador
33
+
34
+
El iniciador es la persona que inicie la compra o adquiere el producto. Con el
35
+
sistema actual, el iniciador tiene que ser miembro de la AECC. Esto se puede
36
+
resolver creando un miembro "dummy" para registrar transacciones con entidades
37
+
que no sean miembros de la AECC.
38
+
39
+
#### Registrador
40
+
41
+
El registrador es la persona que monitorea la compra. Este tiene la
42
+
responsabilidad de verificar que el monto de ingreso o de gasto de la cuenta de
43
+
la AECC sea pagado por completo. Es por esto que se requiere que esta persona
44
+
sea miembro de la directiva de la AECC, sin excepciones. Ademas, se esta
45
+
contemplando restringir los registradores de compra a solo:
46
+
- Tesorero
47
+
- Vice-presidente
48
+
- Presidente
49
+
50
+
#### Metadata
51
+
52
+
En la metadata de la transaccion hay informacion como:
53
+
- el producto
54
+
- la cantidad que se compro
55
+
- si la transaccion fue un gasto o un ingreso
56
+
57
+
### Miembro de la AECC
58
+
59
+
Un miembro de la AECC puede verificar el estado de su cuenta, si esta activa o
60
+
no simplemente visitando el area de "Members" de la pagina de inicio. Alli,
61
+
tambien se pueden crear miembros nuevos. En el futuro, la AECC piensa tener esta
62
+
area publica para que miembros de la AECC puedan verificar si tienen que pagar
63
+
la subscripcion o no. Ademas, la AECC piensa implementar una manera de "log-in",
64
+
que manejaria quienes tienen permiso para crear cuentas nuevas. Implicitamente,
65
+
se registra una compra cada vez que se crea una cuenta nueva, por lo tanto, esto
66
+
va a ser monitoreado por un integrante de la directiva de la AECC.
67
+
68
+
### Actividades de la AECC
69
+
70
+
En el area de "Activities" en la pagina de inicio se pueden ver las actividades
71
+
que la AECC ha hecho. En el futuro, pensamos tener un area de
72
+
"activity-transactions" que nos deja ver todas las transacciones asociadas a una
73
+
actividad. Esto nos seria muy util para encontrar cuanto se gasta o gana por
74
+
actividad.
18
75
19
76
## Proposito del sistema
20
77
21
78
Anterior a la implementacion de este sistema, la AECC mantenia los records de
22
-
transacciones a mano. Esto es
79
+
transacciones a mano y por google sheets. Esto no es muy eficiente y es muy
80
+
tedioso. Ademas, como estudiantes de ciencia de computos, tenemos el
81
+
conocimiento para resolver un problema justo como este.
23
82
24
83
3. Alcance del sistema
25
84
26
-
# Sistema actual (si fuera el caso)
85
+
### Sistema actual (si fuera el caso)
27
86
28
-
# Requisitos
87
+
- No hay un sistema actual.
88
+
89
+
### Requisitos
29
90
1. Funcionales
30
-
- los requisitos funcionales describen la funcionalidad del sistema.
31
-
Un ejemplo puede ser, el sistema debe presentar el orario de clase del
32
-
estudiante.
91
+
- El sistema debe crear, editar y borrar las transacciones de la AECC.
92
+
- El sistema debe calcular cuando un usuario debe pagar la membresia.
33
93
2. No funcionales
34
-
- Usabilidad
35
-
- Fiabilidad
94
+
- El sistema debe ser facil de usar, ya que ese es uno de los problemas que
95
+
encontramos con google sheets.
96
+
- El sitema debe manejar la data de manera segura.
36
97
- Rendimiento
37
98
38
99
## API Endpoints
39
100
40
-
### Create a resource in the database
101
+
### /api/v1/create/
41
102
42
103
```txt
43
104
https://ada.uprrp.edu/~diego.estrada1/CCOM/4027/db/api/v1/create/
···
117
178
- [6]: Como esta pagina es un "single page application", este request se ve
118
179
mejor por `POST` para no afectar el URL de la pagina. Sin embargo, deberia
119
180
ser por `GET`.
120
-
121
-
---
122
-
123
-
Entrega hasta aqu'i
124
-
125
-
---
126
-
127
-
3. Restricciones organizacionales al dise~no
128
-
- Asuntos legales
129
-
130
-
# Refencias
131
-
132
-
# Glosario
133
-
134
-
# Proyecto
135
-
136
-
1. Entrevistar a las personas encargadas para entender la tarea y definir requisitos.
137
-
Al completar la entrevista deben tener toda la informaci'on necesaria para poder hacer los diagramas.
138
-
2. Crear el diagrama de la base de datos y dise~nar la base de datos.
139
-
La base de datos debe tener **al menos** tres entidades y dos relaciones.
140
-
3. Crear el diagrama de flujo de la informaci'on y diagrama de la interfaz (wire frame).
141
-
La interfaz debe tener **al menos** tres p'aginas (views), uno que presente la aplicaci'on y de instrucciones, uno que requiera la manipulacion de datos en la base de datos y uno que muestre datos seleccionados de la base de datos (`select`).
142
-
La p'agina que manipula datos debe poder hacer `insert`, `update` y `delete`.
143
-
4. Crear las tablas con SQL en el sistema MySQL.
144
-
5. Desarrollar la interfaz usando `html` y `php`.