Casos de uso

En vista de los cambios que pronto afrontaremos, debemos tener siempre presente aquello para lo que, en principio, queremos usar Twin Panel. Este post intentará recoger los casos de uso, para así capturar requisitos y poder emprender el diseño.

Twin Panel debe ser una herramienta que permita explorar conjuntos de objetos. Casi cualquier cosa puede ser tratada como un objeto, desde un fichero hasta una máquina, o un mensaje. Dada esta pluralidad, es muy difícil concretar todos los casos de uso. Si encuentras alguno que falta, puedes comentarlo y se tendrá en cuenta.

Consideramos "contenedor" al elemento del sistema que posee al resto de elementos, siendo posible que estos, a su vez, sean "contenedores". Para evitar duplicar el texto, definimos los grupos de acciones permitidas:

• Acciones Mínimas: listar elementos del "contenedor".
• Acciones Básicas: las acciones mínimas, más: copiar, cortar, pegar, crear y eliminar elementos, entre nodos del mismo "contenedor".
  
• Acciones Ampliadas: acciones básicas entre nodos de "contenedores" diferentes (compatibles).

La lista de casos de uso es la siguiente:

• Exploración local de ficheros. Es el caso más obvio. Deber permitir explorar cualquier sistema de ficheros local (obviamente, que esté soportado por el kernel). Debe soportar las Acciones Ampliadas. El mecanismo de acceso podría ser GVFS.
  
• Exploración remota de ficheros. La extensión al caso anterior. Los mecanismos de acceso pueden ser variados: SSH, FTP, Ice... Debe soportar las Acciones Ampliadas. 
• Explorar el conjunto de máquinas de una red. Deberían poderse listar tanto las máquinas (con sus nombres, IP's u otros identificadores), como los servicios que proveen. El conjunto de acciones permitido serían las Acciones Mínimas.
• Visualizar los elementos que componen un documento web. Dependiendo del método de acceso, debería soportarse el conjunto de Acciones Básicas o Acciones Ampliadas.

Podríamos tener descripciones similares para los siguientes casos:

• Objetos Ice
• Elementos de UPnP
• Servidor POP3
• Dispositivos Bluetooth
• Nodos ZigBee
• Redes y AP's WiFi
• Procesos del sistema
• Puertos abiertos con sus servicios asociados
  
• Bibliotecas multimedia (picassa, flickr, youtube...)
  
• Entornos sensibles a localización (GIS)
• Dispositivos X10 de un entorno
• ...

Examinando estos casos, surgen algunas cuestiones que tratar:

1. Debemos definir un mecanismo preciso para la interacción entre diferentes mecanismos de acceso a estos "contenedores" (por ejemplo, para copiar un fichero desde un SF remoto a uno local, usando SSH), algo que todavía no se había abordado.
2. Debemos ser muy estrictos con las interfaces que cada "plugin" debe cumplir. Uno de los problemas que presenta la versión actual es que no hay un conjunto bien definido de interfaces, lo que permite registrar plugins incompletos que desestabilizan el sistema.
3. Es necesario disponer de una buena documentación desde el principio. Si un desarrollador hace un plugin, pero no dispone de toda la documentación necesaria, perderá mucho tiempo, hará cosas duplicadas, y posiblemente causará otros problemas al resto del sistema.
4. Pruebas. He aprendido (por fin :D) que es un aspecto clave a la hora de desarrollar software. Como dice incansablemente David: "las pruebas merecen la pena", y yo añado "sin pruebas, se pierde tiempo y es muy difícil abordar problemas complejos (sin causar otros)".

Con el nuevo diseño que se está planteando, algunas de estas cosas se resuelven. Por ejemplo, el uso de interfaces; utilizando Zeroc-Ice, se fuerza la utilización de interfaces.

Sigamos discutiendo aspectos del diseño.