Practica 1 del segundo año del Máster 'Diseño y Desarrollo de Aplicaciones Web, con Java y JSP'

1. Practica 1Practica 1
Biblioteca MockitoBiblioteca Mockito
UNED 2016UNED 2016
EquipoEquipo
Alberto GómezAlberto Gómez
Ignacio CerezoIgnacio Cerezo
Federico GrazianoFederico Graziano
Ismael MartínIsmael Martín
Carlos LarrondoCarlos Larrondo
Carlos AlmarchaCarlos Almarcha
José BarbaJosé Barba
DocenteDocente
Carlos Luis SánchezCarlos Luis Sánchez

2. Gestión, requisitos y objetivosGestión, requisitos y objetivos
Análisis:
Punto de partida: De qué partimos?
Especificacion de requisitos: Definición exhaustiva del QUÉ
Metodología de trabajo:
Roles: Quién es quién?
Herramientas utilizadas:
Redmine -> Coordinación y gestión de tareas
SVN -> gestión de código fuente.
Reparto de Tareas
Detalle tecnico
Requisitos Globales: Afectan a toda la aplicación.
Requisitos asociados a Libros
Requisitos asociados a Socios
Requisitos asociados a Préstamos

3. AnálisisAnálisis
De dónde partimos?
http://62.204.199.127/JAVA_UNED/bea/browser/biblioteca_Mockito
revision 131
Requisitos
Globales:
[GBL-1]Soporte para conexion a Oracle
[GBL-2]Creación de menú CRUD en menú popup contextual
[GBL-3]Internacionalización de la aplicación
[GBL-4]Cierre ordenado de la aplicación
[GBL-5]Pruebas unitarias
[GBL-6]Creación de un HOW TO JUnit/Mockito
[GBL-7]Presentacion SlideShare
Socios
[SCS-1]Inclusión de una ficha para la modificación de SOCIOS
Prestamos
[PRT-1]Inclusión de una ficha para la inserción de PRESTAMOS
[PRT-2]Inclusión de una ficha para la modificación de PRESTAMOS
[PRT-3]Socios y libros ORDENADOS en combos
Libros
[LBR-1]Inclusión de una ficha para la inserción de PRESTAMOS
[LBR-2]Inclusión de una ficha para la modificación de PRESTAMOS

4. Metodología de trabajoMetodología de trabajo
Roles
Equipo
Carlos Almarcha - en adelante 'calmarcha‘
Carlos Larrondo - en adelante 'clarrondo‘
Federico Graziano - en adelante 'fgraziano‘
Ismael Martín - en adelante 'imartin‘
Ignacio Cerezo - en adelante 'icerezo‘
Responsable Producto
Carlos Luis Sánchez
Scrum Master
José Barba - en adelante 'jbarba‘
Herramientas
Redmain en www.hostedredmine.org para Coordinacion y
asignación de tareas
SVN para gestion de código fuente.

5. Metodología de trabajoMetodología de trabajo-Detalle-Detalle
Uso Redmine
Cada práctica un proyecto en RedMine.
Cada práctica tiene tareas, representadas como 'Issues‘
Cada tarea tiene un resposable asignado
Las tareas las asigna el SM.
Distribucion de tiempo efectivo del equipo
Lunes: Reunion con Responsable producto
Martes-Miercoles: Determinación y asignación de tareas
Miercoles: Reunion SM<->Equipo para aclarar dudas sobre tareas
asignadas
Jueves-Domingo: Tiempo efectivo de trabajo para el equipo
Reuniones
Lunes: Resp producto
Miercoles: SM y Equipo
En cualquier momento:A demanda del equipo.

6. Metodología de trabajo - Uso de SVNMetodología de trabajo - Uso de SVN
Repositorio SVN sobre ArchLinux versión 1.9.0-1
Estructura establecida:
<root>/practica1-BibliotecaGUI
|- branches
|- agomez
|- calmarcha
|- clarrondo
|- fgraziano
|- icerezo
|- imartin
|- jbarba
|- dist
|- trunk
branches:
ramas de desarrollo, una por miembro
cada tarea sera una copia del trunk en el branch del responsable
dist
espacio para entregas a jefe de producto
Trunk
codigo fuente para la práctica

7. Metodología de trabajo - Uso de SVNMetodología de trabajo - Uso de SVN
Ciclo de vida de una tarea sobre repositorio
Se crea tarea en RedMine, con responsable
Se crea rama desde 'trunk' contra
'branches/<responsable>/<id_tarea>‘
La rama creada evoluciona, y la tarea se resuelve
Se realiza 'merge' de la rama contra trunk
Beneficios
Premite paralalelizacion de tareas
Cada tarea tiene su espacio privado de trabajo
Perjuicios
El SM debe coordinar los cambios y hacer los 'merge's contra el trunk
CUIDADO CON PERDER CAMBIOS ENTRE VERSIONES!

8. Acceso a BBDD OracleAcceso a BBDD Oracle
Especificación de requisito
Posibilitar la conexión de la aplicación a bases de datos Oracle.
Revisión y modificación de clases con acceso a datos.
Estrategia de solución usada
Modificación de la lógica de conexión para permitir el uso de BD
Oracle. Esto se podrá realizar mediante parametrización.
PROBLEMA: El modo de generación de identificadores es diferente
en MySql (autogenerado) y Oracle (uso de objetos SECUENCIA).
SOLUCION:
Modificación de clases que implementan DAO, mediante
extensión de las existentes, permitiendo de esta manera la
inserción de registros.
Creación de un método estático que obtenga el valor de una
secuencia.

9. Modificaciones realizadas sobre elModificaciones realizadas sobre el
código existente (I)código existente (I)
Clase ConnectionManager (MODIFICACIÓN)
Selección de método de conexión mediante paramento en
fichero de configuración.
Ahora se permite MySQL u Oracle (SID o Service Name).
Clase CustomersManagementController (MODIFICACIÓN)
Instanciación de ICustomersDAO dependiendo del tipo
de conexión.
Clase BooksManagementController (MODIFICACIÓN)
Instanciación de IBooksDAO dependiendo del tipo de
conexión.

10. Modificaciones realizadas sobre elModificaciones realizadas sobre el
código existente (II)código existente (II)
Clase CustomersDAOImplOracle (CREACIÓN)
Sobre escritura del método insert para asignar el
identificador del socio mediante consulta del valor de una
secuencia.
Clase BooksDAOImplOracle (CREACIÓN)
Sobre escritura del método insert para asignar el
identificador del libro mediante consulta del valor de una
secuencia.
Clase UtilsOracle (CREACIÓN)
Incluye un método estático que devuelve el valor
(NEXTVAL) de una secuencia, a partir del nombre de la
misma.

11. Menú CRUD contextualMenú CRUD contextual
Especificación de requisito
Inclusión de un menú contextual para la realización de la
operaciones CRUD en el componente socios. Éstas serán:
Añadir
Editar
Eliminar
Estrategia de solución usada
Reutilización del código del controlador, realizando las
llamadas de la misma manera que lo hacen los elementos
de la botonera.
Creación de los elementos necesarios y asociación con los
métodos anteriormente comentados

12. Modificaciones realizadas sobre elModificaciones realizadas sobre el
código existentecódigo existente
Clase CustomerManagementView (MODIFICACIÓN)
Creación de elemento JPopMenu.
Creación de ítems que conforman el menú.
Asociación de listeners a estos ítems.
Clase CustomerManagementController (MODIFICACIÓN)
Modificación de método de gestión de listeners

13. Aspecto del menú contextual trasAspecto del menú contextual tras
implementación del cambioimplementación del cambio

14. Requisitos asociados a LibrosRequisitos asociados a Libros
Objetivo
Adecuar el proyecto Biblioteca-Mockito al MVC. En la
parte de libros se pide asemejar toda la funcionalidad en
una sola ficha respetando el modelo MVC.
Resultado
Para cumplir el objetivo, previamente se ha procedido a
entender la funcionalidad existente, hemos adquirido el
conocimiento de MVC para adecuar la practica a la
funcionalidad requerida.
Una vez adquirida los conocimientos hemos eliminado el
paquete “es.csc.biblioteca.books.gui” la vista y el
controlador de la parte Detalle asumiendo dicha
funcionalidad en la pantalla principal.

15. Lógica ModificadaLógica Modificada
Eliminación de Clases
BookDetailsController.java.
BookDetailsView.java.
Modificación de Clases
BooksManagementController. Adquiere la funcionalidad
de la clase eliminada BookDetailsController.java
actionPerformed
getBook
checkMandatoryFields
doClose
BooksManagementView. Adquieres la funcionalidad/métodos de
la clase eliminada BookDetailsView.java
SetOkListener SetBook getBook hideWarnin
SetCancelListener showWarningTitle showWarningTopic setEstado

16. Dificultades EncontradasDificultades Encontradas
Dificultades a nivel conceptual
Funcionamiento del setLayout
Funcionamiento de biblioteca Mockito para pruebas
integradas.
Otras dificultades
Problemas al cargar los datos del detalle cuando teníamos
seleccionado un libro en el multiregistro.

17. FUNCIONALIDADES PRESTAMOSFUNCIONALIDADES PRESTAMOS
BIBLIOTECA MOCKITOBIBLIOTECA MOCKITO
ESQUEMA BASE
REQUISITO. Detalle el requisito (objetivo a cumplir).
DESARROLLO. Breve descripción del desarrollo.
RESOLUCIÓN. Problemas encontrados y su resolución.

18. MODELO MVC PRESTAMOS
REQUISITO: Mantener modelo MVC de desarrollo de la aplicación del que se parte
previamente: Biblioteca_mockito.
DESARROLLO. La mayor parte del desarrollo previo es válida. La separación impuesta
por el patrón MVC está claramente definida. En la parte de Préstamos no estaba
desarrollada la ventana externa a eliminar pero si que necesitábamos incorporar
código para cubrir funcionalidad.
RESOLUCIÓN. Las clases que eran suceptibles de modificar eran las clases del
paquete es.csc.biblioteca.loans.gui: LoansManagementView y
LoansManagementController y las clases para manejar los modelos
CustomersDAOImpl y BooksDAOImpl.
Decidimos modificar exclusivamente las clases del paquete es.csc.biblioteca.loans.gui
para no interferir en el trabajo de los demás. La consecuencia será que tendremos un
par de métodos en la clase controladora "LoansManagementController" que bien
podrían estar en las clases de los paquetes de modelo.

19. ACCESO AL MODELO COMPLETO DE LAACCESO AL MODELO COMPLETO DE LA
APLICACIÓNAPLICACIÓN
REQUISITO: Necesidad de acceso al modelo completo de la aplicación para poder
cumplir con los requisitos funcionales y de desarrollo.
DESARROLLO. La funcionalidad de Préstamos, a diferencia de la funcionalidad de
Socios o de Libros, necesita el acceso completo al modelo. No solo se necesita
acceder al modelo de Préstamos, sino también al modelo de Socios y Libros puesto
que se debe mostrar al usuario información sobre estos modelos a través de los
componentes JComboBox.
RESOLUCIÓN.Para acceder al modelo de préstamos inicialmente se importaron las
clases:
import es.csc.biblioteca.loans.dao.ILoansDAO;
import es.csc.biblioteca.loans.dao.LoansDAOException;
import es.csc.biblioteca.loans.dao.LoansDAOImpl;
Para acceder al resto de modelos se incluyó las siguientes importaciones:
import es.csc.biblioteca.customers.dao.*;
import es.csc.biblioteca.books.dao.*;
import es.csc.biblioteca.loans.dao.LoanDTO;

20. ELIMINACIÓNVENTANA EXTERNA POR FICHA
INTERNA
REQUISITO: Eliminar ventana externa de administración de prestamos. Codigo previo del que se parte
en Biblioteca_mockito.
DESARROLLO. Incorporación de 8 elementos visuales swing dentro de la ventana de Préstamos
objeto de la clase LoansManagemenView. Conformación de la botonera:Añadir, Editar y Eliminar.
Aceptar y Cancelar. Nuevas funcionalidades implementada en LoansManagementController.
RESOLUCIÓN. Se mantiene el modelo MVC. Mientras la ventana de Préstamos esté abierta se
mantendrá la conexión con los modelos. Esto se realizó dentro de la clase controladora ampliando
atributos y modificando su método constructor.

21. CONTROL DE LA FUNCIONALIDAD DESDE LACONTROL DE LA FUNCIONALIDAD DESDE LA
BOTONERABOTONERA

REQUISITO: Solo botón "Eliminar" funciona. Seleccionando sobre la tabla de
Préstamos aquellos a ser borrado de base de datos. El resto de botones están velados
puesto que no tienen funcionalidad. Habilitar.

DESARROLLO. Del resto de botones daremos funcionalidad a "Añadir" y "Editar".
Para ello generaremos sus eventos en la clase "LoansManagementView" y
atendiendolos desde la clase "LoansManagementController".

RESOLUCIÓN. Necesitamos dos nuevos botones para un correcto manejo de la
funcionalidad: "Aceptar" y "Cancelar".
Para conocer si al Aceptar se debe añadir o corregir la edición de un préstamo,
utilizaremos una variable de control "ultimaaccion". Esto se hará en la clase de
Control de Préstamos LoansManagementController.

22. CONTROL DE ERRORES DE ESCRITURA ENCONTROL DE ERRORES DE ESCRITURA EN
LOS COMPONENTES DE LA FICHALOS COMPONENTES DE LA FICHA
REQUISITO: La aplicación no debe aceptar que el usuario introduzca valores en
blanco. Los errores que pueden producirse a priori son:

El usuario introduce fechas en blanco.

El usuario edita sin seleccionar ninguna columna.
DESARROLLO. Para cumplir con este requisito generaremos métodos en la clase
vista "LoansManagementView" que comprueben que el valor de los componentes es
correcto y que hay alguna fila seleccionada de la tabla.
Estos métodos serán llamados desde la clase "LoansManagementController" para
utilizarlos en la lógica de control de la actualización de Préstamos.
RESOLUCIÓN.

Error: Ordenación alfabética de los combos. Sol: incorporar el método estático
Collections.sort().

Error: Fechas de la ficha en blanco. Sol: métodos: public boolean isFechaValida()--
>(fecha inicio y fecha fin), public boolean isSelectedRow()-->seleccione un registro de
tipo prestamo.

23. POPUP PRESTAMOS BOTON DERECHOPOPUP PRESTAMOS BOTON DERECHO
DEL MOUSEDEL MOUSE

REQUISITO. Basándonos en el desarrollo previo de esta funcionalidad sobre clientes
(Costumers) e indicando el código modificado por nuestro Scrum Máster
implementar estas modificaciones adecuándolas a las clases y métodos definidas en
Loans.

DESARROLLO. Clases modificadas:

LoansManagementController.java

LoansManagementView..java

LoansManagementView..form

RESOLUCIÓN. La dificultad surgió a la hora de editar el codigo “protegido” de la
clase LoansManagementView.java y más concretamente en el método private void
initComponents(). No se encontró la fórmula que dispone Netbeans para poder
modificar ese código que genera automáticamente el IDE al diseñar el formulario.
Para poder editarlo se utilizó otro entorno de progración; en nuestro caso
DreamWeaver. Se modificó y tras volver abrir el fichero desde Netbeans, se confirma
que este código vuelve a ser “protegido” y no permite su edición desde este IDE.

24. GENERACIÓN DE PRUEBAS UNITARIASGENERACIÓN DE PRUEBAS UNITARIAS
PRESTAMOSPRESTAMOS
REQUISITO. Para las pruebas unitarias nos basamos en replicar las clases generadas para
las otras funcionalides de Socios y Libros. Se generó una clase para probar métodos de la
clase modelo "LoansDAOTest" y otra clase para probar la vista "LoansTableModel".
DESARROLLO. Las pruebas se soportan sobre las librerías JUnit y Mockito. Las pruebas
sobre la clase vista "LoansTableModel" se realizan con Mockito para evitar utilizar el
repositorio original del desarrollo que es MySQL. Mediante la librería hsqldb se genera una
base de datos en memoria simulando el entorno de Producción.
RESOLUCIÓN. La dificultad surgió a la hora adecuar el método testUpdate() de la clase
"LoansDAOTest". Estas pruebas unitarias se basan en Junit.
Error en la sentecia: LoanDTO expResult = instance.findByPrimaryKey(idPrestamo);
Detalle error: Detalle:PrestamoDTO{idPrestamo=13, idSocio=CustomerDTO{idSocio=1, dni=null,
nombre=Fernandez Najera, apellidos=Luis adfd , direccion=null, fechaAlta=null},
idLibro=LibroDTO{idLibro=1, nombre=Informatica sdaf, autor=null, tema=null}, fechaInicio=2000-01-01,
fechaFin=2015-11-21}
Sol: por determinar.

25. ERRORES DETECTADOS SCRUM MASTERERRORES DETECTADOS SCRUM MASTER

ERROR: Edición de prestamo sin fecha fin.
DETALLE DEL ERROR. Consola:
run:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at
es.csc.biblioteca.loans.gui.LoansManagementView.setEditFicha(LoansManagementView.java:461)
At
es.csc.biblioteca.loans.gui.LoansManagementController.editLoan(LoansManagementController.jav
a:227) etc...
SOLUCIÓN. No se considera q la fecha fin puede ser nula,está en este método:
public void setEditFicha(){
java.sql.Date fecha = (java.sql.Date)this.tblLoans.getValueAt(this.tblLoans.getSelectedRow(),4);
long longfecha = fecha.getTime();
setFechaInicio(new Date(longfecha));
fecha = (java.sql.Date)this.tblLoans.getValueAt(this.tblLoans.getSelectedRow(),5);
longfecha = fecha.getTime(); <-- AQUI ESTA EL ERROR
SOL: java.sql.Date fechaFin=(fecha == null ? fecha : new java.sql.Date(fecha.getTime()) );
setFechaFin(new Date(longfecha));
}