Documentos de Académico
Documentos de Profesional
Documentos de Cultura
09
Fecha de entrega
14/01/2009
Tabla de contenido
1.
Introduccin........................................................................................................... 4
1.1. Justificacin del proyecto............................................................................................................. 4
1.2. Objetivos del trabajo....................................................................................................................... 5
1.2.1. Objetivos tcnicos.........................................................................................................................5
1.2.2. Objetivos metodologicos...........................................................................................................6
1.3. Enfoque metodolgico.................................................................................................................... 6
1.3.1. Manifiesto gil ................................................................................................................................7
1.3.2. Aplicacin de la metodologa gil en nuestro proyecto..............................................8
1.4. Planificacin del proyecto......................................................................................................... 11
1.4.1. Investigacin tecnologa j2ee y posgtreSql ....................................................................11
1.4.2. Instalacion de entorno.............................................................................................................11
1.4.3. Desarrollo de la aplicacin por casos de uso (sprints) .............................................11
1.4.4. Ciclo de cada Sprint: .................................................................................................................12
1.4.5. Diagrama de Gannt....................................................................................................................12
1.5. Productos obtenidos.................................................................................................................... 13
1.5.1. Metodologa y herramientas de testing ...........................................................................13
1.5.2. Entrega del producto................................................................................................................17
2.
3.
Anlisis .................................................................................................................. 36
3.1. Identificacin de las clases de entidades y sus atributos....................................... 36
3.2. Diagramas de estados.................................................................................................................. 37
3.3. Diagramas de actividades......................................................................................................... 37
3.3.1. Transaccin de reserva de plaza.........................................................................................37
3.3.2. Reserva de plaza (bsqueda + reserva) ...........................................................................38
3.3.3. Login................................................................................................................................................39
3.3.4. Alta de usuario ............................................................................................................................40
3.3.5. Integracin (bsqueda, Login, alta, reserva) .................................................................41
3.4. Modelo de datos .............................................................................................................................. 41
4.
Diseo tcnico...................................................................................................... 42
4.1. Vista-Controlador: Validator y Parser helpers ............................................................. 42
4.2. El modelo............................................................................................................................................. 44
4.2.1. La Fachada ....................................................................................................................................44
5.
Implementacin................................................................................................... 46
5.1.
5.2.
Herramientas de desarrollo..................................................................................................... 46
Proceso de instalacin................................................................................................................. 47
5.3.
6.
Juego de pruebas............................................................................................................................ 47
Conclusiones......................................................................................................... 51
Uso de metodologa gil........................................................................................................................... 51
Ciclos de desarrollo cortos.....................................................................................................................51
Pruebas de unidad automatizadas .....................................................................................................51
Metodologa de tests y herramientas.............................................................................................. 52
7.
Bibliografa ........................................................................................................... 52
1. Introduccin
La aplicacin de metodologas y prcticas giles dentro de empresas dedicadas al
desarrollo de software, es en la actualidad una realidad que se viene acrecentando
en los ltimos aos alrededor del mundo.
Son muchas las personas y empresas dedicadas al desarrollo de software que se
enfrentan hoy por hoy con el dilema de ser o no ser giles. Bien sea porque sus
actuales metodologas de desarrollo no dan los resultados esperados o bien porque
desean incursionar en prcticas que estn de moda a lo largo y ancho de las
comunidades de desarrollo en todo el mundo, lo cierto es que el auge de las
metodologas giles es un tema que apasiona y hace reflexionar a todo aquel que se
encuentre inmerso dentro del proceso de desarrollo de software.
Este trabajo presenta un enfoque prctico para la eleccin y adecuacin de
metodologas giles de desarrollo de software a un proyecto real: El desarrollo de
un sistema de reservas para una agencia de viajes usando tecnologa J2EE.
1.1.
1.2.
cdigo corremos el riesgo de estropearlo. Por ello debemos utilizar las tecnicas de
herencia y composicin para aadir funcionalidad a nuestros programas.
1.3.
Enfoque metodolgico
Para este proyecto exploraremos cmo aplicar las principales prcticas de lo que
se conoce como desarrollo gil.
El enfoque tradicional de desarrollo de aplicaciones heredado de otras ramas de la
ingeniera, ha sido el de hacer un estudio exahustivo del problema, establecer un
plan y llevar a cabo la construccion. Es la metodologa conocida como desarrollo
en cascada, con las fases consecutivas de Analisis, Diseo, Codificacion, Pruebas e
Implementacin.
Pero este enfoque no siempre es ptimo para el desarrollo de software. La
programacin no es exactamente comparable a otras ramas de la ingeniera o a la
construccin.
El desarrollo de software, es un proceso puramente creativo, anlogo a lo que en la
construccin de una vivienda sera la elaboracin de los planos.
A diferencia de la ingeniera civil, en el desarrollo de software no existe un proceso
de construccin en el que se sigan unos planos de modo mecnico previamente
establecidos por el arquitecto o ingeniero. En cada fase hay que ser creativo y
tomar decisiones.
En realidad s existe un proceso anlogo al de la pura construccin, en el que no
hay que tomar decisiones y solo aplicar lo dictado por el arquitecto. Es el paso del
cdigo fuente al objeto, la compilacin. Pero su coste es despreciable frente al coste
del diseo. Justo lo contrario a lo que sucede con la ingeniera civil, donde el coste
del diseo es infinitamente menor que el de la construccin.
El objetivo de las metodologas de desarrollo gil de software es la organizacin de
un trabajo creativo, que suele ser bastante catico. Se intenta dar prioridad a la
6
1.3.2.1.
Pruebas Automatizadas
pruebas diferentes.
Con las pruebas de unidad podemos probar estos componentes individualmente, es decir
probaramos el primer control, para lo que escribiramos cuatro pruebas para sus cuatro
posibles valores de entrada. Haramos lo mismo con los 5 controles restantes con lo que
escribiramos 4 pruebas para cada uno, en total
4 + 4 + 4 + 4 + 4 + 4 = 4 * 6 = 24 pruebas para probar todos los controles frente a
las 46.656 pruebas que tendramos que hacer si solo hicisemos pruebas de
integracin.
1.3.2.1.1.
Pruebas de unidad
1.3.2.1.2.
Pruebas de integracin
Para las pruebas de unidad hemos usado HttpUnit y pruebas manuales. HttpUnit es un
cliente http hecho en java que podemos combinar con JUnit para hacer pruebas de
integracin contra el servidor http.
1.3.2.1.3.
Pruebas de rendimiento
Para ver la velocidad de las transacciones hemos usado clases sencillas con un
cronmetro software, para medir los rendimientos, ya que la velocidad era una
parte crtica del sistema.
1.3.2.2.
Documentacin.
1.4.
11
12
1.5.
Productos obtenidos
13
14
ConnectionPostgres
SQLUtil
TestUtils
Timer
15
connection.commit();
assertEquals(new Integer(1), sqlUtil.queryInteger("SELECT COUNT(*) FROM
RESERVA"));
connection.close();
}
16
17
1.1.1.1.
18
Ilustracin 5 Login
19
que habamos
20
21
Si se piden mas plazas de las que se ofrecen pero queda todava alguna plaza, el
sistema nos deja pedir una cantidad menor.
Si no queda ninguna plaza el sistema nos informa del hecho y no nos deja mas
opcin que volver a la pantalla inicial.
22
23
2. Especificacin y requerimientos
2.1.
Informacin inicial
Queremos crear un sistema reservas on-line para una agencia de viajes. El negocio
de una agencia de viajes es la venta de paquetes tursticos que consisten en una
combinacin de diferentes servicios (transporte, alojamiento, excursiones, guas,
etc.) en un solo producto.
El paquete turstico consta de un cdigo interno, un nombre, un precio por
persona, una descripcin, una presentacin ms o menos elaborada y un nmero
de plazas ofertadas.
El sistema de reservas debe ofrecer un catlogo de paquetes tursticos por el que
se pueda buscar por diferentes criterios, como fechas de salida, duracin del viaje,
precio, etc.
Cuando un cliente hace una reserva, el sistema debe actualizar el nmero de plazas
disponibles, restando las que el cliente ha reservado, evitando que se puedan
solicitar ms plazas de las existentes.
El sistema debe guardar con la reserva, el nombre del cliente, el paquete solicitado
y el nmero de plazas que quiere.
El sistema debe permitir la inclusin futura con de una interfaz con medios de
pago electrnico.
El sistema tiene que permitir la introduccin de paquetes tursticos en el catlogo,
su modificacin, consulta y borrado. La modificacin y el borrado solo se podrn
hacer si no se ha vendido ninguna reserva.
El sistema tiene que permitir el registro de los clientes donde introducirn
informacin sobre sus datos personales, tarjetas de crdito, etc. Tambin la
modificacin, consulta y borrado.
El sistema tiene que manejar de manera ptima las transacciones, minimizando
bloqueos y asegurando la consistencia.
2.2.
Glosario
24
2.3.
Oferta:
o Nombre
o Descripcin
o Fecha de Inicio
o Fecha de Fin
o Duracin
o Plazas Disponibles
o Plazas Totales
o Fecha lmite de compra
Reserva
o Numero de plazas reservadas
o Oferta
o Cliente
Cliente
o Nombre
o Apellidos
o Login
o Password
o Fecha de Alta
25
2.4.
2.5.
27
28
Usuario
Disparador:
El usuario ha seleccionado una de las ofertas existentes que tienen disponibilidad
de plaza en ese momento.
Precondicin:
El usuario est registrado.
Flujo principal:
1) El sistema presenta una pantalla con los datos de la oferta:
cdigo interno (no se mostrar) (no editable)
nombre (no editable)
descripcin (no editable)
fechaInicio (no editable)
fechaFin (no editable)
duracin (no editable)
nmero de plazas disponibles (no editable)
nmero de plazas deseadas (editable)
2) El usuario introduce el nmero de plazas deseado
3) El sistema registra la reserva y notifica al usuario el xito de la operacin.
Flujo alternativo:
1-2a) El usuario cancela la operacin
1) El sistema devuelve a la pantalla principal
2a) El nmero de plazas que solicita el usuario es 0 o nulo
1) El sistema informa del error y vuelve al punto 1 (con datos actualizados).
2b)El nmero de plazas que solicita el usuario es superior al nmero de plazas
disponibles
1) El sistema informa del error y vuelve al punto 1 (con datos actualizados).
Poscondicin:
El usuario tiene N reservas de la oferta O
Requisitos no funcionales:
29
Las transacciones deben ser rpidas y correctas., por lo que deben bloquear la
lectura de plazas para luego poder actualizarla, restando las plazas, pero el mnimo
tiempo posible para permitir que otras transacciones operen sobre el mismo
registro.
La transaccin tiene que ser segura, no puede ser falsificable alterando parmetros
de la peticin.
2.5.3. Login
Disparadores:
El usuario elige hacer una reserva y no esta registrado en el sistema.
El usuario elige la opcin de registrarse en el sistema.
Flujo principal:
1) El sistema muestra una pantalla con los campos de:
nombre de usuario
password
2) El usuario escribe su nombre y password.
3) El sistema comprueba que el usuario existe y su contrasea es correcta, por lo
que devuelve al usuario al punto donde se origin el evento, es decir pantalla de
inicio o a la reserva que estaba apunto de reservar.
Flujo alternativo:
1-2a) El usuario cancela la operacin.
1) El sistema devuelve al usuario al men principal
3a) El sistema detecta que el usuario no existe o que la contrasea es incorrecta.
1) El sistema notifica el error y devuelve al usuario al punto 1 con los datos
introducidos por el usuario.
Requisitos no funcionales:
En ningn caso debe intercambiarse entre el navegador y el servidor el nombre de
usuario y/o la contrasea una vez pasada la validacin, para evitar suplantacin de
identidad o robo de contrasea.
Temas pendientes:
Hacer que el proceso de autenticacin vaya encriptado con SSL (estimar el coste)
Hacer que el password de usuario vaya encriptado dentro de la base de datos
(estimar coste)
30
Alta de usuario
Disparadores:
Desde pantalla de login el usuario elige la opcin de darse de alta en el sistema.
Desde la pantalla de mantenimiento de cuenta de usuario, el usuario elige la opcin
de darse alta.
Flujo principal:
1) El sistema muestra una pantalla con los campos de (todos obligatorios):
Consulta de usuario
Precondicin:
El usuario se ha logado en el sistema previamente con lo que tiene visible la opcin
de mantenimiento de cuenta de usuario.
Flujo principal:
1) El usuario elige la opcin de mantenimiento de usuario
2) El sistema recupera los datos del usuario y muestra una pantalla con los campos
de:
nombre
apellidos
login
password
Flujo alternativo:
*a) El usuario cancela la operacin
1) El sistema devuelve a la pantalla de inicio
Puntos de extensin:
Borrar (desactivar) usuario.
Modificar usuario.
2.5.4.3.
Modificacin de usuario
Disparadores:
Desde la pantalla de mantenimiento de cuenta de usuario, el usuario elige la opcin
de modificar su cuenta.
Precondicin:
El usuario se ha logado en el sistema previamente con lo que tiene accesible la
opcin de mantenimiento de cuenta de usuario.
Flujo principal:
32
1) El sistema recupera los datos del usuario y muestra una pantalla con los
campos de:
nombre
apellidos
login
password
Borrado de usuario
Precondicin:
El usuario se ha logado en el sistema previamente con lo que tiene accesible la
opcin de mantenimiento de cuenta de usuario.
Flujo principal:
1) El usuario elige borrar o darse de baja
2 )El sistema pide confirmacin
33
3) El usuario acepta
4) El sistema escribe en fecha de baja el da de hoy, con lo que queda registrada la
baja. (baja lgica) y devuelve al usuario a la pantalla de inicial de la aplicacin.
Flujo alternativo:
1-3) El usuario cancela la operacin
1 El sistema vuelve a la pantalla de detalle de usuario.
Alta de oferta
Flujo principal:
1) El usuario elige la opcin de crear una nueva oferta.
2) El sistema muestra una pantalla con los campos:
34
1) El sistema informa de los errores y devuelve al punto 2 con los datos que
rellen el usuario.
2.5.5.2.
Consulta de oferta
Flujo principal:
1) El usuario elije la opcin de bsqueda de ofertas
2) El sistema muestra una pantalla con los criterios de seleccin de ofertas:
nombre (criterio: contiene palabra)
descripcin (criterio: contiene palabra)
fechaInicio (criterio: mayor o igual que)
fechaFin (criterio: menor o igual que)
3) El usuario elije uno o varios de los criterios de bsqueda y selecciona el filtro.
4) El sistema muestra una pantalla con los resultados de la bsqueda.
5) El usuario elige una de las ofertas.
6) El sistema muestra el detalle de la oferta.
Flujo alternativo:
*a) El usuario cancela en cualquier momento.
1) El sistema devuelve a la pantalla principal.
4a) El sistema detecta que no se ha seleccionado ningn criterio de bsqueda
1) El sistema informa del error y devuelve al punto 2
4b) El sistema detecta que alguno de los campos no contienen datos validos para la
bsqueda. Es decir las fechas no son fechas vlidas o el rango no es correcto.
1) El sistema informa del error y devuelve al punto 2
Requisitos no funcionales:
En el listado deben salir todas las ofertas pero deberamos evitar las lecturas
sucias, ver el nivel de aislamiento optimo de transacciones.
2.5.5.3. Modificacin y baja de oferta
Queda fuera del mbito del proyecto por ser demasiado complejo. El sistema
necesitara detectar si se ha hecho alguna reserva, si es as dependiendo del dato
que se quiera modificar, deber permitir o no la modificacin. Tambin debera
avisar a los usuarios y permitir que cancelasen la reserva, etc.
En cuanto a las transacciones, cuando menos, tendra que bloquear durante la
modificacin, la insercin de nuevos registros.
35
2.6.
3. Anlisis
3.1.
36
3.2.
Diagramas de estados
3.3.
Diagramas de actividades
37
38
3.3.3. Login
39
40
3.4.
Modelo de datos
41
4. Diseo tcnico
La aplicacin est basada en Struts que es una implementacin del patrn
arquitectnico MVC. Modelo Vista Controlador. Es un Framework antiguo ya, pero
sigue siendo vlido.
4.1.
A la arquitectura habitual de Struts, le hemos aadido unas clases que han simplificado
el desarrollo en gran medida. En estas clases hemos invertido mucho tiempo en pruebas
ya que segn nuestra experiencia es en la validacin de los datos del us uario, donde mas
suelen fallar las aplicaciones.
En nuestra aplicacin el mtodo validate del ActionForm se hace slo con mtodos de
la clase Validator.
En el Action, la conversin de los campos del ActionForm
exclusivamente con la clase Parser.
a objetos se hace
Clase: com.dblanch.utils.Validator
Responsabilidad: validar las entradas de los campos de los ActionForm, que son
siempre strings
Colaboraciones: Parser, ActionForm
Clase: com.dblanch.utils.Parser
Responsabilidad: convertir las cadenas de los ActionForm en objeto,s como por
ejemplo de un String a un Date
Colaboraciones: Validator. ActionForm, Action
42
43
4.2.
El modelo
4.2.1. La Fachada
Para acceder a sus funcionalidades, lo hacemos exclusivamente a travs de un
objeto Fachada, que es un objeto que permite ofrecer una interfaz unificada
sencilla y que delega todos sus mtodos en otros objetos.
En nuestra aplicacin, la fachada delega en los DAO y a los objetos de negocio.
Los Action de Struts, para acceder al modelo solo interactan con la fachada, nunca
invocan Objetos de negocio aisladamente.
Hemos mentido un poco, nuestra fachada no es puramente una fachada, hace algo
mas que delegar los mtodos, obtiene un objeto java.sql.Connnection y se los pasa
a los objetos en los que delega. Tambin se encarga de gestionar la transaccin y
cerrar la conexin una vez terminado con el mtodo.
Esto lo hace implementando otro Patrn que es el Template. El mtodo
java.sql.Connection getConnection() es abstracto y las clases hijas lo implementan
de diferente forma.
La forma de obtener la conexin a la base de datos en un contenedor J2EE es
distinta a la forma de hacerlo fuera. En un contenedor se localiza un DataSource
que provee un pool1 de conexiones registrado bajo un nombre2.
Fuera del contenedor se obtiene de la forma habitual.
La razn detrs de esta aparente complejidad es que esta arquitectura nos permite
poder cambiar el objeto de implementacin ModelFacade por otro que podra ser
un ModelFacadeMock, por ejemplo.
45
Los Mock objects son objetos que no implementan funcionalidad real y sirven solo
para pruebas.Los mtodos que devuelven datos del objeto Mock, devuelven
tambin objetos Mock. Esta estrategia se puede usar para desarrollar la parte web,
sin depender de unos datos de la base de datos o para poder trabajar en la parte
web, sin tener terminada la parte del modelo. As se puede trabajar en paralelo en
ambas partes.
Para cambiar de implementacin de ModelFacade, slo habra que cambiar el
Factory.
5. Implementacin
5.1.
Herramientas de desarrollo
46
5.2.
Proceso de instalacin
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Resource name="jdbc/postgres" auth="Container" type="javax.sql.DataSource"
driverClassName="org.postgresql.Driver"
url="jdbc:postgresql:tfc"
username="postgres" password="postgres" maxActive="20" maxIdle="10"
maxWait="-1" />
</Context>
5.3.
Juego de pruebas
Pruebas de rendimiento;
/reservasTest/src/com/dblanch/integracin/RendimientoEscrituraADisco.java
/reservasTest/src/com/dblanch/integracin/RendimientoTransacciones.java
/reservasTest/src/com/dblanch/integracin/TransaccionesMultithread.java
48
<testcase name="testParseInteger"
classname="com.dblanch.utils.ParserTest" time="0.001" />
</testsuite>
<testsuite name="com.dblanch.cliente.ClienteVOTest" time="0.004">
<testcase name="testToString"
classname="com.dblanch.cliente.ClienteVOTest" time="0.004" />
</testsuite>
<testsuite name="com.dblanch.cliente.ClienteDAOTest" time="0.083">
<testcase name="testAddDuplicate"
classname="com.dblanch.cliente.ClienteDAOTest" time="0.028" />
<testcase name="testAdd" classname="com.dblanch.cliente.ClienteDAOTest"
time="0.017" />
<testcase name="testFindClienteByLoginAndPassword"
classname="com.dblanch.cliente.ClienteDAOTest" time="0.038" />
</testsuite>
<testsuite name="All tests" time="0.495">
<testsuite name="com.dblanch.oferta.OfertaDAOTest" time="0.058">
<testcase name="testFindOfertas"
classname="com.dblanch.oferta.OfertaDAOTest" time="0.042" />
<testcase name="testFindOfertaByPk"
classname="com.dblanch.oferta.OfertaDAOTest" time="0.016" />
</testsuite>
<testsuite name="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.003">
<testcase name="testSetNombre"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.001" />
<testcase name="testSetDescripcion"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.0" />
<testcase name="testSetFechaInicio"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.0" />
<testcase name="testSetFechaFin"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.001" />
<testcase name="testSetPlazasDisponibles"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.0" />
<testcase name="testSetDuracion"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.0" />
<testcase name="testComposeSQL"
classname="com.dblanch.oferta.OfertaQueryBuilderTest" time="0.001" />
</testsuite>
<testsuite name="com.dblanch.reserva.ReservaCommandTest" time="0.283">
<testcase name="testReservaNormal"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.028" />
<testcase name="testReservaPlazasInsuficientes"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.027" />
<testcase name="testReservaNingunaPlaza"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.119" />
<testcase name="testUpdateOferta"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.109" />
</testsuite>
<testsuite
name="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.007">
<testcase name="testNingunCritierioDeBusqueda"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.005"
/>
<testcase name="testFechaInicio"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.0"
/>
<testcase name="testFechaFin"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.001"
/>
<testcase name="testPlazasDisponiblesNoValido"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.001"
/>
<testcase name="testDuracionNoValido"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.0"
/>
</testsuite>
<testsuite name="com.dblanch.utils.ValidatorTest" time="0.003">
<testcase name="testFechaValida"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
<testcase name="testRangoFechasCorrecto"
classname="com.dblanch.utils.ValidatorTest" time="0.001" />
<testcase name="testNumeroNatural"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
<testcase name="testValorNulo"
classname="com.dblanch.utils.ValidatorTest" time="0.002" />
<testcase name="testExceedsMaxSize"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
49
<testcase name="testNotReachMinSize"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
</testsuite>
<testsuite name="com.dblanch.utils.ParserTest" time="0.001">
<testcase name="testParseDate"
classname="com.dblanch.utils.ParserTest" time="0.001" />
<testcase name="testParseInteger"
classname="com.dblanch.utils.ParserTest" time="0.0" />
</testsuite>
<testsuite name="com.dblanch.frontend.SystemFacadeAbstractTest"
time="0.051">
<testcase name="testFindOfertas"
classname="com.dblanch.frontend.SystemFacadeAbstractTest" time="0.028" />
<testcase name="testAddClienteTest"
classname="com.dblanch.frontend.SystemFacadeAbstractTest" time="0.023" />
</testsuite>
<testsuite name="com.dblanch.reservasweb.reserva.ReservaFormTest"
time="0.001">
<testcase name="testPlazasDeseadasValido"
classname="com.dblanch.reservasweb.reserva.ReservaFormTest" time="0.001" />
</testsuite>
<testsuite name="com.dblanch.cliente.ClienteVOTest" time="0.001">
<testcase name="testToString"
classname="com.dblanch.cliente.ClienteVOTest" time="0.001" />
</testsuite>
<testsuite name="com.dblanch.cliente.ClienteDAOTest" time="0.087">
<testcase name="testAddDuplicate"
classname="com.dblanch.cliente.ClienteDAOTest" time="0.025" />
<testcase name="testAdd"
classname="com.dblanch.cliente.ClienteDAOTest" time="0.026" />
<testcase name="testFindClienteByLoginAndPassword"
classname="com.dblanch.cliente.ClienteDAOTest" time="0.036" />
</testsuite>
</testsuite>
<testsuite name="com.dblanch.reservasweb.cliente.ClienteParserTest" time="0.001">
<testcase name="testParse"
classname="com.dblanch.reservasweb.cliente.ClienteParserTest" time="0.001" />
</testsuite>
<testsuite name="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest"
time="0.003">
<testcase name="testNingunCritierioDeBusqueda"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.001"
/>
<testcase name="testFechaInicio"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.0"
/>
<testcase name="testFechaFin"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.001"
/>
<testcase name="testPlazasDisponiblesNoValido"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.001"
/>
<testcase name="testDuracionNoValido"
classname="com.dblanch.reservasweb.busquedaofertas.BusquedaOfertasFormTest" time="0.0"
/>
</testsuite>
<testsuite name="com.dblanch.reservasweb.reserva.ReservaFormTest" time="0.0">
<testcase name="testPlazasDeseadasValido"
classname="com.dblanch.reservasweb.reserva.ReservaFormTest" time="0.0" />
</testsuite>
<testsuite name="com.dblanch.reserva.ReservaCommandTest" time="0.104">
<testcase name="testReservaNormal"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.022" />
<testcase name="testReservaPlazasInsuficientes"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.022" />
<testcase name="testReservaNingunaPlaza"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.027" />
<testcase name="testUpdateOferta"
classname="com.dblanch.reserva.ReservaCommandTest" time="0.032" />
</testsuite>
<testsuite name="com.dblanch.utils.ValidatorTest" time="0.004">
<testcase name="testFechaValida"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
<testcase name="testRangoFechasCorrecto"
classname="com.dblanch.utils.ValidatorTest" time="0.001" />
<testcase name="testNumeroNatural"
classname="com.dblanch.utils.ValidatorTest" time="0.003" />
50
<testcase name="testValorNulo"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
<testcase name="testExceedsMaxSize"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
<testcase name="testNotReachMinSize"
classname="com.dblanch.utils.ValidatorTest" time="0.0" />
</testsuite>
<testsuite name="com.dblanch.oferta.OfertaVOTest" time="0.001">
<testcase name="testGetDuracion"
classname="com.dblanch.oferta.OfertaVOTest" time="0.001" />
</testsuite>
<testsuite name="com.dblanch.oferta.OfertaDAOTest" time="0.086">
<testcase name="testFindOfertas"
classname="com.dblanch.oferta.OfertaDAOTest" time="0.06" />
<testcase name="testFindOfertaByPk"
classname="com.dblanch.oferta.OfertaDAOTest" time="0.026" />
</testsuite>
</testrun>
6. Conclusiones
Uso de metodologa gil
No hemos podido aplicar una metodologa de desarrollo gil completamente,
porque nos faltaba la parte fundamental que es tener al cliente dentro del equipo
de desarrollo, para verificar el producto y proponer cambios. Pero hemos usado
otras prcticas que si podemos evaluar, como los ciclos de desarrollo cortos y las
pruebas automatizadas.
7. Bibliografa
JUnit Recipes , JBRainsberr Editorial Manning
Head First Design Patterns, Eric Freeman &Elisabeth Freeman Editorial OReilly
Piensa en Java, Bruce Eckel Editorial Prentice Hall
Core Java Volume II Advanced Features, Cay S. Horstmann Editorial PH PTR
Struts KICK START, James Turner and Kevin Bedell
52