El protocolo 9P está muy integrado en PLAN 9. Nos interesaría que PLAN 9 pudiese acceder a recursos de otras máquinas con arquitecturas y sistemas muy diferentes. Por ello queremos implementar un servidor 9P para otros sistemas.
Plan 9 no es un sistema operativo muy difundido hoy por hoy. La gran mayoría de sistemas que están implantados no ofrecen un modo de acceso claro a sus recursos, para las máquinas con Plan 9.
Implementando un servidor 9P que pueda ejecutarse en otros sistemas diferentes de Plan 9, potenciaremos la capacidad de éste para usar recursos de otras máquinas.
En la figura 2-1 vemos un ejemplo de cómo un cliente 9P, en un sistema Plan 9, accede a recursos de otras plataformas, que los distribuyen mediante el protocolo 9P.
figura 2-1 Cliente 9P accediendo a
servidores con sistemas ajenos a Plan 9
Además existen otras motivaciones, por ejemplo, supongamos que tenemos un sistema con Plan 9 y varios dispositivos como agendas personales o teléfonos móviles. Entendemos que todos los periféricos tienen acceso al mismo medio de transmisión que el sistema con Plan 9. En este caso, poder acceder a los recursos de estos periféricos desde Plan 9 no nos aportaría gran beneficio (en lo que a cantidad de recursos se refiere), pero nos ofrecería movilidad.
Podemos imaginar un programa hospedado en el sistema con Plan 9. Este programa está haciendo uso de todos los recursos del sistema con Plan 9, pero podría ser que esté recaudando información de todos los pequeños periféricos a los que tiene acceso, o incluso podría cambiar su comportamiento dependiendo de unos parámetros que estén ubicados dentro de un periférico (con lo que lograríamos algo parecido a un control remoto).
Una vez identificado el problema, debemos fijarnos unos objetivos o requisitos que deberíamos cumplir para que la implementación del servidor resulte útil.
Protocolo 9P como estándar:
Si pretendemos que el servidor sirva correctamente a todos los clientes 9P que se conecten a él, debemos ajustarnos a la especificación del protocolo 9P.
Puesto que pretendemos que el servidor pueda ejecutarse en múltiples máquinas debemos hacer un diseño altamente portable, que no sea costoso implementar para múltiples plataformas.
Ya que de un protocolo se trata, y puede estar sujeto a futuras ampliaciones, sería un requisito deseable que la modificación fuese lo más sencilla posible. Un diseño modular y claro facilitará este requisito.
Es necesario que el rendimiento cumpla unos límites. No nos vale de nada un servidor que tarde un tiempo excesivo en responder a una petición que debería ser prácticamente instantánea.
2.3. Metodología de desarrollo: Desarrollo espiral
Las metodologías de desarrollo ayudan a desarrollar un producto de software, siguiendo unas pautas para producir el software deseado. Estas metodologías pueden ser tan simples como sentarse a hablar sobre la aplicación o tan sofisticadas como usar lenguajes formales y diagramas, para especificar el desarrollo del software. Las metodologías de software dividen el desarrollo de un producto en cuatro fases fundamentales: análisis, diseño, desarrollo y verificación.
Existen muchos métodos de desarrollo para producir una aplicación desde su fase de análisis al producto final. Una de las metodologías mas comunes es el desarrollo espiral basado en prototipos.
La metodología de desarrollo espiral se basa, fundamentalmente, en generar prototipos de la aplicación y retomar a las fases de análisis, diseño y desarrollo tras cada prototipo, para mejorar o añadir nuevas funcionalidades al producto. Es, por tanto, una metodología iterativa, que retorna a las fases anteriores del desarrollo para iniciar un nuevo ciclo. Con cada ciclo la aplicación está más acabada. En la figura 2-2 podemos ver una representación del modelo.
figura 2-2 Metodología de desarrollo espiral
Una breve explicación, paso a paso, de la metodología mostrada en la figura 2-2 sería como sigue:
· El proyecto se inicia con un análisis previo del problema, pudiendo usar las herramientas necesarias para realizar el análisis, como entrevistas al usuario, especificaciones de requisitos, textos descriptivos del problema que es necesario resolver.
· Tras el primer análisis, se realiza un diseño de la aplicación (al igual que en el análisis, pudiendo usar las herramientas de diseño de las que dispongamos).
· La fase de desarrollo genera el primer prototipo construido a partir del diseño anterior.
· Finalmente pasamos a evaluar el
prototipo. Si falla en algún aspecto retornaremos a la fase de análisis,
realizaremos un nuevo diseño e implementaremos un nuevo prototipo.
Las iteraciones de las fases de desarrollo se producirán hasta que lleguemos al producto final. Con cada iteración iremos encontrando prototipos más cercanos al software final, siendo también en cada nuevo ciclo los cambios menos frecuentes.
Para el desarrollo del presente proyecto hemos seguido esta metodología. La fase de análisis fue realizada, fundamentalmente, con entrevistas verbales con el tutor del proyecto y lectura de la documentación del protocolo 9P.
Tras las entrevistas se procedió a realizar un diseño, elaborado generalmente mediante diagramas de interacción entre entidades y tratando de cumplir a las ideas captadas en el análisis. La implementación de los prototipos se realizó directamente en un lenguaje de programación, siendo más concretos, los prototipos han sido realizados en JAVA.
La evaluación de los prototipos tuvo dos fases:
· Verificar que el software generado cumple las características del diseño.
· Analizar los prototipos junto
con el tutor del proyecto.
Con la evaluación se rechazaba el prototipo o parte de él, retornando la fase de análisis para solucionar los problemas.
Jaime Garzón Pérez 2006 