Interacción entre clases

Introducción

HD Lorean posee dos bloques bien diferenciados, uno es el backend y el otro el frontend o interfaz de usuario. El primero se encarga de la comunicación entre el hardware y las tecnologías que permiten la gestión de snapshots y la monitorización de ficheros. El otro se encarga de la comunicación con el usuario.

Entre ellos, pero formando parte de backend, se encuentra el módulo D-Bus Manager. Esta clase no se limita únicamente a encapsular d-bus sino que su misión es la de traducir los mensajes que reciba en un conjunto de órdenes internas de HD Lorean, las cuales enviará a los distintos módulos de la aplicación para que se realice el trabajo necesario.

Dentro del backend, a su vez, es posible distinguir dos subgrupos importantes que separan además dos cursos de colaboración frecuentes. Por un lado, el grupo formado por las clases config file manager, watcher, scheduler, inotify handler y cron handler forman la ruta de planificación y configuración. Por otro, el formado por snapshot manager y el conjunto de clases que utilizan como interfaz storage manager, que forman la ruta de gestión de snapshots.

Ruta de comunicación con el usuario

Gran parte de los casos de uso son desencadenados por el usuario y por tanto requieren la comunicación con HD Lorean. Para ello existen las clases pertenecientes al frontend. En general, el comportamiento de esta ruta es el siguiente.

  1. Frontend (alguna de sus clases: el diálogo de preferencias, el asistente de configuración, el visor de snapshots…).
  2. D-Bus Manager (recibe un mensaje con la tarea requerida por el usuario).
  3. Ruta de gestión de planificación y configuración

La sencillez de la ruta se apoya en la necesidad de mantener lo más separado posible la interfaz de usuario del backend.

Por último, existe también una ruta inversa (puede denominarse Ruta de comunicación con el usuario inversa) que permite que resultados internos de HD Lorean lleguen en forma de mensajes al frontend y este pueda exponerlos al usuario de alguna forma. Ésta es:

Ruta de comunicación con el usuario inversa

  1. Ruta de gestión de planificación y configuración (desde aquí se emite algún resultado que debe mostrarse al usuario).
  2. D-Bus Manager (dbus recibe el resultado y transmite un mensaje al frontend; alternativamente el frontend escucha mensajes del backend y presenta la información según sea necesario).
  3. Frontend.

Ruta de planificación y configuración

Como se dijo anteriormente, la ruta de planificación engloba las colaboraciones entre config-file-manager, watcher, scheduler, inotify-handler y cron-handler. Config file manager se encarga de la gestión del archivo de configuración, tanto de su versión física escrita en disco como de su versión virtual a la que el resto de módulos puede acceder para conocer diversos aspectos de la configuración. Los inotify handler y cron handler disparan eventos de inotify y cron que permiten monitorización de cambios en tiempo real y bajo planificación respectivamente. También disponen de acceso, a través de la clase clases, a una base de datos rápida o journal donde anotan las operaciones que han de realizarse próximamente, para poder planificarlas y reiniciarlas (a modo de transacciones semiatómicas) a fin de poder recuperarse de caídas del sistema o del programa, planificadas o no.

El scheduler por otro lado se encarga de gestionar y priorizar las órdenes que le llegan desde los disparadores o directamente desde el módulo de dbus, en función de la carga del sistema recogida de diversos monitores. También se comunica con la ruta de gestión de snapshots y atiende a sus resultados como veremos en breve.

La ruta de colaboraciones típica se muestra a continuación:

  1. D-Bus Manager (dbus tiene algún mensaje que convertir en órdenes)
  2. Config file manager (desde dbus se indica si ha de modificarse alguna configuración)
  3. Scheduler (desde dbus se informa al scheduler de alguna orden recibida desde el frontend)
    1. Battery monitor
    2. CPU load monitor
    3. HD Load monitor
  4. Ruta de gestión de snapshots

Desde aquí, dependiendo de la orden, el planificador accedería a la ruta de gestión de snapshots bien para ordenar la creación de un nuevo snapshot, bien para recuperar la información de alguno de los existentes, bien para eliminar algunos de ellos. A esta ruta la llamaremos ruta de usuario.

Como HD Lorean actúa en su mayor parte del tiempo sin necesidad de interacción por parte del usuario, incitado por inotify o cron, otra ruta alternativa probablemente más frecuente que la anterior es la siguiente:

  1. Cron handler o inotify handler (se ha producido algun cambio en un fichero o directorio que debe ser guardado, o se ha producido una señal planificada).
  2. Watcher (escritura al journal y tratamiento del suceso en función de si es cron o inotify)
  3. Scheduler (prioriza las señales recibidas de los módulos anteriores)
  4. Ruta de gestión de snapshots

A esta última ruta la llamaremos ruta de monitorización.

Igual que en el caso anterior, existe una ruta inversa que parte de los resultados de la ruta de gestión hasta llegar a dbus.

Ruta de monitorización inversa

  1. Ruta de gestión de snapshots (la ruta emite algún resultado en forma de objeto Snapshot)
  2. Snapshot manager (objeto con los resultados de la ruta de gestión)
  3. Scheduler (recibe el resultado de una orden)
  4. D-Bus Manager (recibe, si procede, los resultados un mensaje con los resultados de la operación).

Ruta de gestión de snapshots

Esta última ruta está formada por las clases snapshot manager, y el conjunto de storage manager. La primera, snapshot-manager, ofrece toda la funcionalidad relativa a la gestión de snapshots como la creación, eliminación o lectura de los mismos. Esta clase hace uso del conjunto storage manager que ofrece el nivel más bajo de funcionalidad a través de una API común. Los integrantes del módulo codifican esta API dependiendo de si el soporte de snapshots es un sistema de archivos (como LVM o ZFS), una aplicación externa (como xdelta3) o un modelo propio (como snapshot-core), para tratar de permitir el uso del sistema más eficiente según dónde se desplegase la aplicación, así como para obligarnos a separar ese componente crítico del resto de funcionalidad de la aplicación.

La clase Snapshot sirve de puente de comunicación entre Scheduler y la ruta de gestión que nos ocupa. La clase representa un Snapshot como resultado con capacidad para autoarchivarse dentro de una posible base de datos y con toda la información útil que fuese necesaria. Es el resultado de las operaciones de lectura, escritura o eliminación de la ruta de gestión.

La ruta de colaboraciones típica es la siguiente:

  1. Snapshot manager (la orden llega desde el scheduler)
  2. Storage manager (entre ellos, el más adecuado al medio)
  3. Snapshot manager (recibe la terminación del módulo que corresponda)
  4. Snapshot (se crea un objeto snapshot con información relevante asociada a la operación)
  5. Ruta de planificación y configuración

NOTA: En esta última se ha incluido el retorno inverso hasta la comunicación con la ruta de planificación. Hay que notar, que gran parte de estos retornos son implícitos debido al retorno de llamadas a función.

Rutas por casos de uso

Con todas las rutas especificadas, la elaboración de las colaboraciones por casos de uso es mucho más sencilla y clara.


Añadir una nueva carpeta a indexar

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (cambio en la configuración y órdenes)
3. ruta de gestión de snapshots (creación del snapshot)


Borrar todas las versiones de un archivo

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (cambio en la configuración y órdenes)
3. ruta de gestión de snapshots (Cambios a disco, bases de datos)


Borrar una versión de un archivo

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (cambio en la configuración y órdenes)
3. ruta de gestión de snapshots (cambios a disco, bases de datos)


Configurar exclusión

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (cambio en la configuración y órdenes para borrar el patrón; posible feedback al usuario)
3. ruta de gestión de snapshots (consultas a bases de datos, posiblemente borrar, devolver el feedback que sea necesario)


Configuración inicial

1. Ruta de comunicación con el usuario (mediante el asistente)
2. Ruta de planificación y configuración (cambio en la configuración y actualizar estado actual)
3. ruta de gestión de snapshots (si es necesario realizar trabajo o añadir algo)


Copiar al lado

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (cambio en la configuración y órdenes)
3. ruta de gestión de snapshots (lectura y posible reconstrucción del snapshot)


Eliminar una carpeta a indexar

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (cambio en la configuración y actualizar estado actual)
3. ruta de gestión de snapshots (escrituras a disco y base de datos)


Sincronizar

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (registro en base de datos)


Exportar a un dispositivo externo

1. Ruta de comunicación con el usuario, posiblemente colaborando con HAL (en el backend, para detectar dispositivo)
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (registro en base de datos de dónde se encuentra la información; posible eliminación local para ahorrar espacio).


Importar de un dispositivo externo

1. Ruta de comunicación con el usuario, posiblemente colaborando con HAL (en el backend, para detectar dispositivo)
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (añadido a base de datos de la nueva información, comprobando inconsistencias; ver el caso de uso).


Guardar un backup

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (escrituras a disco y base de datos).


Guardar versiones automáticamente

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (posible actualización del estado).


Backup inicial

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (creación de estructuras de datos pertinentes; primer backup).


Sobreescribir última versión

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (lectura del snapshot, reconstrucción del mismo).


Buscar contenidos en backup

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (búsqueda en base de datos).
3.a Alternativamente, además usar clases.


Almacenamiento extra

No cubierto inicialmente por no ser en absoluto crítico.


Interrupción del backup

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes)
3. ruta de gestión de snapshots (según queden o no tareas pendientes)


Aplicaciones de terceros

No cubierta inicialmente al depender de un estado de desarrollo bastante más avanzado de la aplicación y no ser crítico. En cualquier caso el componente dbus ofrece un api de cara a otras interfaces de usuario para la aplicación.


Ver versiones de carpetas

1. Ruta de comunicación con el usuario
2. Ruta de planificación y configuración (órdenes, recibir información)
3. ruta de gestión de snapshots (lectura de los listados de base de datos)


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License