Agencia de Viajes usando J2EE y prcticas de

Desarrollo gil
Taba de contendo
1.
Introduccn........................................................................................................... 4
1.1. |ustcacn de proyecto............................................................................................................. 4
1.2. Ob|etvos de traba|o....................................................................................................................... 5
1.2.1. Ob|etvos tcncos.........................................................................................................................5
1.2.2. Ob|etvos metodoogcos...........................................................................................................6
1.3. Enfoque metodogco.................................................................................................................... 6
1.3.1. Manesto g ................................................................................................................................7
1.3.2. Apcacn de a metodooga Ag en nuestro proyecto..............................................8
1.4. Pancacn de proyecto......................................................................................................... 11
1.4.1. Investgacn tecnooga |2ee y posgtreSq ....................................................................11
1.4.2. Instaacon de entorno.............................................................................................................11
1.4.3. Desarroo de a apcacn por casos de uso (sprnts) .............................................11
1.4.4. Cco de cada Sprnt: .................................................................................................................12
1.4.5. Dagrama de Gannt....................................................................................................................12
1.5. Productos obtendos.................................................................................................................... 13
1.5.1. Metodooga y herramentas de testng ...........................................................................13
1.5.2. Entrega de producto................................................................................................................17
2.
Especcacn y requermentos ...................................................................... 24
2.1. Informacn nca........................................................................................................................ 24
2.2. Gosaro................................................................................................................................................ 24
2.3. Modeo de domno ...................................................................................................................... 25
2.4. Dagrama de casos de uso.......................................................................................................... 26
2.5. Documentacn textua de os casos de uso.................................................................... 26
Expcacn de modeo segudo para documentar os casos de uso ...................................26
2.5.1. Bsqueda de ofertas de paquetes turstcos ..................................................................27
2.5.2. Reserva de pazas de paquetes turstcos .......................................................................28
2.5.3. Logn................................................................................................................................................30
2.5.4. Mantenmento cuenta de usuaro .....................................................................................31
2.5.5. Mantenmento de ofertas......................................................................................................34
2.6. Requstos de a nterfaz de usuaro.................................................................................... 36
3.
Anss .................................................................................................................. 36
3.1. Identcacn de as cases de entdades y sus atrbutos....................................... 36
3.2. Dagramas de estados.................................................................................................................. 37
3.3. Dagramas de actvdades......................................................................................................... 37
3.3.1. Transaccn de reserva de paza.........................................................................................37
3.3.2. Reserva de paza (bsqueda + reserva) ...........................................................................38
3.3.3. Logn................................................................................................................................................39
3.3.4. Ata de usuaro ............................................................................................................................40
3.3.5. Integracn (bsqueda, Logn, ata, reserva) .................................................................41
3.4. Modeo de datos .............................................................................................................................. 41
4.
Dseo tcnco...................................................................................................... 42
4.1. Vsta-Controador: Vadator y Parser hepers ............................................................. 42
4.2. E modeo............................................................................................................................................. 44
4.2.1. La Fachada ....................................................................................................................................44
5.
Impementacn................................................................................................... 46
5.1.
5.2.
Herramentas de desarroo..................................................................................................... 46
Proceso de nstaacn................................................................................................................. 47
2
5.3.
|uego de pruebas............................................................................................................................ 47
6.
Concusones......................................................................................................... 51
Uso de metodooga g........................................................................................................................... 51
Ccos de desarroo cortos.....................................................................................................................51
Pruebas de undad automatzadas .....................................................................................................51
Metodooga de tests y herramentas.............................................................................................. 52
7.
Bbografa ........................................................................................................... 52
3
1. Introduccn
La apcacn de metodoogas y prctcas ges dentro de empresas dedcadas a desarroo de software, es en
a actuadad una readad que se vene acrecentando en os tmos aos arededor de mundo.
Son muchas as personas y empresas dedcadas a desarroo de software que se enfrentan hoy por hoy con e
dema de ser o no ser ges. Ben sea porque sus actuaes metodoogas de desarroo no dan os resutados
esperados o ben porque desean ncursonar en prctcas que estn de moda a o argo y ancho de as
comundades de desarroo en todo e mundo, o certo es que e auge de as metodoogas ges es un tema
que apasona y hace reexonar a todo aque que se encuentre nmerso dentro de proceso de desarroo de
software.
Este traba|o presenta un enfoque prctco para a eeccn y adecuacn de metodoogas ges de desarroo de
software a un proyecto rea: E desarroo de un sstema de reservas para una agenca de va|es usando
tecnooga |2EE.
1.1.
|ustcacn de proyecto
E sector de as Agencas de Va|e ha vvdo una crss desde a aparcn de Internet.
Segn e Foro Internacona de Tursmo, as compras de va|es por Internet han crecdo de forma sgncatva
hasta e punto de evar a a crss a as agencas de va|e tradconaes. La tendenca se presenta como
consodada aunque eo no tene por qu suponer a desaparcn de estas agencas sno un cambo en su
concepcn orgna de manera que se puedan adaptar a os nuevos tempos.
Las compaas areas y as centraes de reservas de hotees fueron agunas de as prmeras entdades en usar
grandes sstemas en red para gestonar a reserva y venta de sus productos. Estos sstemas conectaban os
ordenadores centraes con os termnaes de as Agencas de Va|es. stas por su parte vendan uego e
producto a pbco na evndose una comsn por a gestn.
La ncorporacn de as agencas a a red ha supuesto a berazacn masva de sector, y cuaquer
competenca en a oferta es benecosa para e cente ya que a compettvdad coneva una ba|ada de precos
y una me|ora de producto.
Con a aparcn de Internet as compaas areas y as centraes de reservas de hotees han extenddo sus
redes de computadores que antes ncamente servan a agencas de va|es. En muchos casos hoy en da sae
mas barato comprar un bete por Internet, que en una Agenca. Y as compaas areas recortan cada vez ms
sus comsones a as Agencas.
4
Las compaas de va|es (ferrovaras, areas, de aquer de coches.), os hotees, guas y otros muchos
servcos que antes dependan de una agenca u organzador de va|es, ahora pueden ofertarse drectamente en
a red, sn ntermedaros y sn monopoos que mten su actvdad comerca, de manera que se ponen en
manos de una buena gestn para ofrecer a me|or opcn a cente y de marketng.
Internet es donde se compra, vende y se contratan a nmensa mayora de os va|es, cuaquera con conexn
puede hacero con cuatro ccks.
Las Agencas de va|es estn pues en crss, necestan renventarse, ya no pueden ser ntermedaros en a venta
de betes de proveedores. Necestan poder competr en este nuevo mercado de venta por Internet.
E producto dferencado que ofrecen as agencas de va|es es e paquete turstco, que para poder ser un
producto aternatvo a as ofertas de productos ndvduaes de transporte y ao|amento, debe contar con un
sstema de reservas por Internet que supere a de as compaas areas y centraes hoteeras, un sstema de
reservas que ofrezca a pbco os productos que as agencas eaboran.
E sstema de reservas que eaboraremos en este proyecto contar con una venta|a compettva frente a os
sstemas de as grandes mayorstas tradconaes. Nuestra tecnooga estar basada en a potenca de |ava y
|2EE y utzar metodoogas ges apoyadas en tests automatzados con as que podremos ser ms dnmcos
frente a os cambos que puedan surgr en e futuro.
1.2.
Ob|etvos de traba|o
Con este proyecto pretendemos exporar tanto ob|etvos tcncos como metodogcos.
1.2.1. Ob|etvos tcncos
Para poder competr en este nuevo mercado de venta de va|es por Internet, necestamos por una parte que a
apcacn sea extremadamente rpda en a gestn de reservas de paquetes trstcos. Para eo debemos
mtar a mxmo a contencn en as transaccones y asegurar a msmo tempo su correccn, o o que es o
msmo, mpedr nterferencas con otras transaccones en curso por ausenca
de boqueos.
Por otro ado, tambn ser deseabe que a apcacn sea testabe con facdad, para eo construremos una
arqutectura en a que os ob|etos de negoco se puedan e|ecutar tanto fuera como dentro de contenedor |2EE,
para as podero someter a todas as pruebas necesaras, sn a compcacn, y enttud aadda de arrancar un
servdor |2EE.
Otra caracterstca necesara y dervada de a anteror, es construr una arqutectura basada en e paradgma de
a orentacon a ob|etos, conocddo como Open / Cosed prncpe. Este prncpo postua que e cdgo este
aberto para a extenson pero cerrado para a modcacn ya que cada vez que modquemos cdgo corremos
e resgo de estropearo. Por eo debemos utzar as tecncas de
herenca y composcn para aadr funconadad a nuestros programas.
5
1.2.2. Ob|etvos metodoogcos
Nosotros en este proyecto, usaremos prctcas de desarroo g como as sguentes:
Frecuente retroamentacon: para eo se han pancado casos de uso cortos y en a medda de o posbe
autocontendos, es decr que no necestan de otras partes para ser probados.
Pruebas automatzadas: se comenzar e desarrroo empezando por as pruebas. Haremos pruebas de undad y
de ntegracn en un cco constante como veremos en ms detae ms adeante.
1.3.
Enfoque metodogco
Para este proyecto exporaremos cmo apcar as prncpaes prctcas de o que se conoce como "desarroo
g".
E enfoque tradcona de desarroo de apcacones heredado de otras ramas de a ngenera, ha sdo e de
hacer un estudo exahustvo de probema, estabecer un pan y evar a cabo a construccon. Es a metodooga
conocda como desarroo en cascada, con as fases consecutvas de Anass, Dseo, Codcacon, Pruebas e
Impementacn.
Pero este enfoque no sempre es ptmo para e desarroo de software. La rogramacn no es exactamente
comparabe a otras ramas de a ngenera o a a construccn.
E desarroo de software, es un proceso puramente creatvo, anogo a o que en a construccn de una
vvenda sera a eaboracn de os panos.
A dferenca de a ngenera cv, en e desarroo de software no exste un proceso de construccn en e que se
sgan unos panos de modo mecnco prevamente estabecdos por e arqutecto o ngenero. En cada fase hay
que ser creatvo y tomar decsones.
En readad s exste un proceso anogo a de a pura construccn, en e que no hay que tomar decsones y
soo apcar o dctado por e arqutecto. Es e paso de cdgo fuente a ob|eto, a compacn. Pero su coste es
desprecabe frente a coste de dseo. |usto o contraro a o que sucede con a ngenera cv, donde e coste
de dseo es nntamente menor que e de a construccn.
E ob|etvo de as metodoogas de desarroo g de software es a organzacn de un traba|o creatvo, que
suee ser bastante catco. Se ntenta dar prordad a a e|ecucn sobre a pancacn.
6
A medda que se profundza en e conocmento de un probema se camban os panes. Cuando e cente vea
nuestras propuestas, se e ocurrran nuevas deas que cambarn os panes. Cuando profundcemos en e
conocmento de nuevas teconoogas haremos descubrmentos que cambarn de nuevo os panes.
La pancacon excesva es e probema habtua de os enfoques de desarroo de software en cascada. Una
pancacon es excesva cuando desconocemos parte o gran parte de probema a que nos enfrentamos y an
as estabecemos ob|etvos y pazos. En e me|or de os casos renuncaremos a as venta|as que se obtendran
de un me|or entendmento de probema. En e peor, nuestro pan fracasar por encontrarnos resgos con os
que no contbamos.
Ag quere decr, adaptabe. Desde esta premsa, os cambos son benvendos, dervan de un me|or
entendmento de probema y son una oportundad para me|orar e software.
Este proyecto ser g porque tendremos que tratar con certa ncertdumbre tecnogca a tener que evauar
a tecnooga |2EE y e gestor de bases de datos PostgreSOL.
Tambn ser g porque hemos de estar dspuestos a adaptarnos a a me|or soucn que encontremos a
probema de consegur un eevado rendmento en as transaccones de reservas de va|e, ago que puede
afectar a panteamento genera de a apcacn.
E desarroo g no equvae a caos. Para poderse evar a cabo necesta basarse en en dos pares: pruebas
automtcas y retroamentacon (feedback) temprana, es decr ob|etvos papabes a corto pazo.
1.3.1. Manesto g
Dado que uno de os prncpaes ob|etvos de este proyecto es a vaoracn de uso de metodoogas de
desarroo g, presentaremos e manesto g, suscrto por personadades tan reputadas como Astar
Cockburn y Martn Fower entre otros. Sepuedeveremanestoorgnasguendoesteenace
http://agemanfesto.org/
Manesto g:
Vaorar ms a os ndvduos y su nteraccn que a os procesos y as herramentas
Este es posiblemente el principio ms importante del manifiesto. Por supuesto que los procesos ayudan al
trabajo. Son una gua de operacin. Las herramientas mejoran la eficiencia, pero sin personas con
conocimiento tcnico y actitud adecuada, no producen resultados.
Las empresas suelen predicar muy alto que sus empleados son lo ms importante, pero la realidad es que
en los a!os "# la teora de produccin basada en procesos, la re$ingeniera de procesos ha dado a stos
ms rele%ancia de la que pueden tener en tareas que deben gran parte de su %alor al conocimiento y al
talento de las personas que las reali&an.
Los procesos deben ser una ayuda y un soporte para guiar el trabajo. 'eben adaptarse a la organi&acin, a
los equipos y a las personas( y no al re%s. La defensa a ultran&a de los procesos lle%a a postular que con
ellos se pueden conseguir resultados e)traordinarios con personas mediocres, y lo cierto es que este
principio es peligroso cuando los trabajos necesitan creati%idad e inno%acin.
7
Vaorar ms e software que funcona que a documentacn exhaustva
Poder %er anticipadamente como se comportan las funcionalidades esperadas sobre prototipos o sobre las
partes ya elaboradas del sistema final ofrece una retroalimentacin *feedbac+, muy estimulante y
enriquecedor que genera ideas imposibles de concebir en un primer momento( difcilmente se podr
conseguir un documento que contenga requisitos detallados antes de comen&ar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de la documentacin, permiten
la transferencia del conocimiento, registran informacin histrica, y en muchas cuestiones legales o
normati%as son obligatorios, pero se resalta que son menos importantes que los productos que funcionan.
-enos trascendentales para aportar %alor al producto.
Los documentos no pueden sustituir, ni pueden ofrecer la rique&a y generacin de %alor que se logra con
la comunicacin directa entre las personas y a tra%s de la interaccin con los prototipos. Por eso, siempre
que sea posible debe preferirse, y reducir al mnimo indispensable el uso de documentacin, que genera
trabajo que no aporta un %alor directo al producto.
Si la organi&acin y los equipos se comunican a tra%s de documentos, adems de perder la rique&a que
da la interaccin con el producto, se acaba deri%ando a emplear a los documentos como barricadas entre
departamentos o entre personas.
Vaorar ms a coaboracn con e cente que a negocacn contractua
Las prcticas giles estn especialmente indicadas para productos difciles de definir con detalle en el
principio, o que si se definieran as tendran al final menos %alor que si se %an enriqueciendo con retro$
informacin continua durante el desarrollo. .ambin para los casos en los que los requisitos %an a ser
muy inestables por la %elocidad del entorno de negocio.
Para el desarrollo gil el %alor del resultado no es consecuencia de haber controlado una ejecucin
conforme a procesos, sino de haber sido implementado directamente sobre el producto. /n contrato no
aporta %alor al producto. Es una formalidad que establece lneas di%isorias entre responsabilidades, que
fija los referentes para posibles disputas contractuales entre cliente y pro%eedor.
En el desarrollo gil el cliente es un miembro ms del equipo, que se integra y colabora en el grupo de
trabajo. Los modelos de contrato por obra no encajan.
Vaorar ms a respuesta a cambo que e segumento de un pan
Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al
cambio y la e%olucin rpida y continua, resulta mucho ms %aliosa la capacidad de respuesta que la de
seguimiento y aseguramiento de planes pre$establecidos. Los principales %alores de la gestin gil son la
anticipacin y la adaptacin( diferentes a los de la gestin de proyectos ortodo)a0 planificacin y control
para e%itar des%iaciones sobre el plan.
1.3.2. Apcacn de a metodooga Ag en nuestro proyecto.
1emos intentado seguir una metodologa basada en S23/-, pero el intento de asumir los roles de cliente, jefe de proyecto y programadores
en una sola persona hacan muy artificial este enfoque. Por ello nos hemos centrado en dos aspectos de la metodologa gil que a nuestro
juicio tienen la mayor i portancia0 las pruebas automati&adas, y motorgar mas importancia al soft4are que a la documentacin, es decir la
documentacin
ser una herramienta para el soft4are y no otro producto a a!adir.
8
1.3.2.1. Pruebas Automatzadas
Las pruebas automati&adas son la piedra angular de cualquier metodologa de desarrollo gil, 52mo si no
%amos a permitirnos cambiar las caractersticas de una aplicacin en mitad del desarrollo y tener garantas de
no haber estropeado nada6
7 pesar de los esfuer&os de la ingeniera de soft4are por mantener una independencia de los diferentes componentes que conforman un
sistema., ine%itablemente los mdulos de una aplicacin tienen que interactuar entre si generando interdependencias que a %eces no son
e%identes.
7l cambiar la funcionalidad de alguno de estos mdulos se pueden tener consecuencias impre%istas en otras
partes del sistema. Estas consecuencias las podemos detectar ejecutando pruebas automati&adas que
comprueben todas las partes del sistema. Las pruebas, por tanto nos permiten afrontar con mayores garantas
el cambio. 7dems el hecho de que sean automatzadas nos permite repetirlos infinidad de %eces sin
encarecer el coste de desarrollo.
|ustcacn econmca de as pruebas automatzadas
Esta aplicacin tiene unos unos 89# mtodos. 2ada %e& que hemos incluido o modificado un mtodo hemos
ejecutado una suite de pruebas que ejecuta prcticamente todos los mtodos.
Supongamos que hemos ejecutado la suite unas :## %eces *ejecuto la suite %arias %eces mientras desarrollo,
Si un programador tu%iese que depurar a mano esas pruebas tardara 89# ; :## ; < minutos por prueba =
89#.### minutos, o lo que es lo mismo <"8 jornadas de trabajo.
El escribir las pruebas me ha costado entre ># y ?# minutos por mtodo, hay :? mtodos en el proyecto de
test, por lo que he in%ertido :? ; 9:minutos = unas 9# horas o : jornadas.
El escribir las pruebas automati&adas nos ha ahorrado <@? jornadas de trabajo. Eso suponiendo
que el programador que ejecutase las pruebas no se equi%ocase nunca y fuese tan perfecto como
las pruebas automticas.
|ustcacn de pruebas de undad y de ntegracn
En una apro)imacin ingenua podramos pensar que una prueba se podra limitar a arrancar la aplicacin,
seguir el manual de usuario y %er que hace lo que tiene que hacer, es decir, lo que es una prueba de
integracin.
1.3.2.1.2.
Para las pruebas de unidad hemos usado 1ttp/nit y pruebas manuales. 1ttp/nit es un cliente http hecho en ja%a que podemos combinar con
A/nit para hacer pruebas deintegracin contra el ser%idor http.
Sin embargo, por poner un ejemplo, si un programa tiene ? controles con 9 %alores de entrada posibles para
dar un resultado determinado, probarlo solo con una prueba de integracin nos obligara a escrib ir 9 ; 9 ; 9
; 9 ; 9 ; 9 , pruebas que son las distintas posibilidades de entrada que tendra el sistema, o lo que es lo
mismo 9 B ? = 9?.?:? pruebas diferentes 2on las pruebas de unidad podemos probar estos componentes
indi%idualmente, es decir probaramos el primer control, para lo que escribiramos cuatro pruebas para sus
cuatro posibles %alores de entrada. 1aramos lo mismo con los : controles restantes con lo que escribiramos
9 pruebas para cada uno, en total 4 + 4 + 4 + 4 + 4 + 4 = 4 * 6 = 24 pruebas para probar
todos os controes frente a as 46.656 pruebas que tendramos que hacer s soo
hcsemos pruebas de ntegracn.
9
1.3.2.1.1.
Pruebas de undad
El objeti%o de las pruebas no es demostrar que el sistema funciona, sino encontrar errores. Empricamente
hemos %isto que la mayor parte de los errores en las funciones se encuentran en la entrada de %alores nulos,
las cadenas %acas y los %alores lmite. Por %alores lmite entendemos que si una funcin admite un rango de
%alores, los limites son las fronteras de esos %alores.
Cormalmente en todas las pruebas el primer paso ha sido probar que hace lo que tiene que hacer con los
%alores esperados.
Luego normalmente se han probado con %alores nulos, cadenas %acas y %alores lmite. Co hemos probado
todas las clases, solo las que tenan cierta complejidad. 1abitualmente se ha hecho una prueba por mtodo
aunque en algunos casos se han tenido que hacer ms.
El frame4or+ elegido para las pruebas de unidad ha sido A/nit.
Pruebas de ntegracn
1.3.2.1.3.
Pruebas de rendmento
Para ver a veocdad de as transaccones hemos usado cases sencas con un
cronmetro software, para medr os rendmentos, ya que a veocdad era una
parte crtca de sstema.
1.3.2.2.
Documentacn.
En cuanto a la documentacin, no hemos prescindido de ella, hemos constatado que
son de gran utilidad los casos de uso bien documentados junto con diagramas de
acti%idad /-L.
10
Cos han sido especialmente
Dtiles para describir el comportamiento de los
controladores de cada uno de los casos de uso.
Los diagramas nos han ayudado a mejorar la producti%idad ya que permitan centrarse
en la funcionalidad que se estaba desarrollando y dejar de lado las preocupaciones de
las subsiguientes tareas.
Co nos han parecido Dtiles sin embargo los diagramas de clases, de colaboracin y de
secuencia., y por tanto no los he mos usado. Esto es porque siempre hemos usado los
mismos patrones0 -E2 , FaGade, 'ecorators, Factorys y '7H..
1.4.
Pancacn de proyecto
7 pesar de ser un proyecto gil, no hemos renunciado a una mnima planificacin,
inicialmente identificamos las siguientes etapas0
1.4.1. Investgacn tecnooga |2ee y posgtreSq
Se dedicar un tiempo finito a la formacin e in%estigacin. Iueremos e%aluar la nue%a
tecnologa AEE, 1ibernate, Spring y ASF. 7cabado ese tiempo elegiremos la tecnologa
que mejor se adapte a nuestro problema o la desarrollaremos nosotros mismos.
1.4.2. Instaacon de entorno
7ntes de empe&ar tan siquiera a hacer los casos de uso Jnstalaremos las siguientes
herramientas0
?
?
?
?
?
?
?
?
Eclipse con soporte para jee *Kanymede,
Aa%a 8.?
1erramienta de uml *-agic 'ra4,
.omcat
PostgreSql, jdbc y Pg7dmin.
Aunit *pruebas de unidad,
1ttp/nit *pruebas de integracin,
-etrics *para medir aspectos de calidad del soft4are,
Establecemos tambin un sistema de bac+up automati&ado a una unidad e)terna. Se
e%aluarn la instalacin de herramientas automati&adas de construccin de proyectos
como Ant y Maven.
1.4.3. Desarroo de a apcacn por casos de uso (sprnts)
En a termnooga SCRUM se denomnan sprnts. SCRUM es a metodooga de
desarroo a a que ntentamos atenernos en un prncpo.
11
1.4.3.1. Sprnt1. Transaccon de reserva de pazas.
7l ser la parte mas crtica, la de la gestin de las reser%as con transacciones, se har en
primer lugar para despejar todas las incertidumbres al respecto. Se harn pruebas de
estrs para asegurar el bue n rendimiento de la solucin adoptada.
1.4.3.2. Sprnt2. Bsqueda de ofertas (paquetes turstcos)
Se crear una pantalla de bDsqueda para locali&ar las ofertas por di%ersos criterios y se
enla&ar con la reser%a de pla&a.
1.4.3.3. Sprnt 3. Logn, Ata de usuaro e ntegracon con e
sstema
Se crearn pantallas para el usuario se pueda dar de alta en el sistema en cualquier punto
de la aplicacin y que e)ija estar registrado para hacer la reser%a
1.4.3.4. Sprnt 4. Gestn competa de cuenta de usuaro (CRUD) e
ntegracn con e sstema.
Se crearn las pantallas para el mantenimiento de la cuenta de usuario. 7lta, lectura,
modificacin y borrado.
1.4.3.5. Sprnt 5. Gestn de oferta de paquetes turstcos (CRUD)
Se crearan las pantallas para la gestin de las ofertas. , lectura, modificacin y borrado.
1.4.4. Cco de cada Sprnt:
?1 seguir un modelo en espiral con las etapas de anlisis, dise!o, pruebas y
codificacin e integracin.
Jnsertar grfico mostrando la espriral
1.4.5. Dagrama de Gannt
12
1.5.
Productos obtendos
1.5.1. Metodooga y herramentas de testng
A travs de a experenca obtenda en e desarroo de este proyecto, hemos
egado a desarroar una metodooga de testng que resueve agunos de os
probemas habtuaes en a mpantacn de pruebas automatzadas.
Asamento de e cdgo de pruebas de de produccn.
Hemos creado un workspace especco para e proyecto de reservas, dentro de
se ha creado un proyecto |ava para as pruebas: reservasTest. Este proyecto,
reservasTest accede a os otros proyectos de workspace, que contenen e cdgo
de produccn, as puede acceder a sus cases, nstancaras y probar sus mtodos.
E proyecto reservasTest tene en su casspath referencas a as breras |Unt,
HttpUnt, y as breras |DBC de Postgresq.
Los otros proyectos no tenen nnguna referenca a estas bbotecas. En a fase de
despegue no se exporta e proyecto reservasTest y os componentes de cdgo de
produccn no contenen nngn test n nnguna referenca a estos.
Pruebas de mtodos prvados.
Un probema frecuente con as pruebas es a prueba de os mtodos prvados de as
cases.
Nosotros hemos resueto este probema susttuyendo a vsbdad prvate de
campos y mtodos por a vsbdad de paquete, a vsbdad por defecto.
Las cases de prueba as ponemos en e msmo paquete que as cases a probar,
pero en e proyecto de reservasTest, es decr repcamos e paquete (a estructura
de drectoros)
Para |ava, cuando usa e casspath es como s estuvesen en e msmo paquete, y
por eo as cases de prueba, que estn en otro proyecto pueden ver os membros
con vsbdad de paquete.
13
Iustracn 1 Asamento de cdgo de pruebas de de produccn
Iustracn 2 pruebas de mtodos prvados
14
Utdades para pruebas
Se han creado unas cases de utdad que pueden ser reutzadas en cuaquer otro
proyecto estas cases estn en e paquete com.dbanch.testuts
Taba 1 Test uts
ConnectonPostgres
Proporcona una nueva conexn a PostgreSq, Servdor: ocahost.
User: postgres, Password: postgres
Void executeBatch(e)
SOLUt
Utdades para ser usadas con
pruebas que ncuyan una
base de datos.
Ejecuta un fichero batch sql.
Jnteger queryInteger(sq)
Ejecuta una sentencia que ha de de%ol%er
un entero.
TestUts
Tmer
Utdades para su uso en Tests. Parser de fechas.
Cronmetro smpe para medr rendmentos en Tests.
Pruebas de cases con acceso a bases de datos
Creemos que hemos haado una soucn extremadamente efectva a a vez que
senca para probar cases que acceden a bases de datos.
Para probar estas cases tradconamente a menudo se acababa escrbendo
compcado cdgo |dbc o cases dao, para pruebas sencas. E resutado es que
acababa desstendo de hacer todas as pruebas necesaras a estas cases.
La soucn que hemos haado est en a case SOLUt con sus dos mtodos.
E mtodo SOLUt.executeBatch(Strng e) permte a e|ecucn de un chero
batch sq, que usamos usado para preparar e estado de a base de datos para as
pruebas.
E mtodo SOLUt.queryInteger(Strng sq) e|ecuta una sentenca sq que ha de
devover un entero. Como por e|empo un SELECT COUNT(*), Luego ese vaor se
usar para vercar as pruebas.
A contnuacn mostramos un e|empo de uso de esta case para as pruebas:
pubc vod testReservaNormal() throws Exception {
Connection connection = createConnection();
SQLUtil sqlUtil = new SQLUtil(connection);
sqlUtilexec!te"atc#($sql%&r!e'aUnitariaReserva(&ost)resqlsql$);
ReservaCommand&ost)resql command&ost)resql = new
ReservaCommand&ost)resql(connection);
ReservaV* reserva = new ReservaV*();
reservaset+d*,erta(-);
reservaset+dCliente(-);
reservaset&la.asReservadas(-);
command&ost)resqldoReserva(reserva);
15
connectioncommit();
assertEquas(new +nte)er(-)/ sqlUtilq!er0+nte)er($SELEC1 C*UN1(2) 3R*4
RESERV5$));
connectionclose();
6
Fichero batch LsqlMPrueba/nitaria3eser%aNPostgresql.sqlO
1RUNC51E *3ER15/ CL+EN1E/ RESERV5 CASCADE;
INSERT INTO *3ER15
VALUES(1, 7&*R1U85L 9ER4*S*7/ 7V+5:E &*R L5S ;*N5S 45S "ELL5S <E &*R1U85L7/ 7=>>?@-@
-7/ 7=>>?@-@?7/ -/ -/ 7=>>A@-=@B-7);
INSERT INTO CL+EN1E
VALUES(1, 7<5N+EL7/ 7"L5NC9 "515LLER7/ 7<"L5NC97/ 7-=BC7/ 7=>>A@--@==7/ NULL);
INSERT INTO *3ER15
VALUES(2, 7EspaDa7/ 7EspaDa7/ 7=>>?@-@-7/ 7=>>?@-@?7/ ->/ ->/ 7=>>A@-=@B-7);
INSERT INTO *3ER15
VALUES(3, 73rancia7/ 73rancia7/ 7=>>?@-@-7/ 7=>>?@-@?7/ =>/ =>/ 7=>>A@-=@B-7);
E mtodo SOLUt.queryInteger(Strng sq), es todo o que nos hace fata para
os test, ya que se aprovecha de a exbdad y potenca de SOL.
A menos hasta ahora hemos poddo probar todo que nos ha hecho fata.
Por e|empo, s en a prueba anteror hubsemos querdo comprobar que se
haban nsertado todos os atrbutos en sus correspondentes campos, podramos
haber escrto a sentenca sq de mtodo de este otro modo :
SELECT COUNT(*) FROM RESERVA WHERE ID_OFERTA=1 AND ID_CLIENTE=1
AND PLAZAS_RESERVADAS=1
Y a funcn habra devueto 1, vadando e test.As de fc!
16
1.5.2. Entrega de producto
1.5.2.1. Acance de producto na
E rgor con e que hemos evado os tests ha hecho que nos hayamos tendo que
repantear e acance de proyecto, ago que es perfectamente aceptabe sguendo
a osofa de Desarroo Ag.
Hemos de|ado de ado os dos tmos sprnts, que eran os menos mportantes, os
de mantenmento de as cuentas de Cente y e mantenmento de as Ofertas.
Esta sera a etapa en a que presentaramos e producto a nuestro cente
obtendramos e feedback y reconducramos a apcacn para hacera an me|or.
En esta entrega, hemos mpementado os 3 prmeros sprnts programados
conformando un soo caso de uso competamente funcona, y con cadad
contrastada.
Para expcar e acance de a entrega o ustraremos con e sguente dagrama de
actvdad :
17
1.1.1.1.
Navegacn por as Pantaas
La prmera pantaa de a apcacn es a de stado de va|es. Nos permte trar
por todos os campos de a forma que queramos.
Iustracn 3 Lstado de va|es
S ntroducmos parmetros no vdos e sstema nos ndcara e error por cada
campo.
Iustracn 4 Lstado de va|es. Error
18
S no estamos ogados, a hacer cck sobre un eemento de a sta se nos mostrar
a pantaa de ogn.
Iustracn 5 Logn
E sstema vada os datos de entrada , y nos muestra os errores.
Iustracn 6 Logn. Error
19
Comprueba s exste e usuaro y s a contrasea es correcta.
Iustracn 7 Logn. no usuaro
Una vez ogado, e sstema nos eva a eemento de a sta
seecconado y que dspar este evento.
que habamos
Iustracn 8 Petcn de nmero de pazas
20
E sstema comprueba que e vaor ntroducdo es correcto, rechazndoo s no es
as.
Iustracn 9 Petcn de nmero de pazas. Error
S se pde un nmero de pazas nferor o gua a dsponbe, e sstema hace a
reserva e mprme un tcket
Iustracn 10 Impresn de tcket
21
S se pden mas pazas de as que se ofrecen pero queda todava aguna paza, e
sstema nos de|a pedr una cantdad menor.
Iustracn 11 Pazas nsucentes
S no queda nnguna paza e sstema nos nforma de hecho y no nos de|a mas
opcn que vover a a pantaa nca.
Iustracn 12 Nnguna paza
22
En e proceso de Logn, tambn podamos haber eegdo darnos de ata como
usuaro nuevo. E sstema hace as habtuaes comprobacones de os datos de
entrada.
Iustracn 13 Ata nuevo usuaro. Error
E sstema no permte a entrada de dos Centes con e msmo Logn.
Iustracn 14 Ata nuevo usuaro. Dupcado
23
2. Especcacn y requermentos
2.1.
Informacn nca
Oueremos crear un sstema reservas on-ne para una agenca de va|es. E negoco
de una agenca de va|es es a venta de paquetes turstcos que conssten en una
combnacn de dferentes servcos (transporte, ao|amento, excursones, guas,
etc..) en un soo producto.
E paquete turstco consta de un cdgo nterno, un nombre, un preco por
persona, una descrpcn, una presentacn ms o menos eaborada y un nmero
de pazas ofertadas.
E sstema de reservas debe ofrecer un catogo de paquetes turstcos por e que
se pueda buscar por dferentes crteros, como fechas de sada, duracn de va|e,
preco, etc.
Cuando un cente hace una reserva, e sstema debe actuazar e nmero de pazas
dsponbes, restando as que e cente ha reservado, evtando que se puedan
soctar ms pazas de as exstentes.
E sstema debe guardar con a reserva, e nombre de cente, e paquete soctado
y e nmero de pazas que quere.
E sstema debe permtr a ncusn futura con de una nterfaz con medos de
pago eectrnco.
E sstema tene que permtr a ntroduccn de paquetes turstcos en e catogo,
su modcacn, consuta y borrado. La modcacn y e borrado soo se podrn
hacer s no se ha venddo nnguna reserva.
E sstema tene que permtr e regstro de os centes donde ntroducrn
nformacn sobre sus datos personaes, tar|etas de crdto, etc. Tambn a
modcacn, consuta y borrado.
E sstema tene que mane|ar de manera ptma as transaccones, mnmzando
boqueos y asegurando a consstenca.
2.2.
Gosaro
Oferta: Producto en venta por a agenca de va|es
Cente: Usuaro de a apcacn regstrado
Reserva: Soctud de venta de una oferta
Paquete Turstco: Agregado de servcos turstcos que vende una agenca de
va|es
24
2.3.
Oferta:
Modeo de domno
o Nombre
o Descrpcn
o Fecha de Inco
o Fecha de Fn
o Duracn
o Pazas Dsponbes
o Pazas Totaes
o Fecha mte de compra
Reserva
o Numero de pazas reservadas
o Oferta
o Cente
Cente
o Nombre
o Apedos
o Logn
o Password
o Fecha de Ata
25
2.4.
Dagrama de casos de uso
2.5.
Documentacn textua de os casos de uso
Expcacn de modeo segudo para documentar os casos de uso
Se ha segudo un modeo de Astar Cockburn, gran especasta en metodoogas
de desarroo.
La nca pequea dcutad de a estructura de estos casos de uso es e
segumento de u|o. Como sabemos, una nteraccn con un sstema puede tener
ramcacones, y estas sueen ser dfces de expcar. Trataremos de mostrar
como con un e|empo como as expresa este modeo
Caso de uso:
Sstema de ata segurdad de acceso a contro de anzamento de mses
Fu|o prncpa:
1 E usuaro se senta a os mandos y pusa e botn de acceso
26
2 E sstema pregunta su nombre de usuaro y contrasea
3 E usuaro ntroduce su nombre y contrasea
4 E sstema comprueba sus credencaes y e permte e acceso a contro de
anzamento de mses
Fu|o aternatvo:
*a E usuaro pusa e botn ABORT
1 E sstema vueve a a poscn standby
4a E sstema comprueba que sus credencaes son errneas
1 E sstema devueve a usuaro a punto 2 nformndoe de error
4b E sstema detecta que e usuaro ha ntroducdo sus credencaes errneamente
tres veces
1 E sstema boquea a cuenta de usuaro
2 E sstema cerra as compuertas bndadas de edco
3 E sstema abre as vvuas de gas parazante
4 E sstema dspara a aarma de INTRUSO EN INSTALACIONES
Expcacn:
E u|o prncpa se numeran os pasos
En e u|o aternatvo se expcan as ramcacones. E prmer nmero es e paso
de u|o prncpa, a etra es a referenca de a ramcacn de ese paso. S un paso
1 se puede hacer de 3 formas dferentes, en e u|o aternatvo tendr tres ramas
1a , 1b, 1 c.
Dentro de a rama de u|o aternatvo os pasos se numeran empezando por e
uno.
2.5.1. Bsqueda de ofertas de paquetes turstcos
Actores:
Usuaro
Fu|o prncpa:
1) E usuaro e|e a opcn de bsqueda de oferta.
2) E sstema muestra una pantaa con os crteros de seeccn de ofertas:
nombre (crtero: contene paabra)
27
descrpcn (crtero: contene paabra)
fechaInco (crtero: mayor o gua que)
fechaFn (crtero: menor o gua que)
duracn (crtero: gua a con dos das por arrba y dos das por aba|o)
pazasDsponbes (crtero: mayor que)
3) E usuaro e|e uno o varos de os crteros de bsqueda y seeccona e tro.
4) E sstema muestra una pantaa con os resutados de a bsqueda. En nngn
caso mostrar aqueas ofertas para as que no exstan pazas dsponbes, n cuya
fecha mte de compra sea mayor o gua a a actua.
5) E usuaro ege una de as ofertas.
6) E sstema muestra e detae de a oferta.
Fu|o aternatvo:
*a) E usuaro cancea en cuaquer momento.
1) e sstema devueve a a pantaa prncpa
4a) E sstema detecta que no se ha seecconado nngn crtero de bsqueda
1) E sstema nforma de error y devueve a punto 2
4b) E sstema detecta que aguno de os campos no contenen datos vdos para a
bsqueda. E|. as fechas no son fechas vdas, e campo duracn o e campo
pazasDsponbes no son nmeros
1) E sstema nforma de error y devueve a punto 2
Puntos de extensn:
7) E usuaro e|e reservar a oferta mostrada en detae.
1) E sstema enaza con e caso de uso de reserva de paza.
Requstos no funconaes:
E sstema debe ser rpdo en devover os resutados. Esto mpca que a
transaccn debe permtr hacer ecturas sucas, ya que es mas mportante a
veocdad de respuesta que a exacttud de contendo.
Temas pendentes:
Comprobar resgo de sq n|ecton a construr una cusua where dnmca.
2.5.2. Reserva de pazas de paquetes turstcos
Actores:
28
Usuaro
Dsparador:
E usuaro ha seecconado una de as ofertas exstentes que tenen dsponbdad
de paza en ese momento.
Precondcn:
E usuaro est regstrado.
Fu|o prncpa:
1) E sstema presenta una pantaa con os datos de a oferta:
cdgo nterno (no se mostrar) (no edtabe)
nombre (no edtabe)
descrpcn (no edtabe)
fechaInco (no edtabe)
fechaFn (no edtabe)
duracn (no edtabe)
nmero de pazas dsponbes (no edtabe)
nmero de pazas deseadas (edtabe)
2) E usuaro ntroduce e nmero de pazas deseado
3) E sstema regstra a reserva y notca a usuaro e xto de a operacn.
Fu|o aternatvo:
1-2a) E usuaro cancea a operacn
1) E sstema devueve a a pantaa prncpa
2a) E nmero de pazas que socta e usuaro es 0 o nuo
1) E sstema nforma de error y vueve a punto 1 (con datos actuazados).
2b)E nmero de pazas que socta e usuaro es superor a nmero de pazas
dsponbes
1) E sstema nforma de error y vueve a punto 1 (con datos actuazados).
Poscondcn:
E usuaro tene N reservas de a oferta O
Requstos no funconaes:
29
Las transaccones deben ser rpdas y correctas., por o que deben boquear a
ectura de pazas para uego poder actuazara, restando as pazas, pero e mnmo
tempo posbe para permtr que otras transaccones operen sobre e msmo
regstro.
La transaccn tene que ser segura, no puede ser fascabe aterando parmetros
de a petcn.
2.5.3. Logn
Dsparadores:
E usuaro ege hacer una reserva y no esta regstrado en e sstema.
E usuaro ege a opcn de regstrarse en e sstema.
Fu|o prncpa:
1) E sstema muestra una pantaa con os campos de:
nombre de usuaro
password
2) E usuaro escrbe su nombre y password.
3) E sstema comprueba que e usuaro exste y su contrasea es correcta, por o
que devueve a usuaro a punto donde se orgn e evento, es decr pantaa de
nco o a a reserva que estaba apunto de reservar.
Fu|o aternatvo:
1-2a) E usuaro cancea a operacn.
1) E sstema devueve a usuaro a men prncpa
3a) E sstema detecta que e usuaro no exste o que a contrasea es ncorrecta.
1) E sstema notca e error y devueve a usuaro a punto 1 con os datos
ntroducdos por e usuaro.
Requstos no funconaes:
En nngn caso debe ntercambarse entre e navegador y e servdor e nombre de
usuaro y/o a contrasea una vez pasada a vadacn, para evtar supantacn de
dentdad o robo de contrasea.
Temas pendentes:
Hacer que e proceso de autentcacn vaya encrptado con SSL (estmar e coste)
Hacer que e password de usuaro vaya encrptado dentro de a base de datos
(estmar coste)
30
2.5.4. Mantenmento cuenta de usuaro
2.5.4.1.
Dsparadores:
Desde pantaa de ogn e usuaro ege a opcn de darse de ata en e sstema.
Desde a pantaa de mantenmento de cuenta de usuaro, e usuaro ege a opcn
de darse ata.
Fu|o prncpa:
1) E sstema muestra una pantaa con os campos de (todos obgatoros):

nombre (campo obgatoro)

apedos (campo obgatoro)
ogn (campo obgatoro)
password (campo obgatoro)
Ata de usuaro
2) E usuaro reena os datos.
3) E sstema regstra os datos en a base de datos, reenando una fecha de ata y
devueve a usuaro a a pantaa de ogn comuncando e xto de a operacn.
Fu|o aternatvo:
1-2a) E usuaro cancea a operacn.
1) E sstema devueve a usuaro a a pantaa de nco.
3a) E sstema detecta que no se han reenado todos os campos
1) E sstema ndca que campos son os que no se han reenado y devueve
a punto 1 con os datos que ha enado e usuaro.
3c) E sstema detecta que ya exste un usuaro con e msmo ogn
1) E sstema comunca e error e nsta a usuaro a cambar e ogn
2) E sstema devueve a usuaro a punto 1
Requstos no funconaes:
En nngn caso debe ser vsbe e nombre de usuaro y/o a contrasea una vez
pasada a vadacn.
Temas pendentes:
Hacer que e proceso de ata vaya encrptado con SSL (estmar e coste)
31
Hacer que a contrasea de usuaro vaya encrptada dentro de a base de datos
(estmar coste)
Requerr una contrasea con un nve de segurdad aceptabe es decr con un
nmero de caracteres sucentes, que contenga nmeros, etc. (estmar coste)
2.5.4.2.
Precondcn:
E usuaro se ha ogado en e sstema prevamente con o que tene vsbe a opcn
de mantenmento de cuenta de usuaro.
Consuta de usuaro
Fu|o prncpa:
1) E usuaro ege a opcn de mantenmento de usuaro
2) E sstema recupera os datos de usuaro y muestra una pantaa con os campos
de:

nombre
apedos
ogn
password
Fu|o aternatvo:
*a) E usuaro cancea a operacn
1) E sstema devueve a a pantaa de nco
Puntos de extensn:
Borrar (desactvar) usuaro.
Modcar usuaro.
2.5.4.3.
Dsparadores:
Desde a pantaa de mantenmento de cuenta de usuaro, e usuaro ege a opcn
de modcar su cuenta.
Precondcn:
E usuaro se ha ogado en e sstema prevamente con o que tene accesbe a
opcn de mantenmento de cuenta de usuaro.
Fu|o prncpa:
32
Modcacn de usuaro
1) E sstema recupera os datos de usuaro y muestra una pantaa con os
campos de:

nombre
apedos
ogn
password
2) E usuaro reena os datos.
3) E sstema regstra os datos en a base de datos y devueve a usuaro a a
pantaa nca.
Fu|o aternatvo:
1-2a) E usuaro cancea a operacn
1 E sstema devueve a a pantaa anteror
3a) E sstema detecta que no se han reenado todos os campos
1) E sstema ndca que campos son os que no se han reenado y devueve
a punto 1
3c) E sstema detecta que ya exste un usuaro con e msmo ogn
1) E sstema comunca e error e nsta a usuaro a cambar e ogn
2) E sstema devueve a usuaro a punto 1
Temas pendentes:
Hacer que e proceso de modcacn vaya encrptado con SSL (estmar e coste).
Hacer que a contrasea de usuaro vaya encrptada dentro de a base de datos
(estmar coste).
Requerr una contrasea con un nve de segurdad aceptabe es decr con un
nmero de caracteres sucentes, que contenga nmeros, etc. (estmar coste).
2.5.4.4.
Precondcn:
E usuaro se ha ogado en e sstema prevamente con o que tene accesbe a
opcn de mantenmento de cuenta de usuaro.
Fu|o prncpa:
1) E usuaro ege borrar o darse de ba|a
2 )E sstema pde conrmacn
33
Borrado de usuaro
3) E usuaro acepta
4) E sstema escrbe en fecha de ba|a e da de hoy, con o que queda regstrada a
ba|a. (ba|a gca) y devueve a usuaro a a pantaa de nca de a apcacn.
Fu|o aternatvo:
1-3) E usuaro cancea a operacn
1 E sstema vueve a a pantaa de detae de usuaro.
2.5.5. Mantenmento de ofertas
Sstema opcona que estar stuado dentro de a ntranet de cente, por o que no
ser en prncpo necesaro nnguna consderacn de segurdad especa.
2.5.5.1.
Fu|o prncpa:
1) E usuaro ege a opcn de crear una nueva oferta.
2) E sstema muestra una pantaa con os campos:

Nombre (campo obgatoro)

Descrpcn (campo obgatoro)
fechaInco (campo obgatoro)
fechaFn (campo obgatoro)
pazasTotaes (campo obgatoro)
fechaLmteDeCompra (campo obgatoro)
Ata de oferta
3) E usuaro reena os datos.
4) E sstema regstra os datos en a base de datos, ncaza pazasDsponbes =
pazasTotaes, y devueve a usuaro a a pantaa de ogn comuncando e xto de
a operacn.
Fu|o aternatvo:
1-3a) E usuaro cancea a operacn
1) E sstema devueve a usuaro a a pantaa de nco.
4a) E sstema detecta que no se han reenado todos os campos
1) E sstema ndca que campos son os que no se han reenado y devueve
a punto 2 con os datos que reen e usuaro.
4b) E sstema detecta nconsstencas en os datos. E|. fechaInco mayor o gua a
fechaFn. fechaLmte de compra menor que hoy().
34
1) E sstema nforma de os errores y devueve a punto 2 con os datos que
reen e usuaro.
2.5.5.2.
Fu|o prncpa:
1) E usuaro e|e a opcn de bsqueda de ofertas
2) E sstema muestra una pantaa con os crteros de seeccn de ofertas:
nombre (crtero: contene paabra)
descrpcn (crtero: contene paabra)
fechaInco (crtero: mayor o gua que)
fechaFn (crtero: menor o gua que)
3) E usuaro e|e uno o varos de os crteros de bsqueda y seeccona e tro.
4) E sstema muestra una pantaa con os resutados de a bsqueda.
5) E usuaro ege una de as ofertas.
6) E sstema muestra e detae de a oferta.
Fu|o aternatvo:
*a) E usuaro cancea en cuaquer momento.
1) E sstema devueve a a pantaa prncpa.
4a) E sstema detecta que no se ha seecconado nngn crtero de bsqueda
1) E sstema nforma de error y devueve a punto 2
4b) E sstema detecta que aguno de os campos no contenen datos vados para a
bsqueda. Es decr as fechas no son fechas vdas o e rango no es correcto.
1) E sstema nforma de error y devueve a punto 2
Requstos no funconaes:
En e stado deben sar todas as ofertas pero deberamos evtar as ecturas
sucas, ver e nve de asamento optmo de transaccones.
2.5.5.3. Modcacn y ba|a de oferta
Oueda fuera de mbto de proyecto por ser demasado compe|o. E sstema
necestara detectar s se ha hecho aguna reserva, s es as dependendo de dato
que se quera modcar, deber permtr o no a modcacn. Tambn debera
avsar a os usuaros y permtr que canceasen a reserva, etc.
En cuanto a as transaccones, cuando menos, tendra que boquear durante a
modcacn, a nsercn de nuevos regstros.
35
Consuta de oferta
2.6.
Requstos de a nterfaz de usuaro
La nterfaz de usuaro ser HTML, ya que es una apcacn Web. Prescndremos
de |avascrpt, porque e usuaro o puede desactvar. Evtaremos os dseos
compcados para que e tratamento de pruebas con httpUnt sea posbe.
Haremos hncap en que a navegacn est muy controada. La navegacn ha de
permtr buscar os va|es y soo cuando se seeccone uno, nos pedr ogarnos, o
darnos de ata en e sstema.
E sstema ha de ser amgabe, en partcuar a a hora de mostrar os errores de
vadacn de os formuaros. Estos tenen que presentarse a ado de msmo
campo que orgn e error.
Usaremos css para separar e dseo de os datos.
Cudaremos a mxmo a segurdad evtando e paso de parmetros sensbes a
navegador, como por e|empo datos de a cuenta de usuaro.
3. Anss
3.1.
Identcacn de as cases de entdades y sus atrbutos
36
3.2.
3.3.
Dagramas de estados
Dagramas de actvdades
3.3.1. Transaccn de reserva de paza
37
3.3.2. Reserva de paza (bsqueda + reserva)
38
3.3.3. Logn
39
3.3.4. Ata de usuaro
40
3.3.5. Integracn (bsqueda, Logn, ata, reserva)
3.4.
Modeo de datos
41
4. Dseo tcnco
La apcacn est basada en Struts que es una mpementacn de patrn
arqutectnco MVC. Modeo Vsta Controador. Es un Framework antguo ya, pero
sgue sendo vdo.
4.1.
Vsta-Controador: Vadator y Parser hepers
7 la arquitectura habitual de Struts, le hemos a!adido unas clases que han simplificado
el desarrollo en gran medida. En estas clases hemos in%ertido mucho tiempo en pruebas
ya que segDn nuestra e)periencia es en la %alidacin de los datos del us uario, donde mas
suelen fallar las aplicaciones.
En nuestra aplicacin el mtodo %alidate del 7ctionForm se hace slo con mtodos de
la clase Ealidator.
En el 7ction, la con%ersin de los campos del 7ctionForm
e)clusi%amente con la clase Parser.
a objetos se hace
7 continuacin e)ponemos sus tarjetas 232. En el diagrama de secuencia posterior se
puede %er su papel el la parte arquitectura Struts.
Case: com.dblanch.utils.Ealidator
Responsabdad: %alidar las entradas de los campos de los 7ctionForm, que son
siempre strings
Coaboracones: Parser, 7ctionForm
Case: com.dblanch.utils.Parser
Responsabdad: con%ertir las cadenas de los 7ctionForm en objeto,s como por
ejemplo de un String a un 'ate
Coaboracones: Ealidator. 7ctionForm, 7ction
42
43
4.2.
E modeo
E modeo esta en su propo proyecto reservasMode , as permtmos este msmo
componente se pueda usar en otro entorno que no sea e web.
4.2.1. La Fachada
Para acceder a sus funconadades, o hacemos excusvamente a travs de un
ob|eto Fachada, que es un ob|eto que permte ofrecer una nterfaz uncada
senca y que deega todos sus mtodos en otros ob|etos.
En nuestra apcacn, a fachada deega en os DAO y a os ob|etos de negoco.
Los Acton de Struts, para acceder a modeo soo nteractan con a fachada, nunca
nvocan Ob|etos de negoco asadamente.
Hemos mentdo un poco, nuestra fachada no es puramente una fachada, hace ago
mas que deegar os mtodos, obtene un ob|eto |ava.sq.Connnecton y se os pasa
a os ob|etos en os que deega. Tambn se encarga de gestonar a transaccn y
cerrar a conexn una vez termnado con e mtodo.
Esto o hace mpementando otro Patrn que es e Tempate. E mtodo
|ava.sq.Connecton getConnecton() es abstracto y as cases h|as o mpementan
de dferente forma.
La forma de obtener a conexn a a base de datos en un contenedor |2EE es
dstnta a a forma de hacero fuera. En un contenedor se ocaza un DataSource
que provee un poo1 de conexones regstrado ba|o un nombre2.
Fuera de contenedor se obtene de a forma habtua.
Es un con|unto de conexones, como e coste de obtener nuevas conexones es
eevado, os servdores |2EE sueen tener un grupo de estas abertas y as reccan
entre sus petcones.
1
2
Consutar tecnooga |NDI
44
Como vemos en e dagrama hemos mpementado dos ModeFacade. Uno para e
servdor Tomcat y otro para Test, con este tmo es con e que usamos para
reazar as pruebas.
An queda un punto de compe|dad por expcar, e ob|eto ModeFacadeTomcat no
se nstanca drectamente con un operador new. S no que hemos usado una case
Factory para nstancaro.
La razn detrs de esta aparente compe|dad es que esta arqutectura nos permte
poder cambar e ob|eto de mpementacn ModeFacade por otro que podra ser
un ModeFacadeMock, por e|empo.
45
Los Mock ob|ects son ob|etos que no mpementan funconadad rea y srven soo
para pruebas.Los mtodos que devueven datos de ob|eto Mock, devueven
tambn ob|etos Mock. Esta estratega se puede usar para desarroar a parte web,
sn depender de unos datos de a base de datos o para poder traba|ar en a parte
web, sn tener termnada a parte de modeo. As se puede traba|ar en paraeo en
ambas partes.
Para cambar de mpementacn de ModeFacade, so habra que cambar e
Factory.
5. Impementacn
5.1.
Herramentas de desarroo
Ecpse con soporte para |ee (Ganymede)
|ava 1.6
Herramenta de um (Magc Draw)
Tomcat
PostgreSq, |dbc y PgAdmn.
|unt (pruebas de undad)
HttpUnt (pruebas de ntegracn)
Metrcs (para medr aspectos de cadad de software)
46
5.2.
Proceso de nstaacn
Creacn de base de datos
Se debe crear una base de datos amada tfc y un usuaro postgres, con pasword
postgress
Luego e|ecutar en orden os sguentes scrpts
ReservasDateabase/DataBaseDenton_Postgresq.sq (crea a base de datos)
ReservasDatabase/ProcedmentoReserva_Postgresq.sq (crea e scrpt de a
funcn para hacer a reserva)
ReservasDatabase/Integracon_Postgresq.sq (carga un pequeo |uego de datos de
prueba)
Puesta a punto de servdor |2ee
Necestamos un DataSource para postgresq ba|o e nombre |nd : |dbc/postgres
que se conecte a a base de datos tfc
En tomcat se modca e chero context
EFxml version=$->$ encodin)=$U13@A$FG
EContextG
EHatc#edReso!rceGHE"@+N3%Ie'xmlE%Hatc#edReso!rceG
EReso!rce name=$Jd'c%post)res$ a!t#=$Container$ t0pe=$Javaxsql<ataSo!rce$
driverClassName=$or)post)resql<river$
!rl=$Jd'cKpost)resqlKt,c$
!sername=$post)res$ passIord=$post)res$ max5ctive=$=>$ max+dle=$->$
maxHait=$@-$ %G
E%ContextG
Obtencon de as breras de struts, |unt 1.3, httpUnt, y |dbc de Postrgres
Las breras struts 1.1 y as breras dependentes rn en
/reservasWeb/WebContent/WEB-INF/b
Las breras de |unt.1.3 y httpUnt y e |dbc de postrares rn en e proyecto
/reservasLbs
E proyecto reservasTest ha de mportar todas estas breras.
Arrancar ecpse en e workspace y e|ecutar a apcacn web
5.3.
|uego de pruebas
Dentro de proyecto reservasWeb podemos e|ecutar as sguentes pruebas:
47
Sute de pruebas de undad (|unt);
/reservasTest/src/com/dbanch/sute/ATests.|ava
Pruebas de ntegracn (httpUnt):
Prmero arrancar a apcacn web.
/reservasTest/src/com/dbanch/ntegracn/IntegraconTest.|ava
Pruebas de rendmento;
/reservasTest/src/com/dbanch/ntegracn/RendmentoEscrturaADsco.|ava
/reservasTest/src/com/dbanch/ntegracn/RendmentoTransaccones.|ava
/reservasTest/src/com/dbanch/ntegracn/TransacconesMutthread.|ava
Con ecpse podemos e|ecutar todas as pruebas que se encuentren en un
drecctoro, que es como hemos hecho estas.
Resutado de a e|ecucn de |uego de pruebas, de a apcacn, (reservasTest).
como vemos tenemos 71 mtodos de prueba, todos se han e|ecutado con xto.
EFxml version=$->$ encodin)=$U13@A$FG
Etestr!n name=$src$ proJect=$reservas1est$ tests=$L-$ started=$L-$ ,ail!res=$>$
errors=$>$ i)nored=$>$G
Etests!ite name=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$G
Etestcase name=$testSetNom're$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet<escripcion$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet3ec#a+nicio$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet3ec#a3in$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet&la.as<isponi'les$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet<!racion$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testComposeSQL$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#inte)ration+nte)racion1est$ time=$L==A$G
Etestcase name=$test5ltaNom're<!plicado$
classname=$comd'lanc#inte)ration+nte)racion1est$ time=$BMN=$ %G
Etestcase name=$testReservaN!evoUs!ario$
classname=$comd'lanc#inte)ration+nte)racion1est$ time=$-AN-$ %G
Etestcase name=$testReservaLo)in$
classname=$comd'lanc#inte)ration+nte)racion1est$ time=$-L=N$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#,rontendS0stem3acade5'stract1est$ time=$>>MC$G
Etestcase name=$test3ind*,ertas$
classname=$comd'lanc#,rontendS0stem3acade5'stract1est$ time=$>>BA$ %G
Etestcase name=$test5ddCliente1est$
classname=$comd'lanc#,rontendS0stem3acade5'stract1est$ time=$>>=M$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#!tils&arser1est$ time=$>>>=$G
Etestcase name=$test&arse<ate$ classname=$comd'lanc#!tils&arser1est$
time=$>>>-$ %G
48
Etestcase name=$test&arse+nte)er$
classname=$comd'lanc#!tils&arser1est$ time=$>>>-$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#clienteClienteV*1est$ time=$>>>C$G
Etestcase name=$test1oStrin)$
classname=$comd'lanc#clienteClienteV*1est$ time=$>>>C$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#clienteCliente<5*1est$ time=$>>AB$G
Etestcase name=$test5dd<!plicate$
classname=$comd'lanc#clienteCliente<5*1est$ time=$>>=A$ %G
Etestcase name=$test5dd$ classname=$comd'lanc#clienteCliente<5*1est$
time=$>>-L$ %G
Etestcase name=$test3indCliente"0Lo)in5nd&assIord$
classname=$comd'lanc#clienteCliente<5*1est$ time=$>>BA$ %G
E%tests!iteG
Etests!ite name=$5ll tests$ time=$>C?N$G
Etests!ite name=$comd'lanc#o,erta*,erta<5*1est$ time=$>>NA$G
Etestcase name=$test3ind*,ertas$
classname=$comd'lanc#o,erta*,erta<5*1est$ time=$>>C=$ %G
Etestcase name=$test3ind*,erta"0&O$
classname=$comd'lanc#o,erta*,erta<5*1est$ time=$>>-M$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>>B$G
Etestcase name=$testSetNom're$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>>-$ %G
Etestcase name=$testSet<escripcion$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet3ec#a+nicio$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet3ec#a3in$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>>-$ %G
Etestcase name=$testSet&la.as<isponi'les$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testSet<!racion$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>$ %G
Etestcase name=$testComposeSQL$
classname=$comd'lanc#o,erta*,ertaQ!er0"!ilder1est$ time=$>>>-$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#reservaReservaCommand1est$ time=$>=AB$G
Etestcase name=$testReservaNormal$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>>=A$ %G
Etestcase name=$testReserva&la.as+ns!,icientes$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>>=L$ %G
Etestcase name=$testReservaNin)!na&la.a$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>--?$ %G
Etestcase name=$testUpdate*,erta$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>->?$ %G
E%tests!iteG
Etests!ite
name=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>L$G
Etestcase name=$testNin)!nCritierio<e"!sq!eda$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>N$
%G
Etestcase name=$test3ec#a+nicio$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>$
%G
Etestcase name=$test3ec#a3in$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>-$
%G
Etestcase name=$test&la.as<isponi'lesNoValido$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>-$
%G
Etestcase name=$test<!racionNoValido$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>$
%G
E%tests!iteG
Etests!ite name=$comd'lanc#!tilsValidator1est$ time=$>>>B$G
Etestcase name=$test3ec#aValida$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
Etestcase name=$testRan)o3ec#asCorrecto$
classname=$comd'lanc#!tilsValidator1est$ time=$>>>-$ %G
Etestcase name=$testN!meroNat!ral$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
Etestcase name=$testValorN!lo$
classname=$comd'lanc#!tilsValidator1est$ time=$>>>=$ %G
Etestcase name=$testExceeds4axSi.e$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
49
Etestcase name=$testNotReac#4inSi.e$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#!tils&arser1est$ time=$>>>-$G
Etestcase name=$test&arse<ate$
classname=$comd'lanc#!tils&arser1est$ time=$>>>-$ %G
Etestcase name=$test&arse+nte)er$
classname=$comd'lanc#!tils&arser1est$ time=$>>$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#,rontendS0stem3acade5'stract1est$
time=$>>N-$G
Etestcase name=$test3ind*,ertas$
classname=$comd'lanc#,rontendS0stem3acade5'stract1est$ time=$>>=A$ %G
Etestcase name=$test5ddCliente1est$
classname=$comd'lanc#,rontendS0stem3acade5'stract1est$ time=$>>=B$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#reservasIe'reservaReserva3orm1est$
time=$>>>-$G
Etestcase name=$test&la.as<eseadasValido$
classname=$comd'lanc#reservasIe'reservaReserva3orm1est$ time=$>>>-$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#clienteClienteV*1est$ time=$>>>-$G
Etestcase name=$test1oStrin)$
classname=$comd'lanc#clienteClienteV*1est$ time=$>>>-$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#clienteCliente<5*1est$ time=$>>AL$G
Etestcase name=$test5dd<!plicate$
classname=$comd'lanc#clienteCliente<5*1est$ time=$>>=N$ %G
Etestcase name=$test5dd$
classname=$comd'lanc#clienteCliente<5*1est$ time=$>>=M$ %G
Etestcase name=$test3indCliente"0Lo)in5nd&assIord$
classname=$comd'lanc#clienteCliente<5*1est$ time=$>>BM$ %G
E%tests!iteG
E%tests!iteG
Etests!ite name=$comd'lanc#reservasIe'clienteCliente&arser1est$ time=$>>>-$G
Etestcase name=$test&arse$
classname=$comd'lanc#reservasIe'clienteCliente&arser1est$ time=$>>>-$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$
time=$>>>B$G
Etestcase name=$testNin)!nCritierio<e"!sq!eda$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>-$
%G
Etestcase name=$test3ec#a+nicio$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>$
%G
Etestcase name=$test3ec#a3in$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>-$
%G
Etestcase name=$test&la.as<isponi'lesNoValido$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>>-$
%G
Etestcase name=$test<!racionNoValido$
classname=$comd'lanc#reservasIe''!sq!edao,ertas"!sq!eda*,ertas3orm1est$ time=$>>$
%G
E%tests!iteG
Etests!ite name=$comd'lanc#reservasIe'reservaReserva3orm1est$ time=$>>$G
Etestcase name=$test&la.as<eseadasValido$
classname=$comd'lanc#reservasIe'reservaReserva3orm1est$ time=$>>$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#reservaReservaCommand1est$ time=$>->C$G
Etestcase name=$testReservaNormal$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>>==$ %G
Etestcase name=$testReserva&la.as+ns!,icientes$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>>==$ %G
Etestcase name=$testReservaNin)!na&la.a$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>>=L$ %G
Etestcase name=$testUpdate*,erta$
classname=$comd'lanc#reservaReservaCommand1est$ time=$>>B=$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#!tilsValidator1est$ time=$>>>C$G
Etestcase name=$test3ec#aValida$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
Etestcase name=$testRan)o3ec#asCorrecto$
classname=$comd'lanc#!tilsValidator1est$ time=$>>>-$ %G
Etestcase name=$testN!meroNat!ral$
classname=$comd'lanc#!tilsValidator1est$ time=$>>>B$ %G
50
Etestcase name=$testValorN!lo$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
Etestcase name=$testExceeds4axSi.e$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
Etestcase name=$testNotReac#4inSi.e$
classname=$comd'lanc#!tilsValidator1est$ time=$>>$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#o,erta*,ertaV*1est$ time=$>>>-$G
Etestcase name=$test8et<!racion$
classname=$comd'lanc#o,erta*,ertaV*1est$ time=$>>>-$ %G
E%tests!iteG
Etests!ite name=$comd'lanc#o,erta*,erta<5*1est$ time=$>>AM$G
Etestcase name=$test3ind*,ertas$
classname=$comd'lanc#o,erta*,erta<5*1est$ time=$>>M$ %G
Etestcase name=$test3ind*,erta"0&O$
classname=$comd'lanc#o,erta*,erta<5*1est$ time=$>>=M$ %G
E%tests!iteG
E%testr!nG
6. Concusones
Uso de metodooga g
No hemos poddo apcar una metodooga de desarroo g competamente,
porque nos fataba a parte fundamenta que es tener a cente dentro de equpo
de desarroo, para vercar e producto y proponer cambos. Pero hemos usado
otras prctcas que s podemos evauar, como os ccos de desarroo cortos y as
pruebas automatzadas.
Ccos de desarroo cortos
Hemos afrontado e proyecto como una sucesn de pequeos subprogramas
competos.
Como prmera consecuenca, e centrarnos en una pequea parte nos ha permtdo
denr os casos de uso perfectamente, sn ecos, en especa a nteraccn con e
sstema de forma exceente.
La notacn de casos de uso de Astar Cockburn y os dagramas de actvdad han
demostrado ser unas exceentes herramentas para esta abor.
Pruebas de undad automatzadas
Han sdo mucho mas aborosas de hacer de o que pensaba, creo que tardbamos
hasta cuatro o cnco veces mas en hacer as pruebas que en escrbr e cdgo. Y
escrbr cdgo que se pueda probar ya es de por s mas aboroso.
Sn embargo creemos que han sdo muy tes, apenas hemos pasado tempo
depurando cdgo. Y no hemos perddo nada de tempo en a ntegracn.
Creemos que en e punto 1.3.2.1. queda demostrado a necesdad de hacer pruebas
de undad, s se quere probar e cdgo. Soo con as pruebas de ntegracn es
mposbe.
Hoy en da todava se sguen de|ando as pruebas para e na en os desarroos,
entonces soo podrn ser pruebas de ntegracn. Y como hemos vsto a
51
compe|dad de una prueba competa de ntegracn crece exponencamente en
funcn de nmero de componentes sobre os que opere, mentras que e coste de
as pruebas de undad es nea
En dentva, creemos que as pruebas de undad deben ser un paso necesaro en
todo desarroo de software.
Metodooga de tests y herramentas.
Creemos que hemos ogrado un buen sstema para hacer pruebas con Ecpse, a
forma de separar as pruebas en un proyecto aparte es muy t.
7. Bbografa
|Unt Recpes , |BRansberr Edtora Mannng
Head Frst Desgn Patterns, Erc Freeman &Esabeth Freeman Edtora ORey
Pensa en |ava, Bruce Ecke Edtora Prentce Ha
Core |ava Voume II Advanced Features, Cay S. Horstmann Edtora PH PTR
Struts KICK START, |ames Turner and Kevn Bede
52