-
Notifications
You must be signed in to change notification settings - Fork 0
/
Chapter3.tex
310 lines (244 loc) · 16.8 KB
/
Chapter3.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
\chapter{Diseño y modelado}
\section{Arquitectura}
ALTEM es una aplicación web de Stack Completo la cual está compuesta por las siguientes tecnologías
\begin{itemize}
\item Front-End: Javascript ES5 con AngularJS 1.6
\item BackE-End: PHP 7.1 con Laravel.
\item Bases de Datos: SQL por MySQL.
\end{itemize}
Su API también se comunica con otros sistemas que pertenecen a la universidad, tales como
\begin{itemize}
\item LDAP (Actualmente Deprecado)
\item SAVIO (Moodle)
\item Banner (Oracle)
\end{itemize}
En la Figura 3.1 Se puede apreciar la Arquitectura de ALTEM y la relacion existente entre cada uno de los elementos del stack y las APIs externas.
\begin{figure}[H]
\centering
\includegraphics[width=0.7\textwidth]{img/ALTEM.png}
\caption{Arquitectura de ALTEM}
\end{figure}
\subsection{Cliente (Front-End)}
Al ser una aplicacion web, ALTEM se consume desde el navegador, por medio de un Front-End creado en HTML5, CSS y JavaScript.
La capa de JavaScript está manejada por AngularJS 1.6, el cual nos facilita el desarrollo de las funcionalidades utilizando el patrón MVC el cual es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de su representación, y el módulo encargado de gestionar los eventos y las comunicaciones.
MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario.\cite{trygve}
La aplicación web está compuesta por varios módulos, cada uno con sus modelos, vistas y controladores.
Los módulos son los siguientes:
\begin{itemize}
\item Acción
\item Estrategia
\item Filtros
\item Login
\item Reportes
\item Riesgos
\item Tipos de Riesgos
\item Usuarios
\end{itemize}
\subsubsection{Modelo}
Para el caso del cliente web, nuestro modelo equivale a todos los datos que vienen desde la API y que se solicitan por medio de peticiones HTTP. Estos datos se guardan en el localStorage y sessionStorage, y representan toda la información que el usuario puede ver a través de la vista en tiempo real.
Estas solicitudes a la API se encuentran organizadas en Servicios\cite{servicios} los cuales ejecutan llamadas a distintos endpoints\cite{endpoints}.
\begin{itemize}
\item Acción
\item Archivo Personal
\item Criterio
\item Estrategia
\item Estudiante
\item Filtro
\item Intervención
\item Login
\item Observación
\item Reporte
\item Riesgo
\item Tipo Riesgo
\item Usuario
\end{itemize}
Estos servicios se comunican con el Back-End a trvés de la API de XMLHttpRequest(XHR) y utilizando métodos HTTP.
El Modelo es modificado por los Controladores, los cuales actualizan el estado de los datos dependiendo de las interacciones que tenga la aplicación con el usuario.
\subsubsection{Controlador}
Los controladores son funciones que disparan las instrucciones que modifican el Modelo, generalmente llamadas en la vista a través de eventos y en los servicios a través de Promesas.
En la aplicación web, todas las acciones (iniciar sesión, ver estudiantes, añadir estrategias, filtrar búsquedas, etc) disparan estos controladores, estos controladores se encuentran categorizados por los módulos mencionados en 1.1.
Las funciones principales de los controladores en la aplicación web son los siguientes:
\begin{itemize}
\item Mutar el estado local de la aplicación.
\item Hacer llamadas a los servicios.
\item Actualizar la Vista.
\end{itemize}
Por lo general, las acciones ejecutadas en los controladores hacen que la vista se refresque.
\subsubsection{Vista}
La Vista se concibe como la capa presentacional de la aplicación web. Es la parte que interactúa con el usuario directamente y es la que se encarga de renderizar todos los datos del modelo en una manera que el usuario puede comprender fácilmente.
Las vistas están hechas a través de plantillas HTML5 estilizadas con CSS, las cuales se renderizan de forma dinámica a medida que el modelo de la aplicación se actualice y se vayan ejecutando eventos que disparen los controladores.
La vista también se actualiza por medio de las directivas de AngularJS.
\subsection{Servidor (Back-End)}
El Back-End es el núcleo de ALTEM, consiste en una app Laravel y PHP7 en la que se encuentra toda la lógica del servidor.
Al igual que el Front-End, esta aplicación comparte la misma arquitectura MVC, pero orientada al lado del servidor.
También, se encarga de comunicarse con API's de terceros como BANNER y SAVIO, plataformas pertenecientes a los recursos tecnológicos de la Universidad Tecnológica de Bolívar para obtener datos esenciales para su funcionamiento, de los cuales hablaremos más adelante.
\subsubsection{Modelo}
Para nuestro Back-End, el Modelo es una representación de la estructura de los datos y relaciones que se manejan base de datos, en clases y objetos que comparten la misma estructura. Esto con el propósito de que se maneje una consistencia entre la base de datos y la API.
Para hacer esa integración posible, se utiliza una API llamada Eloquent, la cual nos permite construir y ejecutar consultas a la base de datos utilizando definiciones y métodos propios del lenguaje. Esto también se conoce como ORM.
Para cada tabla existente en la base de datos, existe un modelo correspondiente en el back-end el cual se representa mediante una Clase como lo muestra el siguiente ejemplo:
\begin{lstlisting}
namespace App\Models;
class Tabla extends Model
{
protected $table = 'nombre_tabla';
// columnas de la tabla
protected $fillable = ['columna1', 'columna2', 'columna3'];
//PK
protected $primaryKey= "codigo";
// Relaciones
public function relacion1()
{
// Ejemplo 1:N
return $this->belongsToMany('OtroModelo','FK','FK','FK');
}
public function relacion2(){
// Ejemplo 1:1
return $this->hasOne('OtroModelo','FK','FK');
}
}
\end{lstlisting}
Esta clase extiende de Model, la cual es una clase implementada por Laravel para manejar las relaciones entre tablas. Esa clase posee varios metodos como los observados previamente.
\subsubsection{Controlador}
En el caso del Back-End, los controladores son clases que poseen los métodos que ejecutan la lógica de la aplicación y hacen los cambios en la base de datos al llamar a los Modelos
Una clase controladora se compone de la siguiente manera:
\begin{lstlisting}
namespace App\Http\Controllers;
// importamos Modelo relacionado con el controlador
use \Models\Tabla;
class Acciones extends Controller
{
public function __construct()
{
// Usamos middlewares necesarios
$this->middleware('cors');
}
public function obtener_todos()
{
$datos = Tabla::all();
return response()->json($datos);
}
public function obtener_por_codigo($codigo)
{
$datos_codigo = Tabla::find($codigo);
return response()->json($datos_codigo);
}
public function eliminar_por_codigo($id)
{
$datos_de_id = Tabla::find($id);
$datos_de_id->delete();
return response()->json(["mensaje" => "Eliminado con Exito"]);
}
}
\end{lstlisting}
En este ejemplo, podemos observar como la la clase Acciones posee varios métodos que llaman a Modelo y ejecutan varios métodos sobre este. Estos métodos representan consultas SQL que modifican los datos en la base de datos.
Al final de las instrucciones, se retornan los datos solicitados o el mensaje por medio de JSON.
\subsubsection{Vista}
Al ser una API, en este caso la vista no representa ninguna capa de interacción con el usuario sino más bien un conjunto de rutas o endpoints los cuales son consultados mediante HTTP y que son el puente entre el Back-End y el Front-End.
\subsection{Bases de Datos}
ALTEM se alimenta de 2 bases de datos \textbf{ALTEM} y \textbf{SIRIUS}
Las bases de datos de ALTEM son de tipo SQL, ejecutadas en el motor MySQL X, todas las consultas son manejadas por el ORM del Back-End
\subsubsection{ALTEM DB}
En esta base de datos se guarda toda la información relacionada a los procedimientos que se le hacen a los estudiantes que se encuentren en una situación de riesgo.
Al ser una base de datos Relacional, fue necesario establecer un conjunto de relaciones entre tablas para mantener la consistencia y confiabilidad en los datos utilizados en la aplicación, como se aprecia en la Figura 3.2.
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{img/EER.png}
\caption{Relación de entidades en la base de datos de ALTEM.}
\end{figure}
\subsubsection{SIRIUS DB}
SIRIUS es una base de datos que se creó como una copia de los registros estudiantiles en SIRIUS (Ahora BANNER), esta base de datos se sincronizaba por medio de un script que leía los datos en SIRIUS e importaba todo hacia esta base de datos.
Actualmente, SIRIUS evolucionó a BANNER y algunas tablas cambiaron, como por ejemplo la tabla de ESTUDIANTEs y DATOS\_ACADEMICOS, en las que cambió la collation, el tamaño de los datos de algunas columas y los nombres de algunas columnas también.
\section{Plan de trabajo}
\subsection{Reunión con Consejeros}
Se realizó una reunión con los consejeros de bienestar universitario y se concluyó en que ALTEM debía ser intervenido para que su funcionamiento volviese a la normalidad, se plantearon un conjunto de mejoras las cuales pasaron a ser nuevos requerimientos para la aplicación.
De acuerdo a los análisis realizados en ALTEM para determinar su estado funcional y de implementación, se concluyó que la aplicación podría mejorarse si se cumplen estos nuevos requerimientos y se solucionan las fallas que impiden actualmente su funcionamiento.
\subsection{Identificación de las Fallas Críticas}
Se realizó una revisión de ALTEM en el entorno de producción, el cuál se encontraba en estado de abandono y desuso por parte de los consejeros debido a que manifestaron que el sistema se había vuelto imposible de usar debido a fallas en su funcionamiento.
En esta revisión inicial se identificaron estas fallas:
\begin{itemize}
\item No se podía acceder a la plataforma debido a problemas con la autenticación.
\item No se podían crear nuevos registros debido a que el servidor no tenía almacenamiento.
\item No se podía obtener información estudiantil debido a que no había conexión con SIRIUS (Ahora BANNER).
\end{itemize}
Estas fallas hicieron que la aplicación dejara de funcionar en su totalidad, ya que afectaron componentes esenciales de su arquitectura.
\subsection{Definición de Requerimientos}
Luego de analizar las peticiones de los consejeros y de encontrar todas las fallas en la aplicación, se desarrollaron los siguientes requerimientos:
\begin{itemize}
\item Conectar, consumir y sincronizar los datos académicos y estudiantiles de ALTEM con el nuevo sistema BANNER.
\item Hacer mejoras en las interfaz de usuario ya que no es posible determinar cuando un elemento está cargando.
\item Analizar las falencias en la experiencia de usuario y hacer mejoras en ese aspecto.
\item Resolver las fallas (bugs) presentes en la aplicación.
\item Hacer refactorización de los módulos que presentan problemas de calidad de código y arquitectura.
\item Implementar los nuevos requerimientos solicitados el personal de consejería académica
\end{itemize}
\subsection{Plan de Desarrollo}
Se decidió implementar la metodología Ágil \textbf{SCRUM} como estrategia para llevar a cabo el plan de trabajo.
Se agruparon todas requisitos en \textbf{Epics}, \textbf{Historias de Usuario}, y \textbf{Tareas}, las cuales se ejecutaron de la siguiente manera:
\begin{table}[H]
\centering
\begin{tabular}{ |p{3cm}|p{3cm}|p{3cm}|p{3cm}| }
\hline
\multicolumn{4}{|c|}{Plan de trabajo SCRUM} \\
\hline
Por Hacer & En Progreso & En QA & Terminado\\
\hline
Todas las Tareas pendientes de su realización. & Todas las tareas que se encuentran en progreso (una a la vez). & Todas las tareas que se encuentran en estado de Aseguramiento de la Calidad, agrupadas por historias de usuario o Epic. & Todas las tareas desplegadas en Producción. \\
\hline
\end{tabular}
\label{Plan de trabajo SCRUM}
\caption{Dashboard empleada para llevar control de las tareas.}
\end{table}
\subsubsection{Epics}
Todas las tareas e Historias de Usuario se agruparon en tres Epics principales, los cuales se diferencian por prioridad, ya que fue necesario resolver las tareas e historias de usuario de un Epic prioritario para poder continuar con el trabajo.
Los Epics creados, en orden de prioridad, fueron los siguientes:
\begin{itemize}
\item \textbf{E1} - Adaptación a APIs Externas.
\item \textbf{E2} - Requisitos de Consejería.
\item \textbf{E3} - Mejoras de UI/UX.
\end{itemize}
\subsubsection{Historias de Usuario y Tareas}
Luego de analizar los requerimientos y las recomendaciones planteadas por los consejeros se desarrollaron las siguientes Historias de Usuario las cuales representan las nuevas funcionalidades a implementar. A cada Historia de Usuario se le asigna un Epic relacionado y dentro de ella se determinan las tareas específicas para que esa historia se cumpla.
\begin{itemize}
\item \textbf{Como consejero debo poder iniciar sesión en ALTEM con mis credenciales de SAVIO. (E1)}
\begin{itemize}
\item Usar SAVIO en vez de LDAP para validar las credenciales del usuario.
\item Obtener Datos del usuario en sesión por medio del token de SAVIO.
\end{itemize}
\item \textbf{Como consejero debo poder ver los datos estudiantiles que me provee BANNER. (E1)}
\begin{itemize}
\item Back-End: Identificar cuál es la falla entre la sincronización ALTEM y BANNER.
\item Externo: Solicitar al personal de TI de la UTB acceso a BANNER en caso de ser necesario.
\item Infraestructura: Desarrollar una herramienta que permita importar los datos de BANNER a SAVIO y mantenerlos sincronizados
\item Infraestructura: Programar el sincronizador para que se ejecute de forma automática semanalmente.
\end{itemize}
\item \textbf{Como consejero debo poder descargar un reporte de mis casos activos en MS EXCEL. (E2)}
\begin{itemize}
\item Front-End: Desarrollar una función en la aplicación que convierta las tablas HTML en tablas de EXCEL y las descargue.
\end{itemize}
\item \textbf{Como consejero deseo ver el periodo en el que se presentó algún tipo de riesgo en el estudiante. (E2, E3)}.
\begin{itemize}
\item Front-End: Determinar el período académico a partir de la fecha de creación del riesgo y mostrarlo como una etiqueta.
\end{itemize}
\item \textbf{Como consejero deseo poder añadir anotaciones a los estudiantes. (E2)}
\begin{itemize}
\item Front-End: Crear un componente de anotaciones en el panel de detalles del estudiante.
\item Back-End: Crear una tabla y un endpoint que consulte y guarde las anotaciones de cada estudiante.
\end{itemize}
\item \textbf{Como administrador deseo gestionar qué cuáles usuarios de SAVIO pueden acceder a la aplicación. (E3)}
\begin{itemize}
\item Front-End: Crear una pagina que muestre los usuarios y permita hacer CRUD.
\item Back-End: Crear un endpoint para manipular la tabla de usuarios y hacer CRUD.
\end{itemize}
\item \textbf{Como usuario del sistema me gustaría saber cuándo está cargando una solicitud. (E3)}
\begin{itemize}
\item Front-End: Mostrar animaciones de carga siempre que exista una solicitud a la API en proceso.
\end{itemize}
\end{itemize}
\subsection{Aseguramiento de la Calidad (QA)}
El proceso de Aseguramiento de la Calidad y se realizó por medio de la creación de un entorno de pruebas idéntico al de desarrollo pero utilizando una copia de la base de datos de producción en un estado estable.
\subsubsection{Pruebas Individuales}
Se procedió a probar las funcionalidades requeridas por cada una de las historias de usuario de forma independiente,
una vez que las tareas relacionadas a ellas se encontraran completadas y los cambios integrados al entorno de pruebas.
Estas pruebas consistían en realizar evaluaciones de las funcionalidades ingresando valores o tipos de datos que podrían corromper su funcionamiento y ejecutar casos de uso aislados o poco comunes, al mismo tiempo que se analizaba el comportamiento de la funcionalidad y su rendimiento.
\subsubsection{Pruebas de Regresión}
Cuando todas las pruebas de las historias de usuario correspondientes a un mismo Epic fueron completadas, se procedía a probar el funcionamiento general de la aplicación con el fin de asegurarse de que no se hayan introducido regresiones o fallas en otros componentes, esta prueba es muy importante porque es la que nos asegura la estabilidad a nivel general de la aplicación.