Documentación De la Entrega Final

Proyecto de Aula –Estructuras de Datos

Downtime.

Documentación de la Etapa de implementación.

Descriptor
Un pequeño artículo donde se resuma la experiencia vivida durante la
implementación del código fuente.
Desarrollo
La fase de implementación está basada en el resultado del diseño previo a la
elaboración del sistema, orientándose hacia la generación del código; aunque, y vale
aclararlo, se han presentado algunos cambios respecto al diseño inicial a fin de resolver
algunos aspectos particulares, que por la falta de experiencia no habían sido tenidos en
cuenta. Se ha traducido el modelo preliminar a una estructura Orientada a Objetos (en el
diseño se analizaron los diferentes comportamientos del sistema y fue necesario estimar
esos comportamientos asociándolos a objetos específicos) si dejar de lado la
consideración de ver el sistema como una estructura general, sencilla, completa y directa;
se destaca, además, que las decisiones más generales de la estructura y a su vez más
importantes para lograr la funcionalidad del software, fueron tomadas en las etapas
previas.
Durante esta fase se ha hecho una adaptación al lenguaje de programación Java
(considerando el manejo de datos en memoria principal sin incluir persistencia o bases de
datos y estructurado de acuerdo a las especificaciones del diseño y basados en las
propiedades del lenguaje de programación implementado). Vale aclarar que el grupo de
trabajo no apresuro la intensión de comenzar a programar, a fin de aproximar el sistema
lo más posible al modelo de diseño; sin embargo, este aspecto afecto enormemente los
plazos de entrega (un aspecto muy importante a considerar durante el ejercicio
profesional); como ya se dijo, este fue susceptible de cambios: el grado de
perfeccionamiento del proceso de planeación del sistema final, durante la fase de diseño,
resulta fundamental para evitar los errores durante esta etapa.
Para entendernos en el grupo de trabajo, se definieron preliminarmente aspectos
como la asignación de nombres a las variables, estilo de programación, métodos de
documentación, tipos de estructuras y varios aspectos relacionados; aunque,
nuevamente (por la falta de experiencia), vimos que se podía haber adecuado a otras
formas de trabajo de modo tal que favorezcan la independencia en las actividades de
cada integrante del equipo: otro logro alcanzado con este trabajo, puesto que al
identificar este tipo de errores durante la formación se reducen los riesgos inherentes al
momento de ejercer profesionalmente. Es bueno resaltar que aunque las herramientas de
desarrollo utilizadas (en nuestro caso el IDE Netbeans) favorecen la automatización del
proceso de generación de código, fue labor del equipo la construcción de los diferentes
métodos implementados en el sistema y, como tal, la transición al código fuente. Para
reducir los riesgos, se planteaban en papel y lápiz la solución a problemas específicos y
luego se traducían a código, se hacían las correcciones pertinentes y se relacionaba con
otras estructuras del sistema.
 Para iniciar, se dividió el trabajo por partes identificando cuatro grupos principales:
- El registro de personas,
- La asignación de turnos,
- La solicitud de turnos, y
- La consulta de información.
Posteriormente, se definieron tres paquetes principales: a) el paquete cliente,
donde están las clases que interactúan con el usuario, b) el paquete datos, donde se
registran los TDA de los objetos a utilizar en el sistema, y c) el paquete lógico, donde se
manejaban los aspectos que regían el sistema para satisfacer los requerimientos
funcionales. Algo fundamental en esta etapa era comprender como se relacionaban las
diferentes partes del sistema, por lo que a la par, se hicieron algunas revisiones de
información y documentos que pudieran facilitar la integración de una interfaz gráfica con
las estructuras construidas.
Así, procedimos a construir las estructuras más adecuadas para dar respuesta al
los requerimientos del sistema (posteriormente fueron modificadas con otras estructuras
incluidas en el programa del curso y en documentación relacionada en Internet). Lo
primero en construirse fue la interfaz de registro en el sistema, ya que partíamos del
supuesto que no habían sujetos en el sistema y que estos debían existir (ser creados)
para dar tratamiento a su información. Así, se crean las clases vLogueo, vPrincipal (esta
por la idea de centralizar el sistema y no tener muchos enlaces, sino una estructura a la
cual se volviera siempre a direccionar una acción del sistema), vReg_Doctor y
vReg_Enfermera.
Creamos la clase abstracta Person que hereda las clases Doctor y Enfermera, y
como el sistema es utilizado por el doctor, sólo a este se le asignaron los atributos usuario
y contraseña. Entre tanto, se sabía que se iban a listar y como tal se crearon las clases
ListadoDoctor y ListadoEnfermera. Como el reloj era un elemento que debía ser tenido en
cuenta en el desarrollo del producto de software, se construyeron tres clases que le
permitieran al sistema el manejo del tiempo: a) una interfaz Temporizador (sus métodos
carecen de implementación) b) una clase Timer (que actúa como cronometro o contador
de tiempos con los métodos implementados de la Interfaz antes citada, a fin de poderlos
usar en los métodos que llevan cuenta en el sistema como los turnos de las enfermeras) y
c) reloj, que despliega un reloj con fecha en una ventana contigua a la ventana principal
para que se mantenga visible de manera permanente a medida que se trabaja con el
sistema.
Este paquete de tiempos trabaja con hilos de ejecución para que sin importar que
otra acción se esté desarrollando en el sistema, pueda continuar su proceso. Ahora bien,
de este paquete la clase reloj es la que se ejecuta con el reloj exterior, pero tanto el
temporizador como el Timer tuvieron que sufrir variaciones (las dejamos incluidas para
que se pueda apreciar su construcción). En su lugar, se construyeron las clases
ValidadorTurnos y HoraTiempo para resolver el problema de la gestión de tiempos de los
turnos.
Ya fueron aspectos de tiempo que dificultaron la completitud del programa que se
había diseñado en un lapso de 5 semanas, de los cuales para la fase de implementación
se asignaron dos, es por ello que dentro de la interfaz gráfica algunos enlaces no logran
mostrar el resultado, aun cuando el método ya se encuentra incluido en la lógica del
programa, tal es el caso del ValidadorTurnos que determina quien está en un turno FIFO y
que se hace el conteo para retirar del turno a una enfermera que ha completado su
jornada y se ha identificado la enfermera disponible.
 De igual forma, el hilo de conteo del tiempo para establecer los turnos se ejecuta
de manera paralela a la ejecución del programa. Se listan las enfermeras y los doctores
aunque no se muestran (el método para mostrarlas ya está construido en el programa).
El método main se encuentra en una clase independiente llamada MySystem, desde
donde se inicia la vLogueo y se inicializa el Thread correspondiente al tiempo.

Documentación de la etapa de pruebas

Descriptor
Un documento donde se describan las pruebas desarrolladas, los errores
encontrados y los errores corregidos.
Desarrollo
Fundamentalmente, y por cuestiones de tiempo, las pruebas que se realizaron
fueron pruebas de escritorio de algunos de los algoritmos utilizados para identificar la
viabilidad dentro del sistema. Las pruebas JUnit no se ejecutaron ya que se buscó, en
primera instancia, responder con los requerimientos funcionales del sistema. En algunos
casos, como testeo para las diferentes implementaciones se dieron sobre la ejecución
directa de la funcionalidad y se verificó que se presentara la correspondiente información
esperada, en cuyo caso (contrario), se hacían los ajustes necesarios para lograr
responder con la funcionalidad.
Los principales errores que se encontraron son: sobre todo en el almacenamiento
de información; es decir, en el registro, tanto de doctores como de enfermeras, ya que en
la mayoría de casos algunos datos no quedaban correctamente guardados en relación
con la otra información del mismo sujeto, es decir que se almacenaban independientes.
Sin embargo, se buscó la correcta resolución de esta anomalía y se hicieron los ajustes
necesarios a fin de poder registrar cada sujeto con toda su información de manera
relacionada.
La otra dificultad estaba en la doble instanciación, es decir que en algunas
ocasiones se instanciaba un mismo objeto mas de una vez, dificultando la ejecución del
sistema, por lo que se debieron hacer las revisiones pertinentes para encontrar donde se
lleva a cabo la creación de múltiples objetos (cuando sólo era requerido uno) y llamar los
métodos correspondientes sin repetir la instancia.