¿Qué es primero? ¿El huevo o el pollo rostizado? Que haces primero, las funciones de operación o todo el esquema de usuarios y los privilegios que estos tienen sobre las operaciones. Independientemente si eres un programador OO o eres “funcional”, el iniciar de la manera equivocada puede repercutir en tiempo de reescritura de código adecuando tus funciones o métodos (o peor, todo tu objeto) a los permisos o privilegios que le des a los usuarios de tu sistema.

Estaba escribiendo un sistema que debía incluir un método de otorgamiento de privilegios de acceso a operaciones y funciones. Estos permisos si bien tienen una recomendación y ciertos parámetros forzosos, también debían ser lo suficiente dinámicos como para que si, dentro de los esquemas de privilegios “default” el usuario administrador podría dotar de permisos particulares a usuarios.

Por supuesto no iba a gastar tiempo generando interfases separadas. Reusar código en un sistema no es cortar código y pegarlo en otro lugar! Para mi es diseñar objetos y métodos que pueda usar a lo largo de varios escenarios. Es un simple ley del “menor esfuerzo” aunque pensar las soluciones requieren de mucho esfuerzo.

Mi propuesta de solución: Iniciar diseñando todas los parámetros que definen los provilegios de un usuario. Tomemos de ejemplo un sistema sencillo de recursos humanos (que por cierto recien terminé).
Un usuario tienen, por supuesto una clave de ingreso y un nombre de usuario, el usuario puede ser de diferentes perfiles: administrador del sistema, usuario de RR.HH. o un Gerente de RR.HH. Un usuario de RR.HH tiene asignadas una o mas áreas de “expertise”, tiene acceso o no a ciertas operaciones, es decir, no voy a dejar que un usuario RR. HH. cree usuarios o peor que borre usuarios! eso es un privilegio que solo el usuario administrador de sistema poseerá. El esquema de Casos de Uso para cada usuario nos va a determinar, una serie de “privilegios” que pueden ser catalogados, de allí que apartir de los privilegios pueda crear tablas de tipo catálogos con cada una de las opciones o provilegios de usuario.

De lo anterior, entonces se vislumbra la necesidad de catálogos para tipo de perfiles (Administrador de sistema, Usuario y Gerente), áreas de dominio (Informatica, Contaduría, Administración), el obvio catálogo de usuario (nombre de usuario, clave, identificador único etc).

Hasta aquí todo es muy natural, pero lo que muchas veces pasa de alto es que dados los catálogos, igualmente estamos obteniendo las necesidades funcionales del sistema, en este casi una manera que permitan administrar esos catálogos. Ahora, que te parece lo siguiente, si esto también se aplica a las caras que el sistema poseerá para los diferentes perfiles de usuario, entonces que tal si existe un catálogo de privilegios.

No se si ya lo viste, pero al crear un catálogo de privilegio lo que estas haciendo es una suma de todas las funciones que deberá poseer tu sistema. Claro si tienes el tiempo de realizar un diagrama de Casos de Uso eso lo tendrás ya en mente, pero por el escenario, frecuente en mi medio, donde a) no tienes el tiempo para realizar un RUP o algo! y/o b) Los requerimientos del sistema de repente, como siempre pasa, se ven modificados. Si diseñaste tu sistema a un catálogo de funcionalidades, será cuestión de añadir la operación en tu catálogo y asociarla al perfil/usuario.

El concepto te lo dejo de tarea, la verdad no me había dado cuenta de algo que estaba en mis narices hasta el día que tuve que modificar la mitad de mi código, cuando mi jefe me comunicó que requería que hubiera, tipos de administradores de sistema, que modificaran a las áreas de su dominio.