Resum - UPCommons

Resumen proyecto Final de Carrera Ingeniería
Técnica Informática de Gestión: MIBODA.COM
Mari Luz Rodríguez Salas
Resumen
Miboda.com es una aplicación web destinada a la
organización de una boda. Desde un principio, no fue el
planteamiento de un proyecto teórico sino de un proyecto
para llevar a la práctica y que, de hecho, estuvo
funcionando durante las semanas previas a una boda,
ofreciendo una cómoda interacción entre novios e invitados.
La Web ofrece la posibilidad a los novios de crear su lista
de invitados y de bodas, consultar información asociada a
estos elementos y colgar toda aquella información que
consideren de interés para los invitados. Éstos a su vez
podrán confirmar su asistencia vía Web, seleccionar
artículos de la lista de bodas y consultar toda aquella
información que haya sido colgada entre otras opciones.
Todo esto aplicativo se ha construido sobre tomcat, mysql,
J2EE y struts.
1. Introducción
En la actualidad la Web, cada vez más extendida entre el
público de todas las edades y ámbitos, nos ofrece un sinfín
de posibilidades, acciones que podemos realizar desde casa
cómodamente. La idea de esta Web surgió de un caso real.
Alguien con intención de casarse me planteó la posibilidad,
de aprovechar la potencia que nos ofrecía Internet y hacerle
un portal para interactuar con sus invitados sin necesidad de
numerosas llamadas.
Aunque pueda parecer extraño, en la actualidad, no hay
nada hecho que siga esta línia. Las páginas que tratan esta
temática se limitan a ser informativas y/o directorios de
otras páginas comerciales.
2. Pasos previos
Antes de plantearme siquiera cómo iba a afrontar este
proyecto, era preciso establecer cuáles eran los requisitos
del cliente para poder elegir unas herramientas apropiadas.
Así hubo varias entrevistas con el cliente con la finalidad de
establecer unos requisitos lo más ajustados posible a la sus
necesidades. Las funcionalidades requeridas eran:

el sistema debía tener un sistema de seguridad para
que no pudiera entrar cualquier navegante

debía distinguir dos tipos de usuario (dos perfiles)
los invitados y los novios

los novios debían tener total control sobre los
datos

los novios debían poder crear por ellos mismos,
sin necesidad de un administrador los datos

el sistema debía ofrecer a los novios las opciones
de:

crear su lista de invitados

crear la lista de novios

consultar el estado de confirmaciones

consultar el estado de regalos

consultar dedicatorias dejadas por los
invitados

consultar la lista de canciones

colgar información de contacto

colgar
información
referida
organización del día y horarios
a

los invitados debían disponer de una información
parcial de aquellos datos compartidos con los
novios

se debía permitir la confirmación de asistencia

en caso de haber autocar, también podrían reservar
o solicitar plaza en él

los invitados debían poder consultar y reservar
artículos de la lista de bodas

el sistema debía ofrecerles la posibilidad de
dejarles dedicatorias a lo novios

los asistentes al evento tenían la posibilidad de
participar activamente, eligiendo y recomendando
canciones a los novios

y por último, los invitados tendrían acceso a todos
aquellos apartados de información
Una vez todos los requisitos establecidos era el momento de
decidir qué plataforma utilizar y hacer una previsión de
tiempo.
3. Plataforma
Ya que, después de varios días de trabajar las
especificaciones, se vio que era un tema amplio, sobre el
que no había nada hecho y que dejaba muchas vías abiertas
de futuro desarrollo, se pensó que desarrollar con php (que
era la idea inicial) iba a ser poco ampliable. Con este tipo
de lenguaje las páginas servidas son las que llevan la carga
de programación y lógica de negocio. Este tipo arquitectura
no ofrece una fácil escalabilidad y mantenibilidad. Aunque
las últimas versiones de php ya son orientadas a objeto
existía otra tecnología mucho más potente: struts.
Struts es un proyecto Open-Source creado por la fundacion
Apache. Es un framework de java J2EE, especialmente
creado para el desarrollo de aplicaciones web, basado en la
tecnología Java Servlet y en JavaServer Pages, por lo que
depende de un contenedor web.
Un servlet se mapea a una o más URL y cuando el servidor
recibe una petición para una de las URL’s del servlet, se
invoca al método de servicio en el servlet y éste responde.
Los servlets no los ejecuta directamente el servidor Web,
sino que requieren de un contenedor servlet que los
albergue. Este contenedor está acoplado a una instancia
determinada del servidor y juntos cooperan para servir
peticiones.[1]
El eje principal sobre el que se construyen aplicaciones con
struts es el patrón de diseño MVC. Los componentes de este
patrón son:

Fig.1 Gráfico detallado de los componentes modelo vista
controlador
Modelo: Responsable de la lógica de negocio. En
esta capa se encuentran las clases correspondientes
al modelo de datos (diagrama E/R), son los
llamados Beans.
desde la aplicación: altas/eliminación de usuarios, artículos,
canciones, etc.

Vista: Responsable de una vista de presentación
de la lógica de negocio. En esta capa se encuentran
las clases correspondientes a los formularios, los
llamados formBeans. Son clases que heredan de
ActionFom (org.apache.struts.action.ActionForm).
Una vez decidida la tecnología con la que se iba a trabajar y
establecidos los objetivos del proyecto había que hacer una
planificación detallada, para distribuir y organizar el tiempo
y que a la vez sirviera de guía para saber si era posible
cumplir los plazos.

Controlador: Responsable de controlar el flujo y
estado de datos por parte del usuario. En esta capa
se encuentran las clases que heredan de Action
(org.apache.struts.action.Action)
A la hora de hacer la planificación se tuvieron en cuenta los
siguientes factores:
Un bean es un componente software que tiene la
particularidad de ser reutilizable y evitar la tarea de
programar los distintos componentes uno a uno. Es el caso
de la mayoría de componentes que manejan los editores
visuales más comunes. Un bean puede representar desde un
botón, un grid de resultados o un simple campo de texto. Su
principal característica es tener métodos set() y get()
públicos para acceder a los atributos privados que nos
interesen.
La arquitectura en capas de struts permite que cada parte
tenga sus funciones bien determinadas y sean responsables
de su área, permitiendo que en grandes proyectos haya
varios programadores trabajando en paralelo. Asimismo la
independencia de las jsp facilita la posibilidad de un
diseñador trabajando en ellas pendiente de que los
desarrolladores de struts inserten las referencias a datos
devueltos por la capa de controlador y/o modelo.
Veamos un esquema de cómo funciona esta interacción de
capas (Ver Fig. 1):
La característica de servidor con capacidad para albergar
contenedor servlet, antes explicada y justificada, hacía que
no fuese posible trabajar con un servidor apache típico
(como era el planteamiento inicial), por lo que se eligió
Tomcat, también de la fundación Apache.
Para gestionar la base de datos mysql inicialmente, se
trabajó con phpMyAdmin que ofrece una interfaz de trabajo
amigable y de fácil manejo para la manipulación y creación
de tablas. Digo inicialmente porque, una vez creada la
estructura de la base de datos, el mantenimiento se
realiza
4. Planificación

formación (html, css, javascript, jsp, java, struts y
mysql)

especificación formal

diseño

implementación

pruebas y modificaciones
5. Especificación y diseño
En este documento resumen no detallaré la especificación
formal de los requisitos antes mencionados[2] .
Analizando estos requisitos se llegó a obtener un modelo de
datos E/R (Ver Fig.2) y un diagrama de clases en el que se
detallan las diferentes clases con sus atributos y métodos
(Ver Fig.3) que debido a su tamaño están dispuestas al final
de este documento.
Para la parte de diseño de interfaz me ayudé de un prototipo
navegable, pero sin funcionalidad, ya que consideré que era
el medio más fácil para que el cliente, no perteneciente a
este ámbito, se hiciera una idea del resultado.
Con el uso de prototipos se pretendía conseguir, con más
exactitud, una idea de lo objetivo que buscaba sin necesidad
de volver atrás, y tener que hacer cambios que podrían
retrasarme mucho, una vez en la fase de implementación.
Uno de los prototipos que se hicieron está como documento
anexo.
6. Implementación
Dada la propiedad de modularidad que nos proporcionaba
struts no estaba forzada a empezar a codificar en un punto
determinado. Pero por mi inexperiencia me resultó más
fácil partir del diseño de las páginas.
Lo primero que creé fue la base de datos que, por más
esmero y cuidado que se puso en intentar conseguir un
modelo definitivo, a mitad de desarrollo hubo que
introducir algún cambio.
En ese momento supe agradecer la arquitectura con la que
trabaja struts ya que no me representó hacer muchos
cambios, y los que hice fueron muy ordenados. Estaba muy
claro en que fichero residía la parte que se veía afectada por
cambios en la base de datos.
Para crear las jsp primero hubo diseñé la página html y a
partir de ahí la transformé a jsp cambiando los tags propios
de html por los de struts.
Con la base de datos y las páginas creadas, ya tenía los
datos suficientes para implementar la capa de modelo y
vista respectivamente. Faltaba darle todo el significado y
funcionalidad a todo aquello: era el momento de codificar
la capa de control.
Tras esto, vino la fase de pruebas y desarrollo.
7. Pruebas y modificaciones
Esta fase se convirtió más bien en una fase de pruebas,
modificaciones y ampliaciones. Este hecho que según la
teoría no debería producirse es muy común en la práctica.
Las pruebas, al no ser un sistema que hubiera que integrar
en otro, ni que dependiera del resultado de otro, se pudieron
ir haciendo durante la fase de desarrollo. Sin embargo, las
modificaciones y ampliaciones sí que se realizaron al final.
8. Costes
respecto, hace que las posibles vías de ampliación futuras
sean muchísimas.
A modo genérico se podría subir un nivel de abstracción y
no centrarnos en bodas, sino que sirviera para organizar
cualquier tipo de evento que requiriera la coordinación de
muchas personas (bautizos, comuniones, cenas de
compañeros de primaria, grandes reuniones, etc.)
Otro punto interesante a desarrollar sería la generación
automática de contraseñas, y que el propio sistema,
mediante una opción de recordar contraseña enviara un
mail a la dirección de correo del usuario con la contraseña.
En estos momentos la base de datos está preparada para
soportar dicha función ya que en previsión a posibles
cambios se introdujeron lo campos subMail1 y subMail2.
El mail se almacenaría dividido en dos substrings para una
mayor seguridad contra posibles intrusiones.
10. Conclusiones
En un primer momento consideré que hacer un proyecto
final de carrera implicaba una parte de estudio e
investigación. Por eso cuando me plantearon la idea de
hacerlo con toda esta plataforma no lo dudé.
Sin embargo, he de reconocer que, en muchos momentos,
me arrepentí profundamente de mi decisión: eran
demasiadas cosas nuevas a la vez. Pero hoy día, con todo ya
superado, puedo decir que me alegro de haber tomado
aquella arriesgada decisión.
11. Agradecimientos
No puedo pasar sin darle las gracias a mi tutor, J.L.
Balcázar, por haber sacado tiempo para mí de donde no
había. A Carlos y Marian por impulsarme a trabajar con
struts. Agradecer a Rubén, Jonatan, Manolo y Helena que
estuvieron ahí cuando los necesité. Y especialmente a Juan
Carlos, mi marido y mentor de este proyecto, por toda su
ayuda y paciencia estos meses.
En los inicios de los estudios de costes sobre trabajos
software, las valoraciones se hacían sobre las líneas de
código (LOC o KLOC), sin embargo se fue evolucionando
hacia valorar cada vez más los puntos funcionales.
Ahora no entraré en la aplicación de fórmulas y tablas,
pero sí que a modo orientativo he hecho una estimación, y
el coste temporal de realizar este proyecto ha sido de:
(8meses * 30 días * 3 h/d) = 780 h *
h/d: es la media de las horas diarias dedicadas a la semana,
ya que los fines de semana podían ser 10 y un día entre
semana podía ser 0.
Hay que tener en cuenta que esta dedicación incluye el
tiempo de formación, que al haber sido autodidacta, se ha
ido empleando a lo largo de todo proyecto y practicamente
en todas las fases. Por este motivo es difícil de valorar. Una
aproximación sería entorno al 25-30% dedicado a
formación.
9. Trabajos futuros
Como ya he comentado, la naturaleza del proyecto de
sistema abierto, no dependiente ni encajado en ninguno otro
junto con la circunstancia de que no hay hecho nada al
Referencias
[1]
Cavaness, Chuck. Jakarta Struts / Programming Jakarta
Struts. Madrid: Anaya Multimedia, 2005
[2]
La especificación formal de los requisitos la puede consultar
en los apartado 4.2.1 (funcionales) y 4.2.2(no funcionales)
de la memoria.