sistema colaborativo para seguimiento académico de alumnos
TRANSCRIPT
Sistema colaborativo para seguimientoacadémico de alumnos integrados.
Trabajo Final
Ingeniería de Sistemas
Facultad de Ciencias Exactas UNCPBA
Mayo 2018
Alejandra Tamara Ferenc
ALUMNA
Dr. Cristian García Bauza
DIRECTOR
Ing. Carolina Valdez Gándara
CO-DIRECTORA
1
IndiceCapítulo 1: Introducción................................................................................................................................... 51.1 Motivación.................................................................................................................................................. 71.2 Objetivo.......................................................................................................................................................81.3 Organización del documento...................................................................................................................... 8Capítulo 2: Marco teórico............................................................................................................................... 102.1 Discapacidad y educación.........................................................................................................................102.2 Problemáticas a resolver........................................................................................................................... 122.3 Necesidad del sistema a implementar.......................................................................................................122.4 Aporte de las tecnologías utilizadas para la implementación...................................................................14Capítulo 3: Diseño e implementación.............................................................................................................163.1 Introducción.............................................................................................................................................. 163.2 Yii como framework................................................................................................................................. 163.3 Metodología usada para el desarrollo.......................................................................................................173.4 Desarrollo de la aplicación........................................................................................................................223.4.1 Módulo Modelo: Introducción...............................................................................................................243.4.2 Módulo Modelo: Desarrollo de la funcionalidad Historia académica.................................................. 243.4.4 Módulo Modelo: Comunicación entre profesores.................................................................................313.4.5 Módulo Modelo: Interacción de los usuarios con el sistema - Notificaciones .....................................413.4.6 Módulo Modelo: Resumen.................................................................................................................... 433.4.7 Módulo Controlador: Introducción........................................................................................................443.4.8 Módulo Controlador: Ejemplo del controlador Historia académica ..................................................... 463.4.9 Módulo Vista: Introducción................................................................................................................... 483.4.10 Módulo vista: Ejemplo de la vista Historia Académica...................................................................... 493.4.11 Módulo vista: Ejemplo de la vista inicio del Profesor .........................................................................503.5 Resumen del capítulo................................................................................................................................51Capítulo 4: Implantación.................................................................................................................................534.1 Introducción.............................................................................................................................................. 534.2 Yii Bootstrap............................................................................................................................................. 534.3 Vista de ingreso al sistema........................................................................................................................534.4 Vista Inicio: eventos y notificaciones....................................................................................................... 554.5 Vista de los alumnos asociados al profesor.............................................................................................. 584.6 Comunicación entre profesores: Vista de mensajes privados...................................................................614.7 Comunicación entre profesores: Vista foro.............................................................................................. 644.8 Comunicación entre profesores: Vista agenda..........................................................................................674.9 Vistas de administrador.............................................................................................................................694.10 Vista del profesor administrador: Profesores..........................................................................................704.11 Vista del profesor administrador: Alumnos............................................................................................ 724.12 Vista del profesor administrador: Instituciones...................................................................................... 734.13 Resumen del capítulo..............................................................................................................................75Capítulo 5: Conclusiones y trabajos futuros...................................................................................................775.1 Conclusiones............................................................................................................................................. 775.2 Trabajos futuros.........................................................................................................................................77ANEXO...........................................................................................................................................................79A.1 Introducción............................................................................................................................................. 79A.2 Uso de Yii.................................................................................................................................................79A.3 Uso de Gii.................................................................................................................................................81Referencias......................................................................................................................................................85
2
Indice de ImágenesTabla 2.1 - Compración entre educacion especial y NEE...............................................................................11Tabla 2.2 – Comparación de frameworks PHP...............................................................................................14Prototipo 3.1 – Primer prototipo vista Historia Académica............................................................................18Prototipo 3.2 – Segundo prototipo Historia Académica .................................................................................19Prototipo 3.3 – Intervención de los usuarios en los prototipos .......................................................................20Figura 3.1 – Encuesta para captura de requerimientos...................................................................................21Figura 3.2 – Etapas de desarrollo....................................................................................................................22Figura 3.3 – Modelo-Vista-Controlador......................................................................................................... 23Figura 3.4 – Diagrama de clases para la funcionalidad Historia Académica.................................................26Código 3.1 – Método relations para la funcionalidad Historia Académica....................................................27Código 3.2 - Método relations para la clase Profesor.....................................................................................27Código 3.3 – Validaciones para los atributos de Historia Académica............................................................28Figura 3.5 – Relación entre las clases Profesor, Alumno y Escuela...............................................................30Código 3.4 – Método relations para la clase ProfAlumEsc............................................................................31Figura 3.6 – Relación entre las clases para la funcionalidad el Foro............................................................. 33Código 3.5 – Métodos de la clase MsjForo.................................................................................................... 34Código 3.6 – Método relations de la clase RtaForo........................................................................................34Código 3.7 -Método rules de la clase RtaForo............................................................................................... 35Figura 3.7 – Clases para el intercambio de mensajes privados...................................................................... 37Código 3.8 – Método relations para la clase MensajeRta.............................................................................. 38Figura 3.8 – Relación entre clases para módulo Agenda................................................................................39Código 3.9 – Método relations para la clase Agenda..................................................................................... 40Figura 3.9 – Clases involucradas en las Notificaciones................................................................................. 42Figura 3.10 – Diagrama de los modulos de la aplicacion...............................................................................44Figura 3.11 – Diagrama de secuencia para creación de una Historia Académica..........................................47Código 3.10 – Creación de notificación......................................................................................................... 48Figura 3.11 – Configuración de Bootstrap......................................................................................................49Prototipo 3.4 – Prototipo final Historia Académica........................................................................................50Prototipo 3.5 – Prototipo vista inicial del profesor .........................................................................................51Pantalla 4.1 - Login.........................................................................................................................................54Código 4.1 – Metodo Login............................................................................................................................55Pantalla 4.2 – Vista de eventos públicos.........................................................................................................56Pantalla 4.3 – Vista notificaciones..................................................................................................................57Código 4.2 – Menú de la aplicación............................................................................................................... 58Prototipo 4.1 – Pantalla de listado de Alumnos..............................................................................................59Pantalla 4.4 – Vista de la lista de Alumnos.....................................................................................................59Pantalla 4.5 – Pantalla de perfil de alumno.................................................................................................... 60Código 4.3 – Ejemplo widget......................................................................................................................... 61Prototipo 4.2 – Prototipo de intercambio de mensajes privados .................................................................... 62Pantalla 4.6 – Vista de mensajes privados...................................................................................................... 62Pantalla 4.7 – Vista de mensajes privados-2...................................................................................................63Pantalla 4.8 – Vista Foro.................................................................................................................................64Pantalla 4.9 – Vista nuevo mensaje en el Foro............................................................................................... 65Pantalla 4.10 – Vista ver mensaje Foro...........................................................................................................66Prototipo 4.3 – Pantalla para ver mensajes del Foro...................................................................................... 66Pantalla 4.11 – Vista creación de evento en la agenda................................................................................... 67Pantalla 4.12 – Vista de invitación de profesores al evento........................................................................... 68Pantalla 4.13 – Vista de la agenda...................................................................................................................68Pantalla 4.14 – Vista de relación entre alumnos, profesores y escuelas.........................................................69Pantalla 4.15 – Vista para agregar una relación al sistema.............................................................................70Pantalla 4.16 – Vista de profesores registrados en el sistema........................................................................ 71Código 4.4 – Método Admin para la vista de profesores............................................................................... 71Código 4.5 – Método busqueda de profesores en la base de datos ................................................................ 72
3
Pantalla 4.17 - Vista de alumnos registrados en el sistema............................................................................ 73Pantalla 4.18 -Vista de instituciones registradas en el sistema.......................................................................74Pantalla 4.19 – Vista de creación de institución............................................................................................. 74Código 4.6 – Método create para una institución...........................................................................................75Figura A.1 – Pasos para crear el ambiente de desarrollo................................................................................79Código A.1 – Configuración de la base de datos............................................................................................80Figura A.2 – Creación de la base de datos......................................................................................................81Código A.2 – Configuración de Gii................................................................................................................81Figura A.3 – Uso de Gii.................................................................................................................................. 82Figura A.4 – Creación de clases en Gii...........................................................................................................83Figura A.5 - Creación de clases en Gii - 2......................................................................................................83
4
Capítulo 1: Introducción
Tiempo atrás, las personas con discapacitadas no tenían la posibilidad de
asistir a escuelas comunes, sino que realizaban sus aprendizajes en las escuelas
especiales solamente. En términos generales, nos referimos a niños con alguna
deficiencia física o sensorial a quienes en comparación con sus compañeros de la
misma edad, tienen graves problemas en el aprendizaje, la comunicación o la
conducta, lo que les dificulta la participación en el sistema educativo común.
Con el paso del tiempo y el interés de organismos internacionales, la
integración de alumnos con discapacitados a las escuelas comunes pasó a ser un
tema de discusión primordial en la sociedad, al punto de que alumnos integrados
llegaron a las aulas de las escuelas comunes.
Como consecuencia de la llegada de personas con discapacidad a las
escuelas y buscando encontrar respuestas a aquellos interrogantes que surgían en
relación a esta situación, Mary Warnock[1] planteó en su informe la eliminación de la
idea de “ineducabilidad” y el principio de integración en el ámbito escolar,
introduciendo por primera vez el término Necesidades Educativas Especiales (NEE).
Este concepto constituyó una definición pedagógica que hacía foco en el currículum
y en las dificultades de aprendizaje que podía presentar cualquier alumno, y no en
los diagnósticos médicos y/o psicológicos[2].
Las escuelas ordinarias con esta orientación integradora representan el
medio más eficaz para combatir las actitudes discriminatorias, crear comunidades
de acogida, construir una sociedad integradora y lograr la educación para todos[3];
además, proporcionan una educación efectiva a la mayoría de los niños y mejoran la
eficiencia y, en definitiva, la relación costo-eficacia de todo el sistema educativo.
Con la integración de alumnos a las escuelas regulares se busca que el
sistema educativo reciba y ofrezca una educación de calidad a todos los niños,
niñas y jóvenes, sin discriminaciones de ningún tipo, intentando contribuir a hacer
efectivo el derecho de los alumnos y alumnas con discapacidad a participar y
educarse con igualdad de oportunidades en el sistema regular de educación.
Además, esta convivencia dentro del ámbito educativo ayuda a que las nuevas
5
generaciones aprendan desde temprana edad a relacionarse y respetar las
diferencias como factor de enriquecimiento y desarrollo personal.[4]
La educación inclusiva requiere escuelas que eduquen a todos dentro de un
único sistema educativo, proporcionándoles programas educativos apropiados que
sean estimulantes y adecuados a sus capacidades y necesidades. La escuela debe
ser un lugar al que todos pertenecen, donde son aceptados y apoyados para
aprender. Esto se logra con una cultura de colaboración, que implica un trabajo en
conjunto de forma colectiva y continua.
Durante los últimos treinta años, además del aumento de profesorado
especialista, se ha producido también un incremento progresivo de profesionales en
los centros educativos, bien de forma estable, bien mediante colaboraciones
circunstanciales con profesionales del ámbito comunitario o local. Esta situación
conlleva un aumento de la complejidad de la función docente y mayores exigencias
de coordinación y trabajo en equipo.
En la perspectiva de la educación inclusiva, podemos diferenciar dos
ámbitos: al interior de la escuela especial, como apoyo a los alumnos; y por otro
lado profesores que tengan alumnos integrados en sus aulas, entregando una
asesoría pedagógica más general (metodologías educativas, evaluación
diferenciada, etc.). Es importante la comunicación fluida entre ambas en cuanto a
apoyos pedagógicos, actividades compartidas y reflexión sobre los niños. La
posibilidad de una comunicación fluida entre ambas escuelas condice con lo
postulado en la Ley Nacional de Educación en relación con el desarrollo de
proyectos que permitan compartir espacios curriculares entre los alumnos de las
escuelas de educación común y escuelas especiales y el fomento por parte de las
escuelas a la participación y el intercambio con instituciones locales.
En relación a lo anterior, las formas de comunicación y trabajo entre el
maestro de grado y el maestro integrador, recuperador o profesional de apoyo, son
fundantes de modalidades que promuevan o no la inclusión educativa. Involucrarse,
seguir la historia de cada niño, conocer para poder intervenir mejor,
responsabilizarse por el otro, ser flexible y atento, el sostener un proyecto
colectivamente, son todas prácticas fundamentales para promover la inclusión en el
6
ámbito educativo. En el trabajo colectivo, el alumno ‘es de todos’, la responsabilidad
es conjunta, los niños son de la escuela y el equipo docente es referente de todos.
El diseño de un proyecto de integración debería implicar la labor del docente
especial como conocedor de los procesos cognitivos del alumno integrado, junto con
el maestro de escuela común. Los acuerdos entre ambos docentes permiten
articular la programación general del aula con las necesidades educativas
especiales de los alumnos[5].
Dentro de las problemáticas actuales encontramos la falta de comunicación
formal entre los maestros de las escuelas especiales y los profesores de la escuela
a la cual asisten los alumnos integrados. Actualmente, debido al avance tecnológico,
se utiliza a menudo la comunicación informal, por ejemplo grupos de Whatsapp o
Facebook. Esto genera que información importante se pierda, ya que no queda un
registro formal de la misma e incluso se maneja información sensible y privada de
los alumnos de forma pública. Además, no se lleva un registro de los avances
académicos de los alumnos, ni de las técnicas de aprendizaje que resultaron
efectivas con cada uno, por lo que mientras el alumno transita su paso por la
escuela, información relevante a la enseñanza se pierde por la falta de transferencia
de conocimiento entre los profesores.
1.1 Motivación
De acuerdo con la Organización Mundial de la Salud (OMS), se estima que
alrededor del 15% de la población mundial experimenta alguna forma de
discapacidad o impedimento, ya sea físico, mental o sensorial (OMS, 2012). Así, las
personas con discapacidad constituyen la más grande minoría del mundo.
Adicionalmente, las condiciones generales de exclusión que actualmente vive este
grupo lo llevan a ser uno de los más vulnerables de la población.
El resultado principal del presente trabajo consiste en facilitar el intercambio
de información entre los profesores y los maestros integradores. Concretamente se
espera disponer de un sistema web colaborativo que sirva como herramienta de
comunicación y fuente de información útil para que los profesores puedan ampliar el
espectro de posibilidades al momento de enseñar a alumnos con discapacidades.
7
1.2 Objetivo
El objetivo de este trabajo es crear un medio de comunicación formal entre
los profesores de las escuelas que tienen alumnos integrados y los maestros
integradores, a través de un sistema web para trabajar en equipo de manera
colaborativa. De esta forma podrán compartir e intercambiar información sobre las
necesidades de los alumnos, como también técnicas de enseñanza y material que
les ayude en la formación académica de los alumnos integrados, a través de la
herramienta.
Además, el sistema permite llevar un legajo académico de los alumnos, en el
cual los profesores durante el año lectivo, puedan hacer una evaluación de los
objetivos adquiridos por el alumno, para que el profesor del año siguiente sepa de
donde partir con la planificación anual.
También sirve para que los profesores planteen las problemáticas con las que
se encuentran en las clases, a través de un foro, al que pueden acceder todos los
profesores vinculados a un alumno.
1.3 Organización del documento
Este documento se organiza de la siguiente manera, en el capítulo 2 se
introducen los conceptos generales a tener en cuenta para conocer el contexto del
desarrollo del trabajo de tesis realizado.
En el capítulo 3 se describe el proceso de elicitación de requerimientos a
través de la que se obtuvieron los requerimientos para desarrollar la herramienta,
junto a cómo se fueron implementando.
El capítulo 4 brinda los detalles del diseño visual de la aplicación, junto con
capturas de pantalla y la explicación del proceso de aceptación por parte de los
usuarios.
8
Por último, el capítulo 5 presenta las conclusiones y los trabajos futuros, junto
con la bibliografía consultada.
Además se agregó un anexo con los pasos para la instalaciones del ambiente
con Yii y el uso de Gii.
9
Capítulo 2: Marco teórico
En este capítulo se explicará el contexto en el cual se basa el trabajo y la
problemática a resolver. Además se incluye un análisis de la plataforma a utilizar y
las herramientas necesarias para el desarrollo de la aplicación
2.1 Discapacidad y educación
Las discapacidades pueden traer múltiples limitaciones y restricciones en la
participación en la sociedad para quienes las padecen. Por ejemplo, los niños con
discapacidad tienen menos probabilidades de ingresar en la escuela, permanecer
en ella y superar los cursos sucesivos. El fracaso escolar se observa en todos los
grupos de edad y tanto en los países de ingresos altos como bajos, pero con más
frecuencia en los países más pobres. Incluir niños con discapacidad en el sistema
educativo exige cambios en los planes de estudio, métodos y materiales de
enseñanza y sistemas de evaluación y examen (OMS, 2011).
Tanto la Declaración Universal de los Derechos Humanos (ONU, 1948) como
la Declaración de los Derechos del Niño (ONU, 1959) y la Convención sobre los
Derechos del Niño (ONU, 1989) hacen referencia a la igualdad de todos los
hombres en cuanto a sus derechos sin distinciones de ningún tipo y el derecho de
todos los niños de tener acceso a la educación. Diferentes tratados a nivel
internacional y regional fueron puntales y dieron marco a la posibilidad de una
educación inclusiva.
En los últimos años, en nuestro país ha habido cambios en la educación
primaria y secundaria. En la actualidad, aquellas personas con discapacidad que
poseen habilidades cognitivas normales, pueden asistir a escuelas comunes con el
objetivo de tener una mejor calidad de educación. En este contexto, estas personas
reciben el nombre de "alumnos integrados".
La Ley de Educación Nacional N° 26.206[6] sancionada en el 2006 garantiza
el derecho a la educación de las personas con discapacidad en todos los niveles y
modalidades, alienta la detección temprana de necesidades educativas derivadas
de la discapacidad o de trastornos en el desarrollo a fin de poder brindar atención
10
interdisciplinaria y educativa inclusiva desde el Nivel Inicial y en lo referente a la
accesibilidad establece que debe garantizarse la accesibilidad edilicia en todos los
edificios escolares, situación que aún dista mucho de concretarse. Esta ley define la
Educación Especial como transversal a todo el sistema educativo, como un
lineamiento de política educativa que ha ido sufriendo modificaciones muy
significativas sobre todo en la última década.
A modo de resumen, se presenta un cuadro comparativo, que sintetiza las
características de los términos educación especial, en su sentido tradicional y
necesidades educativas especiales, con el objetivo de esclarecer hacia a dónde
apunta, el uso de esta nueva conceptualización.[7]
EDUCACION ESPECIAL N E C E S I D A D E S E D U C AT I VA SESPECIALES
Término restrictivo, cargado de múltiplesconnotaciones peyorativas.
Término más amplio, general y propiciopara la integración escolar.
Suele ser utilizado como etiquetadiagnostica.
Se hace eco de las necesidadespermanentes o temporales de losalumnos.
Se aleja de los alumnos consideradosnormales.
Se refieren a las necesidades educativas delalumno. Engloban el término educaciónespecial.
Predispone a la ambigüedad y al error. Es un término cuya característica, es larelatividad conceptual.
Presupone una etiología estrictamentepersonal de las dificultades delaprendizaje y/o del desarrollo.
Admite como origen de las dificultadesde aprendizaje y/o desarrollo una causapersonal, escolar o social.
Tiene implicaciones educativas decarácter especial y por lo tanto deescuelas especiales.
Con implicaciones educativas de marcadocarácter positivo.
Conlleva referencias implícitas de curriculumespeciales y por lo tanto deescuelas especiales.
Se refiere al curriculum ordinario eidéntico sistema educativo para todoslos alumnos.
Hace referencia a los proyectos dedesarrollo individual los cuales partende un diseño curricular individual.
Fomenta las adaptaciones curriculares yl a s a d a p t a c i o n e s c u r r i c u l a r e sindividualizadas que parten del diseñocurricular común.
Tabla 2.1 - Compración entre educacion especial y NEE
11
2.2 Problemáticas a resolver
Actualmente se promueve en nuestro país la integración de alumnos con
discapacidad a las escuelas comunes. Sin embargo los profesores no fueron
capacitados, por lo que con este cambio se encontraron con alumnos con otras
necesidades en sus aulas sin saber en muchos casos como tratar con esta
situación. Por lo tanto es de vital importancia que haya una fluida comunicación
entre los profesores de la escuela y las maestras integradoras, psicopedagogas y
todas las personas involucradas en los distintos tipos de apoyo que recibe el alumno
para que puedan trabajar en conjunto y ayudar al paso de los alumnos integrados
por las escuelas comunes.
Debido a cuestiones de disponibilidad de tiempo, es muy común que la
comunicación entre los profesores de las escuelas y, sobre todo, las maestras
integradoras sea compleja. Esta falta de comunicación priva a los profesores de las
escuelas comunes de poder enriquecerse de los conocimientos que podrían
brindarles las maestras integradoras.
Otra problemática que existe actualmente, es que cuando un alumno cambia
de escuela o pasa al siguiente año, el trabajo que realizaron todas las personas
involucradas con el alumno durante el año, no queda registrado y puede perderse si
el alumno cambia de escuela, no continua con los mismos profesores el año
siguiente o no hay comunicación entre los profesores del año anterior y los del
actual.
2.3 Necesidad del sistema a implementar
Con la integración de alumnos especiales a las escuelas comunes los
profesores relacionados con estos chicos tuvieron que buscar una alternativa para
comunicarse ya que muchas veces por cuestiones de disponibilidad, de tiempo o de
distancias no pueden reunirse. En la gran mayoría de los casos, los canales de
comunicación elegidos no funcionan, generando que se pierdan los beneficios del
trabajo en conjunto ya que no pueden compartir los avances del alumno, las
12
problemáticas encontradas o las nuevas ideas que implementaron para mejorar el
aprendizaje. Todo esto termina afectando directamente a los alumnos integrados. En
otros casos encontraron como alternativa de comunicación las redes sociales, por
ejemplo grupos de Facebook o mensajes privados. Esto genera que no se pueda
hacer un seguimiento de los alumnos, ya que se generan publicaciones que no
permiten llevar un legajo ni una línea temporal de los progresos académicos.
Además si los grupos son por ejemplo por escuela, es decir están unidos al grupo
todos los profesores de la institución, todos puede ver los comentarios sobre un
alumno por más de que no esté directamente relacionado.
Por lo tanto se busca que el sistema a implementar tenga el dinamismo de
las redes sociales pero que además maneje un perfil de alumno que permita un
seguimiento e interacción sólo entre los profesores que están involucrados con ese
alumno, sin que sea algo de público conocimiento, manteniendo la privacidad.
Además debe permitir la comunicación entre todos los involucrados en el sistema.
Para plasmar las necesidades en requerimientos, se realizaron distintos tipos
de reuniones que se explican en detalle en el capitulo 3 de este trabajo, junto a
como fueron llevados a cabo.
El sistema será utilizado por profesores, maestras integradoras y otros
profesionales que estén en contacto con los alumnos integrados. No todos son
usuarios frecuentes de computadoras, por lo que el sistema tendrá que cumplir con
ciertos requisitos en lo que a usabilidad y accesibilidad compete.
Debido a todo lo mencionado anteriormente y haciendo hincapié en la
importancia de que la plataforma sea de fácil acceso para todos involucrados, se
tomo la decisión de que el sistema a realizar, sea un sistema web. De esta forma,
los usuarios solo teniendo acceso a una computadora con internet, pueden
interactuar con el sistema, pudiendo incluso utilizarlo de forma remota y no
solamente en las instituciones. Además no requiere de ningún tipo de configuración
por parte de usuario final.
Con respecto a la interfaz gráfica, se definió una interfaz de usuario simple,
para facilitar la interacción de los usuarios con la aplicación, ya que, como se
mencionó con anterioridad, no todos los usuarios están familiarizados con el uso de
la computadora. Además se buscó que fuera amigable, para que no les genere
13
rechazo utilizar el sistema e intuitivo, para facilitar su uso sin requerir ayuda,
pudiendo navegar con total independencia y así explotar al máximo las herramientas
que el mismo ofrece.
La definición de pantallas se hizo en conjunto con los usuarios en las
reuniones, trabajando en borradores hasta llegar a una versión final. Este trabajo se
encuentra detallado en el capitulo 4, en donde se muestran las modificaciones que
se fueron generando en el proceso, desde la definición hasta la implementación
visual de las mismas.
2.4 Aporte de las tecnologías utilizadas para laimplementación
Como se explicó anteriormente, para el desarrollo del trabajo se decidió
realizar un sistema web, desarrollado en PHP. Para esto, se busco un framework
que agilizara y ayudará en el desarrollo. A continuación, se muestran las
características de algunos de los frameworks analizados.
YiiFramework
ZendFramework
Cake PHP Symfony
Conocimientosrequeridos
PHP, POO P H P, P O O ,Pa t rones dediseño
PHP, POO PHP, POO, usod e c o n s o l a ,ORM
T a m a ñ o d eproyecto
P e q u e ñ o -Grande
M e d i a n o -Grande
P e q u e ñ o -Mediano
Grande
Version PHP 5.2 5.2 5.2 5.2
Internacionalización
Si Si Si Si
Instalación Promedio Compleja Baja Compleja
Documentacióny ejemplos
Completa Bueno Normal Normal
Tabla 2.2 – Comparación de frameworks PHP
Basado en los frameworks analizados, en cuanto a las características que los
14
diferencian, el tamaño del sistema en esta instancia del trabajo no es grande pero
puede tener mejoras y nuevas funcionalidades a futuro por lo que elegir un
framework que permita esa flexibilidad seria lo indicado. En cuanto a la instalación,
lo ideal es descartar los que tengan una instalación compleja para facilitar la tarea. Y
por último, hay diferencias en cuanto a la documentación. Esto es un factor muy
importante a tener en cuenta para poder realizar el desarrollo ya que si a futuro se
deciden realizar mejoras, se debe elegir un framework con buena documentación y
una comunidad activa para facilitar la tarea a los futuros programadores.
Basado en el análisis, se decidió usar Yii para la implementación del trabajo,
dado que sirve para proyectos de cualquier tamaño y la documentación es la más
completa. Además ya se tenía un previo conocimiento mínimo en el framework lo
cual facilitó la implementación.
15
Capítulo 3: Diseño e implementación
En este capítulo se detallan las decisiones de diseño e implementación
tomadas para el desarrollo de la aplicación. Además, se hará una introducción a las
herramientas utilizadas y configuraciones necesarias para el armado del proyecto.
3.1 Introducción
Como se mencionó en el capítulo anterior, la propuesta gira en torno a un
sistema de seguimiento de actividades de alumnos integrados. Dada la necesidad
interdisciplinaria de trabajo y el acceso al repositorio de datos por distintos docentes,
la solución se basa en un sistema web. Para ello, se utilizó la plataforma Yii. A
continuación se describe en detalle su uso.
3.2 Yii como framework
Yii es un framework PHP basado en componentes de alta performance para
desarrollar aplicaciones web de gran escala. Está orientado a objetos y software
libre, con alto rendimiento. Permite la máxima reutilización de código y puede
acelerar el proceso de desarrollo. Adicionalmente, tiene un generador de código
automático (Gii) que se utiliza para definir el esqueleto de la aplicación. Yii es
adecuado para desarrollar aplicaciones de gran tráfico como portales, foros,
sistemas de administración de contenidos. Implementa el patrón modelo-vista-
controlador (MVC), el cual es utilizado ampliamente en programación web y provee
una clara separación entre los datos y la lógica de negocio de una aplicación de la
interfaz de usuario y el módulo encargado de gestionar los eventos y las
comunicaciones. Para mas informacion de como funciona Yii y sus herramientas
relacionadas se puede consultar en Anexo presente en este trabajo.
16
3.3 Metodología usada para el desarrollo
Para el desarrollo de este trabajo fue necesario comprender el contexto,
formas de trabajo, capacitación y comunicación de los posibles usuarios del
sistema. Para tomar conciencia de las necesidades fue necesario realizar reuniones
con las profesoras de ATAD y profesores de distintas instituciones que tienen
alumnos con discapacidad en sus aulas.
Para comprender los distintos puntos de vista y planificar el desarrollo de la
aplicación se realizaron distintos tipos de reuniones:
Reuniones grupales entre el equipo de desarrollo y profesores de
ATAD.
Reuniones individuales con profesores con alumnos integrados en sus
aulas.
Reuniones del equipo de desarrollo.
Durante la primera reunión con profesores de ATAD, se realizó la primera
captura de requerimientos mediante un brainstorming. Su principal preocupación era
la privacidad de los datos del sistema y la información personal de los alumnos. Se
plantearon los problemas a los que se enfrentaban en el día a día y posibles
soluciones a los mismos. De manera similar, se realizaron reuniones con profesores
de las escuelas normales que expresaron otras necesidades desde su punto de
vista y posición dentro del aula. Después de las primeras reuniones, se realizaron
prototipos de las posibles vistas de la aplicación.
Una vez finalizada la primera etapa de desarrollo de prototipos, estos fueron
presentados a los usuarios finales. Durante estas reuniones, se plantearon
modificaciones y surgieron nuevas ideas de funcionalidades para agregar a la
aplicación. Por ejemplo, una de las vistas que sufrió modificaciones fue la de historia
académica. El primer prototipo es el que se muestra a continuación:
17
Prototipo 3.1 – Primer prototipo vista Historia Académica
En las reuniones con los profesores, se pensó en hacer una historia
académica más general, y no por materias en sí ya que implicaría más trabajo y la
idea fue mantenerlo lo más simple posible, con idea de mejorarlo a futuro cuando
los profesores estuvieran habituados al uso de la herramienta. De modo que el
resultado final fue:
18
Prototipo 3.2 – Segundo prototipo Historia Académica
Para que los profesores pudieran expresar que cosas modificarían,
eliminarían o agregarían a las pantallas, se imprimieron los prototipos para que
pudieran escribir sobre las pantallas. A continuación se muestra la intervención de
un profesor sobre el prototipo mostrado anteriormente, el cual volvió a sufrir
modificaciones:
19
Prototipo 3.3 – Intervención de los usuarios en los prototipos
Además se realizaron encuestas a los entrevistados para que pudieran
plantear sus ideas. Debido a las complicaciones de horarios y actividades diarias, la
encuesta sirvió para comunicarse con algunos profesores vía e-mail. A continuación
se muestran algunas de las preguntas realizadas:
20
Figura 3.1 – Encuesta para captura de requerimientos
Luego de dar por finalizada la etapa de elicitación de requerimientos, se
comenzó con el desarrollo. Para esto se hicieron reuniones mostrando los avances
parciales y realizando correcciones y mejoras dentro de la aplicación.
Una vez que el desarrollo estaba completo, se realizó un primer testeo con el
equipo. Luego de realizar los ajustes necesarios, se pidió a profesores que
interactuaran con el sistema y dieran su feedback al respecto. A partir de esto, se
realizaron nuevas mejoras, sobre todo a nivel de navegabilidad modificando ciertas
pantallas a nivel UX o mejorando la información que les era más útil para mostrar en
las pantallas.
Luego de finalizada esta etapa, ya con las mejoras planteadas resueltas, se
dio por cerrada la etapa de desarrollo.
En la figura 3.2 se muestran las etapas de desarrollo de la aplicación.
21
Figura 3.2 – Etapas de desarrollo
3.4 Desarrollo de la aplicación
Dado que Yii está basado en MVC, la aplicación desarrollada en este trabajo
de tesis se divide en los siguientes módulos:
22
Figura 3.3 – Modelo-Vista-Controlador
La figura 3.3 muestra el esquema de la aplicación, con las responsabilidades
de los módulos. La interacción entre los mismos se basa en las peticiones que hace
el usuario de la aplicación al navegador. Con la información capturada, el módulo
controlador puede ejecutar la acción y comunicarse con la vista o bien, comunicarse
con el módulo modelo, solicitarle la información necesaria y esperar la respuesta.
Luego de que el módulo controlador ejecuta la acción que solicitó el usuario,
devuelve la vista con el resultado.
A continuación se presentará en mayor detalle cada módulo del sistema junto
con los problemas y desafíos que surgieron para lograr la funcionalidad deseada. En
cada uno de estos módulos se detalla su implementación junto con las decisiones
de diseño tomadas para la resolución del problema. La división de los módulos se
basó en las problemáticas planteadas por los profesores con alumnos integrados en
sus aulas y las maestras integradoras de ATAD durante las reuniones realizadas
para la definición de los requerimientos y necesidades que este trabajo debía cubrir.
23
3.4.1 Módulo Modelo: Introducción
Este módulo es responsable de recuperar los datos desde la base de datos,
de su procesamiento, validación, asociación y cualquier otra tarea relacionada a la
manipulación de la información.
La capa de modelo es responsable de tareas tales como guardar datos de los
nuevos profesores, instituciones, alumnos, mensajes, almacenar asociaciones de
profesores con alumnos e instituciones, almacenar y recuperar los items presentes
en la historia académica de cada alumno, guardar y mostrar las notificaciones, etc.
Mientras que los objetos del modelo son las tablas definidas en el modelo de base
de datos.
En las próximas secciones, se muestra la división del módulo modelo basada
en los requerimientos planteados por los usuarios.
3.4.2 Módulo Modelo: Desarrollo de la funcionalidad Historia
académica
Durante las reuniones realizadas, una de las problemáticas que todos los
participantes plantearon fue la dificultad de llevar un seguimiento académico de los
alumnos. Esto sucede debido a que los alumnos concurren a la escuela normal y al
taller en donde trabajan con las maestras integradoras y no siempre hay
comunicación entre los docentes. Esto genera que se pierda información valiosa
sobre el trabajo realizado por los profesores con los alumnos durante el año.
Actualmente, algunos profesores utilizan grupos de Facebook donde comparten la
información, ya que no tienen un medio físico o herramienta dedicada para esto.
Este bloque es la funcionalidad principal de este trabajo y apunta a resolver
esta problemática. Representa la información académica que los profesores
consideran que es importante almacenar sobre cada alumno. Por ejemplo,
conocimientos adquiridos, temas a reforzar, técnicas de estudio y enseñanzas
efectivas.
24
Dentro de las reuniones los involucrados plantearon además, la necesidad de
asegurar la privacidad de la información de los alumnos. Para resolver esto se
definió que sólo los profesores involucrados con el alumno tendrán acceso a su
perfil y registros académicos.
Para la implementación de la funcionalidad se definieron 3 clases principales:
Profesor: Representa a los profesores con alumnos integrados en sus
cursos, maestras integradoras, psicopedagogas y profesionales que
tengan relación con la trayectoria académica de los alumnos.
Alumno: Niños y adolescentes con discapacidad que asisten a
escuelas comunes y han sido dados de alta en el sistema.
Historia Académica: Registros creados por los profesores sobre el
desarrollo académico de los alumnos.
La clase Alumno, representa la información para identificar al alumno. Se
decidió guardar solamente la información que se muestra como atributo de la clase
luego de las reuniones de captura de requerimientos que se mantuvieron con las
maestras integradoras. Como se busca que el sistema maneje un legajo puramente
académico y no médico o con información relevante a la discapacidad del alumno,
se guardó la mínima información posible para identificarlo.
La clase Profesor, representa la información que el sistema guarda sobre los
profesores o maestros integradores relacionados con alumnos que se encuentren
registrados en el sistema. Además de los datos personales, se usa un campo para
identificar si el profesor es administrador del sistema o no. Ser administrador del
sistema le permite al profesor, ingresar en la base de datos de la aplicación nuevos
alumnos, profesores e instituciones y crear una relación entre ellos. El
funcionamiento de la relación, se explicará más adelante.
La clase Historia académica, representa un registro que puede hacer el
profesor sobre un alumno. La información que se guarda es el identificador del
profesor que genera el nuevo registro, identificador del alumno sobre el que se
25
genera el registro, la fecha en la que se generó el registro y el texto o mensaje que
se quiere guardar.
Este bloque está compuesto por la clase historia académica y está
relacionada con profesor y alumno. Las relaciones entre estas clases se muestran
en la figura 3.4
Figura 3.4 – Diagrama de clases para la funcionalidad Historia Académica
26
La forma en la que se relacionan las clases, se define en el método
relations() declarado en cada una de ellas. Para la clase historia académica el
método define:
Código 3.1 – Método relations para la funcionalidad Historia Académica
Para la clase Profesor y de manera similar para la clase Alumno, el método
relations() define:
Código 3.2 - Método relations para la clase Profesor
Además, en las clases modelo, podemos ver la definición de los atributos de
la clase en el método rules. Estas definiciones surgen de lo definido en Gii para los
atributos de cada columna de la tabla y sirven para las validaciones. Para el modelo
de Historia académica este método define:
27
Código 3.3 – Validaciones para los atributos de Historia Académica
Flujo de la aplicación
Para la implementación de la funcionalidad se decidió que los profesores
participantes en el sistema, después de loguearse, pudean ver el listado de sus
alumnos. Al ingresar al perfil del alumno, pueden acceder a la historia académica,
dividida por años lectivos. Alli pueden consultar información que otros profesores
hayan registrado o crear una nueva entrada, y almacenar información que
consideran que será relevante en el futuro. Los registros académicos de un alumno
sólo pueden ser creados, modificados y consultados por los profesores con los
cuales está vinculado, para garantizar la privacidad de los datos del alumno.
Por ejemplo, el profesor Juan Perez, crea un registro en la historia
académica del alumno Pablo Gonzalez, con el siguiente mensaje: Para recuperar la
atención de Pablo durante las clases, en módulos de 2 horas, a los 50 minutos
tomar un descanso de 5 minutos. Puede ser con un juego matemático, no
necesariamente darle un recreo.
3.4.3 Módulo Modelo: Relación entre Profesor-Alumno-Escuela
En una primera instancia durante las reuniones se planteó la relación entre un
profesor que da clases a un alumno en una escuela determinada. Este bloque se
definió para mantener esa relación dentro del sistema. Con el avance del trabajo, las
maestras integradoras, pidieron que además se tuviera en cuenta a todos los
profesionales que tienen relación con el alumno, no solo profesores de las escuelas
28
comunes y maestras de taller.
Con este nuevo requerimiento, las clases que componen este bloque son las
definidas anteriormente como Profesor y Alumno, y se agrega una nueva entidad:
Escuela: escuelas comunes, escuelas especiales, y cualquier otra
institución a la que asista el alumno.
ProfAlumEsc: se encarga de mantener la relación ternaria.
La clase ProfAlumEsc es la que se encarga de mantener la relación entre un
profesional, un alumno y una institución determinada. Las relaciones son cargadas
en el sistema por los profesionales de tipo admin, desde la vista de administración.
El diagrama 3.5 muestra cómo se relacionan las clases Profesor, Alumno y
Escuela con la clase ProfAlumEsc.
29
Figura 3.5 – Relación entre las clases Profesor, Alumno y Escuela
30
Las relaciones entre las clases están definidas en ProfAlumEsc en el método
relations().
Código 3.4 – Método relations para la clase ProfAlumEsc
3.4.4 Módulo Modelo: Comunicación entre profesores
Otra cuestión planteada en las reuniones con los profesores es la dificultad de
poder participar de conversaciones para intercambiar información y opiniones, útil
en la enseñanza del día a día de los alumnos. Actualmente, los profesores manejan
estas situaciones haciendo una publicación dentro del grupo de Facebook visible
para todos los integrantes del grupo, y reciben las opiniones de los demás a través
de los comentarios sobre la publicación. Para mejorar esta situación, se planteó un
foro, vinculado al perfil del alumno. El foro es un sitio de discusión donde los
profesores pueden publicar mensajes en base a un tópico sobre un alumno en
particular, creando de esta forma un hilo de conversación. La utilización del foro
apunta a plantear problemáticas que los profesores están teniendo con el alumno, y
buscar apoyo y opiniones sobre cómo se podrían resolverse.
Para la implementación de esta funcionalidad se utilizan las clases Profesor y
Alumno, explicadas anteriormente y se plantean 2 nuevas clases:
Mensaje Foro: Es el mensaje principal que da inicio al debate. Es
creado por un profesor sobre el perfil de un alumno en particular.
Respuesta Foro: Es la respuesta de un profesor al mensaje que dio
31
origen al debate.
La clase MsjForo representa un nuevo debate creado por un profesor, este
mensaje sólo podrá ser visto por profesores relacionados con el alumno. Los demás
profesores podrán responder a este debate.
La clase RtaForo, representa una respuesta generada por un profesor, sobre
un debate. Los profesores que pueden responder a un debate son aquellos que
estén relacionados con el alumno.
Este bloque está compuesto por las clases MsjForo y RtaForo, y está
relacionada con Profesor y Alumno. Las relaciones entre estas clases se muestran
en la figura 3.6.
32
Figura 3.6 – Relación entre las clases para la funcionalidad el Foro
La forma en la que se relacionan las clases, se define en el método
relations() declarado en cada una de ellas. También mostraremos el método rules.
Para la clase MsjForo los métodos definen:
33
Código 3.5 – Métodos de la clase MsjForo
Y de manera similar para la clase RtaForo:
Código 3.6 – Método relations de la clase RtaForo
34
Código 3.7 -Método rules de la clase RtaForo
Flujo de la aplicación
Esta funcionalidad dentro de la aplicación, requiere que el profesor se loguee
y acceda al perfil del alumno. Como a cada profesor se le muestran solo los
alumnos con los cuales está relacionado, se puede asegurar que el foro del alumno
solo esta habilitado para sus profesores. Luego, seleccionando la opción Foro podrá
leer los mensajes, responder, o crear un nuevo hilo de debate.
Por ejemplo, el profesor Juan Perez, crea un nuevo debate en el foro
relacionado con el alumno Pablo Gonzalez y escribe como mensaje lo siguiente: a
los profesores que lo tuvieron a Pablo de alumno les consulto si tienen registro de
dificultades en la escritura para derivar en alguna consulta profesional y no perder
tiempo. Pude observar que su letra es prácticamente ilegible y preveo dificultades a
la hora de evaluarlo en forma escrita. La profesora de la institución ATAD Maria
Fernandez, responde al mensaje del profesor Juan Perez, escribiendo: en ATAD
estamos trabajando con Pablo para mejorar su nivel de escritura. Por el momento,
te recomendamos en los casos que sea posible, que lo evalúes en forma oral.
Otra necesidad planteada en las reuniones fue permitir el intercambio de
mensajes privados entre profesores. Actualmente el intercambio de mensajes se
realiza mediante Facebook o un profesor que se quiere comunicar con otro tiene
que conseguir el mail. A diferencia de las funcionalidades que se plantearon hasta el
momento, este permite el intercambio de mensajes entre todos los profesores, no
solo los que tienen alumnos en común.
La clases que se plantearon para resolver esta funcionalidad son:
35
Mensaje: Mensaje privado que un profesor puede enviar a otro que se
encuentre registrado en el sistema.
Mensaje Rta: respuesta del profesor al mensaje original.
La clase Mensaje, representa el inicio del intercambio de mensajes. El
mensaje está compuesto por emisor, receptor, asunto y texto del mensaje. El
funcionamiento es similar al de un email, solo que se maneja dentro de la aplicación.
Cuando un profesor quiere responder a un mensaje, se crea un nuevo
elemento que se corresponde a la clase MensajeRta. Cuando se responde un
mensaje, el campo que el profesor debe completar es el mensaje, ya que los demás
se toman en base al mensaje original.
En el siguiente diagrama se muestran las interacciones de este módulo con
los demás pertenecientes a la aplicación.
36
Figura 3.7 – Clases para el intercambio de mensajes privados
37
El método relations() se muestra cómo se relacionan las clases, con las
relaciones definidas en el la clase MensajeRta:
Código 3.8 – Método relations para la clase MensajeRta
Además de los mensajes privados surgió la idea de crear una agenda de
eventos con el fin de facilitarle a los profesores un medio para generar encuentros,
ya que actualmente no cuentan con una herramienta que se los provea. La creación
de eventos la puede realizar cualquier profesional que esté registrado en la
aplicación y puede invitar a otros profesionales que se encuentren registrados.
Para implementar esta funcionalidad se utiliza la clase profesor, y se crearon
dos clases nuevas que se describen a continuación:
Agenda: representa un evento creado por un profesor
AgendaParticipante: Representa a los profesores invitados al evento
La clase Agenda, representa un nuevo evento. Cuando el profesor crea un
evento, se le solicita que complete la fecha del evento y la descripción. Al crear un
nuevo evento, también puede invitar otros profesores en forma individual y privada,
a diferencia de los eventos generales publicados en la aplicación.
La clase AgendaParticipante, representa la invitación del profesor creador del
evento a otro profesor. De esta forma se puede invitar a más de un profesor al
evento. Los profesores que son invitados al evento recibirán una notificación
informativa.
38
La figura 3.8 muestra como se relacionan las clases que lo componen
Figura 3.8 – Relación entre clases para módulo Agenda
39
Las relaciones entre las clases involucradas se especifican de la siguiente
manera en el código de las clases del modelo.
Código 3.9 – Método relations para la clase Agenda
Al momento de pensar en comunicación abierta a todos los integrantes del
sistema, se pensó en tener una cartelera, donde todos los profesores pudieran
publicar capacitaciones, cursos, eventos a beneficio y que fueran de conocimiento a
todos los profesionales registrados en la aplicación. Para cumplir con esto, se
agregó un panel de eventos, en la pantalla principal.
Para implementar este requerimiento se utiliza la clase profesor y se agrego
la clase Novedades
Novedades: maneja los datos del evento público.
La clase representa la información a registrar sobre el evento. Cuando el
profesor crea un nuevo evento, se le solicitara fecha, nombre del evento y
descripción.
La clase profesor se utiliza para mantener un registro de quién fue el que creó
el evento y así poder permitirle editarlo o eliminarlo.
Flujo de la aplicación
Esta funcionalidad requiere que el profesor se loguee y desde la pantalla
principal en el panel de novedades, seleccione nuevo e ingrese la fecha, titulo y
descripción del evento.
40
3.4.5 Módulo Modelo: Interacción de los usuarios con el sistema -
Notificaciones
Las notificaciones se diseñaron para darle una mejor navegabilidad al
sistema y facilitar la tarea de los profesores, ya que les comunicaran cuando surgió
un cambio en el perfil de uno de los alumnos, recibieron un mensaje privado, una
invitación a un evento, entre otras.
El módulo de notificaciones se planteó con la idea de simular las
notificaciones de Facebook que es la herramienta que actualmente usan algunos
profesores para comunicarse. Las notificaciones se generan mientras que los
usuarios interactúan con el sistema.
Para seguir manteniendo el requerimiento de privacidad de información de los
alumnos, se plantearon distintos tipos de notificaciones, que se diferencian por la
información que se guarda con respecto a cada una en la base de datos.
Públicas: están destinadas a los profesores registrados en el sistema, y
surgen de la creación o modificación de los eventos públicos que se
muestran en la vista principal de la aplicación.
Privadas a grupo de profesores: son notificaciones que se muestran sólo al
grupo de profesores vinculados al perfil de alumno que se está modificando.
Privadas individuales: son notificaciones que apuntan a un profesor en
particular, por ejemplo, un mensaje privado.
Todos los módulos tienen interacción con esta funcionalidad, y para la
implementación se creó la clase Notificaciones que representa cada cambio que se
genera en el sistema y lo muestra a los involucrados. La interacción con los módulos
se pueden ver en la figura 3.9.
41
Figura 3.9 – Clases involucradas en las Notificaciones
La clase Notificaciones tiene como principales atributos el id del alumno
42
sobre el cual se genera la notificación, el profesor que está generando la
notificación, y para el caso de notificaciones a profesores en particular, sus id.
Además, para todos los casos, se utiliza el atributo controller que guarda la url del
lugar en donde se genero la notificación. De esta manera, permite que el usuario
pueda acceder al cambio que se hizo en el sistema de manera más rápida. El
sistema maneja cierta lógica a la hora de mostrar las notificaciones a los usuarios.
Para el caso en que la notificación esté relacionada al cambio de información de un
alumno, por ejemplo, un nuevo mensaje en el foro, un nuevo registro en la historia
académica o se agregó una relación al alumno con un nuevo profesor; la notificación
será informada a los profesores que también estén relacionadas al alumno, excepto
al profesor que la genero.
Flujo de la aplicación
El profesor Juan Perez, crea un nuevo debate en el foro relacionado con el
alumno Pablo Gonzalez y escribe un mensaje. En ese momento, se genera una
notificación a todos los profesores que están relacionados con Pablo, informando
que Juan escribió en su foro.
Otro tipo de notificaciones son las que se generan al crear un evento público
en el panel de eventos. Por ejemplo el profesor Juan Perez, agrega un evento,
invitando a todos a participar del baile a beneficio de la escuela en la que da clases.
Como este evento no está vinculado a un alumno en particular, la notificación se
mostrará a todos los profesores.
3.4.6 Módulo Modelo: Resumen
Una vez que se explicaron todos los módulos con los requerimientos que cada
uno de ellos debe cumplir, podemos mostrar un diagrama general de la aplicación
con todos sus bloques.
43
Figura 3.10 – Diagrama de los modulos de la aplicacion
3.4.7 Módulo Controlador: Introducción
El módulo controlador, está compuesto por los controladores correspondientes
al sistema y se ubican entre el usuario y la aplicación. Su función es la de controlar
la comunicación entre los modelos y las vistas según la solicitud que ha hecho el
usuario. La URL solicitada determina que controlador y qué acción se van a ejecutar
para resolver el requerimiento.
44
El controlador es creado por la aplicación cuando un usuario realiza un
pedido para ese controlador. Cuando un controlador se ejecuta se realiza el pedido
de la acción, que utiliza los modelos necesarios y muestra la información a través de
la vista apropiada. Una acción, en su forma más simple, es un método de la clase
controlador cuyo nombre comienza con action. Los usuarios realizan pedidos por un
controlador y acción en términos de ruta. Una ruta se encuentra formada por la
concatenación de un ID de controlador y un ID de acción separados por una barra.
Todos los controladores en Yii, tienen definidos por defecto las acciones que
se explican a continuación:
actionCreate: este método se invoca cuando en un formulario de
creación el usuario selecciona la opción de crear. Esta selección
genera que se invoque al actionCreate, con los parámetros
correspondientes. El controlador crea una nueva instancia del modelo
correspondiente, setea los campos necesarios y lo guarda en la base
de datos.
actionUpdate: se ejecuta cuando un usuario decide modificar un
registro de la base de datos. Para esto, modifica en el formulario
información y luego hace un submit del mismo. En ese momento, se
invoca al actionUpdate correspondiente al modelo que se está
modificando. El método recibe los parámetros, entre ellos, el id del
modelo. El controlador, busca ese modelo en la base, le setea la
nueva información, y lo guarda.
actionDelete: se ejecuta cuando un usuario decide borrar un registro.
El controlador hace el borrado. Para esto, recibe por parámetro el id
del modelo, y lo elimina. Si hay otras tablas que tienen relación con
este registro, se debe eliminar además el registro de esas tablas.
actionView: esta acción se ejecuta cuando el usuario quiere ver la
información de un registro. Para esto, el controlador busca en el
modelo la información asociada al id recibido por parámetro, y la
devuelve a la vista para que la muestre.
45
actionAdmin: este método devuelve la lista de todas las tuplas que
hay en una tabla de la base, vinculadas al modelo que se esta
consultando mediante el controlador. El controlador devuelve a la vista,
la lista de registros para que la muestre al usuario.
A continuación, se muestra una instanciación de un controlador en el sistema.
3.4.8 Módulo Controlador: Ejemplo del controlador Historia
académica
El controlador de esta funcionalidad, es el que contiene las acciones que se
realizan sobre los registros académicos de los alumnos, mediante la comunicación
con el modelo historia académica.
Algunas de las acciones que son ejecutadas por un profesor mediante este
controlador, se explican a continuación.
actionUpdate: recibe como parámetro el id de una historia académica y
envía a la vista el registro con los datos actuales para que el usuario
los pueda modificar.
actionCreate: envía a la vista un modelo vacío y los datos del perfil del
alumno sobre el cual se ejecuta la acción.
actionSave: cuando se ejecuta tanto una acción de create o update,
luego de que el usuario crea o modifica una historia académica, el
controlador ejecuta una acción save, para guardar el registro en la
base de datos. Además genera un registro en para las notificaciones.
El siguiente diagrama de secuencia muestra la interacción entre los objetos y
actores del sistema desde una perspectiva cronológica.
46
Figura 3.11 – Diagrama de secuencia para creación de una Historia Académica
Al momento de realizar las acciones el controlador se comunica con otros
modelos además del modelo historia académica. Uno de estos modelos es el de
notificaciones. Para esto el controlador crea un objeto de tipo Notificación, y le setea
los datos que se generan con la acción que se está ejecutando. A continuación se
muestra un ejemplo.
47
Código 3.10 – Creación de notificación
3.4.9 Módulo Vista: Introducción
La vista es la parte de la aplicación que los profesores utilizan para interactuar
con el sistema y es la representación visual de los datos. Si un profesor, ejecuta una
petición a través del browser, la vista se comunica con el controlador
correspondiente para que la ejecute. Cuando el controlador tiene la información
solicitada, se la envía a la vista y esta la muestra de acuerdo a los layout y estilos
definidos. Además puede usar widgets, que son componentes con propósito
presentacional principalmente.
Gii genera automáticamente ciertas vistas básicas como: index, admin, view,
form. Estas vistas proveen la visualización básica para un ABM de los datos de la
aplicación. Las vistas se pueden adaptar de acuerdo a las necesidades, o se
pueden crear vistas nuevas.
Para la parte de la interfaz visual, se decidió usar el framework de css
Bootstrap. Es una herramienta para crear interfaces de usuario limpias y totalmente
adaptables. Además, Bootstrap ofrece las herramientas necesarias para crear
cualquier tipo de sitio web utilizando los estilos y elementos de sus librerías y es
compatible con la mayoría de los navegadores, evitando los problemas que
pudieran surgir desarrollando con CSS sin un framework de por medio.
48
Para incluir extensiones como Bootstrap en el proyecto se debe descargar en
p r o t e c t e d / e x t e n s i o n s . A d e m á s , s e d e b e c o n f i g u r a r e l a r c h i v o
protected/config/main.php de la siguiente manera:
Figura 3.11 – Configuración de Bootstrap
A continuación, se explicaran dos vistas del sistema. Para el primer ejemplo,
se mostrará el caso en el que se utiliza una vista base de las que provee el
framework y se realiza la personalización solo de los estilos. En el segundo ejemplo
se muestra el caso de una vista desarrollada desde cero. Para esta se define el
action en el controlador, y se agrega la clase de la nueva vista dentro de las vistas
del controlador correspondiente, creando el html, estilos y lógica.
3.4.10 Módulo vista: Ejemplo de la vista Historia Académica
La vista index, del modelo historia académica, representa el requerimiento
planteado por los usuarios, para poder llevar un control sobre el legajo académico
de los alumnos. En esta vista se muestran los registros académicos y también se
permite agregar nuevos.
A continuación se muestra el mockup aceptado por los usuarios durante las
reuniones.
49
Prototipo 3.4 – Prototipo final Historia Académica
La vista index es una de las vistas básicas que provee Yii que se adapto para
que el look & feel se corresponda con el mockup aprobado. La información que se
debe mostrar la provee el controlador mediante la ejecución del action index. Este
se comunica con el modelo, y le envía a la vista por parámetro la lista con los datos
a mostrar. La vista recibe la información y utiliza el widget TbMenu, en forma de
“pills” de bootstrap para mostrar la historia académica del alumno dividida por años.
Con cada registro se muestra el autor y la fecha. Además, en caso de que es
usuario logueado sea el creador del registro, se da la opción de editar y eliminar.
3.4.11 Módulo vista: Ejemplo de la vista inicio del Profesor
La vista de inicio tiene como función mostrar las notificaciones propias para
cada usuario de la misma forma que funcionan las redes sociales y además las
novedades. Para el desarrollo de esta vista, no se uso una de las definidas por
defecto en Yii, sino que se creó una desde cero. A continuación se muestra el
50
mockup aprobado por los usuarios para el desarrollo de este requerimiento.
Prototipo 3.5 – Prototipo vista inicial del profesor
Para el desarrollo de la vista, se creó una nueva dentro de las vistas del
profesor. Muestra por un lado, las novedades y por otro las notificaciones. Esta vista
interactúa con el controlador Profesor a través del action inicioAction, que fue
definido dentro de este controlador. Este action se comunica con los modelos
Profesor, Notificaciones y Evento para obtener la información que se debe mostrar.
Devuelve la lista de novedades y notificaciones que provee el modelo y la vista se
encarga de mostrarlas en pantalla.
3.5 Resumen del capítulo
En este capítulo se explicó una de las partes más importantes de este trabajo,
que fue la captura de requerimientos. Poder plasmar las ideas de todos los usuarios
51
involucrados, cumpliendo con todas sus expectativas, llevo mucho tiempo de
definición, reuniones, intercambio de opiniones y desarrollo de prototipos. Además
fue necesario comprender la problemática en la que viven y cómo eso afecta a los
alumnos integrados en su paso por la escuela.
Además, se realizó una introducción al framework en el que está basado el
desarrollo, junto con el patrón de diseño utilizado.
Para el módulo modelo, se desarrollaron los requerimientos y se explicó
como se definieron las tablas de la base de datos para poder cumplir con todas las
necesidades planteadas por los usuarios.
Para el módulo controlador, se ejemplifico el funcionamiento del mismo en
base al desarrollo del controlador historia académica.
Para el módulo de las vistas se explicó cómo se definen las mismas en el
framework ya sea que se utilicen las que provee por defecto Yii o se realice una
vista personalizada. En el próximo capítulo, se explica en profundidad cada vista en
base a la UI.
52
Capítulo 4: Implantación
4.1 Introducción
Este capítulo se basa en el desarrollo de la UI de la aplicación. Se mostrarán
desde los mockups a las vistas finales explicando cómo fueron modificándose
durante el transcurso del desarrollo y como cumplen con los requerimientos pedidos
por los usuarios.
Debido a que muchos usuarios no tienen experiencia con sistemas
complejos, se tuvo que organizar su forma de trabajo dentro de un sistema simple,
de fácil navegabilidad y que cumpliera con todos los requerimientos. Además se
buscó hacer un sistema con buena usabilidad, para que los usuarios puedan
interactuar con el de la forma más fácil, cómoda e intuitiva posible, centrando el
diseño en el feedback que los usuarios daban sobre los prototipos base.
A nivel general, en las pantallas se decidió usar paneles, para englobar la
información y que resulte claro y simple para los usuarios. Como framework para la
parte visual del desarrollo se utilizó Yii Bootstrap
4.2 Yii Bootstrap
Yii-Bootstrap es una extensión de bootstrap pensada para ser utilizada con
Yii. Provee widgets que fueron desarrollados siguiendo las convenciones de Yii y
trabajan juntos con bootstrap y plugins de jQuery.
Para ser utilizada dentro del sistema, se debe descargar y luego agregar en
el archivo main.php.
4.3 Vista de ingreso al sistema
Durante las reuniones de captura de requerimientos las maestras
integradoras hicieron hincapié en su preocupación sobre la privacidad y seguridad
de los datos de los alumnos que estuviesen registrados en el sistema. Para darle
seguridad al ingreso al sistema y que no pudieran ingresar personas ajenas a la
53
educación de los alumnos, se diseño una pantalla de login, en la que se pide
documento de identidad y contraseña.
Para la administración del sistema, contaremos con uno o más usuarios
super admin, que podrán dar de alta profesores en el sistema. La idea inicial que se
planteó, fue que el rol de super admin, estuviera asociado a las directoras de las
instituciones.
A continuación se muestra la pantalla de login:
Pantalla 4.1 - Login
Como se puede observar, es una pantalla simple, pero que cubre la
necesidad planteada por los usuarios con respecto a restringir el acceso a personas
ajenas a los alumnos.
Para el código de esta funcionalidad, usamos el que provee por defecto Yii.
54
Código 4.1 – Metodo Login
Se puede ver que si llegan los datos ingresados por el usuario por POST, se
setean en el modelo de Login, se validan y si los datos son correctos se busca el
profesor vinculado a esa información y se redirige a la página de inicio del mismo.
4.4 Vista Inicio: eventos y notificaciones
Lo primero que ven los profesores al ingresar al sistema son los eventos
públicos y sus notificaciones. El prototipo para esta pantalla se puede ver en la
sección 3.4.11.
Los eventos se actualizan según las fechas y una vez que la fecha del evento
pase se dejará de mostrar. Al ingresar al icono se podrá ver más información del
evento. Debajo se puede ver la parte parcial de la vista para los eventos.
55
Pantalla 4.2 – Vista de eventos públicos
Las notificaciones se actualizan en base a la actividad de los demás
profesores dentro de la aplicación. Cuando un profesor quiere ver el cambio que
genero la notificación, puede seleccionar el icono , y el sistema lo va a redirigir a
la pantalla asociada. Por ejemplo, si la notificación dice que recibió un mensaje
privado, puede seleccionar el icono y la aplicación le mostrará la pantalla con el
mensaje recibido.
56
Pantalla 4.3 – Vista notificaciones
La forma en que se generan las notificaciones y los distintos tipos que hay en
la aplicación se puede ver en la sección 3.4.5 del Capítulo 3.
Como trabajo futuro, se puede agregar que una vez que el usuario vio la
notificación la misma pueda ser eliminada de la lista de notificaciones o marcar con
diferentes colores las notificaciones que ya fueron vistas de las que no.
Este es un widget menú de yii bootstrap de tipo lista. La forma en la que se
visualiza el menú se puede ver en la vista de novedades de esta misma sección.
57
Código 4.2 – Menú de la aplicación
4.5 Vista de los alumnos asociados al profesor
En esta vista se muestra la información básica de los alumnos con los que
tiene relación un profesor. Con información básica, nos referimos a la mínima
información posible para identificarlos, y así poder cumplir con el requerimiento de
no incluir información propia del diagnóstico médico, sino la información puramente
académica. A continuación se adjuntan el prototipo inicial y la pantalla final, luego de
algunas modificaciones.
58
Prototipo 4.1 – Pantalla de listado de Alumnos
A este diseño, se le realizaron algunas modificaciones, obteniendo como
resultado final la siguiente pantalla:
Pantalla 4.4 – Vista de la lista de Alumnos
En la vista final no se muestran los datos del profesor y la institución, ya que
59
cada alumno puede estar relacionado con muchos profesores. Debido a esto, se
agregó otra pantalla dentro del perfil del alumno, no contemplada en el prototipo
inicial, a la que se accede desde el botón Ver perfil, en la cual se puede ver a todos
los profesores con los cuales está relacionado y las instituciones a las que asiste.
Permitiendo desde esta pantalla, intercambiar mensajes con los profesores y ver
sus perfiles y los datos de las instituciones
Pantalla 4.5 – Pantalla de perfil de alumno
En el panel de la izquierda, se puede ver la lista de los profesores que están
vinculados con el alumno. Desde el botón contactar, se le puede enviar un mensaje
privado, facilitando la comunicación entre profesionales y desde el botón ver perfil,
se pueden ver los datos personales del profesor. Esto es de utilidad para los
profesores, ya que si necesitan contactarse de manera privada con otro profesor
vinculado al alumno pueden hacerlo a través del sistema.
En el panel de la derecha, se muestran las instituciones a las que asiste el
alumno, y al seleccionar el botón ver datos, podemos ver la información registrada
de cada institución.
Para mostrar solo los alumnos que están relacionados con el profesor se
realizó el filtro que se muestra a continuación utilizando un widget de Yii:
60
Código 4.3 – Ejemplo widget
4.6 Comunicación entre profesores: Vista de mensajes
privados
Como se mencionó en la vista anterior, los profesores pueden enviarse
mensajes privados. A esta vista se puede acceder como se mostró en la sección
anterior, o desde el menú principal, a través de la opción mensajes. La pantalla está
dividida a través del componente pills de bootstrap, que funcionan de manera similar
a pestañas. El primer prototipo creado para esta funcionalidad era más simple, y se
dividía en dos pantallas, una para la lista de mensajes recibidos y otra para el envío
de mensajes.
61
Prototipo 4.2 – Prototipo de intercambio de mensajes privados
En la pantalla final, si queremos enviar un mensaje, seleccionando la opción
nuevo mensaje, la aplicación muestra la siguiente pantalla.
Pantalla 4.6 – Vista de mensajes privados
62
El envío de mensajes funciona de manera similar a una cuenta de mail, como
por ejemplo gmail, hotmail, etcétera. Se puede escribir un asunto, un mensaje y se
debe seleccionar un profesor de la lista de todos los profesores ingresados en el
sistema. Esta funcionalidad facilita la comunicación entre los profesores de manera
directa. Cuando un profesor recibe un mensaje, ve una notificación en su panel de
notificaciones y puede acceder desde la misma al mensaje, que se encuentra en la
opción de recibidos. La pantalla de mensajes recibidos se muestra a continuación.
Pantalla 4.7 – Vista de mensajes privados-2
En el primer mensaje privado, se puede ver como se listan los mensajes por
63
defecto. Al seleccionar el botón Ver, señalado dentro del recuadro rojo, se despliega
el mensaje dentro de la misma pantalla. Si un profesor quiere responder un
mensaje, puede hacerlo seleccionando el botón Responder. En este caso, también
se despliegan dentro de la misma pantalla los campos a completar para el envío. En
ambos casos, se decidió mantener las distintas funcionalidades dentro de una vista
para no generar una navegación más compleja dentro del sitio.
La pestaña de mensajes enviados, es similar a la anterior, con la diferencia
de que solo muestra la opción de Ver.
Actualmente no se permite agregar documentos adjuntos a los mensajes. Esto
queda pendiente para futuros trabajos. Más información sobre cómo se planteó el
requerimiento para el intercambio de mensajes privados entre profesores puede
encontrarse en la sección 3.4.4 del capítulo 3.
4.7 Comunicación entre profesores: Vista foro
Esta vista representa la parte visual de uno de los requerimientos para la
comunicación entre profesores, especificada en la sección 3.4.4. En esta primer
pantalla se puede ver el historial del foro para un alumno. Cada nuevo hilo se crea
dentro de un panel de bootstrap siguiendo con lo planteado para la mayoría de las
funcionalidades. Para cada nuevo hilo se muestra la fecha de creación y título, el
texto del mensaje y en el pie del bloque, el profesor que realizó la publicación.
Pantalla 4.8 – Vista Foro
64
La creación de un nuevo hilo se puede realizar a través del botón “Nuevo
comentario”. Una vez que se selecciona esta opción, se muestra sobre la misma
pantalla los campos a completar para la publicación del mensaje. El diseño es
similar al que se utilizó a la hora de responder los mensajes privados entre
profesores para mantener consistencia entre las pantallas y facilitar el uso y la
navegabilidad.
Pantalla 4.9 – Vista nuevo mensaje en el Foro
Por otro lado está la opción Ver. Cuando se selecciona esta opción, se
muestra el mensaje que dio origen al hilo y además todas las respuestas sobre el
mismo, permitiendo agregar una nueva respuesta.
65
Pantalla 4.10 – Vista ver mensaje Foro
Para esta vista en una primera instancia se había planteado el siguiente
prototipo
Prototipo 4.3 – Pantalla para ver mensajes del Foro
66
Como se puede observar, se había planteado solo una pantalla en la que se
mostraban tanto los mensajes iniciales de los hilos, como las respuestas. Para
manejar una lectura más clara, se decidió dividirlo en dos pantallas como se mostró
en las capturas finales.
4.8 Comunicación entre profesores: Vista agenda
Esta funcionalidad se planteó con la idea de permitir a los profesores
organizar reuniones. La definición del requerimiento se encuentra en la sección
3.3.4 del capítulo 3. En esta sección se mostrarán las pantallas involucradas en la
funcionalidad.
Cuando un profesor crea un evento, la pantalla que se muestra pide la fecha
de la reunión, un título y una descripción.
Pantalla 4.11 – Vista creación de evento en la agenda
Una vez que se guardó el evento, se pasa a la siguiente pantalla para
agregar los invitados. En esta pantalla se seleccionan los participantes dentro de los
67
profesores que están dados de alta en el sistema.
Pantalla 4.12 – Vista de invitación de profesores al evento
Cuando se agregaron todos los profesores se guarda la información y se
muestra una pantalla con todos los eventos creados y a los que está invitado el
usuario.
Pantalla 4.13 – Vista de la agenda
Con el botón Nuevo, se muestra la pantalla de creación de eventos. Si el
usuario es el creador del evento tiene acceso a eliminar y editarlo. Cuando un
profesor es invitado a un evento se crea una notificación para informarle del mismo.
Esta notificación puede verse en el panel de notificaciones de la pantalla de inicio.
68
Como trabajo futuro se podría agregar que se permita adjuntar documentos al
evento, como por ejemplo una agenda de los temas a tratar. Además en vez de solo
enviar una notificación dentro del sistema a los invitados a la reunión se podría
agregar que se envíe un mail a los profesores a la casilla personal.
4.9 Vistas de administrador
Las vistas de administrador solo son visibles para los usuarios con rol de
administrador. La idea dentro del trabajo para la asignación de este rol apunta a
seleccionar un profesor o directivo responsables por institución para que sea el
encargo de que a principio del año lectivo todas las nuevas relaciones se
encuentren registradas en el sistema.
A partir de estas vistas los usuarios pueden agregar y modificar los datos del
sistema. La vista inicial muestra las relaciones ternarias entre los profesores,
escuelas y alumnos del sistema.
Pantalla 4.14 – Vista de relación entre alumnos, profesores y escuelas
Además permite agregar nuevas relaciones. Estas se crean seleccionando un
69
profesor, alumno y escuela que ya estén cargados en el sistema como se muestra
en la vista a continuación.
Pantalla 4.15 – Vista para agregar una relación al sistema
Si para la relación se quiere seleccionar algún dato que no está previamente
cargado, el usuario tiene que agregar primero la información en las demás vistas de
administración. La forma en como se agregan profesores, alumnos y escuelas se
explicará en las próximas secciones.
4.10 Vista del profesor administrador: Profesores
Esta vista muestra el listado de los profesores registrados en el sistema con
la información de cada uno. La información que se registra en el sistema es el
nombre, email, dni y se le asigna el rol de administrador o profesor no
administrador. Si se necesita actualizar información de un profesor o crear uno
nuevo, es el profesor con rol de administrador quien tiene acceso a esto.
70
Pantalla 4.16 – Vista de profesores registrados en el sistema
La vista de admin es una de las que provee Yii por defecto. A continuación, se
muestra el código del controlador que define el framework y también el body del grid
que se usa en la vista para mostrar el listado de profesores
Código 4.4 – Método Admin para la vista de profesores
En este fragmento de código se puede ver que se buscan en la base de
datos todas las filas de la tabla Profesor y se envían a la vista admin para que las
muestre.
71
Código 4.5 – Método busqueda de profesores en la base de datos
En el código de la vista podemos ver el cuerpo del grid, en donde se usa
como data de entrada el modelo enviado por el controlador, y se muestran las
columnas nombre, mail, dni directamente con la información de cada fila. Además,
para la columna de administrador, se agrega una lógica adicional, para que en vez
de mostrarse el booleano guardado en la base, se muestre de forma más clara la
información. También se agrega una columna, para permitir actualizar datos, en la
que se utiliza un icono y al seleccionarlo redirige al action update de la clase
profesor.
4.11 Vista del profesor administrador: Alumnos
Esta vista tiene como funcionalidad permitir la actualización y creación de
alumnos en el sistema. La información que se necesita para agregar un nuevo
72
alumno es la mínima necesaria para identificar a los alumnos sin dar información
adicional sobre su discapacidad o tratamientos.
La imagen que se muestra a continuación, es la vista del listado de todos los
alumnos registrados. Los datos que se muestran son el nombre y dni del alumno y
además la opción de actualizar los datos.
Pantalla 4.17 - Vista de alumnos registrados en el sistema
Al igual que la vista de profesores, esta vista es la de admin que provee Yii
por defecto, de modo que funciona de manera similar a la explicada en la sección
anterior.
La información se muestra dentro de un panel de bootstrap utilizando un
widget de tipo TbGridView. Además se utiliza un widget de tipo TbButton para el
botón Nuevo.
4.12 Vista del profesor administrador: Instituciones
De manera similar a las dos secciones anteriores, esta vista se utiliza para
agregar y modificar instituciones al sistema. En esta vista podemos ver que no todos
los campos son obligatorios, como por ejemplo el número de teléfono. La idea sobre
la persona de contacto, es que sea el profesor administrador o la persona de
73
contacto que tenga conocimiento del funcionamiento del sistema de cada institución.
Pantalla 4.18 -Vista de instituciones registradas en el sistema
Al seleccionar el botón Nuevo se muestra la pantalla detallada a continuación.
Pantalla 4.19 – Vista de creación de institución
En la misma se puede ver que los campos obligatorios están marcados con el
74
asterisco y los opcionales no lo tienen. Cuando se completan todos los campos y se
selecciona enviar, se redirige al actionCreate del controlador de Escuela.
Código 4.6 – Método create para una institución
En esta sección de código se pueden ver que se mapean los datos recibidos
en el post al modelo de escuela y se guarda el nuevo registro en la base. Si el
registro se crea exitosamente, se crea además la notificación asociada que luego
se mostrará en la pantalla inicial.
4.13 Resumen del capítulo
En este capítulo se mostraron las pantallas de la aplicación y se explicaron las
decisiones que se tomaron a nivel de UI y usabilidad. Además se definieron las
posibles mejoras como trabajos a futuro.
Se mostró también el proceso de aprobación de las pantallas por parte de los
usuarios y como se fueron modificando en el proceso ajustándose a las
75
necesidades y tratando de facilitar la usabilidad ya que muchos no están
familiarizados con el uso de las computadoras.
76
Capítulo 5: Conclusiones y trabajos futuros
5.1 Conclusiones
En este trabajo se presentó un sistema web para llevar un legajo académico
de alumnos integrados en escuelas comunes. Se logró crear un puente digital entre
los profesores de las escuelas comunes y los maestros integradores. Se les brindó
una herramienta donde pueden compartir y dejar un registro del paso de los niños
por la escuela, junto con las problemáticas a las que se enfrentaron y cómo
pudieron resolverlas en conjunto. También se podrá utilizar para que profesores de
años futuros sepan cuáles fueron los conocimientos adquiridos por los alumnos y
que quedó pendiente, ya que en la historia académica, el profesor actual puede
dejar registro de esto. Además funciona de medio de comunicación, sin tener que
disponer de tiempo para encontrarse personalmente ni de herramientas externas al
sistema.
5.2 Trabajos futuros
Algunas de las funcionalidades pendientes de implementación son:
Agregar una sección de ayuda dentro de la aplicación y/o un manual
de usuario, en donde se explique el uso del sistema para que los
usuarios tengan a donde recurrir en caso de dudas. También se podría
brindar un curso para explicar a los usuarios las cuestiones básicas de
uso del sistema.
Permitir compartir archivos dentro del sistema. Esto servirá para que
los profesores puedan por ejemplo, dejar un registro de las
77
evaluaciones que hicieron sobre los alumnos durante el año. También
se podrán compartir ejercicios típicos para que los profesores de los
años siguientes sepan de donde partir para la planificación anual.
Instalar el sistema en las escuelas para ser utilizado por un grupo
reducido de profesores y así llevarlo a la práctica y poder obtener más
feedback del uso entre profesores y seguir mejorando el sistema.
Agregar al sistema diseño responsive para que pueda ser utilizado
desde tablets o celulares.
Integrarlo con la plataforma de desarrollo de videojuegos Simón, para
poder mostrar información que provee la aplicación en el perfil de los
alumnos que la utilizan.[8]
Mejorar la accesibilidad, para que personas no videntes puedan utilizar
esta herramienta con soporte para lectores de pantalla. Y además, se
puede agregar cambios de contraste de los colores para que pueda
ser utilizado por personas con daltonismo.
Ampliar el sistema no solo para alumnos integrados sino también a
alumnos con problemas de conducta o cualquier otra problemática que
pudiera requerir una atención especial.
Agregar Tags en los mensajes, por ejemplo en los del foro, para que
como mejora se pueda agregar una búsqueda y filtros en caso de que
se quiera encontrar información en la aplicación.
78
ANEXO
A.1 Introducción
En este capítulo se explica como se creo el ambiente de desarrollo del
trabajo. Se definen los pasos necesarios a seguir y se muestra un ejemplo de cómo
se utiliza la herramienta Gii para la creación de tablas en la base de datos y las
clases necesarias para respetar el modelo MVC planteado por el framework.
A.2 Uso de Yii
En el siguiente gráfico se muestran los pasos que se siguieron para crear el
ambiente de desarrollo de este proyecto.
Figura A.1 – Pasos para crear el ambiente de desarrollo
Paso 1: Es requisito para poder empezar con la instalación de Yii,
contar con un servidor Apache instalado en la máquina de desarrollo.
Paso 2: Descargar el framework desde la web, en la página
http://www.yiiframework.com/download/ y descomprimirlo dentro de ”nombre
de la carpeta”.
79
P aso 3: Ejecutar el comando : “YiiRoot/framework/yiic webapp
WebRoot/alumnosIntegrados” desde consola, para generar el esqueleto de la
aplicación. Con esto ya podemos ingresar desde el navegador a la pantalla
de login que viene por defecto.
Paso 4: Configurar la base de datos modif icando el archivo
protected/config/main.php con los datos de la base.
Código A.1 – Configuración de la base de datos
Paso 5: Se debe crear la base de datos y las tablas correspondientes con
sus relaciones. Las tablas se crean desde phpmyadmin, completando nombre
de la tabla, y las columnas con los datos correspondientes a cada una.
Además, se deben definir las relaciones con otras tablas, obteniendo una
tabla como la que se muestra a continuación.
80
Figura A.2 – Creación de la base de datos
Paso 6: Una vez que tenemos la base de datos definida, se utiliza el
generador de código Gii.
A.3 Uso de Gii
P a r a u t i l i z a r l o , p r i m e r o s e d e b e c o n f i g u r a r e l a r c h i v o
protected/config/main.php de la siguiente manera:
Código A.2 – Configuración de Gii
Por razones de seguridad, Gii se configura para que sea accesible solo
desde localhost. Si se requiere que sea accesible desde otras computadoras se
tiene que configurar la propiedad GiiModule::ipFilters.
81
P a r a a c c e d e r a G i i , s e d e b e h a c e r d e s d e l a u r l
h t t p : / / h o s t n a m e / p a t h / t o / i n d e x . p h p ? r = g i i , a s u m i e n d o q u e
http://hostname/path/to/index.php es la url para acceder a la aplicación.
Gii nos presenta las siguientes opciones de generadores de código:
Figura A.3 – Uso de Gii
Para este trabajo de tesis, se comenzó seleccionando el generador de
modelo. Este permite, a través del nombre de la tabla creada en la base de datos,
generar la clase correspondiente. Gii nos presenta la siguiente pantalla:
82
Figura A.4 – Creación de clases en Gii
Luego, se seleccionó el generador CRUD. Este genera las vistas básicas
para el modelo y el controlador asociado. La herramienta muestra la siguiente
pantalla con información a completar.
Figura A.5 - Creación de clases en Gii - 2
83
Las clases generadas para este ejemplo son:
AlumnoController.php
Alumno/form.php
Alumno/search.php
Alumno/view.php
Alumno/admin.php
Alumno/create.php
Alumno/update.php
Alumno/index.php
84
Referencias
[1]MEN. (1998). Acuerdo Marco A-19. Ministerio de Educación Argentina.
[2] R. Donato, M. Kurlat, C.Padín y V. Rusler, “Experiencias de inclusión educativadesde la perspectiva de aprender juntos”. Fondo de las Naciones Unidas para laInfancia (UNICEF), Junio de 2014.
[3] “Conferencia mundial sobre necesidades educativas especiales: Acceso ycalidad”. Salamanca, España Junio 1994.
[4] Cynthia Duk, “Educar en la diversidad”. Ministerio de educación de Brasil.
[5]Dubrovsky, S., Navarro, A., & Rosenbaum, Z.“Ilusiones y verdades acerca de laintegración en la escuela común. Buenos Aires: Secretaría de Educación. Gobiernode la Ciudad de Buenos Aires 2001
[6] Ley Nº 26.378
[7] Romina Lawson, “Integración de alumnos con necesidades educativas
especiales”. Universidad abierta interamericana, Noviembre de 2014.
[8] Mariel Ivonne Contreras, “Desarrollo de videojuegos como herramienta educacional y terapéutica para niños y jóvenes con discapacidad.”. Facultad de Ciencias Exactas UNCPBA, Tandil Marzo 2016.
85