Especificaciones de requisitos

Lamento haber estado tanto tiempo sin escribir, pero todo ha sido derivado por problemas de agenda. Sí, ya sé que seguramente podría haber sacado 20 minutos para actualizar un poco esto.

Esta entrada está referida a los requisitos que he obtenido que, a mi parecer, debería tener el framework para poder ser efectivo. Como principales objetivos de los que parto para reunir las especificaciones son los siguientes:

1. Encapsulación del código para su mejor mantenimiento y futuros desarrollos que puedan derivar de código ya escrito.
2. Dar capacidad al desarrollador de ahorro de tiempo. El desarrollador por lo tanto, tiene que escribir menos lineas de código que lo haría con un desarrollo normal. Hay que tener en consideración el punto anterior.

A partir de aquí, derivan los siguientes requisitos. Puede que sea un breve número, pero debido a la abstracción que esto requiere, prefiero que sean genéricos y también lo suficientemente abstractos para que una vez en la etapa de desarrollo se puedan ir desglosando o añadiendo nuevos. Por supuesto, espero que las siguientes etapas no sean tan abstractas, aunque como se ha dicho, prefiero que el desarrollo sea lo suficientemente dinámico para cambiar requisitos y diseño (también espero que ésto no sea muy frecuente :P).

1. Crear una serie de clases que permitan implementar con facilidad nuevos componentes de interfaz de usuario. El objetivo se centraría en poder crear una buena estructura de las clases que componen el proyecto, para que pueda facilitarse el trabajo al desarrollador a la hora de utilizarlas para sus proyectos personales y poder a su vez, reutilizarlos en otros proyectos sin causar errores críticos en el funcionamiento.

2. Abstracción de dependencias con otras librerías que pueda ser usada en el sistema (por ejemplo, si el modelo son objetos de persistencia). Lo mas normal es que la simpleza de los diversos componentes del framework pueda hacer que se puedan utilizar elementos de otras librerías y frameworks tanto en la parte del modelo como en la vista.

3. El modelo debe notificar a los controladores que dependan activamente de el. Con lo cual se podrá mantener en tiempo real el reflejo de las estructuras de datos del modelo sin que haya un gran consumo de recursos que afecten la aplicación. Por ejemplo, al crear un nuevo elemento, se guardaría en la base de datos, pero no se debería volver a pedir toda la información referente a el a la base de datos otra vez.

4. El controlador deberá implementar un sistema eficaz, que gestione todas las peticiones que haga el usuario en la vista (un handler) y realizar las acciones pertinentes. En caso de que el modelo se modifique y se quiera realizar un actualizado, este deberá notificar a los controladores que su información ha sido cambiada, para así realizar una actualización de la vista. Este requisito esta enfocado a la realización de algún sistema, bien por asociación del nombre de componente con el evento. Por ejemplo, botón “btnBuscar”, la notación que tendríamos seria que al recibir el evento, se tendría que invocar un método llamado “btnBuscarPressed”. Por supuesto, esto no es regla la regla de como debería ser implementado, pero nos acercaría a que esta especificación de como debería de simplificar el trabajo del desarrollador.

5. Los controladores deben tener mecanismos que permitan al desarrollador, actualizar la vista, actualizar solo uno de los componentes de la vista (puede estar formados por varios componentes). Se debería de implementar alguna serie de reglas para definir el comportamiento de las vistas. Debería ser posible mediante la definición de los tipos de evento lanzados y que el controlador pueda decidir la acción a llevar. Esto implicaría que al modificar el modelo, no se debería modificar directamente la vista, sino a partir del controlador.

6. Los componentes GTK# deberán ser adaptados a este framework, por lo tanto, deberán ser extendidos todos los componentes GTK que se usaran en el. Al igual que se definió en el primer punto, Los componentes deberán ser redefinidos para implementar la funcionalidad del framework y hacer que puedan ser fácilmente utilizados en el desarrollo. Por supuesto, en caso de poder realizar alguna modificación en el comportamiento (por ejemplo, simplificación de la inserción de objetos en un componente Combo Box) del componente, seria ideal hacerlo, aunque deberíamos poder dejar al desarrollador la capacidad de poder realizar operaciones con el componente directamente (es decir, manipulación directa de los componentes GTK#).

7. Se debe tener un control sobre los datos, tal que permita al desarrollador recuperar datos del modelo cambiados en sucesivas fases. Este requisito estaría lejos de la idea inicial y podría ser implementado en un futuro, en caso de tener tiempo. La idea seria poder realizar una cola con los diversos estados de los datos que el modelo ha ido teniendo a lo largo del periodo (puede estar limitado) de ejecución de la aplicación.

Ya tengo desarrollado los casos de uso y estoy a punto de terminar el diseño, aunque esperaré a terminar este último punto antes de publicar otros dos posts, referidos a cada una de las etapas descritas respectivamente.