Data Collection Processes for Case Studies

En la sección anterior (sección 5.2.1) se presentaron los requerimientos de seguridad del sistema. Dichos requerimientos se expresaron como una política de seguridad, misma que será utilizada a lo largo de esta sección y sus sub-secciones para guiar el proceso de diseño del sistema.

En las sub-secciones siguientes se presenta el proceso de diseño del sistema tomando como base la política descrita y utilizando como apoyo la herramienta DSMAS, desarrollada para este propósito y la cual se describe en el apéndice 1 de este trabajo.

5.2.2.1 El análisis

Siguiendo los lineamientos expuestos en el capítulo 4, la primera etapa del diseño es el análisis, en el cual se desarrollará el modelo organizacional y los modelos preliminares de restricciones, comportamiento, roles, interacciones y del ambiente.

El sistema bien podría diseñarse para explotar múltiples organizaciones, por ejemplo una organización para cada país participante en el sistema. Esto sería conveniente ya que los componentes que representan a cada país son independientes del resto del sistema. Sin embargo no hay una delimitación clara de responsabilidades ya que los componentes de cada país realizarán las mismas tareas que los del resto de los países.

Otra posible división podría realizarse con respecto a las dos tareas principales del sistema: la realización de consultas y la creación de itinerarios. Esta división no es del todo conveniente pues la creación de itinerarios utiliza la realización de consultas para su operación.

El sistema estará compuesto por una sola organización a la cual pertenecerán todos sus elementos. El modelo preliminar de restricciones para el sistema se muestra en las imágenes 5.1 a 5.4, las cuales fueron obtenidas mediante la captura de restricciones en la aplicación DSMAS.

Imagen 5.4. Modelo preliminar de restricciones del sistema @lis.

En el modelo preliminar de restricciones se presentan 23 restricciones derivadas de las 26 restricciones originales descritas anteriormente. Las restricciones originales 1, 26, 27 y 28 fueron agregadas al modelo sin cambios y están representadas en las restricciones 1, 23, 21 y 22 del modelo de restricciones respectivamente. Las restricciones 23 a 33 indican atributos necesarios en las entidades y recursos para la verificación de diversas restricciones.

En la siguiente tabla se presenta la relación entre las restricciones originales de la política y su representación en el modelo preliminar de restricciones.

Representación en el modelo Restricciones originales

1 1 2 2, 14 3 3, 16 4 4, 18 5 4,18 6 5, 24 7 5, 24 8 5, 24 9 6, 22 10 6, 22

11 6, 22 12 7, 20 13 7, 20 14 8, 15 15 9, 17 16 10, 19 17 11, 25 18 12, 23 19 13, 21 20 26 21 27 22 28

Tabla 2. Representación de la política original en el modelo de restricciones

En el modelo preliminar de restricciones se pueden identificar algunas de las entidades del sistema. Entre estas entidades están la interfaz de usuario, el proveedor, el planeador de itinerarios y el servicio de consulta. De la misma manera se pueden identificar algunos recursos como lo son los perfiles de usuarios, los perfiles de proveedores, las ofertas turísticas, los registros de pagos, los registros de reservaciones y los itinerarios.

Además de las entidades y recursos, en el modelo preliminar de restricciones se pueden identificar algunas de las acciones que las entidades pueden realizar sobre los recursos. Entre ellas están la lectura y escritura, las cuales están sujetas a las restricciones establecidas en la política.

Las entidades en el sistema deben interactuar entre ellas para poder realizar las tareas para las cuales fueron diseñadas. Anteriormente se mencionó que los servicios serían dados de alta y eliminados de manera dinámica por lo que debe existir al menos un registro de servicios en el cual se establezca cuales servicios están presentes en el sistema. Este registro podría modelarse como un recurso, es decir como una lista de servicios activos en el sistema, sin embargo cada servicio tendría que poder leer y escribir en dicho recurso además de que las entidades que necesiten averiguar si un servicio está activo tendrían que leer el mismo recurso. La concurrencia en lectura y escritura del recurso podría ocasionar problemas de coherencia por lo que es más adecuado modelar el registro como una entidad. Esta entidad mantendría la lista de servicios activos permitiendo a los servicios registrarse y al resto de las entidades consultar los servicios activos.

El sistema tendrá entonces dos elementos más, una entidad que realice la gestión de servicios y un recurso que represente un registro de servicios. La entidad gestor de servicios actuará sobre el recurso registro de servicios ya sea leyendo su contenido o escribiendo el mismo.

Entonces, las entidades que requieran interactuar con los servicios de consulta tendrían que interactuar con el registro de servicios para identificar a las entidades de servicio de consulta con las cuales tendrían que interactuar. La interfaz de usuario y el planeador de itinerarios son las entidades que realizan consultas a los servicios de consulta.

Los servicios de consulta tienen la tarea de identificar ofertas turísticas de acuerdo a ciertos parámetros. La interfaz de usuario y el planeador de itinerarios utilizan las ofertas identificadas por el servicio de consulta y de ellas obtienen información acerca de los proveedores de servicios turísticos con los cuales deberán interactuar para poder realizar reservaciones, pagos y cancelaciones.

La interfaz de usuario deberá interactuar con el planeador de itinerarios para obtener itinerarios y para poder modificar, reservar, cancelar y pagar los itinerarios además de recibir notificaciones de contingencias. A su vez, el planeador de itinerarios deberá interactuar con los proveedores para reservar, cancelar, pagar y recibir notificaciones de contingencias de los servicios que constituyen el itinerario.

En las imágenes 5, 6 y 7 se presenta el modelo preliminar de comportamiento del sistema tomando en cuenta las entidades, recursos y acciones identificados en el modelo preliminar de restricciones y las nuevas entidades e interacciones descritas en los párrafos anteriores.

De el modelo preliminar de comportamiento se pueden identificar 5 entidades activas, las cuales son modeladas como roles en el modelo preliminar de roles que se presenta en la imagen 5.8.

Imagen 5.6. Modelo preliminar de comportamiento (interacciones).

Imagen 5.8. Modelo preliminar de roles del sistema @lis.

En la imagen 5.9 se presenta el modelo de interacciones del sistema, en el cual se han modelado como protocolos las interacciones descritas en el modelo de comportamiento (imagen 5.6).

Antes de pasar al diseño arquitectural es necesario modelar algunas reglas organizacionales que soporten el modelo de seguridad. Las restricciones de la política no definen explícitamente que entidades pueden coexistir simultáneamente. Por ejemplo, una entidad no puede ser un Proveedor y un Usuario al mismo tiempo. A continuación se presentan las reglas organizacionales del sistema @lis.

~ (Usuario | Proveedor) ~ (Usuario | GestorDeServicios)

~ (Usuaro | ServicioDeConsulta) ~ (Planeador | Proveedor)

~ (Planeador | GestorDeServicios) ~ (Planeador | ServicioDeConsulta) ~ (Proveedor | GestorDeServicios) ~ (Proveedor | ServicioDeConsulta) ~ (ServicioDeConsulta | GestorDeServicios)

En conjunto, los modelos presentados representan la salida de la fase de análisis del sistema @lis. A través de ellos se modelaron las funcionalidades mínimas del sistema y los requerimientos del mismo en cuanto a operación y seguridad. En la siguiente sección se discute y detalla el uso de estos modelos dentro de la fase de diseño arquitectural.

5.2.2.2 El diseño arquitectural

A lo largo de esta fase se definirá la estructura que finalmente el sistema presentará. Como paso inicial se debe definir la arquitectura organizacional, es decir, las entidades o roles del sistema y la relación que entre ellos habrá.

En la fase de análisis se identificaron 5 roles: Usuario, Proveedor, Planeador, GestorDeServicios y ServicioDeConsulta. Sin embargo, las restricciones del sistema hacen evidente la necesidad de incorporar nuevos roles al sistema. El primero de ellos resalta con la restricción R14. En ella se indica que solo el rol Usuario puede escribir el perfil de usuario y solo puede escribir el perfil perteneciente al usuario al que representa la entidad. Lo mismo sucede con la restricción R15 al indicar qué entidad es la autorizada a escribir perfiles de proveedores. Ambas restricciones requieren que se verifique una condición pero la entidad que podría verificarla es la misma que debe cumplir la condición. Se propone entonces una nueva entidad, gestor de perfiles, encargada de la gestión de los perfiles de usuario y de proveedor.

Lo mismo sucede con los registros de reservaciones, pagos e itinerarios por lo que se propone otra entidad, gestor de registros, encargada de la gestión de estos registros y de verificar el cumplimiento de las restricciones sobre ellos impuestas.

Los servicios de consulta se pueden dividir en 3 grupos, aquellos que responden a consultas acerca de hospedajes, los que responden a consultas de transporte y los que responden a consultas sobre actividades. Podrían modelarse como tres diferentes roles, sin embargo su naturaleza es la misma y solo se diferencian por el tipo de datos que responderán en las consultas. Por lo tanto se considerarán como un solo tipo de entidad.

En la imagen 5.10 se presenta la arquitectura organizacional del sistema integrando las entidades previamente identificadas y las aquí propuestas.

Imagen 5.10. Arquitectura organizacional del sistema @lis.

Una vez que se definieron los roles del sistema, se debe detallar cada uno de ellos. En la imagen 5.11 se presenta el modelo de roles del sistema.

Algunos de los cambios realizados a los roles no se aprecian en el modelo de roles pues los protocolos y actividades son incluidos sin diferencia en los esquemas. El rol Usuario previamente se había definido con acciones directas sobre el perfil de usuario, esta tarea la realizará a través de una interacción con el gestor de perfiles quien verificará que las restricciones sobre la lectura del perfil de usuario se cumplan. El mismo caso se da para las acciones de escritura de perfil de usuario, escritura de perfil de proveedor y lectura de perfil de proveedor, las cuales se convierten en interacciones con el gestor de perfiles.

Un caso similar se da con las acciones de lectura y escritura de pagos, reservaciones, itinerarios y ofertas, los roles que realizaban estas acciones ahora realizan interacciones con el gestor de registros, el cual verifica el cumplimiento de las restricciones sobre los registros. En las imágenes 12, 13 y 14 se presenta el modelo de interacciones del sistema.

Imagen 5.14. Modelo de interacciones del sistema @lis.

En las tres primeras etapas del diseño detallado se definieron y modelaron nuevos roles y se modificaron los definidos en la fase de análisis convirtiendo algunas de sus acciones en interacciones con nuevas entidades. Los cambios realizados implican que el modelo de restricciones debe ser actualizado y revisado de modo que las nuevas acciones e interacciones y los nuevos roles cumplan con las restricciones impuestas en la política original. Varias de las restricciones que se habían definido en el modelo preliminar de roles

no son aplicables al sistema con las modificaciones realizadas. En las imágenes 15, 16 y 17 se presenta el modelo de restricciones final del sistema.

Imagen 5.17. Modelo de restricciones del sistema @lis.

Imagen 5.19. Modelo de comportamiento (acciones).

Imagen 5.21. Modelo de comportamiento (interacciones, parte 2).

En las imágenes 18, 19, 20 y 21 se presenta el modelo de comportamiento del sistema @lis.

Las reglas organizacionales del sistema deben también ser adaptadas a los nuevos elementos y cambio realizados, a continuación se presentan las reglas organizacionales actualizadas.

~ (GestorDePerfiles | Usuario) ~ (GestorDePerfiles | Proveedor)

~ (GestorDePerfiles | Planeador) ~ (GestorDePerfiles | ServicioDeConsulta) ~ (GestorDeRegistros | Usuario) ~ (GestorDeRegistros | Proveedor)

~ (GestorDeRegistros | Planeador) ~ (GestorDeRegistros | ServicioDeConsulta) ~ (GestorDeServicios | Usuario) ~ (GestorDeServicios | Proveedor)

~ (GestorDeServicios | Planeador) ~ (GestorDeServicios | ServicioDeConsulta) ~ (Usuario | Proveedor) ~ (Usuario | ServicioDeConsulta)

~ (Usuario| ServicioDeConsulta) ~ (Proveedor | Planeador) ~ (Proveedor | ServicioDeConsulta)

5.2.2.3 El diseño detallado

Ya que han sido definidos los roles que existirán en el sistema el siguiente paso es definir clases de agentes que actuaran dichos roles. Hay que tomar en cuenta las reglas organizacionales y la política de seguridad para asegurar que dos roles que no pueden coexistir no sean actuados por la misma clase de agente. En la imagen 5.22 se presenta el modelo de agentes del sistema @lis.

Imagen 5.22. Modelo de agentes del sistema @lis.

Ya que las tareas de los roles GestorDeRegistros, GestorDeServicios y GestorDePerfiles son muy similares y no hay ninguna restricción que indique que no pueden coexistir, se propone una sola clase de agente que actúe los tres roles.

El rol Planeador tiene como función realizar tareas en nombre del rol Usuario, así se modela la clase AgenteDeUsuario que actúa ambos roles. Para los roles Proveedor y ServicioDeConsulta se modelan las clases AgenteProveedor y AgenteDeConsulta respectivamente.

En las imágenes 23 y 24 se muestra el modelo de servicios del sistema. Como se puede apreciar en este modelo, no se estableció un servicio correspondiente a cada protocolo, algunos protocolos fueron modelados como un solo servicio debido a su similaridad, por ejemplo, para la clase AgenteDeUsuario existen dos protocolos asociados de la lectura de reservaciones, uno correspondiendo a cada rol que esta clase de agente actúa, ambos protocolos son modelados dentro del servicio UsuarioLeeReservación.

Cada servicio definido hereda las restricciones del protocolo que modela. En los casos donde se modeló más de un protocolo en el mismo servicio, dicho servicio hereda todas las restricciones asociadas a cada uno de los protocolos que modela.