Caracter´ısticas del sistema

Cap´ıtulo 4. Descripci´on del sistema 31

4.2.1.

Usuarios, recursos y grupos

El sistema cuenta con usuarios y recursos sobre los cuales se basar´an todas las funcionalidades.Los usuarios son registrados al mismo para poder realizar reservas sobre los recursos (aulas) creados. Este es el esquema de funcionalidad b´asico de la aplicaci´on.

El sistema en un principio era independiente, pero luego se vincul´o con el Servicio de Autenticaci´on Central (CAS) de la UNICEN 2_{. Por esto, cada usuario debe estar}

registrado con cuenta en el mismo y acceder al sistema a trav´es de la p´agina central del CAS. Esta vinculaci´on fue f´acilmente ejecutada, debido a que la misma aplicaci´on contaba con m´odulos para la integraci´on de sistemas externos.

Tanto los usuarios como los recursos registrados pueden ser agrupados en conjun- tos de acuerdo a las necesidades. En nuestro caso, estos grupos fueron definidos por unidad acad´emica para poder realizar una buena separaci´on de los elementos para una mejor y ordenada funcionalidad.

4.2.2.

Roles de usuarios

El sistema cuenta con la posibilidad de darle diferentes roles a los usuarios del mismo dependiendo del uso que se le da desde cada uno. As´ı, determinados usuarios puede acceder a las funcionalidades que les son alcanzables desde su rol.

A nivel m´as detallado del funcionamiento del sistema, los usuarios pertenecen a grupos, y estos tienen diferentes tipos de roles. Los roles con los que cuenta la aplicaci´on son 3, teniendo cada uno de estos diferentes accesos a funcionalidades del sistema o posibilidades dentro del mismo:

Administrador de aplicaci´on.

Administrador de recurso.

Administrador de schedule.

2 _{El CAS es un servicio que centraliza los usuarios y contrase˜nas de todo el personal de la} UNICEN. Su objetivo es que los usuarios no tengan m´ultiples nombres y contrase˜nas para cada sistema.

Cap´ıtulo 4. Descripci´on del sistema 32

Los administradores de la aplicaci´on pueden crear recursos, usuarios y grupos de estos, como as´ı tambi´en modificarlos. Los administradores de recursos, pueden reali- zar reservas sobre las aulas que gestiona, como as´ı tambi´en aprobar las reservas sobre sus aulas cuando se requiera. Losschedules en el sistema, son conjuntos de recursos. Los administradores de estos, est´an permitidos a realizar las acciones mencionadas anteriormente sobre los recursos pertenecientes al grupo que administra.

4.2.3.

Sistema de Permisos

Una de las razones por la cual se eligi´o trabajar sobre el sistema que se esta- ba usando, fue que este ya contaba con un m´odulo de permisos de usuarios sobre los recursos existentes. Esto incluye permisos tanto de lectura (para ver) como de escritura o edici´on (realizaci´on o modificaci´on) de reservas en el sistema.

A partir de esto, y una vez estudiado su funcionamiento, se pudo tambi´en agregar un comportamiento m´as adecuado a las necesidades y los requerimientos planteados. Por ello, se estudi´o la forma en quephpScheduleIt maneja los recursos para introducir los cambios necesarios. As´ı, se construy´o un ´arbol de decisiones que diagrama las cuestiones a tener en cuenta en cuanto a cada permisos de cada usuario sobre tal recurso.

Cap´ıtulo 4. Descripci´on del sistema 33

Figura 4.5: Usuarios que pueden aprobar una reserva.

En las Figuras 4.4 y 4.5 se observa dicha l´ogica. En la Figura 4.4 se muestra el ´arbol de decisiones para hacer o modificar una reserva. Se observa que existe un m´odulo que decide si un usuario tiene acceso ante a un recurso (Es Accesible). El permiso para ver las reservas sobre un aula s´olo llama a este m´odulo. En cambio, para poder realizar o modificar reservas (m´odulo ”Puede Editar”), se tiene en cuen- ta algunos conceptos m´as para decidir. A su vez, algunos recursos requieren que las reservas que son realizadas sobre ellos sean aprobadas. Dicha aprobaci´on ser´a realizada por determinadas personas que tengan los permisos adecuados. En cuanto a la aprobaci´on (Figura 4.5) primero la reserva debe ser aprobable. Luego, siendo administrador de la aplicaci´on, administrador de quien cre´o la reserva, o del recurso en el cual se realiz´o, se podr´a aprobar la misma.

En una primera etapa, no hubo mayores modificaciones al sistema original, ya que los usuarios se correspond´ıan con cada unidad acad´emica. La vinculaci´on con el CAS llev´o a una modificaci´on de la cantidad de usuarios por cada facultad. As´ı, existe la posibilidad de que varias personas manejen las aulas de una misma unidad acad´emica. Esto requiri´o que se modifique el sistema de permisos en cuanto a qui´en puede realizar, modificar o dar de baja las reservas sobre determinado recurso. La limitaci´on que surgi´o fue que las reservas creadas por un usuario deber´ıan poder editarse y eliminarse por otro colega de su misma unidad acad´emica (caso que no se permit´ıa en las aulas de Universidad de las que no eran administradores).

Para resolver este cambio de requerimientos se defini´o que haya un grupo para cada unidad acad´emica. Cada usuario pertenece al correspondiente grupo seg´un su Facultad. Estos grupos administran un conjunto de recursos (aulas propias) y, a su vez, tienen permisos sobre otros (reservas sobre aulas comunes). La forma de determinar si una reserva es editable (Figura4.4) se modific´o para permitir controlar

Cap´ıtulo 4. Descripci´on del sistema 34

reservas creadas por otro usuario de la misma unidad acad´emica. M´as precisamente, en el m´odulo Es Accesible se agreg´o la condici´on que establece si el creador de la reserva pertenece a la misma unidad acad´emica (mismo grupo) de quien quiere modificar dicha reserva. El diagrama final puede verse en la Figura 4.6.

Figura 4.6: Sistema de permisos final.